- Boost - lists.boost.org

RE: [boost] should boost::ref forward some operators?
by Powell, Gary 03 Feb '04

03 Feb '04

-------------------------------------------- I ran into the following problem. I have an algorithm which looks like: template<typename in_t, typename out_t> void Alg (in_t in, in_t inend, out_t out) { for (; in != inend; in++, out++) do_something() } Now if I want to call this algorithm more than once, it would be convenient to pass out by ref, so it would be incremented: Alg (v.begin(), v.end(), boost::ref (out)) that is, pass a reference to some kind of output iterator this fails, because boost::ref doesn't have operator++ defined for reference_wrapper. My question is, should boost::ref forward operators like ++ so that this would work? ---------------------------------------------- Gary Replied: I think you need a different tool, either FC++ or Lambda. "ref()" is just a simple wrapper to make something act like a reference. What you need is the whole operator set and Lambda and FC++ have those. Alg(v.begin(), v.end(), boost::lambda::var(out) ); Should work as you want. Yours, -Gary-

1 0

[filesystem] file_size() added
by Beman Dawes 03 Feb '04

03 Feb '04

I've added a file_size() function to the CVS HEAD. It has been tested only on Windows. It hasn't even been compiled on other systems. Testing is a bit difficult. The regular operations_test has been updated to cover several cases, but it would place a burden on testers to test the cases of file sizes requiring 32-bit and greater than 32-bit representations. In other words: * File sizes between 2,147,483,648 and 4,294,967,295. * File sizes greater than 4,294,967,295. boost-root/libs/filesystem/example now contains a program file_size.cpp and a simple Jamfile to build it. Of course it can also be build with your favorite make tool or IDE. When invoked from the command line with a (native) file path, it will display the size of the file in bytes. To know if the value is correct, you have to look at the file size with some system specific tool such as "dir", "ls", or a graphical file explorer. It works with large files on Windows, using Borland 0x0564, CodeWarrior 8.3, GCC 3.3.1 cygming special, Intel 8.0, Microsoft 7.0 and 7.1. It fails to compile on VC++6.0 because of limited 64-bit support. I'd appreciate hearing test results on other systems, particularly a variety of POSIX systems. If it doesn't work for large files on your system, suggestions to get it working will be much appreciated. Thanks, --Beman

1 0

Borland c++6 is compatible with random lib
by Narendran 03 Feb '04

03 Feb '04

Sir, I tried random number generation using boost random. I used uniform_int for my random generation. When I tried with the Borland c++ 6.0 personal it worked correctly. Again same code I tried to compile in Borland c++ 6.0 professional it is showing the error as follows: " [C++ Error] uniform_int.hpp(210): E2404 Dependent type qualifier 'boost::is_float<long>' has no member type named 'value' " Will you please give suggestion in this error. Thanks & Regards, Narendran.

2 1

1.31.0 closed for changes without permission
by Beman Dawes 03 Feb '04

03 Feb '04

Please make no more changes to the RC_1_31_0 branch without the release manager's permission. The one exception is removal of is_abstract code. We need to be totally stable so that the regression tests can cycle one last time. --Beman PS: For the next release, we need to define written "release discipline". What kind of changes are allowed at various points, such as after branch, after release candidates start, etc.

7 21

shared_pointer for C-allocated object?
by Neal D. Becker 03 Feb '04

03 Feb '04

I have some legacy C code that returns a pointer: fftw_plan fftw_create_plan(int n, fftw_direction dir, int flags); where fftw_plan is a pointer. Can I use shared_pointer to wrap it? I guess the issue is that eventually delete will be called on this pointer, but it wasn't allocated with new. Is this a problem?

6 11

Re: [boost] Re: [filesystem] size() on directory?
by Beman Dawes 03 Feb '04

03 Feb '04

At 04:00 AM 2/3/2004, Christoph Ludwig wrote: >I don't know about other filesystems, but in the examples above it >makes perfectly sense to ask for the size of a directory (rather than >the sum of the size of its content). It isn't available on other systems. Windows reports 0, for example. --Beman

1 0

Re: class static constants, mpl, and linker problems
by David Abrahams 03 Feb '04

03 Feb '04

