- Boost - lists.preview.boost.org

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

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. However, "deferred" and, say, "try" functionalities are orthogonal. That is, as one might need to defer a blocking lock scoped_lock l(m, deferred); one might need a deferred try_lock as well. Therefore, as we are trying to provide one universal lock, it appears we have to have something complex like basic_lock(mutex_type&, const elapsed_time&, defer_type); that would address all the lock variability/configurability. Such a basic lock would not be for general consumption but rather the basis for something like: try_lock : private (?) basic_lock { ... try_lock(mutex_type& m, deferred d) : basic_lock(m, 0, d) {} } Best, V.

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