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

hierarchy_tree container
by Morgan Freeberg 06 Nov '12

06 Nov '12

Ready to assess the level of interest and look into the possibility of a preliminary submission on my container library. I needed something to organize objects of type T, into a simple tree with parent-child relationships, which could then be filtered and listed. Also needed the container to maintain a "current add" position if you will, much like an output file stream, so I could feed tree structure data into it, for example as when reading from XML. I have the logic for this nicely separated into a header that seems to meet all the Boost coding guidelines, although I know a peer review process would likely yield helpful improvements that aren't immediately obvious to me. The doc file I prepared goes into much greater detail how this all works...would there be interest in looking into such a thing?

2 1

[type_traits] possible regression on is_function trait
by Vicente J. Botet Escriba 06 Nov '12

06 Nov '12

Hi, I don't know if this is a regression on Boost.TypeTraits or if I'm using incorrectly the is_function trait. John, could you confirm there is a bug in is_function? Best, Vicente Test output: Sandia-darwin-4.4 - thread - async__async_p / darwin-4.4 Rev 81191 / Mon, 5 Nov 2012 06:30:00 +0000 *Report Time: *Mon, 5 Nov 2012 14:19:58 +0000 Compile [2012-11-05 07:50:44 UTC]: fail "/opt/local/bin/g++-mp-4.4" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -dynamic -gdwarf-2 -fexceptions -fPIC -Wextra -Wno-long-long -fpermissive -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -c -o "/Volumes/scratch/kbelco/boost/results/boost/bin.v2/libs/thread/test/async__async_p.test/darwin-4.4/debug/threading-multi/sync/futures/async/async_pass.o" "../libs/thread/test/sync/futures/async/async_pass.cpp" In file included from ../boost/type_traits/is_convertible.hpp:28, from ../boost/thread/detail/move.hpp:13, from ../boost/thread/future.hpp:20, from ../libs/thread/test/sync/futures/async/async_pass.cpp:28: ../boost/type_traits/is_function.hpp: In instantiation of 'boost::detail::is_function_chooser<false>::result_<boost::rv<boost::rv<boost::packaged_task<int()> > >&>': ../boost/type_traits/is_function.hpp:60: instantiated from 'boost::detail::is_function_impl<boost::rv<boost::rv<boost::packaged_task<int()> > >&>' ../boost/type_traits/is_function.hpp:102: instantiated from 'boost::is_function<boost::rv<boost::rv<boost::packaged_task<int()> > >&>' ../boost/type_traits/is_convertible.hpp:354: instantiated from 'const bool boost::detail::is_convertible_impl<boost::rv<boost::packaged_task<int()> >&, boost::rv<boost::rv<boost::packaged_task<int()> > >&>::value' ../boost/type_traits/is_convertible.hpp:480: instantiated from 'boost::is_convertible<boost::rv<boost::packaged_task<int()> >&, boost::rv<boost::rv<boost::packaged_task<int()> > >&>' ../boost/thread/future.hpp:2717: instantiated from 'boost::future<T> boost::async(boost::launch, R (*)()) [with R = int]' ../libs/thread/test/sync/futures/async/async_pass.cpp:117: instantiated from here ../boost/type_traits/is_function.hpp:52: error: forming pointer to reference type 'boost::rv<boost::rv<boost::packaged_task<int()> > >&'

3 5

[test] BOOST_TEST - universal testing tool
by Gennadiy Rozental 06 Nov '12

06 Nov '12

