- Boost - lists.boost.org

[smart_ptr] sp_deleter_wrapper
by Daniel Frey 28 Apr '08

28 Apr '08

Here's the next patch, this time optimizing sp_deleter_wrapper. It replaces the shared_ptr<void> by shared_count, saving the implicitly stored void*. It also removes _internal_get_deleter and makes enable_shared_from_this use basic_get_deleter to take advantage of the workarounds it provides. OK to commit? BTW: One could also remove _internal_less and use: template<class T, class U> inline bool operator<(shared_ptr<T> const & a, shared_ptr<U> const & b) { return a.get_shared_count() < b.get_shared_count(); } Regards, Daniel

2 3

[1.35.1] Plans for 1.35.1?
by JOAQUIN M. LOPEZ MUÑOZ 27 Apr '08

27 Apr '08

Hello, Are there any plans to release a 1.35.1 version? If so, any tentative schedule and guidelines for what changes are acceptable to include into the libs? Thank you, Joaquín M López Muñoz Teléfónica, Investigación y Desarrollo

1 0

[mirror] change in the directory structure
by Matus Chochlik 27 Apr '08

27 Apr '08

Cheers, I've made some changes in the directory structure under 'mirror/libs' in the sandbox. This invalidated the links that I've pasted previously. Sorry for the inconvenience. The samples can be now found at: http://svn.boost.org/svn/boost/sandbox/mirror/libs/mirror/example/ I also added a Jamfile to build the examples. You'll need a Jamroot though. In case you don't have any, there is a sample provided. The current version adds the meta_type for boost::tuple and an example showing it in action: https://svn.boost.org/svn/boost/sandbox/mirror/libs/mirror/example/special/… Best regards, --matus

1 0

[optional] problems with swap()
by Thorsten Ottosen 27 Apr '08

27 Apr '08

Hi Fernando, I have some comments on the way optional<T>::swap() is implemented. I looks like this: // optional's swap: // If both are initialized, calls swap(T&, T&). If this swap throws, //both will remain initialized but their values are now unspecified. // If only one is initialized, calls U.reset(*I), THEN I.reset(). // If U.reset(*I) throws, both are left UNCHANGED (U is kept //uinitialized and I is never reset) // If both are uninitialized, do nothing (no-throw) template<class T> inline void optional_swap ( optional<T>& x, optional<T>& y ) { if ( !x && !!y ) { x.reset(*y); y.reset(); } else if ( !!x && !y ) { y.reset(*x); x.reset(); } else if ( !!x && !!y ) { // GCC > 3.2 and all other compilers have the using declaration at function scope (FLC) #ifndef BOOST_OPTIONAL_STD_SWAP_INTRODUCED_AT_NS_SCOPE // allow for Koenig lookup using std::swap ; #endif swap(*x,*y); } } The problem here is that the two first cases do not delegate to the version of swap found by ADL. That only happens in cases where both objects are initialized. This is, AFAICT, a major problem because copy-construction has quite different semantics than swap() when it comes to invalidation of iterators or pointers. It works ok for ints, but creates havoc when using a container with internal memory. I suggest we do something along these lines: template<class T> inline void optional_swap ( optional<T>& x, optional<T>& y ) { bool hasX = x; bool hasY = y; if ( !hasX && !hasY ) return; if( !hasX ) x = boost::in_place(); else if ( !hasY ) y = boost::in_place(); // GCC > 3.2 and all other compilers have the using declaration at function scope (FLC) #ifndef BOOST_OPTIONAL_STD_SWAP_INTRODUCED_AT_NS_SCOPE // allow for Koenig lookup using std::swap ; #endif swap(*x,*y); if( !hasX ) y.reset(); else if( !hasY ) x.reset(); } Comments? -Thorsten

10 25

[announce] Multi signature boost::function
by Marco Costalba 27 Apr '08

27 Apr '08

Hi everybody, in Vault it is possible to download msf.zip, a (very small) file that contains multi-signature extension to boost::function It is possible to instantiate a boost::multi_signature_function::function on a mpl sequence of signatures and this object will behave as expected, in particular it keeps all the functionality of boost::function but allows to be called with different arguments types and/or number. Interested people could read (and compile) included test.cpp file, an example is better then 1000 words. If there is interest I can improve documentation and examples. Regards Marco P.S: This puppy should be compiler friendly, anyhow tested on g++ and MSVC

