February 2013 - Boost - lists.preview.boost.org

[lexical_cast][math] can't unconditionally call math::changesign with long double
by Eric Niebler 24 Feb '13

24 Feb '13

lexical_cast is using math::changesign with long double regardless of whether BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS is defined or not. This is causing Boost.Test build problems (see here http://tinyurl.com/af5453h) I'm pretty sure this is a bug in lexical_cast, so I've opened a ticket: https://svn.boost.org/trac/boost/ticket/8162 I've assigned it to the last person to touch lexical_cast.hpp. Apologies if that's not right. There is no entry for lexical_cast in libs/maintainers.txt. -- Eric Niebler Boost.org http://www.boost.org

6 6

[tuple] - Move constructors for Tuple
by Moore, Andrew 23 Feb '13

23 Feb '13

Are there plans for move constructors/assignment operations in the tuples library?

4 8

Re: [boost] [thread] ~condition_variable_any verifications
by Martin Elzen 22 Feb '13

22 Feb '13

Because the standard exit function doesn't call destructors for 'temporary or automatic objects that exist at the time of the call' (see: http://msdn.microsoft.com/en-us/library/6wdz5232%28v=vs.80%29.aspx ) which just ... seems surprising, I prefer not to use it in C++ projects. So I think it's not necessarily a bad thing to re-write code to get rid of it.

1 0

New gil::io has been added
by Christian Henning 22 Feb '13

22 Feb '13

Hi all, I have successfully replaced the old gil::io extension with the new gil::io. The new io has been developed on and off over the last few years and I believe it's a great improvement over the old one. Before going into details I like thank everyone that has been helping me out along the way. I have learned a lot of things and I'm very grateful for the experience! There are numerous improvements and perhaps it's best to study the documentation before using it. Here are some noteworthy points that come to my mind: * updating code that uses the old version only requires to change the header from "boost/extension/io/jpeg_io.hpp" to "boost/extension/io/jpeg/jpeg_io_old.hpp" * new formats: bmp, pnm, raw, targa * read numerous meta information from images. See boost/gil/extension/io/png_tags.hpp for example. * use all sorts of file metaphers or file names, like FILE*, ifstream, stringstream, wstring, filesystem::path, etc * in-memory images are supported * read large images with a scanline_read_iterator * have access to the file format backend * etc. There are some items left for which I need help from the boost maintainers. * How do I hook up the gil::io documentation so it's build when all boost documentation is build? * Same for the test suite. * Should I update boost_release? Or should the new extension "simmer" for a while? Again thanks for everything, Christian

3 7

Re: [boost] boost serialization backwardscompatibility ofbinary archives broken
by Markus Henschel 22 Feb '13

22 Feb '13

> -----Original Message----- > > You didn't comment any part of my mail that proposed a fix for > > compatibility of archives prior to 1.42. Does that mean that you > > consider this issue solved or will you look into that later? > > Actually I'm afraid to touch it. But I'm willing to take a look at it. > Maybe you should add your patch and email (and maybe my > response) as a comment to one of the trac items which touch upon this > subject. Another benefit of this - and another reason that I left the items > open is that other people how had variations on this problem will get notified > when you append to the trac item and that might also be helpful. > > Robert Ramey I posted my analysis of the problem to this track item: https://svn.boost.org/trac/boost/ticket/4660#comment:51 I will provide a patch against the current svn trunk next week. May be it will be possible to reduce the problem to archives created by 1.44.0. Have a nice weekend

2 1

[flat_map] doxygen bug
by Steve Lorimer 22 Feb '13

22 Feb '13

Hi all The default types for 'Predicate' and 'Allocator' exposed to doxygen in flat_map are incorrect. See below ./flat_map.hpp: #ifdef BOOST_CONTAINER_DOXYGEN_INVOKED template <class Key ,class T ,class Pred = std::less< std::pair< Key, T> > <-- incorrect ,class A = std::allocator<T> > <-- incorrect #else template <class Key, class T, class Pred, class A> #endif class flat_map; ./container_fwd.hpp: template <class Key ,class T ,class Pred = std::less<Key> ,class A = std::allocator<std::pair<Key, T> > > class flat_map;

1 0

Problems with building quickbook docs
by Andrey Semashev 21 Feb '13

21 Feb '13

Hi, I'm having problems with building quickbook docs for my library. I have the using quickbook ; as well as doxygen, xsltproc and boostbook in my ~/user-config.jam. When I run: bjam -j 2 release link=static libs/log/doc I get the following error: .../boost-release/tools/build/v2/build/generators.jam:978: in try-one-generator-really *** argument error * rule object(generator)(a)60.run ( project name ? : property-set : sources + ) * called with: ( object(project-target)@1010 filters_reference-xml : object(property-set)@1387 : ) * missing argument sources .../boost-release/tools/build/v2/build/generators.jam:370:see definition of rule 'object(generator)(a)60.run' being called .../boost-release/tools/build/v2/build/generators.jam:1040: in try-one-generator .../boost-release/tools/build/v2/build/generators.jam:1254: in construct-really .../boost-release/tools/build/v2/build/generators.jam:1338: in generators.construct .../boost-release/tools/build/v2/build/targets.jam:1495: in construct .../boost-release/tools/build/v2/build/targets.jam:1298: in object(typed-target)(a)1058.generate .../boost-release/tools/build/v2/build/targets.jam:732: in generate-really .../boost-release/tools/build/v2/build/targets.jam:704: in object(main-target)(a)1164.generate .../boost-release/tools/build/v2/build/targets.jam:848: in targets.generate-from-reference .../boost-release/tools/build/v2/build/targets.jam:1217: in generate-dependencies .../boost-release/tools/build/v2/build/targets.jam:1269: in object(typed-target)(a)1061.generate .../boost-release/tools/build/v2/build/targets.jam:732: in generate-really .../boost-release/tools/build/v2/build/targets.jam:704: in object(main-target)(a)1165.generate .../boost-release/tools/build/v2/build/targets.jam:848: in targets.generate-from-reference .../boost-release/tools/build/v2/build/targets.jam:1217: in generate-dependencies .../boost-release/tools/build/v2/build/targets.jam:1269: in object(typed-target)(a)1062.generate .../boost-release/tools/build/v2/build/targets.jam:732: in generate-really .../boost-release/tools/build/v2/build/targets.jam:704: in object(main-target)(a)1166.generate .../boost-release/tools/build/v2/build/targets.jam:848: in targets.generate-from-reference .../boost-release/tools/build/v2/build/targets.jam:1217: in generate-dependencies .../boost-release/tools/build/v2/build/targets.jam:1269: in object(install-target-class)(a)1065.generate .../boost-release/tools/build/v2/build/targets.jam:732: in generate-really .../boost-release/tools/build/v2/build/targets.jam:704: in object(main-target)(a)1167.generate .../boost-release/tools/build/v2/build/targets.jam:848: in targets.generate-from-reference .../boost-release/tools/build/v2/build/targets.jam:1217: in generate-dependencies .../boost-release/tools/build/v2/build/targets.jam:1399: in basic-target.compute-usage-requirements .../boost-release/tools/build/v2/build/alias.jam:47: in compute-usage-requirements .../boost-release/tools/build/v2/build/targets.jam:1319: in object(alias-target-class)(a)1068.generate .../boost-release/tools/build/v2/build/targets.jam:732: in generate-really .../boost-release/tools/build/v2/build/targets.jam:704: in object(main-target)(a)1168.generate .../boost-release/tools/build/v2/build/targets.jam:258: in object(project-target)(a)1010.generate .../boost-release/tools/build/v2/build-system.jam:736: in load .../boost-release/tools/build/v2/kernel/modules.jam:283: in import .../boost-release/tools/build/v2/kernel/bootstrap.jam:142: in boost-build .../boost-release/boost-build.jam:17: in module scope index.html libs/index.html more/getting_started.html tools/index.html I'm using the release branch. Does anyone know what the problem could be?

2 2

boost serialization backwards compatibility of binary archives broken
by Markus Henschel 21 Feb '13

21 Feb '13

Hello, in its current state boost serialization isn't able to read binary archives from older versions. The documentation states that there is a problem with version 1.42-1.44 but this is not the whole story. My archives from 1.34 don't work either. There are currently open bugs for this: https://svn.boost.org/trac/boost/ticket/4903 https://svn.boost.org/trac/boost/ticket/5567 https://svn.boost.org/trac/boost/ticket/4660 This situation has been like this for a very long time now. Comments of users even suggest not using binary archives or switching to another serialization library because of maintenance problems. I'm posting to this list as it seems like no one cares about these bug reports anymore. The least thing that should be done I think is to update the release notes. There are even patches in the bug reports that provide fixes although I don't know if they work for all situations. The current situation is quite uncomfortable for me as I have to patch every new boost version to get serialization working. What can be done to improve this situation? Thanks, Markus Henschel

2 5

[test][thread] double free or corruption
by Vicente J. Botet Escriba 21 Feb '13

21 Feb '13

Hi, before moving from Boost.Test to lightweight_test.hpp the following error occurred on Boost.Thread test_barrier. After the change the error has disappeared. The same kind of error occurs on all the test using Boost.Test Could other confirm that this error is on Boost.Test? Best, Vicente Sandia-gcc-4.7.1 ------------------------------------------------------------------------ Tests are run on Linux platform. ------------------------------------------------------------------------ Command Line run.py --proxy=http://wwwproxy.sandia.gov:80 --runner=Sandia-gcc-4.7.1 \ --bjam-toolset=gcc --pjl-toolset=gcc --toolsets=gcc-4.7.1 \ "--bjam-options=-j15 warnings=on warnings-as-errors=on" Test output: Sandia-gcc-4.7.1 - thread - test_barrier / gcc-4.7.1 Rev 82993 / Tue, 19 Feb 2013 08:14:00 +0000 *Report Time: *Tue, 19 Feb 2013 19:31:12 +0000 Compile [2013-02-19 08:54:27 UTC]: succeed "/sierra/Sntools/extras/compilers/gcc-4.7.1/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -Werror -g -pthread -fPIC -Wextra -Wno-long-long -Wno-variadic-macros -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -c -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier.o" "../libs/thread/test/test_barrier.cpp" Link [2013-02-19 08:54:27 UTC]: succeed "/sierra/Sntools/extras/compilers/gcc-4.7.1/bin/g++" -Wl,-R -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi" -Wl,-R -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi" -Wl,-R -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi" -Wl,-rpath-link -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi" -Wl,-rpath-link -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi" -Wl,-rpath-link -Wl,"/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi" -o "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier" -Wl,--start-group "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier.o" "/scratch/kbelco/boost/results/boost/bin.v2/libs/test/build/gcc-4.7.1/debug/link-static/threading-multi/libboost_unit_test_framework.a" "/scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi/libboost_chrono.so.1.54.0" "/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi/libboost_thread.so.1.54.0" "/scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi/libboost_system.so.1.54.0" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -g -pthread Run [2013-02-19 08:54:27 UTC]: fail Running 1 test case... *** No errors detected *** glibc detected *** /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier: double free or corruption (out): 0x000000000f903530 *** ======= Backtrace: ========= /lib64/libc.so.6[0x30ab67245f] /lib64/libc.so.6(cfree+0x4b)[0x30ab6728bb] /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libstdc++.so.6(_ZNSsD1Ev+0x20)[0x2b123aaa5660] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x421c1a] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x421c34] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x42028f] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x421b97] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x421bca] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x47918f] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier[0x478fb2] /lib64/libc.so.6(exit+0xe5)[0x30ab6334f5] /lib64/libc.so.6(__libc_start_main+0xfb)[0x30ab61d99b] /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier(_ZNSt8ios_base4InitD1Ev+0x39)[0x4116d9] ======= Memory map: ======== 00400000-004f1000 r-xp 00000000 68:11 12550145 /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier 006f1000-006f3000 rw-p 000f1000 68:11 12550145 /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/test_barrier.test/gcc-4.7.1/debug/threading-multi/test_barrier 006f3000-006f6000 rw-p 006f3000 00:00 0 0f8fb000-0f91c000 rw-p 0f8fb000 00:00 0 [heap] 414fe000-414ff000 ---p 414fe000 00:00 0 414ff000-416ff000 rw-p 414ff000 00:00 0 416ff000-41700000 ---p 416ff000 00:00 0 41700000-41900000 rw-p 41700000 00:00 0 41a48000-41a49000 ---p 41a48000 00:00 0 41a49000-41c49000 rw-p 41a49000 00:00 0 41f6d000-41f6e000 ---p 41f6d000 00:00 0 41f6e000-4216e000 rw-p 41f6e000 00:00 0 4216e000-4216f000 ---p 4216e000 00:00 0 4216f000-4236f000 rw-p 4216f000 00:00 0 4236f000-42370000 ---p 4236f000 00:00 0 42370000-42570000 rw-p 42370000 00:00 0 42570000-42571000 ---p 42570000 00:00 0 42571000-42771000 rw-p 42571000 00:00 0 42771000-42772000 ---p 42771000 00:00 0 42772000-42972000 rw-p 42772000 00:00 0 42972000-42973000 ---p 42972000 00:00 0 42973000-42b73000 rw-p 42973000 00:00 0 42b73000-42b74000 ---p 42b73000 00:00 0 42b74000-42d74000 rw-p 42b74000 00:00 0 30ab200000-30ab21c000 r-xp 00000000 68:05 27394072 /lib64/ld-2.5.so 30ab41b000-30ab41c000 r--p 0001b000 68:05 27394072 /lib64/ld-2.5.so 30ab41c000-30ab41d000 rw-p 0001c000 68:05 27394072 /lib64/ld-2.5.so 30ab600000-30ab74e000 r-xp 00000000 68:05 27394073 /lib64/libc-2.5.so 30ab74e000-30ab94e000 ---p 0014e000 68:05 27394073 /lib64/libc-2.5.so 30ab94e000-30ab952000 r--p 0014e000 68:05 27394073 /lib64/libc-2.5.so 30ab952000-30ab953000 rw-p 00152000 68:05 27394073 /lib64/libc-2.5.so 30ab953000-30ab958000 rw-p 30ab953000 00:00 0 30aba00000-30aba82000 r-xp 00000000 68:05 27394266 /lib64/libm-2.5.so 30aba82000-30abc81000 ---p 00082000 68:05 27394266 /lib64/libm-2.5.so 30abc81000-30abc82000 r--p 00081000 68:05 27394266 /lib64/libm-2.5.so 30abc82000-30abc83000 rw-p 00082000 68:05 27394266 /lib64/libm-2.5.so 30ac200000-30ac216000 r-xp 00000000 68:05 27394078 /lib64/libpthread-2.5.so 30ac216000-30ac415000 ---p 00016000 68:05 27394078 /lib64/libpthread-2.5.so 30ac415000-30ac416000 r--p 00015000 68:05 27394078 /lib64/libpthread-2.5.so 30ac416000-30ac417000 rw-p 00016000 68:05 27394078 /lib64/libpthread-2.5.so 30ac417000-30ac41b000 rw-p 30ac417000 00:00 0 30ade00000-30ade07000 r-xp 00000000 68:05 27394095 /lib64/librt-2.5.so 30ade07000-30ae007000 ---p 00007000 68:05 27394095 /lib64/librt-2.5.so 30ae007000-30ae008000 r--p 00007000 68:05 27394095 /lib64/librt-2.5.so 30ae008000-30ae009000 rw-p 00008000 68:05 27394095 /lib64/librt-2.5.so 2b123a378000-2b123a37a000 rw-p 2b123a378000 00:00 0 2b123a37a000-2b123a387000 r-xp 00000000 68:11 67521223 /scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi/libboost_chrono.so.1.54.0 2b123a387000-2b123a587000 ---p 0000d000 68:11 67521223 /scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi/libboost_chrono.so.1.54.0 2b123a587000-2b123a588000 rw-p 0000d000 68:11 67521223 /scratch/kbelco/boost/results/boost/bin.v2/libs/chrono/build/gcc-4.7.1/debug/threading-multi/libboost_chrono.so.1.54.0 2b123a588000-2b123a589000 rw-p 2b123a588000 00:00 0 2b123a589000-2b123a5ba000 r-xp 00000000 68:11 70570074 /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi/libboost_thread.so.1.54.0 2b123a5ba000-2b123a7b9000 ---p 00031000 68:11 70570074 /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi/libboost_thread.so.1.54.0 2b123a7b9000-2b123a7bc000 rw-p 00030000 68:11 70570074 /scratch/kbelco/boost/results/boost/bin.v2/libs/thread/build/gcc-4.7.1/debug/threading-multi/libboost_thread.so.1.54.0 2b123a7bc000-2b123a7c0000 r-xp 00000000 68:11 70568307 /scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi/libboost_system.so.1.54.0 2b123a7c0000-2b123a9bf000 ---p 00004000 68:11 70568307 /scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi/libboost_system.so.1.54.0 2b123a9bf000-2b123a9c0000 rw-p 00003000 68:11 70568307 /scratch/kbelco/boost/results/boost/bin.v2/libs/system/build/gcc-4.7.1/debug/threading-multi/libboost_system.so.1.54.0 2b123a9c0000-2b123a9c1000 rw-p 2b123a9c0000 00:00 0 2b123a9e6000-2b123a9e7000 rw-p 2b123a9e6000 00:00 0 2b123a9e7000-2b123aad1000 r-xp 00000000 00:4a 2200568155 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libstdc++.so.6.0.17 2b123aad1000-2b123acd0000 ---p 000ea000 00:4a 2200568155 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libstdc++.so.6.0.17 2b123acd0000-2b123acd8000 r--p 000e9000 00:4a 2200568155 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libstdc++.so.6.0.17 2b123acd8000-2b123acda000 rw-p 000f1000 00:4a 2200568155 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libstdc++.so.6.0.17 2b123acda000-2b123acef000 rw-p 2b123acda000 00:00 0 2b123acef000-2b123ad04000 r-xp 00000000 00:4a 2201263450 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libgcc_s.so.1 2b123ad04000-2b123af03000 ---p 00015000 00:4a 2201263450 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libgcc_s.so.1 2b123af03000-2b123af04000 rw-p 00014000 00:4a 2201263450 /sierra/Sntools/extras/compilers/gcc-4.7.1/lib64/libgcc_s.so.1 2b123af04000-2b123af07000 rw-p 2b123af04000 00:00 0 7fff4d39e000-7fff4d3b3000 rw-p 7ffffffe9000 00:00 0 [stack] 7fff4d3f6000-7fff4d3fa000 r-xp 7fff4d3f6000 00:00 0 [vdso] ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vsyscall] EXIT STATUS: 134 TinyUrl <javascript:make_tinyurl()>

1 0

[tuple] Functionals for tuple element access?
by Jan Hudec 21 Feb '13

21 Feb '13

Hello All, Doing some heavy template work on collections of pairs and tuples I came across the need for functors returning tuple and pair members. So I looked whether Boost has anything like that, but couldn't find any. Now the functors can be written using bind like: bind(_1, &TupleType::get<3>); bind(_1, &PairType::first); except that requires explicitly mentioning the tuple/pair type. Trying to use simply &boost::tuples::get<3, WHAT?!?!?> even failed for me as boost::tuples::get is actually a 3-argument template based on boost::tuples::cons, which looks like implementation detail I better not rely on. Besides bost methods involve pointer-to-{function,member}, which might interfere with inlining. So I think it would be convenient to have functions like this somewhere in boost: template <int N> struct getter { template <typename X> struct result; template <typename F, typename T> struct result<F(T &)> { typedef BOOST_DEDUCED_TYPENAME element<N, T>::type &type; }; template <typename F, typename T> struct result<F(T const &)> { typedef BOOST_DEDUCED_TYPENAME element<N, T>::type const &type; }; template <typename T> BOOST_DEDUCED_TYPENAME element<N, T>::type & operator()(T &t) { return get<N>(t); } template <typename T> BOOST_DEDUCED_TYPENAME element<N, T>::type const & operator()(T const &t) { return get<N>(t); } }; I would like to ask: 1. Would there be interest in adding this? Should I polish it up? 2. What would be good name and place for it (boost::tuples::getter)? 3. To support pairs, would it be preferred to specialize the N=0 and N=1 cases (unfortunately I don't see how to handle the result struct without copy-paste) or define separate first_getter and second_getter or something like that? 4. The definition of result with const and non-const reference was enough for my uses in boost::transform_value_property_map, but I suspect it does not cover all necessary cases (I need non-reference and rvalue reference for C++11 too, right?) My actual use-case was with boost::transform_value_property_map. I needed several property maps with the same set of keys, so I created one boost::associative_property_map with tuple values and splitted it to maps for the items using the above functor. Obviously nothing of this is needed with C++11 lambdas, but I am stuck having to support some obscure platforms like WinCE 4.2 and for it with MSVC++9.0. -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 2

