November 2010 - Boost - lists.preview.boost.org

What's so cool about Boost.MPI?
by David Abrahams 18 Nov '10

18 Nov '10

Just wanted to call some attention to this article I wrote about Boost.MPI: http://daveabrahams.com/2010/09/03/whats-so-cool-about-boost-mpi/ I think it might be useful to link that from the Boost.MPI docs, too. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 2

[Probing interest] -- automatization of writing predicates.
by Petr Pilař 18 Nov '10

18 Nov '10

Hi folks, I often find myself in a situation where I need a simple comparison predicate for filtering, look-up, etc. Writing such predicates can get tedious over time and adds unnecessary "bloat", especially when you use the predicate only once. For that reason I have automated this process and I'm interested whether others might find it useful as well. Usage example: auto_predicate(&ClassName::getter, compareWithMe) -- this returns functor which compares the returned value with compareWithMe using == operator. auto_predicate(&ClassName::getter, compareWithMe, comparator) -- this returns functor which compares the returned value with compareWithMe using the given comparator. (Note: getter return type does not have to match compareWithMe type have you supplied comparator with proper signature.) Best regards, Petr Pilař.

3 3

Boost.FileSystem dependency on Boost.System
by Matthew Gwynne 18 Nov '10

18 Nov '10

Hi, It seems when compiling anything using Boost.FileSystem that the Boost.System library is also linked. Is this always the case? I can't see any clear documentation of this on the Boost.FileSystem page. If this is the case, is there a nice list of all such dependencies somewhere, as this is currently causing us certain issues? Thanks! Matthew Gwynne http://cs.swan.ac.uk/~csmg/

1 0

for_each abstraction
by Karsten Ahnert 18 Nov '10

18 Nov '10

Hi, I need something like an abstraction layer for iterations over some range. Consider for example the following three statements, which all do the same, but the loop inside each for_each is different: // thrust is an STL-like interface for CUDA [1] thrust::device_vector< double > a1( 3 ); thrust::for_each( a1.begin() , a1.end() , op() ); std::vector< double > a2( 3 ); __gnu_parallel::for_each( a2.begin() , a2.end() , op() ); std::vector< double > a3( 3 ); std::for_each( a3.begin() , a3.end() , op() ); //maybe even fusion::vector< double , double , double > a4; fusion::for_each( a4 , op() ); Is there a way or some part of a boost-library which handles the above three statements in a unique manner? I want to write algorithms which are independent of the specific for_each implementation. Best regards, Karsten [1] http://code.google.com/p/thrust/

5 13

[config] macro for unified initialization syntax?
by Eric Niebler 17 Nov '10

17 Nov '10

Is there a config macro for the presence/absence of C++0x uniform initialization syntax? http://en.wikipedia.org/wiki/C%2B%2B0x#Uniform_initialization If not, I suggest BOOST_NO_UNIFORM_INITIALIZATION_SYNTAX. A quick test shows that gcc-4.5 in 0x mode has it. -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 2

[1.45] Beta 1 release candidates
by Beman Dawes 17 Nov '10

17 Nov '10

[1.45] Beta 1 release candidates are available at http://boost.cowic.de/rc/ As usual, please report success or failure doing builds. We like to get reports of successful builds on several varied platforms before the files are pushed out to SourceForge and the formal announcement made. Thanks, --Beman

8 14

Interest in B-tree library for Boost?
by Beman Dawes 17 Nov '10

17 Nov '10

A Boost B-tree library would provide disk-based associative containers that scale all the way from really, really, small to really, really, large. B-trees perform well on hardware ranging from ancient floppy disk drives all the way up to humongous disk arrays. They are the technology behind most high-performance disk file systems and databases. If you don't know what a B-tree is, or think that "B-tree" is an abbreviation for "Binary tree", you might want to read the Wikipedia B-Tree article: http://en.wikipedia.org/wiki/B-tree. Knuth and other computer science texts also supply descriptions. See http://mysite.verizon.net/beman/btree/index.html for a more complete description of the proposed library. A preliminary implementation is available. Download http://mysite.verizon.net/beman/btree/btree-preview-1.zip, and unpack into a current Boost distribution. A few existing Jamfiles will be overwritten. The only compilers tested and working so far are VC++ 10 and GCC/MinGW 4.5. You can view the library online at http://github.com/Beman/Boost-Btree There is no detailed documentation yet, but if you know how to use std::map and other standard library associative containers, you already know most of what you need to know. Critical differences are documented in the Library Characteristics section of the index.html page referenced above. Initial timing tests have been very encouraging. The time test compares the btree_map implementation to std::map. As expected, a btree_map is many times slower than a std::map, given a cold operating system file cache and constraining the btree_map's caching to a minimum. But at the other extreme, when the O/S file cache is warm and the btree_map's cache is as large as the file, the btree_map is very similar in speed to std::map.The btree library's code is still very new, so timings and everything else may be subject to lots of revision. Any interest? --Beman

14 37

[build] bjam in boost/tools/build/v2/test doesn't work
by Jim Bell 17 Nov '10

17 Nov '10

Running bjam in boost/tools/build/v2/test doesn't (seem to) run build's regressions. Instead, I get: jamfile.jam:8: in modules.load rule project-root unknown in module Jamfile</F:/tmp/boost-MinGW-32/trunk/boost/t ools/build/v2/test>. F:/tmp/boost-MinGW-32/trunk/boost/tools/build/v2/build\project.jam:314: in load- jamfile F:/tmp/boost-MinGW-32/trunk/boost/tools/build/v2/build\project.jam:62: in load F:/tmp/boost-MinGW-32/trunk/boost/tools/build/v2/build\project.jam:168: in proje ct.find F:/tmp/boost-MinGW-32/trunk/boost/tools/build/v2\build-system.jam:569: in load F:\tmp\boost-MinGW-32\trunk\boost\tools\build\v2\test\..\kernel\modules.jam:283: in import F:\tmp\boost-MinGW-32\trunk\boost\tools\build\v2\test\..\kernel\bootstrap.jam:14 2: in boost-build F:\tmp\boost-MinGW-32\trunk\boost\tools\build\v2\test\boost-build.jam:14: in mod ule scope If I run "python absolute_sources.py" (to pick that test as an example), I get very little (and it doesn't match regression test output): F:\tmp\boost-MinGW-32\trunk\boost\tools\build\v2\test\TestCmd.py:60: Deprecation Warning: The popen2 module is deprecated. Use the subprocess module. import popen2 Am I close? I realize that build is a different animal. Are there instructions for running its tests in isolation? (Could those instructions be put in boost/tools/build/v2/index.html?)

1 0

[python] [1.45] select_holder test failing
by Eric Niebler 17 Nov '10

17 Nov '10

Dave, The python "select_holder" test is failing across a large number of platforms on the release branch including all clang and gcc compilers. Can you please look into this prior to 1.45? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 8

Boost.Build -q fix for 1.45
by Vladimir Prus 16 Nov '10

16 Nov '10

On IRC, Philipp Reh reported that 1.45 beta will fail if Boost.Build is invoked with -q, and any configuration test fails. The reason is that while Steven fixed this on trunk some time ago, I failed to merge to release branch. Since this bug means that Boost will outright not build in some cases, and since the fix is not really new, I think it should be checked in to release branch even at this point. The proposed diff is this: http://codepad.org/eoeawRoG Any objections before I go ahead? - Volodya

3 2