- Boost - lists.boost.org

[1.37] status/Jamfile.v2
by Nicola Musatti 27 Oct '08

27 Oct '08

Hallo, I believe the Jamfile.v2 in the status directory should be merged to the release branch. The one that's there looks older than the directory reorganization that was performed a while ago, and it doesn't include the tests for several libraries. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

9 17

[mpl] Error in map docs (or bug)
by John Bytheway 26 Oct '08

26 Oct '08

I think I've found an error in the MPL docs (In trunk and 1.35, and presumably everything in between). The documentation for mpl::map state that "count<m,k>::type" yields "The number of elements with the key k in m", where in fact what it returns is the number of elements *equal* to k in m. This is consistent with the documentation of mpl::count. I suspect this is an error in the docs rather than a bug, since there is also mpl::has_key, which serves the purpose count claims to be serving (but isn't). Consider this code: #include <boost/mpl/has_key.hpp> #include <boost/mpl/count.hpp> #include <boost/mpl/assert.hpp> #include <boost/mpl/set.hpp> #include <boost/mpl/map.hpp> #include <boost/mpl/insert.hpp> using namespace boost::mpl; typedef set< int >::type my_set; typedef map< boost::mpl::pair<int, int> >::type my_map; BOOST_MPL_ASSERT((has_key<my_set, int >::type)); BOOST_MPL_ASSERT((count<my_set, int >::type)); BOOST_MPL_ASSERT((has_key<my_map, int >::type)); BOOST_MPL_ASSERT((count<my_map, int >::type)); BOOST_MPL_ASSERT((count<my_map, pair<int,int> >::type)); The fourth assertion fails. If the map docs were accurate then it would be the fifth assertion that failed. The same error is in the Associative Sequence docs, and perhaps other places. John Bytheway

1 0

Directory monitor for Windows (Boost.Asio extension)
by Boris 26 Oct '08

26 Oct '08

I had created a file monitor in March as a reference implementation of how to develop a Boost.Asio extension. While it was pretty incomplete at that time it has become a grown-up and fully tested directory monitor which supports both synchronous and asynchronous I/O. It currently works on Windows only as it is based on Microsoft's I/O Completion Ports (for those who need a directory monitor on Linux see http://article.gmane.org/gmane.comp.lib.boost.asio.user/2699) The directory monitor can be downloaded here: http://www.highscore.de/boost/dir_monitor.zip The zip archive contains various tests which can be used for a quick start. As the directory monitor is pretty small it shouldn't take much longer than 10 minutes to use it in your own projects. Boris

1 0

[test] Patch for gcc warning suppression.
by John Maddock 25 Oct '08

25 Oct '08

I'm getting a bunch of warnings from floating_point_comparison.hpp with gcc, the attached patch fixes these, if these are OK, I can commit from here. That just leaves: c:\data\boost\boost\trunk/boost/test/floating_point_comparison.hpp:246: warning: 'boost::test_tools::<unnamed>::check_is_small' defined but not used Is there any way to get rid of that as well? Thanks, John.

3 3

Welcome to the Boost Developers Archive on Google Groups!
by Eric Niebler 24 Oct '08

24 Oct '08

I've subscribed Google Groups to the boost developers list, so that people who would like to follow the group that way (and get an RSS feed to the list) can do so. http://groups.google.com/group/boost-developers-archive It can't import old messages, but new messages should show up there and be search-able. I hope. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

Class-level instrospection
by Joel Falcou 24 Oct '08

24 Oct '08