[range] [general] making member functions SFINAE-friendly
by Nathan Ridge 21 Feb '13

21 Feb '13

Hi, I recently came across a request to make iterator_range::size() SFINAE-friendly [1]. The respect in which it is not currently SFINAE-friendly is that it is only applicable to instantiations where I is a random-access iterator, but it is defined for all instantiations, and fails with a static assertion if I is not random-access. This makes it impossible to use SFINAE techniques to detect whether "r.size()" is valid where r is some iterator_range. The suggested workaround is to give iterator_range a base class, specialize this base class for random-access iterators, and only define size() in this specialization. I think this deficiency and workaround can be generalized to any template class 'C<T>' with a member function 'foo' that is only applicable for a subset of valid template arguments for 'T'. I am curious what the Boost community thinks about applying this workaround (factoring out the member function into a base class) as a general rule in such situations? Is making the member function SFINAE-friendly worth the decrease in readability? Are there other disadvantages to this workaround? Are there alternative ways of making such a function SFINAE- friendly that don't require introducing a base class? Finally, if the consensus is that such a workaround is not justified in general, is there any reason it should be justified specifically for iterator_range::size()? Regards, Nate [1] https://svn.boost.org/trac/boost/ticket/8011

15 49

[git] Should I commit to SVN or Git?
by Joaquín Mª López Muñoz 20 Feb '13

