- Boost - lists.preview.boost.org

Identifying a compiler's version in a Jamfile
by Bart Garst 23 Jul '04

23 Jul '04

Is it possible to differentiate between compiler versions in a Jamfile? What I want to do is run our serialization tests (date_time) with gcc but only version 3 and up. Anyone know how to do this? Thanks, Bart Garst

4 5

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

23 Jul '04

> Batov, Vladimir wrote: > > > How 'bout > > > > scoped_lock lk1(m, defer); > > scoped_lock lk2(m, try); > > > > "try" is a keyword, last I checked. ;-) [Batov, Vladimir] Oh, my goodness. Of course, it is. LOL. Looks like I have not woken up yet. Then, I guess, I am leaning towards Howard's original scoped_lock lk1(m, defer_lock); scoped_lock lk2(m, try_lock); Minor repetition issue aside, it looks like the clearest, simplest and most consistent choice.

1 0

RE: [boost] Re: Lock unification [move]
by Glen Knowles 22 Jul '04

22 Jul '04

> From: Howard Hinnant [mailto:hinnant@twcny.rr.com] > > I mostly agree with Bronek Kozicki. Given a movable lock, Eric > > Niebler's > > proposal: > > > > scoped_lock try_lock( Mutex & m ); > > scoped_lock timed_lock( Mutex & m ); > > > > is a better try/timed interface. Heisenberg constructors must die. > > Sorry, I don't know what a Heisenberg constructor is. It's a reference to the Heisenberg uncertainty principle. Constructors that sometimes act one way and sometimes another must die. ;) > From: David Abrahams [mailto:dave@boost-consulting.com] > Howard Hinnant <hinnant(a)twcny.rr.com> writes: > > > scoped_lock lk1(m, defer_lock); // not locked > ^^^^ ^^^^ > Redundant. "deferred" is better. If you named it not_locked you wouldn't need the comment. ;) Of these three choices: 1. try, deferred 2. try_lock, deferred 3. try_lock, defer_lock I tend to like #3 the best. Glen

3 2

status/explicit-failures-markup.xml broken
by Martin Wille 22 Jul '04

22 Jul '04

Hi, someone broke status/explicit-failures-markup.xml, apparently. I'm getting these error messages from xsltproc: /boost/head-regression/boost/status/explicit-failures-markup.xml:594: parser error : Opening and ending tag mismatch: ostream line 594 and note <note>Interval IO require <ostream> header.</note> ^ /boost/head-regression/boost/status/explicit-failures-markup.xml:595: parser error : Opening and ending tag mismatch: note line 594 and mark-failure </mark-failure> ^ /boost/head-regression/boost/status/explicit-failures-markup.xml:596: parser error : Opening and ending tag mismatch: mark-failure line 591 and test </test> ^ /boost/head-regression/boost/status/explicit-failures-markup.xml:597: parser error : Opening and ending tag mismatch: test line 584 and library </library> ^ /boost/head-regression/boost/status/explicit-failures-markup.xml:1159: parser error : Opening and ending tag mismatch: library line 570 and explicit-failures-markup </explicit-failures-markup> ^ /boost/head-regression/boost/status/explicit-failures-markup.xml:1161: parser error : Premature end of data in tag explicit-failures-markup line 1 Please, make sure to quote '<' and '>' correctly in XML files. Regards, m

2 1

Re: [boost] [minmax] failure in GCC 3.4.1
by JOAQUIN LOPEZ MU?Z 22 Jul '04

22 Jul '04

----- Mensaje original ----- De: Hervé Brönnimann <hbr(a)poly.edu> Fecha: Jueves, Julio 22, 2004 8:43 pm Asunto: Re: [boost] [minmax] failure in GCC 3.4.1 > > On Jul 22, 2004, at 2:56 AM, Joaquín Mª López Muñoz wrote: > > 107c107 > > < RCIterator rfirst(last), rlast(first), rmin(min), rmax(max); > > --- > >> RCIterator rfirst(last), rlast(first), rmin, rmax; > > Joaquin: I thought I committed that patch yesterday. If not, my > mistake, you can go ahead. I always "cvs update" before committing > so I > will see it. You did commit that patch. The other three patches we were taking about some hours ago are also commited, so in principle minmax could now work for every compiler in Linux and Win32 tests. The current Linux cycle is broken, so we will have to wait until tomorrow to know. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[minmax] failure in GCC 3.4.1
by Joaquín Mª López Muñoz 22 Jul '04

22 Jul '04

GCC 3.4.1 complains with this absolutely clear run-time message (http://tinyurl.com/42bey) error: attempt to copy-construct an iterator from a singular iterator I've inspected the code of minmax_element_test.cpp and think the problem lies in lines 106-107: CIterator min, max; RCIterator rfirst(last), rlast(first), rmin(min), rmax(max); where rmin and rmax are copy-constructed from min,max, which are singular. Anyone sees a problem in fixing this? (Please find diff below.) I don't have GCC 3.4.1 available, so I can only guess this will clear the problem away. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 107c107 < RCIterator rfirst(last), rlast(first), rmin(min), rmax(max); --- > RCIterator rfirst(last), rlast(first), rmin, rmax;

2 1

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

22 Jul '04

The problem is that since my_int2 is not a random access iterator, class iterator_adaptor's member function "advance" would not compile because of the static assertion below trying to convert random_access_traversal_tag to bidirectional_traversal_tag (my_traversal). FILE: boost/iterator/iterator_adaptor.hpp:310 void advance(typename super_t::difference_type n) { // precompiled to: // typedef int assertion[sizeof(detail::static_assert_convertible_to<random_access_trav ersal_tag>(my_traversal()))]; BOOST_ITERATOR_ADAPTOR_ASSERT_TRAVERSAL(random_access_traversal_tag) m_iterator += n; } -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Thursday, July 22, 2004 7:20 AM To: boost(a)lists.boost.org Subject: [boost] Re: counting_iterator_test.hpp fails on aC++ "DY, JERRY U \(SBCSI\)" <jd2419(a)sbc.com> writes: > 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. But we don't want my_int2 to pass the is_numeric test. What's the problem? If counting_iterator_test.cpp fails there must be another reason.

2 1

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

22 Jul '04

Arkadiy Vertleyb wrote: >"Robert Ramey" <ramey(a)rrsd.com> wrote >> 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. >Most importantly, does this scheme really work in practice? Is it easy >enough for end users, and does it allow users and libraries to avoid >collisions with each other? Oh it works - its being subject to the boost torture test process as we speak. The issue of unique type identification was addressed at length during the first serialization review. If the typeid is only used within a program runtime type_info can be used. The system doesn't require type_info to be used but that's usually the most convenient - unless your compiler doesn't support runtime typing. If its to be passed from one executable to another - persistence and/or marshalling - you have to export it with some sort of key. I usually use the class name. Its all in there and even explained in the context of its usage within the serialization package. There is also a facility referred to a void_cast which is used to correctly cast from one type to another at runtime. That's the short version - you might want to check out the manual and the code. It could easily be excised from the serialization library. I only did it because I had to have it and I couldn't find anything else out there. Honestly, I'm not even sure it addresses the same issue that you do. Feel free to check it out. Robert Ramey

1 0

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