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

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

23 Jul '04

Jonathan Turkanis wrote: >"Edward Diener" <eddielee(a)tropicsoft.com> wrote in message >news:cdq036$1m7$1@sea.gmane.org... >> BTW, your library is great and you should never feel that because >>you don't >> hear from others about it that this indicates a lack of interest in >users. >Lack of interest??? Soemtimes it seems that the boost developers list >is really the boost serialization list. ;-) Hmmm I was just thinking the same thing re mutex/… [View More]

1 0

typeof: type registration
by Vertleyb 23 Jul '04

23 Jul '04

Hello everybody, Recently there was a discussion about a typeof emulation library. The library determines the type of an expression by passing it to a function template, encoding the type as a list of integers, "returning" them one-by-one via sizeof(), and decoding the type. One of the main problems of any such emulation is the need to associate types and templates with unique compile-time integral identifiers. This becomes even bigger problem, when expressions can contain types/templates … [View More]from different libraries. It's not quite clear how to ensure uniqueness of identifiers in this case (GUID would be an option, but it's far too big to fit into an integer). An attempt was made to generate the identifiers automatically. However, since mechanisms to achieve this always work inside only one compilation unit, there is no way to preserve the same identifiers for the same entities throughout different compilation units. Hence, inevitably, we run into the ODR violation. An attempt to work this around by defining stuff in anonimous namespace, forces everything that uses this facility to also be defined in the anonimous namespace or, again, the ODR is violated. Although compilers don't seem to care much about ODR in this particular case (meta-functions only, no runtime constructs), somehow I feel uneasy to proceed with the solution that does not quite comply to the standard. And so, once again, I tried to come-up with a registration scheme that, on the one hand, would not violate the ODR, and on the other hand, would not put a significant burden on the end user -- the crutial condition for this library to be of any use at all. Here is this scheme: The typeof library registers primitive types, as well as some other standard stuff, like functions, pointers, references, arrays, consts, etc. If the user only wants any combination of those, no additional actions is required, such as the following type: int& (*)(char[20], double&) would be handled. If, in addition to this, the user wants to handle types from other libraries, such as Spirit, Lambda, etc., it works as following: - The typeof library #defines a preprocessor constant, currently called BOOST_TYPEOF_USER_GROUP, which is the next identifier after the last one it actually used. - The Spirit library registers its types against some symbolic identifiers. Only one per file is required (inside the same file __LINE__ does the job). Something looking similarly to the include guard seems like a decent choice. In addition, Spirit defines a separate header where it enumerates all these symbolic identifiers. This header looks something like this: <boost/spirit/groups.hpp> #ifndef SPIRIT_GROUPS_HPP_INCLUDED #define SPIRIT_GROUPS_HPP_INCLUDED #include <boost/spirit/typeof/typeof.hpp> enum { SPIRIT_REGISTER_HPP = BOOST_TYPEOF_USER_GROUP, SPIRIT_LAST }; #undef BOOST_TYPEOF_USER_GROUP #define BOOST_TYPEOF_USER_GROUP SPIRIT_LAST #endif//SPIRIT_GROUPS_HPP_INCLUDED IOW, the Spirit identifiers start where the typeof library identifiers ended, and BOOST_TYPEOF_USER_GROUP is, again, the next available. - The Lambda library does the same, etc. - The user combines all the groups in a single include, effectively chaining the enums: #ifndef GROUPS_HPP_INCLUDED #define GROUPS_HPP_INCLUDED #include <boost/spirit/groups.hpp> #include <boost/lambda/groups.hpp> #endif//GROUPS_HPP_INCLUDED - The user includes this file before any registration file provided by these libraries. Since the file contains only enums, the compile-time penalty is minimal. This insures that identifiers remain fixed across compilation units. - Whenever the user needs to register her own classes, she provides identifiers by any means she prefers, such as enum, etc., starting from BOOST_TYPEOF_USER_GROUP. See http://groups.yahoo.com/group/boost/files/typeof.zip (or Spirit repository, TYPEOF_DEV branch) for how it all works together. I appologize for such a long post (if you are still here :) ) Any comments? Regards, Arkadiy [View Less]

2 1

[Boost-bugs] [ boost-Support Requests-996331 ] with constructor not allowed in union
by SourceForge.net 23 Jul '04

23 Jul '04

Support Requests item #996331, was opened at 2004-07-22 21:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=996331&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: with constructor not allowed in union Initial Comment: I get error - with '..' … [View More]

1 0

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 … [View More]

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. … [View More]

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 … [View More]

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, … [View More]

1 0