20 Feb '13

Hi, I'd like to commit some changes to one of my libs for delivery with Boost 1.54. Should I use SVN as always or begin now using Git for the commit? I've skimmed thru the Git transition project wiki and it doesn't seem to have anything on dates for SVN deprecation etc. Thank you, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

5 5

[thread] Is there interest in shared_lock_prioritized?
by Antony Polukhin 20 Feb '13

20 Feb '13

Hi, I've got a very basic implementation and tests of shared_lock_prioritized, that can be used like that: // Events are written down in order of // their execution in different threads shared_lock_prioritized<2 /*priorities count*/ > lock; // thread #1 // Lock with minimal priority lock_shared(); // thread #2 // Lock with minimal priority lock_shared(0); // thread #3 // Lock for writing with priority // greater than locks of threads 1 and 2 // Waits till already acquired locks in #1 and #2 finish // and then writes lock(1); // thread #4 // Will wait till thread #3 finishes, only then acquire lock lock_shared(0); Such shared lock gives us ability to manage order/priority of different lock attempts, we can make write locks have bigger priority that read locks, have multiple priorities writes (ordered write locks) and so on... Is there an interest in it? -- Best regards, Antony Polukhin

2 2

[PropertyMap] proposing compose_property_map
by Guillaume Pinot 19 Feb '13

19 Feb '13

Hi. Using boost graph, and particulary reverse_graph, I needed a compose_property_map adaptor. As it may be interesting to everyone, I propose my code. http://texitoi.eu/~texitoi/compose_property_map/ I had problems to find a good return type for the get() free function. The solution proposed here has the drawback of needing a copy constructible type for the value_type of the FPMap in the concept checks. I didn't find any other type for the get() function that pass the concept checks and that do not return stack variable, and avoid useless copy. The patch may not work completely as I am discovering the boost build system. I am open to any comment. Thanks.

2 4

[interprocess] atomic<offset_ptr>
by Tim Blechmann 19 Feb '13

19 Feb '13

hi ion, i was wondering, what would be the best way to provide an atomic<offset_ptr>? it cannot be used out of the box, as offset_ptr does not conform to the std/boost::atomic<> requirements. afaict, one would have to pre-compute the offset for a specific memory location when performing a compare_exchange or store and fix up the offset after an atomic load. to do that, it will probably be required to access some internals of the offset_ptr. also, if i'm going to work on it (not sure if i will have time), where shall the implementation go? in a way, i'd rather put it into interprocess than into atomic. thoughts? cheers, tim

2 2

[test] recent commit causing general failure
by Joaquín Mª López Muñoz 19 Feb '13

19 Feb '13

Boost.MultiIndex trunk tests fail all over with message errors like this: C:\...\boost/test/impl/test_main.ipp(39) : error C3861: 'BOOST_CHECK': identifier not found which is seemingly caused by the suppresion of an internal #include in a recent change to Boost.Test: https://svn.boost.org/trac/boost/changeset/82718#file5 Thank you, Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx

4 6

Tests failing?
by Marshall Clow 19 Feb '13

19 Feb '13

A bunch of my (String.Algo and Boost.Algo) tests are failing locally, with errors like: darwin.compile.c++ ../../../bin.v2/libs/test/build/darwin-4.2.1/debug/link-static/test_main.o In file included from ../../../libs/test/src/test_main.cpp:16: ../../../boost/test/impl/test_main.ipp: In member function 'void test_main_caller::operator()()': ../../../boost/test/impl/test_main.ipp:39: error: 'BOOST_CHECK' was not declared in this scope "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -gdwarf-2 -fexceptions -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "../../../bin.v2/libs/test/build/darwin-4.2.1/debug/link-static/test_main.o" "../../../libs/test/src/test_main.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/test/build/darwin-4.2.1/debug/link-static/test_main.o... Before I dive into this - is anyone else seeing this? Looking at the test results on the web site, it appears that Boost.Test is broken for several libraries. For example: http://www.boost.org/development/tests/trunk/developer/algorithm.html http://www.boost.org/development/tests/trunk/developer/crc.html http://www.boost.org/development/tests/trunk/developer/geometry.html -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

7 16

Re: [boost] (no subject)
by Vishnu M Menon 19 Feb '13

19 Feb '13

http://www.morguardlogistics.com/ssgd/uc9d53wpgmm.9z7a?nvb0jr11asciq Vishnu M Menon 2/19/2013 6:03:25 PM

1 0

[algorithm] gather.hpp include guard
by Ian Hobson 19 Feb '13

19 Feb '13

Hi, The include guard in boost/algorithm/gather.hpp on SVN is incorrect: #ifndef BOOST_ALGORITHM_GATHER_HPP #define ADOBE_ALGORITHM_GATHER_HPP Best, Ian

2 1

Release Managers: permission to merge small feature to release?
by Marshall Clow 19 Feb '13

19 Feb '13

I have a ticket <https://svn.boost.org/trac/boost/ticket/7652> asking for compile-time checked access to elements of a boost::array. I have implemented a specialization of boost::get (and for c++11, std::get) that does this, and it's been on the trunk and being tested for a couple weeks. This is technically not a bug fix, but new functionality, but I'd like to get it into the next release. So, I'm asking permission to merge to release. The change lists are 82083 (for the functionality), 82084 and 82102 (for the tests), and 82103 (for the docs) Thanks! -- Marshall

5 5

Cannot commit due to "svn:mime_type is not set"
by Christian Henning 18 Feb '13

18 Feb '13

