- Boost - lists.boost.org

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

value_initialized, deep const, and template instantiation
by Jim Apple 02 Feb '04

02 Feb '04

value_initialized has non-deep (shallow?) const semantics. const value_initialized<T> is supposed to be const. Unfortunately, due to compiler errors in VC++ and Borland, it has operator T &() const instead of operator T&() operator const T&() const which breaks const-correctness in a big way. I'd like for there to be a config macro that identifies this error. I would make one, as well as a test for it, myself, but I only have access to icc and gcc on linux, both of which pass the test, so it's hard trying to identify the extent of the overloading selection failure. After creating this macro, we could use it to make a const correct value_initialized class for users with more advanced compilers. For those compilers, I think there would be value to adding operator-> for the invocation of member functions, like boost::optional. As an alternative, deep-copy would break const expectations in generic functions that take a const T &, but it would preserve it elsewhere, so it may be worth some more thought. Finally, I have come up with a similar class (which I wrote with deep const sematics, although I am open to argument about shallow const) for solving the following problem: ---------------------------------------------------------------------- #include <iostream> template<typename T> struct wrap { static const T joe; }; template<typename T> const T wrap<T>::joe; struct call_out { int num; call_out() : num(77) {} }; template<typename T> struct check_call { check_call() { std::cout << wrap<T>::joe.num << std::endl; } }; check_call<call_out> x; int main(){} ----------------------------------------------------------------------- This outputs 0, not 77, on gcc 3.3.2, intel 8, and vc6. I don't know if that's correct, 14.7.1/1 says: "... in particular, the initialization (and any associated side effects) of a static data member does not occur unless the static data member is itself used in a way that requires the definition of the static data member to exist." If this is std-conforming behavior, or not, i have a workaround that allows: ------------------------------------------------------------------------ #include <iostream> #include "can_init.hpp" template<typename T> struct wrap { static can_init<const T> joe; }; template<typename T> can_init<const T> wrap<T>::joe; struct call_out { int num; call_out() : num(77) {} }; template<typename T> struct check_call { check_call() { wrap<T>::joe.ensure_init(); std::cout << wrap<T>::joe->num << std::endl; } }; check_call<call_out> x; int main(){} ----------------------------------------------------------------------- which obviously uses deep const. Is there any interest in including this in boost/utility/? Should it have shallow or deep const semantics? Jim

2 5

Output Formatters [update]
by Reece Dunn 02 Feb '04

02 Feb '04

There are now Jamfiles for the examples and test facility :) that has been tested on Boost.Build V2. I am currently working on developing a regression test facility that has been posted to the sandbox CVS (this is still experimental, but is quite stable). Feedback? When you run one of the test programs, they will produce a results.xml file, or add to it if the file already exists. To work as intended, the programs need to be moved to a directory that contains the view.xsl file then run seperately for each compiler/library configuration you are testing. I am looking at how to do this within the Jamfile :). Aside from that, I have been working on bugs and completing the read/input facilities. I have fixed it now so that sequential, set and associative containers are read properly. The only defect remaining (thus far) is reading string types: The string handling code has been dropped from basic_object as this intefered with wrapped_object, causing the serialization example to fail. I am currently working on getting strings properly supported and will upload it when it is working. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

compile-time array count
by Gennaro Prota 02 Feb '04

02 Feb '04

Having a look to some old list messages I've seen there has been some discussion about discovering the number of elements of an array in compile-time. Sorry if I have simply misunderstood something here (I'm rapidly catching up with old threads), but isn't this enough? http://article.gmane.org/gmane.comp.lib.boost.devel/3216 That's for expressions, of course, not type-ids. Genny.

4 8

Re: [boost] Re: Boost Digest, Vol 622, Issue 5
by John Maddock 02 Feb '04

02 Feb '04

> How about using Boost.Thread's call_once function? I realize it requires > extra code, but something along these lines seems like it should both > avoid too much locking and still work: > Aha, good thinking, yes that's a good idea. John.

2 1