- Boost - lists.boost.org

RE: [boost] [Boost.Test] bug
by Rozental, Gennadiy 23 Jul '04

23 Jul '04

> There's boost/compatibility/cpp_c_headers/cwctype and > boost/compatibility/cpp_c_headers/cctype. Can we use those > instead and be assured of portability? Everyone seems to be > reinventing workarounds for these nasty little beasts. I was under impression that we should only use these headers where there are no native headers with appropriate name. Isn't it true? Gennadiy.

2 1

Re:[boost] Re: Re:Re: additional boost libraries?
by Robert Ramey 23 Jul '04

23 Jul '04

Edward Diener wrote: >> Note that the serialization library relies upon Spirit 100 % for XML >> parsing. >Regarding your problems using an older version of Spirit with lesser >compilers, would it make sense to split the serialization library so that >those who never use XML parsing wouldn't need to have a correct version of >Spirit for their compiler ? As it is now the "correct" version of spirit is already part of the boost distribution if you're using a newer compiler. If you want to use an older compiler you'll have to get and "older" version of spirit. If you don't want to take the 15 minutes to do this, you can build with an older compiler and without spirit at all, you could easily modify the jamfile. Spirit is only used in the building of the library. It is not imported at all into programs that just use the serialization library. If one want's to build a library without spirit - all tests will compile - the xml ones would fail to link. I believe that the current setup and the method for addressing less frequently occurring situations is very convenient and practical. Robert Ramey

3 2

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