Hi there, I'm trying to commit the gil::io test suite and I get the following errors: Error: Commit failed (details follow): Error: Commit blocked by pre-commit hook (exit code 1) with output: Error: /home/subversion/boost/hooks/check-mime-type.pl: Error: Error: trunk/libs/gil/io/test_images/bmp/readme.txt : svn:mime-type is not set Error: trunk/libs/gil/io/test_images/png/PngSuite/readme.txt : svn:mime-type is not set Error: trunk/libs/gil/io/test_images/pnm/readme.txt : svn:mime-type is not set Error: trunk/libs/gil/io/test_images/raw/readme.txt : svn:mime-type is not set Error: trunk/libs/gil/io/test_images/targa/fileformat.info/readme.txt : svn:mime-type Error: is not set Error: trunk/libs/gil/io/test_images/tiff/graphicmagick/readme.txt : svn:mime-type is Error: not set Error: trunk/libs/gil/io/test_images/tiff/libtiffpic/readme.txt : svn:mime-type is not Error: set Error: Error: Error: Every added file must have the svn:mime-type property set. In Error: addition text files must have the svn:eol-style property set. Error: Error: For binary files try running Error: svn propset svn:mime-type application/octet-stream path/of/file Error: Error: For text files try Error: svn propset svn:mime-type text/plain path/of/file Error: svn propset svn:eol-style native path/of/file Error: Error: You may want to consider uncommenting the auto-props section Error: in your ~/.subversion/config file. Read the Subversion book Error: (http://svnbook.red-bean.com/) Chapter 7, Properties section, Error: Automatic Property Setting subsection for more help. Also, Error: see http://svn.boost.org/trac/boost/wiki/BoostSubversion I'm using Tortoise subversion and in my configuration file I set the mime types as follows: *.txt = svn:eol-style=native;svn:keywords=Author Date Id Rev URL;svn:mime-type=text/plain *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg *.bmp = svn:mime-type=image/bmp *.tga = svn:mime-type=image/tga *.tif = svn:mime-type=image/tiff Can someone help out, please. Thanks, Christian

2 2

[type_erasure] Overloading
by Christophe Henry 18 Feb '13

18 Feb '13

