July 2004 - Boost - lists.preview.boost.org

rwlocks in boost::thread
by Aleksander Demko 22 Jul '04

22 Jul '04

Does boost::thread provide a rwlock primitive? I can't seem to find it. If not, is it because it's not a true primitive? or because not all OSes have this concept in their native APIs? -- // scopira.org | ninjacoder.com //

2 2

[minmax] fixes to support MSVC
by Joaquín Mª López Muñoz 22 Jul '04

22 Jul '04

The following patches make the two tests of Boost.Minmax pass for MSVC 6.5: 1. minmax.hpp: 28a29 > #include <boost/ref.hpp> There were some usages of boost::ref without including its header. I think this patch is necessary for every copmiler, not only MSVC. 2. minmax_test.hpp: 52,53c52,53 < BOOST_CHECK_EQUAL( result1.get<0>(), zero ); < BOOST_CHECK_EQUAL( result1.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result1), zero ); > … [View More]BOOST_CHECK_EQUAL( get<1>(result1), one ); 56,57c56,57 < BOOST_CHECK_EQUAL( result2.get<0>(), zero ); < BOOST_CHECK_EQUAL( result2.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result2), zero ); > BOOST_CHECK_EQUAL( get<1>(result2), one ); 62,63c62,63 < BOOST_CHECK_EQUAL( result3.get<0>(), zero ); < BOOST_CHECK_EQUAL( result3.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result3), zero ); > BOOST_CHECK_EQUAL( get<1>(result3), one ); 68,69c68,69 < BOOST_CHECK_EQUAL( result4.get<0>(), zero ); < BOOST_CHECK_EQUAL( result4.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result4), zero ); > BOOST_CHECK_EQUAL( get<1>(result4), one ); In MSVC 6.0 and later Boost.Tuple does not provide the get<>() member function, so we have to resort to the global get function. I don't think this does any harm to any other compiler. 3. minmax_element_test.hpp 0a1 > #include <boost/config.hpp> /* prevents some nasty warns in MSVC */ 35a37,38 > > BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION(custom) The first include activates pragmas in MSVC that help avoid some nasty and harmless warnings. As for the second change, the error messages clearly indicate that this macro be used. This is what I've done, and the now test compiles and runs like breeze. With these three changes, all failures for MSVC 6.5 are solved. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 28a29 > #include <boost/ref.hpp> 52,53c52,53 < BOOST_CHECK_EQUAL( result1.get<0>(), zero ); < BOOST_CHECK_EQUAL( result1.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result1), zero ); > BOOST_CHECK_EQUAL( get<1>(result1), one ); 56,57c56,57 < BOOST_CHECK_EQUAL( result2.get<0>(), zero ); < BOOST_CHECK_EQUAL( result2.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result2), zero ); > BOOST_CHECK_EQUAL( get<1>(result2), one ); 62,63c62,63 < BOOST_CHECK_EQUAL( result3.get<0>(), zero ); < BOOST_CHECK_EQUAL( result3.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result3), zero ); > BOOST_CHECK_EQUAL( get<1>(result3), one ); 68,69c68,69 < BOOST_CHECK_EQUAL( result4.get<0>(), zero ); < BOOST_CHECK_EQUAL( result4.get<1>(), one ); --- > BOOST_CHECK_EQUAL( get<0>(result4), zero ); > BOOST_CHECK_EQUAL( get<1>(result4), one ); 0a1 > #include <boost/config.hpp> /* prevents some nasty warns in MSVC */ 35a37,38 > > BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION(custom) [View Less]

2 1

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 22 Jul '04

22 Jul '04

Does it have to be in 'std'? Cannot that be under 'scoped_lock'? Do not have the docs handy. Won't lookup mechanism pick it up? > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Howard Hinnant > Sent: Thursday, 22 July 2004 10:31 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Lock unification [move] > > On Jul 21, 2004, at 7:16 PM, David Abrahams wrote: > > > Howard Hinnant <… [View More]

2 1

RE: [boost] Re: Lock unification [move]
by Batov, Vladimir 22 Jul '04

22 Jul '04

Howard, Thank you for taking on the task of shaping up the interface. That activity is of great importance. A few comments. explicit scoped_lock(mutex_type& m); scoped_lock(mutex_type& m, detail::defer_lock_type); scoped_lock(mutex_type& m, detail::try_lock_type); scoped_lock(mutex_type& m, const elapsed_time& elps_time); The problem (as I can see it) with the set above is that "deferred", "tried" and "timed" appear to be alternatives or mutually exclusive.… [View More]

3 2

RE: [boost] Re: Boost.Test and mingw (Was: [1.32 release] Intel 8 .0/Mingw regression results)
by Rob Lievaart 22 Jul '04

22 Jul '04

