- Boost - lists.boost.org

Re:Re: [boost] question re linux serialization test results
by Robert Ramey 22 Jul '04

22 Jul '04

Jonathan Wakely wrote: On Wed, Jul 21, 2004 at 04:29:23PM -0700, Robert Ramey wrote: >> http://boost.sourceforge.net/regression-logs/cs-Linux.html shows >> errors in build of the serialization libraries related to pthreads, >etc.... >This is a known (*) issue with GCC 3.4, you must explicitly define >BOOST_DISABLE_THREADS if you are not going to link with -pthread. Hmm - isn't this something that could/should be automatically handled by the bjam - gcc toolset file? I'm not really sure what I should do here. Things worked before but I suspect that this was because I had static-linking specified as the default - but I removed this to address some other confusion and relied on the default set "somewhere else" I'm not at all sure what I should do here. I think it is also affecting builds with Itel 7.1 on linux. Robert Ramey

2 1

question re linux serialization test results
by Robert Ramey 22 Jul '04

22 Jul '04

http://boost.sourceforge.net/regression-logs/cs-Linux.html shows errors in build of the serialization libraries related to pthreads, etc.... I suspect this is a build issue of some sort. When this first occurred I tweaked the jamfile. I suspect there might be some stale *.o files. Thanks for looking into this whoever you are. Robert Ramey

5 8

RE: [boost] Re: What is it with boost and tinyurl?
by Max Khesin 22 Jul '04

22 Jul '04

> -----Original Message----- > From: Rob Stewart [mailto:stewart@sig.com] > If you were aware that foo.com/~mark became mark.com, you could > make the translation having the other information in the original > URL. And how often are you aware of foo.com/~mark becoming mark.com? m This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

Re:[boost] typeof: type registration
by Robert Ramey 22 Jul '04

22 Jul '04

Arkadiy Vertleyb wrote: <big snip> >Any comments? I'm just taken a cursory look at this scheme. But it likes it might be similar or even identical to that implemented by the serialization library to recover types for serialized pointers. See extended_type_info. Robert Ramey

2 1

Latest Boost.Threads regression results on intel-8.0-linux
by Michael Glassford 22 Jul '04

22 Jul '04

All of the Boost.Threads tests for intel-8.0-linux at http://boost.sourceforge.net/regression-logs/cs-Linux/developer/thread.html are failing, and the entire error report looks like: <quote> Compiler output: Linker output: Chmod1 ../bin/boost/libs/thread/test/test_barrier.test/intel-8.0-linux/debug/threading-multi/test_barrier Run output: EXIT STATUS: 139 </quote> Every test failing with the same error indicates a fundamental problem, but since I don't have access to the compiler or OS, I have no way of troubleshooting the problem. Any help would be appreciated. Mike

4 9

RE: counting_iterator_test.hpp fails on aC++
by DY, JERRY U (SBCSI) 22 Jul '04

22 Jul '04

Sorry... sent the original e-mail too quickly. Here's why I say that std::numeric_limits has to be specialized and the is_specialized member must be set to true if you want a particular type to pass the is_numeric test. template <class T> struct is_numeric_impl { typedef ::boost::static_assert_test< sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( ::boost::is_integral<char>::value ) >) > boost_static_assert_typedef_33 ; static const bool value = std::numeric_limits<T>::is_specialized ; }; template <> class std::numeric_limits<my_int2> { public: static bool const is_specialized = true; }; -Jerry -----Original Message----- From: DY, JERRY U (SBCSI) Sent: Wednesday, July 21, 2004 4:08 PM To: boost(a)lists.boost.org Subject: counting_iterator_test.hpp fails on aC++ I'm troubleshooting counting_iterator_test.hpp. In particular: FILE: counting_iterator_test.cpp class my_int2 { public: ... typedef std::bidirectional_iterator_tag iterator_category; }; FILE: counting_iterator.hpp template <class Incrementable, class CategoryOrTraversal, class Difference> struct counting_iterator_base { typedef typename detail::ia_dflt_help< CategoryOrTraversal , mpl::apply_if< is_numeric<Incrementable> , mpl::identity<random_access_traversal_tag> , iterator_traversal<Incrementable> > >::type traversal; ... } The class my_int2 is passed as parameter "Incrementable" to counting_iterator_base, but is failing the is_numeric test so my_int2 is just a bidirectional iterator (see mpl::apply_if above). If it passes the is_numeric test, then it's a random access traversal tag. The way it passes the is_numeric test is to specialize std::numeric_limits like so: template <> class std::numeric_limits<my_int2> { public: static bool const is_specialized = false; }; But I don't find that in the source. It appears that aC++ doing the right thing, but I know I'm wrong. Could somebody please help?? Thanks! -Jerry

2 1

Boost.Threads metacomm regression tests not working
by Michael Glassford 22 Jul '04

22 Jul '04

I've been mentioning this problem on the "Boost.Test problem" / "Boost.Threads problem" / "Boost.Threads status?" thread, but have been getting no help, so I thought I'd try a new thread. All of the Boost.Threads regression tests are failing due to an error like this: <quote> Cannot open include file: 'boost/thread/detail/config.hpp': No such file or directory </quote> The "missing" file is in cvs, and has been for a long time. Looking at the compiler command line, I see that the it contains -I"C:\Users\Administrator\boost\main\results\bin\boost\libs\thread\build" and no other directory; looking at the command line for other Boost libraries, I see that they also contain -I"C:\Users\Administrator\boost\main\boost". What do I need to do to get Boost.Threads to build with -I"C:\Users\Administrator\boost\main\boost"? Is it a problem with the Boost.Threads bjam file? A configuration problem with the regression tests? Something else? Mike

6 13

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 ); > 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)

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 <hinnant(a)twcny.rr.com> writes: > > > >> <nod> How's: > >> > >> scoped_lock lk1(m, defer_lock); // not locked > > ^^^^ ^^^^ > > > > Redundant. "deferred" is better. > > I seriously thought about deferred. The word, whatever it is, if > standardized, would be at namespace scope in namespace std. I was > worried about it conflicting, or with its use not being easily > associated with locks if it was just "deferred". Otoh, it is only a > tag. Maybe it is a feature, not a bug for "deferred" to be able to > influence (conflict with) things other than locks! Thanks for the > second thought. > > -Howard > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1