On Wed, 11 Dec 2002, Beman Dawes wrote:
> At 07:09 AM 12/9/2002, Ben Young wrote:
>
> >I have recently implemented a set of custom output iterators that allow
> >you to very trivially do escaping and quoting on data from any kind of
> >iterator source...
>
> >...
>
> >Would anyone be intere
> [mailto:[EMAIL PROTECTED]]On Behalf Of William E. Kempf
> Sent: 11 December 2002 20:42
>
[ snip ...]
>
> I agree with this. The optional<> concept takes some type and extends
> it's possible values to include a new "uninitialized" value. It seems
> wholly logical to me for this:
>
> optiona
On Wed, 11 Dec 2002, David Abrahams wrote:
> [EMAIL PROTECTED] (Dave Harris) writes:
>
> >> 1. Agreement on terms. In particular, I strongly suggest beginning
> >>with the definitions of serialization and persistence outlined by
> >>Augustus Saunders in
> >>http://lists.boost.org/MailA
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Joel de Guzman
> Sent: 11 December 2002 23:02
> To: Boost mailing list
> Subject: Re: [boost] Re: Call for Volunteers [license review]
>
>
>
> - Original Message -
> From: "Joel de Guzman"
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David Abrahams
> Sent: 04 December 2002 01:01
> To: boost
> Subject: [boost] Call for Volunteers [license review]
>
>
>
> This is a formal call for volunteers to fill out a few of the
> open-source
> [mailto:[EMAIL PROTECTED]]On Behalf Of Iain K.Hanson
> Sent: 12 December 2002 10:15
> To: 'Boost mailing list'
> Subject: RE: [boost] Formal review: Optional library
>
>
>
> assert( a == b ) // pointer semantics.
> if this used value semantics then this would mostly fail and randomly
> sucee
> i) Linux with KAI C++, Intel C++
>
> On Linux, BOOST_HAS_PTHREADS macro is defined only if we use gcc
> (config/compiler/gcc.hpp), but it's not defined for other compilers
> (KAI, Intel, etc). I found that boost.thread compiles successfully by
> the latter compilers if I defined BOOST_HAS_PTHREA
> The Win32 regression tests are working again, but there are a lot of new
> Borland failures.
>
> See http://boost.sourceforge.net/regression-logs/cs-win32-diff.html
>
> It looks like some change to a commonly used library is causing an
> assertion to fail in the Borland compiler.
Strange: I trie
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>
> Let me check if I followed your logic:
>
> optional opt(v) does a 'copy' of the 'v'; it does not hold onto the
> 'v' itself as if it were given a handle. So it clearly has deep copy
> semantics.
> Your argument is that since it has deep copy semanti
"Terje Slettebø" <[EMAIL PROTECTED]> wrote in message
082701c2a12f$15c74170$60fb5dd5@pc">news:082701c2a12f$15c74170$60fb5dd5@pc...
> >From: "Eric Woodruff" <[EMAIL PROTECTED]>
>
> > "Johan Nilsson" <[EMAIL PROTECTED]> wrote in message
> > at76e1$2ro$[EMAIL PROTECTED]">news:at76e1$2ro$[EMAIL PROTEC
At 07:28 AM 12/12/2002, John Maddock wrote:
>> The Win32 regression tests are working again, but there are a lot of
new
>> Borland failures.
>>
>> See http://boost.sourceforge.net/regression-logs/cs-win32-diff.html
>>
>> It looks like some change to a commonly used library is causing an
>> asserti
On Wednesday 11 December 2002 22:11, Herve Bronnimann wrote:
> There was also some work on algorithms. I have taken a very close look
> at binary trees, and priority queues (Dietmar Kuehl's beta submission),
> and linear-time sorting (radix, etc.) which is in the sandbox. I've also
> implemented a
On Thursday 12 December 2002 01:06, Jeremy Maitin-Shepard wrote:
> It seems quite clear from the Boost.Compatbility rationale that extensions
> to the C++ standard library do not belong in it.
OK. And indeed boost _is_ an extension. So I think it makes sense to
implement all these extensions in bo
- Original Message -
From: "Iain K.Hanson" <[EMAIL PROTECTED]>
To: "'Boost mailing list'" <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 8:20 AM
Subject: RE: [boost] Formal review: Optional library
>
>
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Iain K.Hanson
> > Sent: 12 December
I personally would like that very much, and as a matter of fact I was going
to write a hash class of my own but didn't have the time yet...
There are some perfect hash functions on the web, my favorite is
http://www.burtleburtle.net/bob/
Yakov
- Original Message -
From: "Jeremy Maitin-She
Toon Knapen wrote:
My only remaining question is : if the STL (used by the developer) already
provides the algorithm (in the std namespace however), would'nt it be better
to reuse it.
IMHO yes. (Although the algorithm need not be in std namespace
-- see http://lists.boost.org/MailArchives/bo
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 9:41 AM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> >
> > Let me check if I followed your
Fernando Cacciola said:
> From: "Peter Dimov" <[EMAIL PROTECTED]>
>> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>> > Perhaps this could be called get_pointer() as shared_ptr<> does.
>>
>> get_pointer() would be... less objectionable. :-)
>>
> This particular free function is precisely intended t
Toon Knapen wrote:
When including some boost libraries Visual C++ 6.0 (with Intel compiler 7.0
and STLPort) is unable to generate the browse info. Have others experienced
the same effect or is there some workaround ?
From the top of my head, so take care. IIRC browse info generation is
still
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 12:18 PM
Subject: Re: [boost] Formal review: Optional library
> Fernando Cacciola said:
> > From: "Peter Dimov" <[EMAIL PROTECTED]>
> >> From: "Fernando Cacciola" <
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > Yes, I thought about that, too. But if the current swap semantics are
> > retained, it should simply be removed. Otherwise optional::swap must
> > offer at least swap(T&, T&)'s guarantee.
> >
> I'm not sure I follow.
> What are swap(T&, T&) guarante
I'm having a problem using fold with the example from the reference
page. I can get the following example from copy to comile as fold
namespace mpl = boost::mpl;
using mpl::_;
typedef mpl::vector10_c answer;
typedef mpl::fold<
mpl::range_c
, mpl::vector<>
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>> > Yes, I thought about that, too. But if the current swap semantics are
>> > retained, it should simply be removed. Otherwise optional::swap must
>> > offer at least swap(T&, T&)'s guarantee.
>> >
>> I'm n
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Dimov
> Optional does not have pointer semantics. Two optionals can
> never alias each
> other. "Consistent with pointer semantics" doesn't make
> sense. Optional is
> not a pointer. Don't try to make it into one; you'll arrive
> at shared_ptr.
From: "Iain K.Hanson" <[EMAIL PROTECTED]>
>
> :-) true. But it also does not have container semantics either.
> I prefered your analogy with a special valued INT. Given that we
> have
> *opt1 == *opt2
> for ordinary value comparisons
But this doesn't work when one of the optionals is uninitialized
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Dimov
> Sent: 12 December 2002 17:09
>
> From: "Iain K.Hanson" <[EMAIL PROTECTED]>
> >
> > :-) true. But it also does not have container semantics either.
> > I prefered your analogy with a special valued INT. Given that we
> > have
> > *opt1 == *opt
> * What kinds of applications are we intending to serve?
Something that I would really like to see, is the cooperation between the
serialization library and the dynamic_any type (developed by Alexander
Nasonov, not yet into Boost). More specifically, it must be possible to
serialize and deser
From: "Iain K.Hanson" <[EMAIL PROTECTED]>
>
> Given the above, I can't see the utility of defining rel-ops with
container
> semantics.
I did not say that there is utility in the "equivalence" semantics (although
they do make specifying and testing postconditions easier.) I am saying that
these are
"Iain K.Hanson" <[EMAIL PROTECTED]> writes:
>> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Dimov
>> Sent: 12 December 2002 17:09
>>
>> From: "Iain K.Hanson" <[EMAIL PROTECTED]>
>> >
>> > :-) true. But it also does not have container semantics either.
>> > I prefered your analogy with a special va
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 1:00 PM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > > Yes, I thought about that, too. B
"Paul Mensonides" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "David Abrahams" <[EMAIL PROTECTED]>
>
>
>> David Abrahams <[EMAIL PROTECTED]> writes:
>>
>> > How can we say
>> >
>> > #if BOOST_WORKAROUND(__SUNPRO_CC, /*something involving 0x530 */)
>> >
>> > and have it ente
> [mailto:[EMAIL PROTECTED]]On Behalf Of David Abrahams
> Sent: 12 December 2002 18:16
>
>1. The contained value is part of the state. Pretending otherwise
>just confuses everything.
Whether it is initialised is orthaganal to its contained value. As
Bill Kempf said "if it walks like a du
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> To: "Boost mailing list" <[EMAIL PROTECTED]>
> Sent: Thursday, December 12, 2002 1:00 PM
> Subject: Re: [boost] Formal review: Optional library
>
>
>> From: "Fernando Cacciola
On Thu, Dec 12, 2002 at 02:54:46PM +0100, Toon Knapen wrote:
>
> [snip]
>
> My only remaining question is : if the STL (used by the developer) already
> provides the algorithm (in the std namespace however), would'nt it be better
> to reuse it. Maybe that algorithm is written in a way to offer t
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
> This is a formal call for volunteers to fill out a few of the
> open-source license evaluations at
>
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License
>
OCLC Research P
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> From: "Peter Dimov" <[EMAIL PROTECTED]>
> > True, swap()'s guarantees depend on the type. If T provides a
> > nothrow/strong/basic swap, optional::swap should be at least
> > nothrow/strong/basic, respectively. I think that this can be done
provided
>
"Iain K.Hanson" <[EMAIL PROTECTED]> writes:
>> [mailto:[EMAIL PROTECTED]]On Behalf Of David Abrahams
>> Sent: 12 December 2002 18:16
>>
>
>>1. The contained value is part of the state. Pretending otherwise
>>just confuses everything.
>
> Whether it is initialised is orthaganal to its contai
From: "Beman Dawes" <[EMAIL PROTECTED]>
> The exception class has been given additional functionality to provide a
> portable error code. Etc, etc.
Q: have you considered using standard errno codes as the portable error
code?
___
Unsubscribe & other cha
> [mailto:[EMAIL PROTECTED]]On Behalf Of David Abrahams
> Sent: 12 December 2002 19:03
>
>But it doesn't, really. If you're going to have deep constness and
>deep assignment, the only thing remaining that makes it pointer-like
>is the operator*/operator-> interface. At that point, it's just a
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 3:45 PM
Subject: Re: [boost] Formal review: Optional library
> >
> > In order to achieve this, I considered fundamental the following
> > rule of
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 3:59 PM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > From: "Peter Dimov" <[EMAIL PROTECTE
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> From: "Peter Dimov" <[EMAIL PROTECTED]>
[...]
> > if(both uninitialized)
> > {
> > // do nothing, nothrow
> > }
> > else if(one initialized, one not)
> > {
> > lhs.reset(*rhs); // strong
> > rhs.reset(); // nothrow
> > }
> > else // both initi
Fernando Cacciola said:
> From: "Peter Dimov" <[EMAIL PROTECTED]>
>> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>> > From: "Peter Dimov" <[EMAIL PROTECTED]>
>> > optional<> is not intended to replace _all_ situations were optional
>> values
>> > are used.
>> > It is itended to be used on those
From: "Peter Dimov" <[EMAIL PROTECTED]>
Oops,
> Yes it will. :-)
>
> optional m;
should have been
optional m(t);
> foo(m, m); // comparison inside yields false
>
> T * p;
and this should have been
T * p = &t;
> foo(p, p); // comparison inside yields true
_
Due to some significant changes to the optional<> class, I had to upload a
new version so that the review can continue based on the revised class.
http://groups.yahoo.com/group/boost/files/optional.zip
The new zip contains the new code, new test and new documentation.
NOTE: The header optional_d
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 5:31 PM
Subject: Re: [boost] Formal review: Optional library
>
> Fernando Cacciola said:
> > From: "Peter Dimov" <[EMAIL PROTECTED]>
> >> From: "Fernando Cacciola"
At 02:14 PM 12/12/2002, Peter Dimov wrote:
>From: "Beman Dawes" <[EMAIL PROTECTED]>
>> The exception class has been given additional functionality to provide
a
>> portable error code. Etc, etc.
>
>Q: have you considered using standard errno codes as the portable error
>code?
If I understand your
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 5:35 PM
Subject: Re: [boost] Formal review: Optional library
> From: "Peter Dimov" <[EMAIL PROTECTED]>
>
> Oops,
>
> > Yes it will. :-)
> >
> > opti
From: "Beman Dawes" <[EMAIL PROTECTED]>
>
> The alternative I considered was to try to map the system specific code
> into a POSIX errno code. However, the macros seemed messy for C++.
POSIX errno codes were what I meant, yes. On a POSIX implementation there
would be no mapping. On Win32, you can
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > optional m(t);
> >
> > > foo(m, m); // comparison inside yields false
where foo is
void foo(optional const &, optional const &);
> > >
> Nop... :-)
>
> it compares true because get_pointer(x)==get_poiner(x) is true for any x,
> whether initializ
Fernando Cacciola said:
> Due to some significant changes to the optional<> class, I had to upload
> a new version so that the review can continue based on the revised
> class.
>
> http://groups.yahoo.com/group/boost/files/optional.zip
>
> The new zip contains the new code, new test and new documen
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.lib.boost.devel
Sent: Thursday, December 12, 2002 6:24 PM
Subject: Re: Formal review: Optional library
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > > optional m(t);
> > >
> > > > foo(m, m); // comp
I think that a lot of this discussion is boiling down to whether or
not optional should sport a pointer interface at all. As previously
discussed, an optional cannot--doesn't want to--support several bits
of pointer semantics.
To me, the only really important benefit of pointer syntax is for
u
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Fernando Cacciola said:
> > Due to some significant changes to the optional<> class, I had to upload
> > a new version so that the review can continue based on the revised
> > class.
> >
> > http
"Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:
> I am already doing this in mycode. But it only hides the problem. Metrowerks
> has the header similar to MSVC one. If you will take a look into
> this header you see that C runtime debug hooks (_CRT_ERROR is part if this
> API) are gets defined i
At 04:19 PM 12/12/2002, Peter Dimov wrote:
>From: "Beman Dawes" <[EMAIL PROTECTED]>
>>
>> The alternative I considered was to try to map the system specific code
>> into a POSIX errno code. However, the macros seemed messy for C++.
>
>POSIX errno codes were what I meant, yes. On a POSIX implementa
Fernando Cacciola said:
> From: "Peter Dimov" <[EMAIL PROTECTED]>
>> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>> > > optional m(t);
>> > >
>> > > > foo(m, m); // comparison inside yields false
>>
>> where foo is
>>
>> void foo(optional const &, optional const &);
>>
>> > > >
>> > Nop... :-)
>
- Original Message -
From: "Augustus Saunders" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, December 12, 2002 6:42 PM
Subject: [boost] Re: Optional Review, consider iterators
>
> I think that a lot of this discussion is boiling down to whether or
> not optional should spor
Iain K.Hanson wrote:
> I'm having a problem using fold with the example from the reference
> page. I can get the following example from copy to comile as fold
>
> namespace mpl = boost::mpl;
> using mpl::_;
>
> typedef mpl::vector10_c answer;
>
> typedef mpl::fold<
> mp
Yitzhak Sapir <[EMAIL PROTECTED]> writes:
> I would like to offer the following definition (based on the previous
> definition given by Augustus Saunders):
>
> Serialization is the process of breaking up various application-defined
> containers of data into their components and serializing each co
Fernando Cacciola wrote:
>> I think that a lot of this discussion is boiling down to whether
or
>> not optional should sport a pointer interface at all.
>
>I think that the discussion is boiling down to whether or not
optional
>should support relational operators, and then how should these be
>def
Yitzhak Sapir wrote:
>I would like to offer the following definition (based on the
previous
>definition given by Augustus Saunders):
>
>Serialization is the process of breaking up various
application-defined
>containers of data into their components and serializing each
component
>one by one into
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
> Errors are not a good response here, unless of course that's done
> purely as an option.
I was under the impression that causing errors and/or warnings was so
developers could be "reminded" of some type of hack for some com
In-Reply-To: <[EMAIL PROTECTED]>
On Wed, 11 Dec 2002 18:17:21 -0500 David Abrahams
([EMAIL PROTECTED]) wrote:
> I'm willing to use any terms that everyone will agree to
> (including yours)
Me too.
> but whichever terms we use should be at least as clearly defined
> as what Augustus wrote.
I'm
"Paul Mensonides" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "David Abrahams" <[EMAIL PROTECTED]>
>
>> Errors are not a good response here, unless of course that's done
>> purely as an option.
>
> I was under the impression that causing errors and/or warnings was so
> devel
[EMAIL PROTECTED] (Dave Harris) writes:
>> > We could send a binary format through a "uuencode" filter, but a
>> > text format which was natively safe would be neater (and probably
>> > more efficient).
>>
>> Why would it be more efficient?
>
> Because it has more knowledge.
>
> For example, if
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
> > I was under the impression that causing errors and/or warnings was so
> > developers could be "reminded" of some type of hack for some compiler.
The
> > macro could be conditionally be defined based on whether or not you w
At 08:17 PM 12/11/2002, Jeremy Maitin-Shepard wrote:
>I forgot to mention in my previous post the following proposed ideas:
>
>A hash map and hash multimap in which a single value type is specified
>along with a traits class that is used to extract the key from the
>value type. The std::pair-spec
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
> > Optional does not have pointer semantics. Two optionals can never alias each
> > other. "Consistent with pointer semantics" doesn't make sense. Optional is
> > not a pointer. Don't try to make it into one; you'll arrive a
- Original Message -
From: "Gennaro Prota" <[EMAIL PROTECTED]>
> >Does it only emit a warning for modulus by zero too?
>
> Yes. I don't know about Kylix but all the other flavours of Borland
> C++ just give W8082 for both / and %, in constant expressions (by
> default; of course you can
At this point in time, I vote to reject the library. My vote is based
upon a review of the interface and implementation in optional.hpp of the
zip file I downloaded from the link posted by Fernando on Dec. 12, and
following the discussion via the mailing list digests. I will qualify my
vote by in
Dave Harris wrote:
>To me, "persistence"
>and "serialisation" are at different levels of abstraction.
Serialisation
>is one way to implement persistence. As such they do not compete;
they are
>not mutually incompatible alternatives.
I agree, a symmetric serialization scheme could be used as o
Adjusted at five points; please ignore the previous one.
-- Forwarded message --
At this point in time, I vote to reject the library. My vote is based
upon a review of the interface and implementation in optional.hpp of the
zip file I downloaded from the link posted by Fernando on
Most of this has probably been said before, but I wanted to make a
concise summary. I have a couple of questions and my views on them:
1) What does a Serialization library do (or make easier) that you
can't do by yourself with iostreams?
Me: Basic usages of MFC's serialization system can be rec
On Thu, Dec 12, 2002 at 08:06:12PM -0500, Beman Dawes wrote:
> [snip
> Are you aware that a hash_map proposal from Matt Austern is almost sure to
> be included in the upcoming C++ Standard Library Technical Report?
>
> See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1399.html
I was n
"Paul Mensonides" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "David Abrahams" <[EMAIL PROTECTED]>
>
>> > I was under the impression that causing errors and/or warnings was so
>> > developers could be "reminded" of some type of hack for some compiler.
> The
>> > macro could
"Dave Gomboc" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> In my opinion, optional [which perhaps ought to be may_be
> or maybe, as an earlier poster suggested, also see below] works
> best as denoting a type T', whose assignable values are the legal v
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
> > I'm not sure what you mean here. You mean overloading
> > "BOOST_WORKAROUND" to cause an error (or warning) if you use
> > "BOOST_CURRENT_VERSION"? That's no problem at all.
>
> I mean that
>
> #if BOOST_WORKAROUND(_
From: "Peter Petrov" <[EMAIL PROTECTED]>
>Something that I would really like to see, is the cooperation between the
>serialization library and the dynamic_any type (developed by Alexander
>Nasonov, not yet into Boost). More specifically, it must be possible to
>serialize and deserialize dynamic_an
My usage of "Serialization" is:
Serialization is a by directional transformation or mapping of an arbitray set
of Objects to a sequence of bytes.
The following link has a nice definition of "Serializer Pattern" which is line
with my usage.
http://www.riehle.org/computer-science-research/1996/plo
- Original Message -
From: "Paul Mensonides" <[EMAIL PROTECTED]>
> > > I'm not sure what you mean here. You mean overloading
> > > "BOOST_WORKAROUND" to cause an error (or warning) if you use
> > > "BOOST_CURRENT_VERSION"? That's no problem at all.
> >
> > I mean that
> >
> > #if BOO
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> At 07:28 AM 12/12/2002, John Maddock wrote:
> >> The Win32 regression tests are working again, but there are a lot of
> new
> >> Borland failures.
> >>
> >> See http://boost.sourceforge.net/regress
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
> And, BTW, can you show us how to do it?
Yes, pick which one of these syntax variants you want, and I'll implement
it.
[note: I'm removing all the extra wrapping parentheses here for clarity.]
Normal usage would generate
Some time ago I started what became a long discussion about the presentation
of math constants, like pi.
Eventually these discussions proved inconclusive and there seemed no
acceptable solution, although there was agreement that
collection(s) of highly accurate constants were needed.
After more t
84 matches
Mail list logo