Hi, > Fix is in cvs. Lets see what next regression test show. Thanks, Test is running again now with the fix, and so far no lines in bjam.log complaining about wcscmp. Rob.

1 0

Tom Brinkman to become the new Review Wizard
by John Maddock 22 Jul '04

22 Jul '04

Boosters, As you will know already, we recently advertised for a Review Wizard to take over from Thomas Witt, who pioneered the role and has done an excellent job, but now has other commitments. We have had several excellent applications giving the moderators a tough choice: but in the end an excellent application and a healthy dose of enthusiasm gave Tom Brinkman the job. On behalf of all the moderators I'd like to welcome Tom to the post, and look forward to the reviews once again … [View More]

1 0

[bug, patch] Bashism in boost/tools/build/v2/tools/common.jam
by Philipp Frauenfelder 22 Jul '04

22 Jul '04

Hi There is a bashism in common.jam of Boost.Build v2. I have reported this problem to the jamboost mailing list but apparently, nobody picked it up (no reply whatsoever). The normal 'sh' shell does not allow 'export VAR=value' but only 'VAR=value;export VAR' instead. The patch against 1.24 is attached (I also removed some trailing white space, there is more 4 lines down but I did not correct it). Regards -- Philipp | work: pfrauenf(a)math.ethz.ch +41 44 632 60 38 Frauenfelder | home: … [View More]

1 0

question regarding vacpp tests and mpl
by Robert Ramey 22 Jul '04

22 Jul '04

The serialization library is failing all tests with IBM visual age compiler. Errors occur within mpl. a) Can any one give me some hints to try to address this? b) Is there not a new version of mpl that is going to uploaded. Maybe if I just wait things will improve? Robert Ramey

2 1

RE: Boost.Test and mingw (Was: [boost] [1.32 release] Intel 8.0/M ingw regression results)
by Rob Lievaart 22 Jul '04

22 Jul '04

Hi, Hi Volodya, There are some lines in test_tools.cpp to work around this but are defined only for GCC 3.3 and I am using 3.2 :-( There was a discussion on this isssue (I think) 2 days ago: http://lists.boost.org/MailArchives/boost/msg67745.php Where Gennadiy says he wil fix it. But that has not made it into cvs yet. This is the cause of a lot of errors in the report. I "hacked" around it locally by also testing for GCC 3.2 and that clears up a lot of the problems. I could post a … [View More]

3 2

Problems with program_options using GCC 3.4 on FreeBSD
by Jonathan Wakely 22 Jul '04

22 Jul '04

Hi Boosters, I've just tried building the program_options library, using GCC 3.4.1 on FreeBSD 4.8 and hit a couple of compilation errors. One error is caused by the platform, one by the compiler's stdlib. The first problem is line 116 in libs/program_options/src/utf8_codecvt_facet.cpp gcc-C++-action bin/boost/libs/program_options/build/libboost_program_options.a/gcc/debug/utf8_codecvt_facet.o /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp: In … [View More]member function `virtual std::codecvt_base::result boost::program_options::detail::utf8_codecvt_facet_wchar_t::do_out(mbstate_t&, const wchar_t*, const wchar_t*, const wchar_t*&, char*, char*, char*&) const': /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp:116: error: `WCHAR_MAX' undeclared (first use this function) /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp:116: error: (Each undeclared identifier is reported only once for each function it appears in.) WCHAR_MAX is not defined by FreeBSD's wchar.h. Can boost::numeric_limits<wchar_t> be used instead? The second problem is visible because I built GCC with concept-checks enabled, which means the STL containers use a version of Boost's concept checks. This reveals that boost/program_options/options_description.hpp uses an incomplete type on line 232: gcc-C++-action bin/boost/libs/program_options/build/libboost_program_options.a/gcc/debug/options_description.o In file included from /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/options_description.cpp:9: /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/boost_concept_check.h: In instantiation of `__gnu_cxx::_SGIAssignableConcept<boost::program_options::options_description>': /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/stl_vector.h:144: instantiated from `std::vector<boost::program_options::options_description, std::allocator<boost::program_options::options_description> >' /data/development/jw/src/extcvs/boost/boost/program_options/options_description.hpp:232: instantiated from here /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/boost_concept_check.h:216: error: `__gnu_cxx::_SGIAssignableConcept<_Tp>::__a' has incomplete type /data/development/jw/src/extcvs/boost/boost/program_options/options_description.hpp:142: error: forward declaration of `class boost::program_options::options_description' This error can be reproduced by compiling with -D_GLIBCXX_CONCEPT_CHECKS, or -D_GLIBCXX_DEBUG. Both the concept-checks and debug mode will reject std::vector< incomplete type >. jon -- "Nothing is true. Everything is permissible." - Hassan i Sabbah [View Less]

3 9