- Boost - lists.boost.org

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<I>::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<I>::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