Hi Steven, I'm afraid I might need some help again. I try to take as model the example in the doc (http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure…) First problem, it seems that the example has a typo. It will not compile without a :Base in the concept_interface specialization: struct concept_interface< ::foo<T, U,void>, Base, T, Enable> : Base ... Second, the example overload.cpp includes a as_param.hpp which no more exists. But my problem is that I need an overload with 1 and 2 parameters: Test t; any< mpl::vector< foo<_self, int>, foo<_self, int, double>, boost::type_erasure::copy_constructible<> > > x (t); x.foo(1); // calls foo(int) x.foo(1,1.0); // calls foo(int, double) I don't get this to compile, the second foo cannot be found, I suppose the first one hides the second. Thanks in advance, Christophe Here my failed attempt (well, one of them ;-) ): template<class T, class U, class V=void, class Enable=void> struct foo {}; template<class T, class U, class V> struct foo<T,U,V,typename boost::disable_if<boost::is_same<V,void> >::type > { static void apply(T& t, const U& u, const V& v) { t.foo(u,v); } }; template<class T, class U, class V> struct foo<T,U,V,typename boost::enable_if<boost::is_same<V,void> >::type > { static void apply(T& t, const U& u) { t.foo(u); } }; namespace boost { namespace type_erasure { template<class T, class U, class Base, class Enable> struct concept_interface< ::foo<T, U,void>, Base, T, Enable> : Base { typedef void _fun_defined; void foo(typename rebind_any<Base, const U&>::type arg) { call(::foo<T, U, void>(), *this, arg); } }; template<class T, class U, class V, class Base> struct concept_interface< ::foo<T, U,V>, Base, T, typename Base::_fun_defined> : Base { using Base::foo; void foo(typename rebind_any<Base, const U&>::type arg, typename rebind_any<Base, const V&>::type arg2) { call(::foo<T, U,V>(), *this, arg,arg2); } }; } } struct Test { void foo(int) { std::cout << "foo(int) called" << std::endl; } void foo(double) { std::cout << "foo(double) called" << std::endl; } void foo(int,double) { std::cout << "foo(int,double) called" << std::endl; } }; int main() { Test t; any< mpl::vector< foo<_self, int>, foo<_self, int, double>, boost::type_erasure::copy_constructible<> > > x (t); x.foo(1); // calls foo(int) x.foo(1,1.0); // calls foo(int, double) return 0; }

2 2

*BSD detail/endian.hpp header patch looking for review
by Brad Smith 18 Feb '13

18 Feb '13

Hi, There is a patch for the detail/endian.hpp header for *BSD OS's in ticket 6013 that needs review and to be commited. Anyone able to help out here? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

3 9

Re: [boost] [geometry] Documentation building
by Alexey Kutumov 18 Feb '13

18 Feb '13

> I'm working on CMake'fication of boost libraries, and i 've got issue when > > building documentation of Boost.Geometry. This library uses > doxygen_xml2qbk > > utility for convertiong doxygen XML to quickbook, and this utility uses > > RapidXML for xml processing. I found rapidxml in Boost.PropertyTree > > library, but it is in detail subdirectory and also have different > > namespaces (`boost::property_tree::detail::rapidxml` vs `rapidxml`) > > > > Can i use rapidxml from PropertyTree library, or i must write CMake > script > > for searching rapidxml as thirdparty library? > > Unfortunately they're not interchangeable. PropertyTree has rapidxml in > boost::property_tree::detail namespace and in the "official" release it > is in global namespace. The doxygen_xml2qbk currently assumes that the > "official" one is used. > > Aside from this. During my work on the spatial index library I've > developed an version of this tool which supports additional doxygen > features like paragraphs, warnings, text formatting and automatic > references. You might check it out. It can be found here: > > > http://svn.boost.org/svn/boost/sandbox-branches/geometry/index/doc/src/tool… > > If --output_style alt is passed as a parameter like in > > > http://svn.boost.org/svn/boost/sandbox-branches/geometry/index/doc/make_qbk… > > the alternative qbk is generated for a class or a group. > > The example of a reference which structure is defined here: > > > http://svn.boost.org/svn/boost/sandbox-branches/geometry/index/doc/rtree/re… > > looks like this: > > > http://svn.boost.org/svn/boost/sandbox-branches/geometry/index/doc/html/geo… Thanks for responce, i'll try these changes. I'm not sure whether my sources is up to date, but i made some changes, you can find them here: https://github.com/boost-cmake/geometry/tree/master/doc/src/docutils/tools/… * Added optional parameter with output file (it is needed for CMake script). * Also i fixed issue with brackets in description (added proper escaping).

1 0

[algorithm] adjacent_for_each interest?
by Ian Hobson 18 Feb '13

18 Feb '13

Hi, Is there any interest in a version of for_each that operates on each adjacent pair of elements in a range? #include <iostream> #include <boost/algorithm/adjacent_for_each.hpp> void PrintInts(int a, int b) { std::cout << '(' << a << ", " << b << ")\n"; } int main() { const int ints[] = {0, 1, 2, 3, 4}; boost::algorithm::adjacent_for_each(ints, ints + 5, PrintInts); } Output: (0, 1) (1, 2) (2, 3) (3, 4) Initial implementation available at http://github.com/irh/adjacent_for_each Best, Ian

7 18

[git] Bad superproject.
by Rene Rivera 18 Feb '13

18 Feb '13

In trying to use the new boost git superproject there's a reference to a non-existent subrepo "boostorg/spirit_classic.git". This of course makes it impossible to do a full clone. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

3 4

[Test] Allowing assert to break into debugger
by Alexander Lamaison 18 Feb '13

18 Feb '13

Normally when debugging a program in Visual Studio 2005, the debugger will let the user break the program if it asserts. But when the program in a Boost.Test runner, that doesn't happen. In this thread [1] other people report the same problem but Gennadiy says that it should work. Was this ever fixed? I'm using Boost 1.50. [1] http://boost.2283326.n4.nabble.com/BOOST-ASSERT-any-one-against-improving-d… Thanks, Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

1 0

[Installer] Windows 1.51 installer is broken
by Alexander Lamaison 18 Feb '13

18 Feb '13

I'm not sure who's dealing with this now, but the installer for 1.51 on Windows is broken with multiple File Not Found (404) errors. The sourceforge directory it tries to access seems to not be a real folder. Or at least it appear strangely when browsed: http://sourceforge.net/projects/boost/files/boost-binaries/ Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)

1 0

[gil::io] Objections to replace gil::io
by Christian Henning 17 Feb '13

17 Feb '13

I'm ready to replace the old gil:io extension with the new version. Does anyone have any objections? Thanks, Christian

1 0

[website] SSL certificate for *.boost.org has expired
by Lars Viklund 17 Feb '13

17 Feb '13

It seems like the certificate for *.boost.org expired on the 16th, I'd reckon it's time to renew it and review the routines for renewing it in time. -- Lars Viklund | zao(a)acc.umu.se

2 1

[serialization] Limited Forward Compatibility
by Dmitry Shesterkin 17 Feb '13

17 Feb '13

Hello, We use xml serialization for saving and loading several types of metadata and we have to support possibility of reading new versions of files with old versions of soft. Boost::serialization is very good at backward compatibility but does not provide anything with opposite problem. So, This patch introduces new flag boost::archive::skip_unknown_tail_tags. When this flag is set and basic_xml_iarchive is faced with unknown tags at the end of element it will skip them (include nested). E.g., the first version of some file was: <Test class_id="0" tracking_level="0" version="0"> <a>31</a> <t2 class_id="1" tracking_level="0" version="0"> <a>11</a> 12 </t2> 32 </Test> After a while, the second version could be: <Test class_id="0" tracking_level="0" version="0"> <a>31</a> <t2 class_id="1" tracking_level="0" version="1"> <a>11</a> 12 <c>13</c> <d>14</d> <t1 class_id="2" tracking_level="0" version="0"> <a>1</a> 2 </t1> </t2> 32 </Test> Therefore, if the first version software set skip_unknown_tail_tags it can read second version of file (if does not set then exception will be thrown). See patch in attachments for details. Could it be useful, and should it be merged in trunk? Thanks in advance, Dmitry

2 3

[geometry] Documentation building
by Alexey Kutumov 17 Feb '13

17 Feb '13

I'm working on CMake'fication of boost libraries, and i 've got issue when building documentation of Boost.Geometry. This library uses doxygen_xml2qbk utility for convertiong doxygen XML to quickbook, and this utility uses RapidXML for xml processing. I found rapidxml in Boost.PropertyTree library, but it is in detail subdirectory and also have different namespaces (`boost::property_tree::detail::rapidxml` vs `rapidxml`) Can i use rapidxml from PropertyTree library, or i must write CMake script for searching rapidxml as thirdparty library?

2 1

[atomic] errors since the introduction of constexpr noexcept.
by Vicente J. Botet Escriba 17 Feb '13

17 Feb '13

Hi, There are some errors since the introduction of constexpr noexcept. Could you apply this patch? Best, Vicente svn diff boost/atomic Index: boost/atomic/detail/cas64strong.hpp =================================================================== --- boost/atomic/detail/cas64strong.hpp (revision 82919) +++ boost/atomic/detail/cas64strong.hpp (working copy) @@ -13,6 +13,7 @@ // atomic, so they are funnelled through cmpxchg as well. #include <cstddef> +#include <boost/config.hpp> #include <boost/cstdint.hpp> #include <boost/memory_order.hpp> #include <boost/atomic/detail/config.hpp> @@ -34,7 +35,8 @@ typedef T value_type; typedef T difference_type; public: - BOOST_CONSTEXPR base_atomic(atomic_type v) BOOST_NOEXCEPT: v_(v) {} + int xxx; + BOOST_CONSTEXPR base_atomic(value_type v) BOOST_NOEXCEPT: v_(v) {} base_atomic(void) {} void @@ -158,7 +160,7 @@ typedef void * value_type; typedef ptrdiff_t difference_type; public: - BOOST_CONSTEXPR base_atomic(atomic_type v) BOOST_NOEXCEPT: v_(v) {} + BOOST_CONSTEXPR base_atomic(value_type v) BOOST_NOEXCEPT: v_(v) {} base_atomic(void) {} void @@ -253,7 +255,7 @@ typedef T * value_type; typedef ptrdiff_t difference_type; public: - BOOST_CONSTEXPR base_atomic(atomic_type v) BOOST_NOEXCEPT: v_(v) {} + BOOST_CONSTEXPR base_atomic(value_type v) BOOST_NOEXCEPT: v_(v) {} base_atomic(void) {} void Index: boost/atomic/detail/gcc-x86.hpp =================================================================== --- boost/atomic/detail/gcc-x86.hpp (revision 82919) +++ boost/atomic/detail/gcc-x86.hpp (working copy) @@ -1621,7 +1621,7 @@ template<typename T> inline T -platform_load64(const volatile BOOST_NOEXCEPT T * ptr) +platform_load64(const volatile T * ptr) BOOST_NOEXCEPT { T expected = *ptr; for (; !platform_cmpxchg64_strong(expected, expected, const_cast<volatile T*>(ptr));)

2 3

[mixin] Introducing a new library.
by Borislav Stanimirov 17 Feb '13

17 Feb '13

Hello, Boost.Mixin is a library I'm developing with the idea to someday submit it to Boost. It is an entity-component system, with full abstraction between interface and implementation. In short, users can define objects by combining components (often referred to from here on out as mixins). A mixin is a regular C++ class for which two macros are defined. The main thing however are the messages. Instead of getting the component with some function like `get_component` (which is possible but discouraged in the library), users deal with objects only. They can call messages (inspired by Smalltalk's messages) which are dynamically dispatched to the appropriate mixin. The messages (also defined with macros) are the only thing needed for a user to call methods from the object's mixins. When defining a mixin, the user tells which messages it's going to implement, and when adding this mixin to the object a virtual table of sorts is filled and the object starts responding to those messages by calling the mixin's actual C++ methods. Some of the key features are: * Multicast messages. A message that is implemented and handled by more than one mixin. See the message `trace` in the example. (As opposed to unicast messages, that are handled by a single mixin) * Object access from within the mixin. The macro `bm_this` (Boost.Mixin this). See the renderer do in the example. * "Live" object mutation by adding and removing mixins. As demonstrated in `change_rendering_system` in the example. This is done via the `object_transformer` class and is currently the only way of adding mixins to objects. * Mixin (and message) domains. The domain is a collection of mixins and messages that work together. If you create a set of mixins that will never conceivably have to exist in the same object as another set of mixins, you should use a different domain. Here is a github link to the library: http://github.com/iboB/boost.mixin A working example can be found here: http://github.com/iboB/boost.mixin/tree/master/libs/mixin/example/basic The example is nothing more than some objects and mixins working together as they would hypothetically in a simple game. All "game" code has been shortcut to text outputs like: "right now an object is being rendered by the d3d renderer". The example demonstrates most of the currently supported library features. There is no jamfile yet. I develop it with Qt Creator and Code::Blocks in Linux and MS Visual Studio Express 2008 and 2012 in Windows (the Windows projects might be somewhat outdated), so the are project files for these four in libs/mixin/build. The same goes for the example. I'd qualify the current state of the library as pre-alpha, so it might have some bugs. I also create a small performance testing project (much more is to be added). It calls a regular function, a virtual function, `std::function` and a unicast mixin message a hundred million times. So far I'm generally happy with the performance, which is not to say that I won't be working on improving it. Still my computer is the only one I've tested it on and I'd be happy if somebody else tries the perf project. Here are my results: 100,000,000 x | Debug t | Release t ------------------------------------------ regular method | 781 ms | 211 ms virtual method | 639 ms | 253 ms `std::function` | 10695 ms | 272 ms Mixin message | 3298 ms | 865 ms It should also be noted that currently the library depends on a piece of code from Don Clugston's fastdelegate (found here: http://www.codeproject.com/Articles/7150/Member-Function-Pointers-and-the-F…) The piece in question has been copy-pasted verbatim (wrapped around in the boost::mixin namespace) in the third_party subfolder. Don Clugston has done a wonderful job of creating a platform-independent representation of C++ methods as a pair of pointers. Boost.Mixin heavily relies on such a thing for its virtual tables. For now I am the only developer of the library. Zahary Karadjov (credited in the license) hasn't written anything in it yet, but he is responsible for most of the library's public interface design, the idea to reuse fastdelegate, and the ideas and implementation suggestions for many of the roadmap features listed below. The programming languages Smalltalk, Ruby, and, to a degree, Objective C have also influenced the design. So, here is a project roadmap of sorts: 1. Soon: * Overloaded messages - messages that call overloaded functions. The message's name is different for each overload but the calling function remains the same * Work on more sensible (and helpful) runtime and compile-time errors. Missing messages, ambiguous message priority, etc. * Add multicast result collectors. Like `and` or `or` for boolean return values. Like `sum` for numeric values. Sample usage some_multicast_message(obj, p1, p2, boost::mixin::sum). User-defined result collectors will be possible. * Add a new mixin feature `fact`. Facts are static const variables in a mixin. No multicasts. No virtual tables. * Add object type templates. Instead of manually transforming each object, you would be able to call `type_template::new_object()` * Add more graceful runtime error handling: default message implementations (if none is provided), more specific non-breaking exceptions * Rigorous unit tests * Performance tests * Tutorials 2. Later: * Boost.Jam build files * Full reference documentation * Formal submission to Boost?? * Call mixin constructors when mutating object or constructing them via object type templates. Sample usage: `mutate(obj).add<mixin>("foo", param2).add<other_mixin>(42)` * Reduce library memory footprint * Optional external allocators per domain. Every memory allocation should pass through them. * Make use of the fact that a BIG execution time improvement can be made if a user has no mixins or messages defined in a dynamic library (and has no plans to add such) * Integration with Boost.Serialization. As long as the mixins of an object are serializable, the object will be, too. * "Static" mixins. As long as they're not mutated in or out, it provides a faster message execution. * Reflection. Create objects with mixins by string. Call messages by string. * Object mutation injections. Automatically add some mixins when others are present. Substitute a mentioned mixin with another. Ban a mixin from being added to an object. 3. When humankind becomes a Kardashev type two civilization: * Integration with Boost.Thread. Call messages for a specific thread. * User-defined message hooks. Sample implementation with messages called on objects on another device through Boost.Asio. * A way to mutate static mixins in and out. Slight mutation execution penalty. * Some magic to make it work even faster. * Integration with Boost.Python and luabind. * Remove C++03 backward compatibility???? * Library being accepted in Boost???? I think I will be done with the items form list one by April (some of them are even semi-implemented) and with the items of list two by the end of the year (and if I have more free time maybe even sooner). As for the items in the this list... well... they are nice to think about. I do have at least some vague ideas for each of them, but then again, this is list three. Any questions, comments, and suggestions are welcome. ------ Borislav Stanimirov ------ PS: Whoa. I'm sorry this post turned out so long. I didn't expect it to.