Hi, Based on a discussion on mini-review thread I make some changes to the universal testing tool interface and now it look as follows (similar interfaces on WARN and REQUIRE levels): BOOST_CHECK_ASSERTION(A) - new expression template based testing tool BOOST_TEST(A,M) := BOOST_CHECK_ASSERTION(A) if M is not supplied or BOOST_CHECK_MESSAGE(A,M) if M is supplied. BOOST_TEST (and it's siblings BOOST_TEST_WARN and BOOST_TEST_REQUIRE) is intended to become a primary (only?) testing tools from now on. It replaces and deprecates right away following tools: BOOST_CHECK BOOST_CHECK_MESSAGE BOOST_CHECK_EQUAL, BOOST_CHECK_NE, BOOST_CHECK_LT, BOOST_CHECK_LE, BOOST_CHECK_GT, BOOST_CHECK_GE There are still some tools which are not directly replaceable. I have some ideas how we can get there, but your input is appreciated: 1. BOOST_CHECK_THROW, BOOST_CHECK_EXCEPTION, BOOST_CHECK_NO_THROW We can probably leave these as is. Alternatively we'll need to postpone expression evaluation with separate BOOST_TEST_DELAYED tool. We also need to introduce special tags unit_test::throws, unit_test::no_throw: BOOST_TEST_DELAYED(foo(), unit_test::throws<my_exception>() ); BOOST_TEST_DELAYED(foo(), unit_test::throws<my_exception>(predicate) ); BOOST_TEST_DELAYED(foo(), unit_test::throws( my_exception(...) ) ); BOOST_TEST_DELAYED(foo(), unit_test::no_throw() ); Later form will match to exact exception value. We might be able to fit into BOOST_TEST interface, but that would require somehow we need to recognize executable entity as special case: BOOST_TEST( foo, unit_test::throws<my_exception>() ); Not quite sure if this is possible. 2. BOOST_CHECK_CLOSE, BOOST_CHECK_CLOSE_FRACTION, BOOST_CHECK_SMALL We can deal with these by introducing couple special tags: BOOST_TEST(a == 1.5, unit_test::tolerance(1e-6) ); BOOST_TEST(a == 0.003, unit_test::percent_tolerance(1e-6) ); BOOST_TEST(a, unit_test::small(1e-3) ); On a plus side we'll be able to use these in new previously unavailable way: BOOST_TEST(a > 1.1, unit_test::tolerance(1e-6) ); This would test that value of a either > 1.1 or within a fraction tolerance of it. 3. BOOST_CHECK_PREDICATE Similar to (1) we need to delay predicate execution. Might be easier to leave it be. 4. BOOST_CHECK_EQUAL_COLLECTIONS I think using overloading of equality comparisons we should be able to support this directly: BOOST_TEST( expr == std::vector<int>{1,2,3,4}); 5. BOOST_CHECK_BITWISE_EQUAL We can introduce yet another tag to deal with this: BOOST_TEST(a == 0xA1FB, unit_test::bitwise ); As usual any comments are welcome. Gennadiy

7 16

[locale] [filesystem] Windows local 8 bit encoding
by Thiel, Bjoern 06 Nov '12

06 Nov '12

Hi, developing platform independent code I really like the convenience functions conv::to_utf, conv::from_utf, and conv::utf_to_utf from locale. Why not add something like conv::local8bit_to_utf and conv::local8bit_from_utf following the rational from filesystem (path encoding conversions): template < typename CharType > std::basic_string< CharType > local8bit_to_utf ( std::string const & text, method_type how = default_method ) { char const * encoding = impl::local8bit_encoding() ; return to_utf< CharType >( text, encoding, how ) ; } template< typename CharType > std::string local8bit_from_utf ( std::basic_string< CharType > const & text, method_type how = default_method ) { char const * encoding = impl::local8bit_encoding() ; return from_utf< CharType >( text, encoding, how ) ; } with char const * local8bit_encoding() { #ifdef WIN32 UINT codepage = AreFileApisANSI() ? GetACP() : GetOEMCP() ; return windows_codepage_to_encoding( codepage ) ; #else return "UTF-8" ; #endif } and with (better using a map) char const * windows_codepage_to_encoding( int const codepage ) { switch (codepage) { case 874: return "windows-874" ; case 932: return "Shift_JIS" ; // but should be "Windows-31J" ; case 936: return "GB2312" ; case 949: return "KS_C_5601-1987" ; case 950: return "Big5" ; case 1250: return "windows-1250" ; case 1251: return "windows-1251" ; case 1252: return "windows-1252" ; case 1253: return "windows-1253" ; case 1254: return "windows-1254" ; case 1255: return "windows-1255" ; case 1256: return "windows-1256" ; case 1257: return "windows-1257" ; case 1258: return "windows-1258" ; case 20127: return "US-ASCII" ; case 20866: return "KOI8-R" ; case 20932: return "EUC-JP" ; case 21866: return "KOI8-U" ; case 28591: return "ISO-8859-1" ; case 28592: return "ISO-8859-2" ; case 28593: return "ISO-8859-3" ; case 28594: return "ISO-8859-4" ; case 28595: return "ISO-8859-5" ; case 28596: return "ISO-8859-6" ; case 28597: return "ISO-8859-7" ; case 28598: return "ISO-8859-8" ; case 28599: return "ISO-8859-9" ; case 28603: return "ISO-8859-13" ; case 28605: return "ISO-8859-15" ; case 50220: return "ISO-2022-JP" ; case 50225: return "ISO-2022-KR" ; case 51949: return "EUC-KR" ; case 54936: return "GB18030" ; case 65001: return "UTF-8" ; default: { std::ostringstream message ; message << "Unknown codepage " << codepage ; throw std::invalid_argument( message.str() ) ; } } } Best regards Bjoern.

5 10

[geometry] Can't build docs?
by John Maddock 06 Nov '12

06 Nov '12

I'm trying to build the PDF of the geometry docs for the 1.52 release, but the build is failing: warning: Tag `SHOW_DIRECTORIES' at line 162 of file Doxyfile has become obsolete. To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u" warning: Tag `HTML_ALIGN_MEMBERS' at line 257 of file Doxyfile has become obsolete. To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u" M:/data/boost/branches/release/boost/geometry/strategies/spherical/distance_haversine.hpp:106: warning: found </em> at different nesting level (7) than expected (4) M:/data/boost/branches/release/boost/geometry/strategies/spherical/distance_haversine.hpp:107: warning: found </em> at different nesting level (7) than expected (4) M:/data/boost/branches/release/boost/geometry/strategies/spherical/distance_haversine.hpp:113: warning: end of comment block while expecting command </em> M:/data/boost/branches/release/boost/geometry/strategies/spherical/distance_haversine.hpp:113: warning: end of comment block while expecting command </em> M:/data/boost/branches/release/boost/geometry/strategies/spherical/distance_haversine.hpp:106: warning: found </em> at different nesting level (7) than expected (4) M:/data/boost/branches/release/boost/geometry/strategies/spherical/distance_haversine.hpp:107: warning: found </em> at different nesting level (7) than expected (4) M:/data/boost/branches/release/boost/geometry/strategies/spherical/distance_haversine.hpp:113: warning: end of comment block while expecting command </em> M:/data/boost/branches/release/boost/geometry/strategies/spherical/distance_haversine.hpp:113: warning: end of comment block while expecting command </em> warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (M:\data\boost\branches\release\b2.exe) is 2011.04.00 warning: Boost.Build core (at M:/data/boost/branches/release/tools/build/v2) is 2011.12-svn ...patience... ...found 318 targets... ...updating 3 targets... quickbook.quickbook-to-boostbook ..\..\..\bin.v2\libs\geometry\doc\msvc-10.0\debug\threading-multi\geometry.xml Generating Output File: ..\..\..\bin.v2\libs\geometry\doc\msvc-10.0\debug\threading-multi\geometry.xml generated/get.qbk:32: error: Syntax Error near column 2. generated/get.qbk:32: error: Syntax Error near column 3. generated/get.qbk:32: error: Syntax Error near column 3. generated/get.qbk:69: error: Syntax Error near column 2. generated/get.qbk:69: error: Syntax Error near column 3. generated/get.qbk:69: error: Syntax Error near column 3. Error: Error count: 6. Any ideas? BTW I see the same failures on Trunk and release branches. Thanks, John.

1 0

[array] compile-time checked access
by Tobias Loew 06 Nov '12

06 Nov '12

Hi, I was just rewriting some old code with hard coded indices for array access and though that compile-time checked access to array elements would be a nice thing. Maybe there are smart compilers out there that emit warnings or errors for a hard coded out-of-bounds access, but my compiler does not. So, code like compiles without warnings or erros. Now, adding the following functions to array would make it possible to write which results in the expected error messages. Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/array-compile-time-checked-access-tp4638… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 8

shared_ptr<X[5]>
by Peter Dimov 06 Nov '12

06 Nov '12

Now that we (are going to) have shared_ptr<X[]>, what should shared_ptr<X[5]> do? >From user point of view, it seems obvious that this is as good a pointer to an array as shared_ptr<X[]> is, so it should behave similarly, having op[] and an element_type of X. >From a generic point of view, this could potentially break code that assumes that shared_ptr<T>::get() always returns a T*, even when T is X[5]. But how common is such a scenario? On the other hand, it will actually _fix_ generic code of the form shared_ptr<T> p( new T ); when T is X[5].

2 1

Re: [boost] C++ announcements coming tomorrow
by Brian Wood 05 Nov '12

05 Nov '12

From: Paul Mensonides > In that last announcement talk alone together with the follow-up Q & A > there are numerous "subtle" bits of marketing. The entire general trend > is one of attempting to turn a product (software) into a service. That > is an anti-consumer nickle-and-dime model which is just as anti-consumer > as trying to trick people that can't afford something into making > payments. It is just as anti-consumer as many other related things > occurring in the software industry nowadays--microtransactions being one > of them. I bet MS investors would think differently. Is there another option available to them than services? -- Brian Wood Ebenezer Enterprises -- so far G-d has helped us. http://webEbenezer.net

2 1

Boost mpi, serialization and shared_ptr
by Gabriel 05 Nov '12

05 Nov '12

Hello, Has this problem been solved? I have the same problems, I have a class with a shared_ptr member which does not compile with MPI skeleton and content. I receive the same error: *class boost::mpi::packed_skeleton_* *iarchive' has no member named 'reset' *and so on (I refere to the older posts) Thanks for any reply! BR Gabriel Nützi

1 0

[iterator] Library name (was [website] Wrong library name)
by Daniel James 04 Nov '12

04 Nov '12

On 4 November 2012 07:51, Michel Morin <mimomorin(a)gmail.com> wrote: > Boost.Iterator is listed as "Iterators" (note the plural form) in > > * http://www.boost.org/doc/libs/ > * trunk/boost/libs/libraries.htm > > But it should be "Iterator". I'll fix this in a sec, although 'libs/libraries' will only be updated in 1.53. I replied with an 'iterator' subject so that the appropriate people might see this.

2 2

Help! Detecting that two template aliases are equal.
by Matt Calabrese 04 Nov '12

04 Nov '12

In working on Boost.Generic I need, in multiple parts of the library, to detect if two template aliases are equivalent. For instance, this is required when comparing the compatibility of an automatically generated concept map of a less-refined concept with an explicitly created concept map for the less-refined concept when the concept in question has an associated class template. This seems like it shouldn't be too difficult, but apparently my understanding of template aliases is incomplete: //////////////////// // Create a template template< class > struct template_ {}; // Make a simple alias of the template template< class A > using template_alias = template_< A >; // Create a metafunction to determine if two unary type templates are the same template< template< class > class L, template< class > class R > struct templates_are_the_same { static bool constexpr value = false; }; template< template< class > class T > struct templates_are_the_same< T, T > { static bool constexpr value = true; }; // In Clang and GCC, the following static_assert will be triggered static_assert( templates_are_the_same< template_, template_alias >::value , "Templates are not the same." ); //////////////////// This behavior is observed in both Clang and GCC, though I haven't verified that it is correct behavior in the standard. Assuming that it is in fact standard, can anyone conceive of a way around this limitation? I've considered passing dummy arguments to the templates based on the template parameter list and checking that the resultant types are equal, but I'd like to avoid that if at all possible, since it seems like it would be difficult or impossible to support certain templates properly (I.E. consider the template parameter list of a template where one parameter type is dependent on another, like std::integral_constant). This type of detection is very important in making Boost.Generic work as closely to N2914 as possible so any workaround, however hairy, would be a huge help. -- -Matt Calabrese

5 8

[test] linking issues on trunk
by Vicente J. Botet Escriba 04 Nov '12

04 Nov '12

Hi, I have found some linking issues (see bellow) with Boost.Test ubuntu gcc-4.4.6,gcc-4.6.1.0(c++0x),intel-12.1.3.0(c++0x). I'm linking with boost_unit_test_framework. Should other libraries be added? Best, Vicente P.S. This worked well before. time bjam --build-dir=/tmp/bin.v2 toolset=gcc-4.4.6,gcc-4.6.1.0x,intel-12.1.3.0x -q -d2 gcc.link /tmp/bin.v2/boost/bin.v2/libs/thread/test/test_thread.test/gcc-4.4.6/debug/threading-multi/test_thread "g++-4.4" -Wl,-R -Wl,"/tmp/bin.v2/boost/bin.v2/libs/chrono/build/gcc-4.4.6/debug/threading-multi" -Wl,-R -Wl,"/tmp/bin.v2/boost/bin.v2/libs/system/build/gcc-4.4.6/debug/threading-multi" -Wl,-R -Wl,"/tmp/bin.v2/boost/bin.v2/libs/thread/build/gcc-4.4.6/debug/threading-multi" -Wl,-rpath-link -Wl,"/tmp/bin.v2/boost/bin.v2/libs/chrono/build/gcc-4.4.6/debug/threading-multi" -Wl,-rpath-link -Wl,"/tmp/bin.v2/boost/bin.v2/libs/system/build/gcc-4.4.6/debug/threading-multi" -Wl,-rpath-link -Wl,"/tmp/bin.v2/boost/bin.v2/libs/thread/build/gcc-4.4.6/debug/threading-multi" -o "/tmp/bin.v2/boost/bin.v2/libs/thread/test/test_thread.test/gcc-4.4.6/debug/threading-multi/test_thread" -Wl,--start-group "/tmp/bin.v2/boost/bin.v2/libs/thread/test/test_thread.test/gcc-4.4.6/debug/threading-multi/test_thread.o" "/tmp/bin.v2/boost/bin.v2/libs/chrono/build/gcc-4.4.6/debug/threading-multi/libboost_chrono.so.1.52.0" "/tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a" "/tmp/bin.v2/boost/bin.v2/libs/thread/build/gcc-4.4.6/debug/threading-multi/libboost_thread.so.1.52.0" "/tmp/bin.v2/boost/bin.v2/libs/system/build/gcc-4.4.6/debug/threading-multi/libboost_system.so.1.52.0" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -g -pthread /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(unit_test_main.o): In function `boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/unit_test_main.ipp:92: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::framework::impl::apply_filters(unsigned long)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:506: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:533: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:537: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:548: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o):/mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:603: more undefined references to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' follow /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `visit': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:686: undefined reference to `boost::unit_test::decorator::for_test_unit::apply(boost::unit_test::test_unit&)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::framework::init(boost::unit_test::test_suite* (*)(int, char**), int, char**)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:691: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:698: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::framework::run(unsigned long, bool)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:1008: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:1045: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::ut_detail::label_filter::visit(boost::unit_test::test_unit const&)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:217: undefined reference to `boost::unit_test::test_unit::has_label(boost::unit_test::basic_cstring<char const>) const' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(framework.o): In function `boost::unit_test::ut_detail::remove_disabled::visit(boost::unit_test::test_unit const&)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/framework.ipp:300: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(progress_monitor.o): In function `boost::unit_test::traverse_test_tree(boost::unit_test::test_unit const&, boost::unit_test::test_tree_visitor&, bool)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/tree/traverse.hpp:46: undefined reference to `boost::unit_test::traverse_test_tree(boost::unit_test::test_case const&, boost::unit_test::test_tree_visitor&, bool)' /mnt/boost/trunk/libs/thread/test/../../../boost/test/tree/traverse.hpp:48: undefined reference to `boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&, bool)' /tmp/bin.v2/boost/bin.v2/libs/test/build/gcc-4.4.6/debug/link-static/threading-multi/libboost_unit_test_framework.a(results_reporter.o): In function `boost::unit_test::results_reporter::make_report(boost::unit_test::report_level, unsigned long)': /mnt/boost/trunk/libs/thread/test/../../../boost/test/impl/results_reporter.ipp:181: undefined reference to `boost::unit_test::traverse_test_tree(unsigned long, boost::unit_test::test_tree_visitor&, bool)' collect2: ld returned 1 exit status ...failed gcc.link /tmp/bin.v2/boost/bin.v2/libs/thread/test/test_thread.test/gcc-4.4.6/debug/threading-multi/test_thread... ...failed updating 1 target...

2 1

[website] Wrong library name
by Michel Morin 04 Nov '12

04 Nov '12

Boost.Iterator is listed as "Iterators" (note the plural form) in * http://www.boost.org/doc/libs/ * trunk/boost/libs/libraries.htm But it should be "Iterator". Regards, Michel

1 0

[variant] awkward recursion
by Dave Abrahams 03 Nov '12

03 Nov '12

I've been playing around with variant a bit and decided to try to build a data structure for storing json. I came up with several different approaches but none are super-satisfying. I'd like some feedback. (If you need a refresher on what's in json, the front page of http://json.org tells all). In the abstract, json looks like: struct null {}; typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, object, array, bool > value; Naturally, this code isn't legal C++, so I set about making it be. The first thing I tried was to use recursive_wrapper<>, as the documentation implies it is the most flexible way to do this sort of thing. Unfortunately, there's no clean way to reformulate this type in a way that allows recursive_wrapper work, because the type that needs to be wrapped in recursive_wrapper includes "value" in its name, and I can't forward-declare it. The only way to forward-declare a type X, as far as I know, is: struct X; // or class X; So to try to get recursive_wrapper to work, I tried a couple of formulations that started with that, but it turns out that when you do this, you end up not needing recursive_wrapper at all struct value; typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, object, array, bool > value_base; struct value : value_base { value() {}; template <class T> value(T const& x) : base(x) {} // no move; I'm in C++03-land value& operator=(value const& x) { base::operator=(x); return *this; } } }; I don't know if I've missed some things that should be in that "value" class. I know that a recursive variant, in principle, requires a pointer indirection somewhere, so I was wondering if, had I wrapped object and array in recursive_wrapper as below, I would have been adding an unnecessary inefficiency. typedef variant< null, std::string, double, reference_wrapper<object>, reference_wrapper<array>, bool > value_base; I also wondered whether that would give me different results from typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, std::map<std::string, reference_wrapper<value> >, std::vector<reference_wrapper<value> >, bool > value_base; and which one was better. Does anyone know? I think that should be in the docs. Using recursive_variant_ works out quite nicely, except that it doesn't allow me to separately declare "object" and "array" and re-use them in the definition of "value": typedef boost::make_recursive_variant< null , std::string , double , std::map<std::string, boost::recursive_variant_> , std::vector<boost::recursive_variant_> , bool >::type value; I also wonder if I'm getting an unnecessary inefficiency in that case. Lastly, what flexibility am I sacrificing by using this approach? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

9 28

[1.52.0] Release candidates available
by Marshall Clow 03 Nov '12

03 Nov '12

Release candidate files for 1.52.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, -- Marshall

5 5

New Stepanov lecture videos released by A9
by Mat Marcus 02 Nov '12

02 Nov '12

http://www.youtube.com/user/A9Videos/videos?flow=grid&view=1

1 0

[string_algo] Documentation Complaint
by Dave Abrahams 02 Nov '12

02 Nov '12

Wow, I found this documentation hard to use! I wanted to translate various 1-character substrings into new strings, e.g. translate the TAB character ('\t') to its textual escaped representation "\\t", and I went looking for an algorithm to do it. After 5 minutes of searching, I *think* the algorithm isn't there, but I'm still not sure. I nearly went blind (well, not really, but it felt that way) looking at http://www.boost.org/doc/libs/1_51_0/doc/html/string_algo/reference.html#he… because there's no vertical whitespace. More importantly, there's *no description of what any of these algorithms actually do*! ... calming down ... Heh, very terse descriptions are in the "Quick Reference": http://www.boost.org/doc/libs/1_51_0/doc/html/string_algo/quickref.html These might be good enough for me, but I always figure I'm going to get complete detail from the non-quick reference, and this one is just a dump of all the declarations, so I had to go around in a big circle and begin writing this documentation complaint before I found it. Can this situation be improved? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 2

[Variant] Documentation Questions/Notes
by Dave Abrahams 02 Nov '12

02 Nov '12

- What does this mean? Full value semantics, including adherence to standard overload resolution rules for conversion operations. Seems to me that it's impossible *not* to adhere to any standard rules. Is the part after the comma vacuous? - The "temporary heap backup" technique seems to have a hole: 1. Copy-construct the content of the left-hand side to the heap; call the pointer to this data backup. 2. Destroy the content of the left-hand side. 3. Copy-construct the content of the right-hand side in the (now-empty) storage of the left-hand side. 4. In the event of failure, copy backup to the left-hand side storage. 5. In the event of success, deallocate the data pointed to by backup. What happens in the event of a failure in step 4? - I note the section on motivation doesn't mention the new capabilities of C++11 unions. Now some of the constructs are possible... *if* you do all the bookeeping yourself. - I note that the implementation has at least some support for move semantics and yet the docs require all elements to be "bounded types", which in turn are required to be CopyConstructible. Is that accurate, or outdated? - "completeness at the point of template instantiation" is a rather odd thing to put in a concept. I suggest that that should be just part of the requirements on the variant template rather than on BoundedType. - Do the semantics for are_strict_equals at http://www.boost.org/doc/libs/1_51_0/doc/html/variant/tutorial.html differ from those of the built-in equality operator? - it might be worth making the point that recursive variants offer the ability to define complex linked data structures *as value types* in a type- and memory-safe manner. I.e. no explicit handling of pointers; copy construction and assignment "just work," etc. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

3 5

[optional] Doc Nit
by Dave Abrahams 01 Nov '12

01 Nov '12

> A typical approach is to consider the existence of a > valid return value as a postcondition, so that if the > function cannot compute the value to return, it has > either undefined behavior (and can use assert in a > debug build) or uses a runtime check and throws an > exception if the postcondition is violated. This is a > reasonable choice for example, for function (A), This is possibly technically correct, but confusing. Undefined behavior results from precondition violations, not postcondition violations. I'd suggest: One approach is to make a non-negative argument a precondition, so when violated the function has undefined behavior (and can use assert in a debug build). Alternatively, one can use a runtime check and specify that an exception is thrown if the postcondition cannot be satisfied. These are a reasonable choice for example, for function (A), I'm not sure the first sentence is quite right for your needs, but I'm out of time to improve it further. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 1

Re: [boost] make_shared_array and allocate_shared_array
by Glen Fernandes 01 Nov '12

01 Nov '12

On Thu Nov 1 2012 at 1:48 PM, Olaf van der Spek <ml(a)vdspek.org> wrote: > Does Glen's make_shared_array have variants for both initialized and uninitialized allocations (for builtin types)? Hi Olaf, I just updated the code to only have initialization for non POD types: https://github.com/glenfe/glenfern/commit/05ea1f429bddfe7f07e4bb392db248492… Glen

1 0

Review: Code Review: allocate_shared_array and make_shared_array
by Glen Fernandes 01 Nov '12

01 Nov '12

A big thank you to Peter Dimov who has been kind enough to review my code. The open question we both have is whether these functions should continue to return shared_ptr<T> or be changed to return shared_array<T> after some modification to shared_array (both to support construction from (or conversion to) a shared_ptr and to have things like a no-throw constructor). Updated code: https://github.com/glenfe/glenfern/tree/master/boost Original blog post: http://glenfernandes.wordpress.com/ Some context from our discussion: Peter Dimov wrote: > Providing two separate sets of functions doesn't appeal to me much. > make_shared_array should return whatever we decide they should return. You > are right about shared_array's default constructor though, and maybe we can > use this opportunity to fix it (and add move support), and perhaps provide a > way for people to get a shared_ptr from a shared_array, if they have to work > with other people who only use that in their APIs. :-) > > Let's see what the Boost list will say. > > Glen Fernandes wrote: > > 1. I keep the functions returning shared_ptr but rename them to > > allocate_shared_sequence and make_shared_sequence. I think they are still > > useful for people who would want to avoid shared_array in their APIs for > > various reasons (e.g. its default constructor can throw). > >

1 0