Daniel Krügler <dsp(a)bdal.de> writes: > - Assumption one: Boost does not provide the definitions of > potential static constants hidden by the BOOST_STATIC_CONSTANT > definition (I used only the headers of the library, so my potential > testing bug would be that I had to include the corresponding > translation units of boost providing the constant's definitions, > but sorry - I did not find them!). In general BOOST_STATIC_CONSTANT is used within templates, so the definition of a corresponding member may be given in the header file: template <int N> struct int_ { BOOST_STATIC_CONSTANT(int, value = N); }; #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION template <int N> int const int_<N>::value; #endif > As I said: If this assumption is false, please blame me straight > for incomplete testing and for trying to spread bad rumors on this > (really!) great library. It's probably not false in most cases. > - Assumption two: Even if Boost does provide these definitions, > there may occur problems due to the VC7.1 flags /Za and /Ze (aka > disabling and enabling language extensions), which I will explain > in the following. The same point applies as to assumptions one, if > I did incomplete testing or testing with rather old boost libraries. > > The nasty thing concerning the /Ze flag is that it effectively does > not "extend" the language in every case. A small testing case is the > following program: > > a.h: ------------------------- > #ifndef A_H_INC > #define A_H_INC > struct A > { > static const int val = 42; // Declaration of a static member variable > }; > #endif > ------------------------- > > a.cpp -------------------- > #include "a.h" > const int A::val; // Definition might be needed, if the program accesses > // the adress of A::val > ------------------------- > > main.cpp -------------------- > #include "a.h" > int main() > { > } > ------------------------- > > Although this is a C++ Standard compliant program, it will not > successfully link with the /Ze flag enabled, which is to my opion a > real compiler bug (which I already posted to m.p.v.language, but got > no reasonable response yet). The obtained error message is: > > error LNK2005: "private: static int const A::val" (?val@A@@0HB) already > defined in a.obj > error LNK2005: "private: static int const A::val" (?val@A@@0HB) already > defined in main.obj Looks like a bug to me. > Question: Is this special deficiency of the VC7.1 compiler taken > account in the current boost library? I doubt it. How would we do that? > I think, it is impossible to demand, that users are enforced to use > either only /Ze or only /Za, because each of these choices has some > considerable drawbacks (at least on Windows systems...) Well, it seems to me that we can only respond to actual problems. Do you have an actual case of using a Boost library where these issues cause you trouble? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 9

[filesystem] On POSIX, any reliable way to find file size?
by Beman Dawes 02 Feb '04

02 Feb '04

There have been requests for a Boost.Filesystem function which returns file size. But I don't want to provide such a function if it will be unreliable. On POSIX compliant 32-bit systems, is there any reliable way to find the size of a file? It looks to me as if stat::st_size's type of off_t isn't large enough on 32-bit systems to cope with large file sizes. Am I wrong, or missing something? How big is the largest possible file on, say, Linux? Isn't it larger than the 2 gigs a 32-bit signed integer can represent? --Beman

5 10

1.31.0 Win32 Graph/graph failures?
by Beman Dawes 02 Feb '04

02 Feb '04

Damn! Win32 Graph/graph has been failing for Intel and Microsoft since sometime Friday! That's a showstopper. Quick response would be greatly appreciated. --Beman The VC++7.1 error message begins: D:\boost-snapshot\boost\graph\detail\adjacency_list.hpp(1325) : error C2440: 'initializing' : cannot convert from 'std::_Tree<_Traits>::const_iterator' to 'std::_Tree<_Traits>::iterator' with [ _Traits=std::_Tset_traits<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge,std::less<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge>,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,! boost: : no_property,boost::listS>::config::StoredEdge>,false> ] and [ _Traits=std::_Tset_traits<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge,std::less<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,boost::no_property,boost::listS>::config::StoredEdge>,std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>>,boost::setS,boost::setS,boost::undirectedS,boost::property<vertex_id_t,size_t>,boost::property<edge_id_t,size_t>,! boost: : no_property,boost::listS>::config::StoredEdge>,false> ] No constructor could take the source type, or constructor overload resolution was ambiguous

3 5

[filesystem] adding path equality and path equivalence
by Beman Dawes 02 Feb '04

02 Feb '04

Equality -------- The path relational operators will be defined purely in terms of string comparison between the textual representation of the two paths. There are two ways to do this: (1) string comparison using std::string relational operators or (2) string comparison using std::lexicographical_compare. Given two paths, "foo.bar" and "foo/bar", (1) will order them: foo.bar foo/bar While (2) will order them: foo/bar foo.bar The primary use case I know of for operator<() is default ordering for paths used as keys in associative containers. I can't see that either approach is superior for this use, so unless someone comes up with a compelling argument, (1) will be used. Equivalence ----------- Two paths will be considered equivalent if they resolve to the same physical directory or file. Question 1: What is a use case that requires this function? Verifying that source and target files are different before some modifying operation is the only one I've come up with. I guess that is sufficient to justify adding the function. Question 2: What if neither exist? Only one exists? My initial thought is that these are likely to be errors, so treat them as such. It could be argued that if either or both don't exist, they can't be equivalent, so return false. Question 3: The implementation on Windows (see below) leaves a small hole in that duplicated media (such as two CD's) mounted on devices with the same device id on two different networked machines would be reported as equivalent. POSIX requires that such networked devices have different device id's, avoiding the problem. Is the fact that Windows and POSIX implementations would perform slightly differently on this corner case a showstopper? I think not. Windows logic for path equivalent: same device id AND same media volume serial number AND same physical location on disk AND same creation time. This works even in degenerate cases like camera formatted FAT flash memory cards or floppy disks with volume serial numbers incorrectly initialized to 0. POSIX logic: same device id AND same physical location on disk AND same modification time. The modification time is in theory redundant, but is an added protection in case the device id on networked devices failed to meet the POSIX specs. --Beman

6 16