6 22

[Lockfree] ringbuffer
by Rich E 17 Feb '13

17 Feb '13

First off, all Boost.Lockfree tests in trunk are passing for me on clang 4.0 on OS X, hurrah! Thank you Tim for working on this for so long... I'm running through the examples now, only with the outdated documentation as a guide (more than a couple years old). I cannot find the ringbuffer container - was it renamed or removed altogether during the review period? I notice spsc_queue acts awefully like a ringbuffer, and it's implementation contains many

2 6

Track system Connection failing
by Vicente Botet 16 Feb '13

16 Feb '13

While connecting to the Trac system https://svn.boost.org/trac/boost/newticket I'm getting svn.boost.org uses an invalid security certificate. The certificate expired on 16/02/2013 17:02. The current time is 16/02/2013 17:25. (Error code: sec_error_expired_certificate) Could others confirm this behavior? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Track-system-Connection-failing-tp464291… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[array] failures in c++11 mode
by Tim Blechmann 15 Feb '13

15 Feb '13

hi, r82834 seems to break compilation of boost.array when compiled in c++11 mode: ../../../boost/array.hpp:131:9: error: body of constexpr function ‘constexpr const T& boost::array<T, N>::operator[](boost::array<T, N>::size_type) const [with T = boost::heap::detail::skew_heap_node<q_tester, false>*; long unsigned int N = 2ul; boost::array<T, N>::const_reference = boost::heap::detail::skew_heap_node<q_tester, false>* const&; boost::array<T, N>::size_type = long unsigned int]’ not a return-statement the boost.heap testsuite exposes this failure: http://www.boost.org/development/tests/trunk/developer/output/Sandia-gcc-4-… thnx, tim

5 9

setting <cxxflags> and <linkflags> in Jamfile?
by Oliver Kowalke 14 Feb '13

14 Feb '13

Hello, if the define BOOST_USE_XYZ is given at b2/bjam command-line how can I set special compiler- and linker-flags in the Jamfile? something like this: Jamfile.v2: *project boost/abc : requirements <toolset>gcc-4.7,<defined>BOOST_USE_XYZ:<cxxflags>-fxyz <toolset>gcc-4.7,<defined>BOOST_USE_XYZ:<linkflags>"-static-libxyz" <link>static <threading>multi : source-location ../src : usage-requirements <link>shared:<define>BOOST_ABC_DYN_LINK=1 ; * if the lib is build with b2 toolset=gcc cxxflags="-DBOOST_USE_XYZ" then -fxyz static-libxyz is applied to the compiler otherwise not. How can I achieve this behaviour? best, Oliver

2 2

Re: [boost] [smart ptr] Any interest in copy-on-write pointer for C++11?
by Andreas Pfaffenbichler 14 Feb '13

14 Feb '13

hi ralph! a heavy argument for a 'COW' pattern is made here: http://cppnow.org/session/value-semantics-and-concepts-based-polymorphism ( 'copy_on_write' class template included). maybe it could be interesting to compare your 'cow_ptr' to this 'copy_on_write'. but no doubt: the direct support of 'COW' in boost would fill e need thank you for your efforts! best regards andreas pfaffenbichler

7 20

[gil] ToolBox uploaded
by Christian Henning 14 Feb '13

14 Feb '13

Hi all, I finally have managed to upload the "toolbox" extension for boost::gil. The toolbox provides some helpful extension for gil that are too small to be an extension themselves. There are: * color spaces: cmyka, gray_alpha, hsl, hsv, lab, xyz * metafunctions: channel_type_to_index, is_bit_aligned, is_similar, is_homogeneous, get_num_bits, channel_type, get_pixel_type, pixel_bit_size * image types: indexed_image * color converters: gray -> rgba I would need some help hooking up the tests and doc generation. Let me know if you any questions or improvements. Regards, Christian

3 9

Relational database library (was: [GSOC] Are we going to participate?)
by Mateusz Loskot 14 Feb '13

14 Feb '13

On 14 February 2013 09:40, Roland Bock <rbock(a)eudoxos.de> wrote: > On 2013-02-14 06:04, Michael Marcin wrote: >> - relational database library (what ever happened with boost and soci?) > FYI: > I am currently working on a C++11 SQL library. Once you declare your > table structures in C++, it will allow you to express queries very close > to SQL: For example: > > TabSample t; > auto results = sql::select(sql::distinct, t.b, t.c) > .from(t) > .where(t.a > 7 and t.b != "cheesecake") > .order_by(t.c).run(db); > > for (auto row: results) > { > int a = row.a; > std::string c = row.c; > } > > The library will take care of escaping (to prevent code injection), the > compiler will enforce type safety (e.g. disallow comparison of integral > and string values). There will also be a lot of sanity checks at compile > time, for instance you cannot call .from() twice. It will even be able > to tell you, if you are referencing tables, which are missing in > .from(), etc. > > No more string concatenation and hoping to get the syntax right. The > compiler will tell you, if you do it wrong. > No more indexed access to string results. Result rows will allow you to > access individual columns by name (and they will have a decent type). > [...] Roland, It all sounds exciting. I remember the discussion long time ago we had, with similar ideas brainstormed [1], where you also asked this question, later discussed with Maciej: "Maybe it would make sense to add such a layer as an option to SOCI?" FYI, in SOCI, we're planning [2] to move SOCI towards C++11 It likely may happen during SOCI 4.0.0 release. So, I'd be interested in taking another look at this and having such layer adopted in SOCI too. Where I could learn about your solution more? [1] http://lists.boost.org/Archives/boost/2010/09/170983.php [2] https://github.com/SOCI/soci/wiki/Roadmap Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Git] Documentation update
by Beman Dawes 14 Feb '13

14 Feb '13

The "Git and Modular Boost" documentation has been updated: * The GitHub mothership with be github.com/boostorg * Full history for the current trunk and branches/release will be available. * There are now active milestone and issue trackers for the conversion. See https://svn.boost.org/trac/boost/wiki/WikiStart#GitandModularBoost --Beman

10 31

adding comment to boost_1_54_0.qbk?
by Oliver Kowalke 14 Feb '13

14 Feb '13

Is it allowed to add an entry for updated libraries in public_html/live/feed/history/boost_1_54_0.qbk? Oliver

2 1

[smart ptr] Any interest in copy-on-write pointer for C++11?
by Ralph Tandetzky 14 Feb '13

14 Feb '13

Hi, is there any interest in a copy-on-write pointer implementation? I wrote a cow_ptr<T> template class for C++11 which has the following use cases: 1. They are well suited as pimpl pointers for classes with value semantics. With most other smart pointers it is always necessary to reimplement the copy constructor, and the copy assignment operator, sometimes also the destructor. This is not necessary here and you'll get the right semantics and even the additional performance gain due to lazy copying. A futher advantage is that constness of cow pointer member functions propagates to the Impl object naturally making it easier to write const-correct code. // central_class_with_value_semantics.h class CentralClassWithValueSemantics { public: // ... public interface goes here ... // private: struct Impl; // forward declaration cow_ptr<Impl> m; }; // central_class_with_value_semantics.cpp struct CentralClassWithValueSemantics::Impl { // ... definition of hidden members goes here ... // } This is called the pimpl idiom, or private implementation idiom, handle body idiom, or compiler firewall idiom. 2. For classes with members whose copy-operations are expensive and/or which take a lot of space in memory, these members can be wrapped in a cow pointer. An example are matrix or image classes whose data might be stored in a std::vector. The matrix header information may be changed without deep copy. This boosts performance and optimizes memory usage, but at the same time retains the value semantics one feels comfortable with. class Matrix { public: // ... public interface goes here ... // private: size_t nRows, nCols; // can be touched without deep copy. cow_ptr<std::vector<float>> data; // copy-on-write } In such classes the default version of copy and move construction will usually work just fine. 3. You can add cloning to a class hierarchy from the outside. With cow_ptr<Base> a( new Derived1 ); cow_ptr<Base> b( new Derived2 ); cow_ptr<Base> c; c = a; // performs a shallow copy. c->doSomething(); // makes a deep copy of a as a Derived1 class. // There is no slicing involved. you copy Base objects polymorphically. The class Base can even be abstract here. It is only required that Derived1 and Derived2 be CopyConstructible. 4. You can create arrays with elements that retain polymorphic behaviour and have genuine value sematics at the same time with std::vector<cow_ptr<Base>> polymorphic_array_with_value_semantics; -- There are probably other use cases. I published the code on github ( https://github.com/ralphtandetzky/cow_ptr) Any suggestions for improvements would be greatly appreciated. Regards, Ralph Tandetzky.

10 42

[container] varray aka static_vector
by Andrew Hundt 13 Feb '13

13 Feb '13