4 8

[metagraph] initial release of metagraph libraries
by Gordon Woodhull 27 Apr '08

27 Apr '08

Hi friends - I just uploaded the first two of the metagraph libraries to the sandbox. These are * an mpl_graph for bgl-like graphs in c++ metaprogramming ( s/(/</ ) * a fusion_graph for basic heterogeneous-typed graphs where edges describe the links (pointers, containers of pointers) and vertices are the types of objects. There is a long way to go, but I wanted to post something in advance of BoostCon to invite conversation. The eventual idea is to make graphs-of-graphs, graphs that refer to other graphs, and graph layers of detail, all easy to specify and use. One would combine patterns such as "graph," "tree," or "chain," to build more complex data structures without resorting to inefficient overgeneralizations or unsafe ad-hoc methods. Along the way I will also offer Yet Another Reflection Mechanism: much as any graph data structure can be adapted as a Boost Graph, any system of objects which refer to one another can be reflected as a metagraph. What is available now just allows you to build systems of objects with pointers (or containers of pointers) to each other, which is mostly useful to library developers wanting to generate such types at compile time. They are not yet managed, by which I mean, all of the cross- referencing that naturally takes place in such systems has to be kept track of by the application, or by metagraph libraries yet to be written... Thanks in advance for any comments, references to related libraries, etc. Gordon

1 0

1.35 Release announcement on SF
by Sean Hunt 27 Apr '08

27 Apr '08

The SourceForge project page for Boost doesn't have an announcement for 1.35 being released. This seems to me like an oversight.

1 0

Re: [boost] But it would Re: [gil] [announcement] New IO lib
by Tom Brinkman 27 Apr '08

27 Apr '08

> Tom Brinkman wrote: >>>> But it would introduce the dependency to boost::filesystem >> >> That would be a show-stopper for shur. I definately could not use >> your IO library if it had a boost::filesystem dependency. PLEASE - >> keep it header only. >> I have no interest in boost::filesystem or gil. Just trying to >> understand your requirement for being header-only: You *want* to compile >> the same code over and over rather than just once? >> >> No, he's probably using a pre-compiled header. :-) No, we generally dont use pre-compiled headers on UNIX. If at all. You must be using dev-studio on windows. The trend is for all "new" libraries to be header only, unless there is an overwhelming, and I mean absolutely overwhelming reason not too. Also, you should not have unecessary dependencies. The filesystem library is not a necessity in this case, and becouse the filesystem library is is not a header only library, it makes using it by other libraries very problematic.

3 8

Re: [boost] Can you please elaborate on what makes a non-header-only library so very Re: But it would Re: [gil] [announcement] New IO lib
by Tom Brinkman 26 Apr '08

26 Apr '08

Sorry about the long subject line. lol. Also, I just took a look at your blog. Nice. I've added it to my bookmarks of blogs that I read. >> Why don't you rebuild your dependent libraries along with your code? >> Then you are guaranteed to have the right stuff. I mean, you already >> said you would like to recompile everything over and over with >> header-only stuff. Might as well make it official. You make a good valid point. It guess it really just comes down to the "hastle" factor. Managing libraries is just a pain. I cant tell you how many times that I've had to track down stupid things related to making sure that all the current libraries are in place for the library to compile. My experience with header only libraries is much more pleasant.

2 1

Can you please elaborate on what makes a non-header-only library so very Re: But it would Re: [gil] [announcement] New IO lib
by Tom Brinkman 26 Apr '08

26 Apr '08

>> Can you please elaborate on what makes a non-header-only library so very >> problematic? Its probably more a UNIX thing, I'm not sure if windows developers could care one way or another. But on LINUX/UNIX, there is a central repository of pre-built libraries that we syncronize our builds against. Uncecessarily adding new libraries makes the process that much more to manage. It is "so" much easier to not have to bother with that and just have the compiler link in any functions that are used at compile time from the headers. You would be surprised to now how much compiler technology has improved in the last 3-4 years. The old reasons for making libraries are no longer always valid. Compilers are very smart and very fast, and thats how I pefer to code.

3 2