Daniel Walker a écrit : > Why don't we both package what we have, upload to vault, and then > work out merging the two and adding the rest in another thread? I've cleaned-up my files and 'boostified' them so to speak. I've uploaded a 'introspection.zip' on the vault so you can grab it and we can start discussing this in a proper topic ;) Basically i've uploaded the following : BOOST_HAVE_MEMBER_FUNCTION BOOST_HAVE_CONST_MEMBER_FUNCTION BOOST_HAVE_NON_CONST_MEMBER_FUNCTION BOOST_HAVE_MEMBER_DATA Basically, the usage is really simple. You want to check if classes provides a bool is_ok(long) method and you want to catch both const and non-const variations : BOOST_HAVE_MEMBER_FUNCTION(is_ok, bool(long) ) then the check itself is done via : has_member_function<T>::type For BOOST_HAVE_DATA_MEMBER, my method can only check for public members. So I added a macoer called BOOST_INSTROSPECTION_SUPPORT(C,V) that have to be used in user-defined class C that want to publish a member named V to our introspection mecanism. struct foo { private : int mValue; }; struct bar { BOOST_INTROSPECTION_SUPPORT(bar,mValue); private : int mValue; }; BOOST_HAVE_MEMBER_DATA(int, mValue) has_member_data_mValue<foo>::value is false has_member_data_mValue<bar>::value is true Other limitations is that currently you can't have various check for a method with a given name but different signature. I'm working on a fix using PP sequence and : BOOST_HAS_MEMBER_FUNCTION_OVERLOADS(func,(void())(void(int))(void(int,int))) In the same way, checking for suff like operator[] yields invalid class name has_member_function_operator[]. So I propose we hand-code the following : BOOST_HAS_SUBSCRIPT_OPERATOR( void(int) ) that builds a has_subscript_operator<T> class. Other similar operator should be handled the same way.

4 7

[General] A standard idiom or technique?
by Robert Jones 24 Oct '08

24 Oct '08

A recent post in this list started me thinking... Given this code snippet, using namespace std; void f( int, int ); vector<int> v1; vector<int> v2; // populate... for ( unsigned i = 0; i <= v1.size( ); ++ i ) { f( v1[ i ], v2[ i ] ); } How would you write this as a for_each() or in some other Boosty, functional way? (The aspect I'm trying to highlight is that two iterators over different ranges must advance in step) One could imagine a tuple-based solution, in which one specifies how an operation applied to the tuple distributes to operations applied to each of the tuple's elements. Does any such thing exist in Boost? Is it ever necessary, or can the functionality be achieved by some C++/STL/Boost idiom that I've not thought of? If there is no obvious technique, is there any interest in a Boost library which address this in a generic way? Thanks. - Rob.

5 7

How to install Boost.Numeric.Bindings
by Peng Yu 24 Oct '08

24 Oct '08

Hi, I've downloaded the whole boost src. svn co https://svn.boost.org/svn/boost boost Right now, I need Boost.Numeric.Bindings which is in the sandbox. I tried bjam, but I got the following error. Can somebody let me know how to compile Boost.Numeric.Bindings? Thanks, Peng $ bjam Unable to load Boost.Build: could not find build system. --------------------------------------------------------- /home/local/eda06/yupeng/test/C++/svn/boost/sandbox/boost-build.jam attempted to load the build system by invoking 'boost-build ;' but we were unable to find "bootstrap.jam" in the specified directory or in BOOST_BUILD_PATH (searching /usr/share/boost-build). Please consult the documentation at 'http://www.boost.org'.

3 8

[Pool]: How to tag pool_allocator
by VoidEx 24 Oct '08

24 Oct '08

Hello pool_allocator based on singleton allocator, but uses it's own tag. But I want use one pool_allocator for some strings/vectors/lists and another for some other data, because I want destroy data separately. Is it possible now? Or may be I do it wrong?

2 2

[pool] Conversion to Boost.Thread for singleton_pool
by Chris Newbold 24 Oct '08

24 Oct '08

Boost.Pool contains a private mutex implementation used as the default mutex type for singleton_pool (which provides a thread-safe API). Now that Boost.Thread is well-established and in line with TR1, I'd like to jettison the private mutex implementation inside Boost.Pool and switch the default mutex type to be boost::mutex. The obvious consequence of this change is that singleton_pool becomes dependent on Boost.Thread. The dependency would exist only for singleton_pool and its clients and would not affect the other Boost.Pool interfaces. Anyone have any objections or reasons why this wouldn't be a good idea? -Chris

3 5