As Adam mentioned in an earlier thread we have renamed static_vector to varray to better represent how it works like an array with size without requiring the values to be default constructible, and to better distinguish it from hybrid_vector. varray location: https://svn.boost.org/svn/boost/sandbox/varray/ Documentation: https://svn.boost.org/svn/boost/sandbox/varray/doc/html/index.html One open question is if the 3rd strategy parameter should be public or in the detail namespace. Based on some of the feedback we moved the strategy from container to container_detail, and made the public version varray<typename T, std::size_t N>. However, we wanted to get others' thoughts on this change. Additionally, should primitives be default initialized with the contents of memory like an array or value initialized to 0 like a standard container in the constructor, resize(), and emplace_back()? Generally, built-in types are initialized when the constructor is called explicitly. For example: int a; // a has the value of underlying memory int b = int(); // b has a value of 0 Right now the default behavior of our container is more like a vector than an array when creating values using the default ctor. Default constructable values are explicitly initialized in the varray ctor, resize(), emplace() and emplace_back() functions, even when they are trivially constructable. We find this behavior more intuitive and therefore we have made it the default. If the performance needs to be improved slightly the behavior may be changed or disabled in container_detail::varray_traits<V, C, S>. Here is an example demonstrating the current default behavior: vector<int> vec(3); varray<int, 3> varr(3); array<int, 3> arr; vec[0] == varr[0] and vec[0] != arr[0] Any feedback is very much appreciated. Cheers! Andrew Hundt Adam Wulkiewicz

5 19

[bind] Boost.Bind compile error with msvc-11 and msvc-10
by Ian Emmons 13 Feb '13

13 Feb '13

I have attached a short, self-contained test case that uses Boost.Bind. this test case compiles and runs correctly with the following tool sets: darwin (gcc 4.2.1 on MacOS 10.8) clang (clang on MacOS 10.8) gcc (gcc 4.7 on Ubuntu 12.04) msvc-9 (Visual Studio 2008 on Windows 7) It fails to compile on these: msvc-11 (Visual Studio 2012 on Windows 7) msvc-10 (Visual Studio 2010 on Windows 7) I have also attached the error messages from msvc-11, which seem to indicate that Boost.Bind is the problem. Can anyone shed any light on this issue? Is this an error in my usage of Boost.Bind? A Boost.Bind bug? A Visual Studio bug? Something else? Thanks, Ian

6 7

[Contract] Eagerly waiting...
by Robert Jones 13 Feb '13

13 Feb '13

Hi Lorenzo (or anyone who knows) AFAICS your contract library seems to have been approved for a while, but not made it into a release. Do you have an ETA for this? Thx, Rob.

2 1

[container] boost::container::vector, hybrid_vector, and performance
by Andrew Hundt 13 Feb '13

13 Feb '13

After some of the varray discussion and interest in hybrid_vector I modified an existing synthetic benchmark from the C++Next site (cpp-next.com) to test varray, boost::container::vector, boost::container::vector<T, stack_allocator>, and std::vector. Essentially for each container it times constructing a container of containers of primitives, std::sort, std::rotate, and destruction. Note that the test calls reserve() when setting up each container so that each gets a fair shot and isn't unfairly bogged down by a simple allocation optimization. The short results summary: varray was generally at or near the top for performance due to its simplicity, and interestingly on almost all platforms std::vector significantly outperformed boost::container::vector, which edged out boost::container::vector<T, stack_allocator>. Of course these are synthetic tests of only a subset of these containers’ functionality using only primitives so it should not be construed to necessarily represent the performance of these containers for other uses. Nonetheless I thought it may be interesting for discussion. There is also an additional benchmark of Adam Wulkiewicz’s rtree using linux clang comparing varray, container::vector, and std::vector with similar results. One question this leads me to ask is if someone might be able to illustrate a significant advantage hybrid_vector could have over boost::container::vector<T, stack_allocator>? The test can be found at: https://svn.boost.org/svn/boost/sandbox/varray/example/bench_varray.cpp Results are below. Cheers! Andrew Hundt --------------------------------------------------------------------------------------------------------------------------- Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.2.0 Thread model: posix Processor 2.2 GHz Intel Core i7 Memory 16 GB 1333 MHz DDR3 Software OS X 10.8.2 (12C60) --------------------------------------------------------------------------------------------------------------------------- set stack size limit to: 17000000 bytes N = 1000 varray benchmark: construction took 10.576854s wall, 10.580000s user + 0.020000s system = 10.600000s CPU (100.2%) sort took 4.323139s wall, 4.290000s user + 0.010000s system = 4.300000s CPU (99.5%) rotate took 0.909033s wall, 0.910000s user + 0.000000s system = 0.910000s CPU (100.1%) destruction took 0.000725s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) done Total time = 15.824697s wall, 15.780000s user + 0.040000s system = 15.820000s CPU (100.0%) boost::container::vector benchmark construction took 11.656541s wall, 11.180000s user + 0.320000s system = 11.500000s CPU (98.7%) sort took 5.213782s wall, 4.940000s user + 0.000000s system = 4.940000s CPU (94.7%) rotate took 0.003201s wall, 0.010000s user + 0.000000s system = 0.010000s CPU (312.4%) destruction took 2.482177s wall, 0.640000s user + 2.000000s system = 2.640000s CPU (106.4%) done Total time = 19.367074s wall, 16.770000s user + 2.330000s system = 19.100000s CPU (98.6%) boost::container::vector benchmark with stack_allocator construction took 11.698265s wall, 11.110000s user + 0.430000s system = 11.540000s CPU (98.6%) sort took 5.227070s wall, 5.180000s user + 0.000000s system = 5.180000s CPU (99.1%) rotate took 0.003778s wall, 0.010000s user + 0.000000s system = 0.010000s CPU (264.7%) destruction took 2.493007s wall, 0.510000s user + 1.900000s system = 2.410000s CPU (96.7%) done Total time = 19.433571s wall, 16.810000s user + 2.340000s system = 19.150000s CPU (98.5%) std::vector benchmark construction took 11.605458s wall, 11.400000s user + 0.300000s system = 11.700000s CPU (100.8%) sort took 2.256151s wall, 2.250000s user + 0.000000s system = 2.250000s CPU (99.7%) rotate took 0.003200s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 2.498035s wall, 0.370000s user + 2.040000s system = 2.410000s CPU (96.5%) done Total time = 16.374640s wall, 14.020000s user + 2.350000s system = 16.370000s CPU (100.0%) varray/boost::container::vector total time comparison: wall = 0.817093 user = 0.940966 system = 0.0171674 (user+system) = 0.828272 varray/(boost::container::vector + stack_allocator) total time comparison: wall = 0.814297 user = 0.938727 system = 0.017094 (user+system) = 0.82611 varray/std::vector total time comparison: wall = 0.966415 user = 1.12553 system = 0.0170213 (user+system) = 0.966402 --------------------------------------------------------------------------------------------------------------------------- Windows VS2012 Core2Duo P7350 2GHz, 3GB Ram --------------------------------------------------------------------------------------------------------------------------- N = 1000 varray benchmark: construction took 18.901735s wall, 18.798121s user + 0.000000s system = 18.798121s CPU (99.5%) sort took 3.093771s wall, 3.260421s user + 0.000000s system = 3.260421s CPU (105.4%) rotate took 0.336938s wall, 0.280802s user + 0.000000s system = 0.280802s CPU (83.3%) destruction took 0.000270s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) done Total time = 22.339054s wall, 22.339343s user + 0.000000s system = 22.339343s CPU (100.0%) boost::container::vector benchmark construction took 18.757410s wall, 18.595319s user + 0.202801s system = 18.798121s CPU (100.2%) sort took 0.120896s wall, 0.140401s user + 0.000000s system = 0.140401s CPU (116.1%) rotate took 0.004482s wall, 0.015600s user + 0.000000s system = 0.015600s CPU (348.0%) destruction took 0.282280s wall, 0.046800s user + 0.171601s system = 0.218401s CPU (77.4%) done Total time = 19.167624s wall, 18.798121s user + 0.374402s system = 19.172523s CPU (100.0%) boost::container::vector benchmark with stack_allocator construction took 18.811076s wall, 18.361318s user + 0.312002s system = 18.673320s CPU (99.3%) sort took 0.134590s wall, 0.218401s user + 0.000000s system = 0.218401s CPU (162.3%) rotate took 0.004111s wall, 0.015600s user + 0.000000s system = 0.015600s CPU (379.5%) destruction took 0.279619s wall, 0.031200s user + 0.280802s system = 0.312002s CPU (111.6%) done Total time = 19.231975s wall, 18.626519s user + 0.592804s system = 19.219323s CPU (99.9%) std::vector benchmark construction took 19.587929s wall, 19.359724s user + 0.234002s system = 19.593726s CPU (100.0%) sort took 0.112920s wall, 0.124801s user + 0.000000s system = 0.124801s CPU (110.5%) rotate took 0.002486s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 0.262937s wall, 0.031200s user + 0.218401s system = 0.249602s CPU (94.9%) done Total time = 19.968799s wall, 19.515725s user + 0.452403s system = 19.968128s CPU (100.0%) varray/boost::container::vector total time comparison: wall = 1.16546 user = 1.18838 system = 0 (user+system) = 1.16517 varray/(boost::container::vector + stack_allocator) total time comparison: wall = 1.16156 user = 1.19933 system = 0 (user+system) = 1.16234 varray/std::vector total time comparison: wall = 1.1187 user = 1.14468 system = 0 (user+system) = 1.11875 --------------------------------------------------------------------------------------------------------------------------- Windows mingw_4_7 -O2 Core2Duo P7350 2GHz, 3GB Ram --------------------------------------------------------------------------------------------------------------------------- N = 1000 varray benchmark: construction took 13.752772s wall, 13.447286s user + 0.000000s system = 13.447286s CPU (97.8%) sort took 2.207612s wall, 2.449216s user + 0.000000s system = 2.449216s CPU (110.9%) rotate took 0.381684s wall, 0.452403s user + 0.000000s system = 0.452403s CPU (118.5%) destruction took 0.000265s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) done Total time = 16.348433s wall, 16.348905s user + 0.000000s system = 16.348905s CPU (100.0%) boost::container::vector benchmark construction took 16.736949s wall, 15.631300s user + 1.060807s system = 16.692107s CPU (99.7%) sort took 5.170353s wall, 5.226034s user + 0.000000s system = 5.226034s CPU (101.1%) rotate took 0.001871s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 0.537667s wall, 0.124801s user + 0.374402s system = 0.499203s CPU (92.8%) done Total time = 22.453639s wall, 20.982135s user + 1.435209s system = 22.417344s CPU (99.8%) boost::container::vector benchmark with stack_allocator construction took 16.227005s wall, 15.412899s user + 0.624004s system = 16.036903s CPU (98.8%) sort took 4.376050s wall, 4.477229s user + 0.000000s system = 4.477229s CPU (102.3%) rotate took 0.001871s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 0.523920s wall, 0.109201s user + 0.514803s system = 0.624004s CPU (119.1%) done Total time = 21.134513s wall, 19.999328s user + 1.138807s system = 21.138135s CPU (100.0%) std::vector benchmark construction took 15.182662s wall, 14.149291s user + 0.904806s system = 15.054096s CPU (99.2%) sort took 1.408413s wall, 1.528810s user + 0.000000s system = 1.528810s CPU (108.5%) rotate took 0.001668s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 0.451160s wall, 0.046800s user + 0.421203s system = 0.468003s CPU (103.7%) done Total time = 17.049415s wall, 15.724901s user + 1.326008s system = 17.050909s CPU (100.0%) varray/boost::container::vector total time comparison: wall = 0.728097 user = 0.779182 system = 0 (user+system) = 0.729297 varray/(boost::container::vector + stack_allocator) total time comparison: wall = 0.773542 user = 0.817473 system = 0 (user+system) = 0.773432 varray/std::vector total time comparison: wall = 0.958885 user = 1.03968 system = 0 (user+system) = 0.958829 --------------------------------------------------------------------------------------------------------------------------- Linux clang_3_0_6 -O2 Core2Duo P7350 2GHz, 3GB Ram --------------------------------------------------------------------------------------------------------------------------- set stack size limit to: 9000000 bytes N = 1000 varray benchmark: construction took 27.455347s wall, 27.360000s user + 0.050000s system = 27.410000s CPU (99.8%) sort took 5.683607s wall, 5.750000s user + 0.010000s system = 5.760000s CPU (101.3%) rotate took 1.651716s wall, 1.560000s user + 0.000000s system = 1.560000s CPU (94.4%) destruction took 0.002050s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) done Total time = 34.810039s wall, 34.700000s user + 0.060000s system = 34.760000s CPU (99.9%) boost::container::vector benchmark construction took 39.073566s wall, 33.070000s user + 5.960000s system = 39.030000s CPU (99.9%) sort took 13.405286s wall, 13.440000s user + 0.020000s system = 13.460000s CPU (100.4%) rotate took 0.011300s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 1.005573s wall, 0.810000s user + 0.150000s system = 0.960000s CPU (95.5%) done Total time = 53.509749s wall, 47.330000s user + 6.130000s system = 53.460000s CPU (99.9%) boost::container::vector benchmark with stack_allocator construction took 39.457245s wall, 33.660000s user + 5.790000s system = 39.450000s CPU (100.0%) sort took 13.454378s wall, 13.190000s user + 0.050000s system = 13.240000s CPU (98.4%) rotate took 0.013398s wall, 0.040000s user + 0.000000s system = 0.040000s CPU (298.5%) destruction took 1.007952s wall, 0.860000s user + 0.300000s system = 1.160000s CPU (115.1%) done Total time = 53.947026s wall, 47.750000s user + 6.140000s system = 53.890000s CPU (99.9%) std::vector benchmark construction took 31.662683s wall, 25.550000s user + 6.240000s system = 31.790000s CPU (100.4%) sort took 3.102917s wall, 2.870000s user + 0.080000s system = 2.950000s CPU (95.1%) rotate took 0.010094s wall, 0.020000s user + 0.000000s system = 0.020000s CPU (198.1%) destruction took 1.002616s wall, 0.770000s user + 0.210000s system = 0.980000s CPU (97.7%) done Total time = 35.793019s wall, 29.220000s user + 6.530000s system = 35.750000s CPU (99.9%) varray/boost::container::vector total time comparison: wall = 0.650536 user = 0.73315 system = 0.00978793 (user+system) = 0.650206 varray/(boost::container::vector + stack_allocator) total time comparison: wall = 0.645263 user = 0.726702 system = 0.00977199 (user+system) = 0.645018 varray/std::vector total time comparison: wall = 0.972537 user = 1.18754 system = 0.00918836 (user+system) = 0.972308 --------------------------------------------------------------------------------------------------------------------------- Linux gcc_4_7_2 -O2 Core2Duo P7350 2GHz, 3GB Ram --------------------------------------------------------------------------------------------------------------------------- set stack size limit to: 9000000 bytes N = 1000 varray benchmark: construction took 27.677216s wall, 27.560000s user + 0.050000s system = 27.610000s CPU (99.8%) sort took 5.934591s wall, 6.080000s user + 0.010000s system = 6.090000s CPU (102.6%) rotate took 1.720024s wall, 1.590000s user + 0.000000s system = 1.590000s CPU (92.4%) destruction took 0.002077s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) done Total time = 35.350653s wall, 35.240000s user + 0.060000s system = 35.300000s CPU (99.9%) boost::container::vector benchmark construction took 38.196097s wall, 32.530000s user + 5.830000s system = 38.360000s CPU (100.4%) sort took 12.107587s wall, 12.070000s user + 0.010000s system = 12.080000s CPU (99.8%) rotate took 0.011146s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 1.054511s wall, 0.680000s user + 0.190000s system = 0.870000s CPU (82.5%) done Total time = 51.383338s wall, 45.290000s user + 6.030000s system = 51.320000s CPU (99.9%) boost::container::vector benchmark with stack_allocator construction took 37.421275s wall, 31.590000s user + 5.840000s system = 37.430000s CPU (100.0%) sort took 12.009866s wall, 11.930000s user + 0.020000s system = 11.950000s CPU (99.5%) rotate took 0.013459s wall, 0.010000s user + 0.000000s system = 0.010000s CPU (74.3%) destruction took 1.053435s wall, 0.770000s user + 0.300000s system = 1.070000s CPU (101.6%) done Total time = 50.511806s wall, 44.300000s user + 6.170000s system = 50.470000s CPU (99.9%) std::vector benchmark construction took 31.849724s wall, 25.920000s user + 5.760000s system = 31.680000s CPU (99.5%) sort took 3.244223s wall, 3.240000s user + 0.110000s system = 3.350000s CPU (103.3%) rotate took 0.010454s wall, 0.000000s user + 0.000000s system = 0.000000s CPU (n/a%) destruction took 1.054326s wall, 0.780000s user + 0.280000s system = 1.060000s CPU (100.5%) done Total time = 36.173664s wall, 29.950000s user + 6.150000s system = 36.100000s CPU (99.8%) varray/boost::container::vector total time comparison: wall = 0.687979 user = 0.778097 system = 0.00995025 (user+system) = 0.687841 varray/(boost::container::vector + stack_allocator) total time comparison: wall = 0.699849 user = 0.795485 system = 0.00972447 (user+system) = 0.699425 varray/std::vector total time comparison: wall = 0.977248 user = 1.17663 system = 0.0097561 (user+system) = 0.977839 --------------------------------------------------------------------------------------------------------------------------- Linux clang_3_0_6 -O2 Core2Duo P7350 2GHz, 3GB Ram Additional benchmark of Adam Wulkiewicz’s rtree --------------------------------------------------------------------------------------------------------------------------- ins[s] qB[s] qiwo[s] qn[s] qnP5[s] qnB[s] rem[s] mem[MB] - container::vector 10.8 14.4 6.9 3.1 4.8 6.0 5.7 184.1 - std::vector 10.9 13.5 6.9 3.4 5.2 5.9 5.4 274,8 - varray 10.2 12.6 6.3 2.8 4.5 5.8 4.9 207,1 So in this case varray is slightly faster from both and consumes less memory than std::vector.

6 10

[iostreams] Check zlib/bzip2 availability on configuration checks
by Kohei Takahashi 13 Feb '13

13 Feb '13

Hi all, I attached a patch for preventing build error with the environment which provides no zlib and/or bzip2. This patch detects zlib.h and bzlib.h availability on configuration checks timing. It also should work with any environment variable (e.g. ZLIB_SOURCE,BZIP2_SOURCE, ...). Suggestions and comments welcome. Thanks, Kohei Takahashi

1 0

[mpl] is_lambda_expression bug?
by James Hirschorn 12 Feb '13

12 Feb '13

The compile-time assertion fails in the following program. I have tried with more than one version of boost including 1.53. Is it a bug? Shall I report it? -------------------------------------------------- #include <boost/mpl/assert.hpp> #include <boost/mpl/lambda.hpp> #include <boost/mpl/plus.hpp> namespace mpl = boost::mpl; struct MetafunctionClass { template<typename T1, typename T2> struct apply { typedef typename mpl::plus<T1,T2>::type type; }; }; BOOST_MPL_ASSERT((mpl::is_lambda_expression<MetafunctionClass>)); int main(int argc, char * argv[]) { } --------------------------------------------------

4 12