Re: [boost] Compile problem with Spirit & CodeWarrior

On Sunday, August 31, 2003, at 11:29 AM, Hartmut Kaiser wrote: Use grammars ... The article describes Spirit V1.2 (it was written nearly two years ago). ... Thanks a lot, that's very helpful. -- ___ Unsubscribe & other change

[boost] Re: Re: [boost.variant] It is possible to make a variantLessThanComparable

"Peter Dimov" <[EMAIL PROTECTED]> wrote > David Abrahams wrote: > > But, IIUC, if operator< is not provided, you'd oppose a std::less > > specialization, right? > > Right. When there is one and only one strict weak ordering (equality) for a > type, not using operator< and operator== because some us

Re: [boost] Re: Boost memory management guidelines

On Sunday, Aug 31, 2003, at 13:51 America/Denver, Peter Dimov wrote: Gregory Colvin wrote: [...] Two small corrections: shared_ptr currently uses std::allocator to allocate counts regardless. No, it uses plain new/delete by default. It is possible to get it to use std::allocator via a #define.

Re: [boost] Re: Boost memory management guidelines

On Sunday, Aug 31, 2003, at 13:13 America/Denver, David Abrahams wrote: Gregory Colvin <[EMAIL PROTECTED]> writes: But indeed allocate/construct/deallocate/destroy is more work than ^^^^ Oyeah. These two absolutely don't belong in allocator, period.

Re: [boost] Re: Boost memory management guidelines

Gregory Colvin wrote: [...] Two small corrections: > shared_ptr currently uses std::allocator to allocate counts > regardless. No, it uses plain new/delete by default. It is possible to get it to use std::allocator via a #define. [...] > versus standard Allocator > >Allocator::pointer p =

[boost] Re: lexicographic: review request?

Brian McNamara wrote: The point is, that Jan proposed to add something which has a hidden overhead and I'm not sure it's a good idea. Instead of nested if-else-cascades, the user could also write: bool operator<( const person& lhs, const person& rhs ) { return lhs.lastname != rhs.lastname

Re: [boost] Re: [boost.variant] It is possible to make a variantLessThanComparable

David Abrahams wrote: > "Peter Dimov" <[EMAIL PROTECTED]> writes: > >> If you want a second opinion, I'm in the "just provide operator== and >> operator<" camp. > > But, IIUC, if operator< is not provided, you'd oppose a std::less > specialization, right? Right. When there is one and only one stri

Re: [boost] Re: Optional, tie, and iterator_adaptor

On Sun, Aug 31, 2003 at 11:11:10AM -0700, Mat Marcus wrote: > --On Sunday, August 31, 2003 1:35 PM -0400 Brian McNamara > >On Sun, Aug 31, 2003 at 11:59:42PM +0800, Joel de Guzman wrote: > >>It's really strange (and hard to explain) that you have to > >>dereference optional. Example: > >> > >>

Re: [boost] Re: Optional, tie, and iterator_adaptor

On Sun, Aug 31, 2003 at 10:41:15AM -0700, Mat Marcus wrote: > --On Sunday, August 31, 2003 10:29 AM -0400 Brian McNamara > >First off, let me say I do think this is a compelling use-case. ... > >I missed the beginning of this thread, but I imagine the motivation > >is to avoid having to say > >

[boost] Re: [boost.variant] It is possible to make a variantLessThanComparable

"Peter Dimov" <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> "Eric Friedman" <[EMAIL PROTECTED]> writes: >> >>> Ultimately, I do not believe any ordering scheme will provide >>> meaningful, straightforward semantics. Assuming I am correct, I >>> propose that the variant library offer your

[boost] Re: Boost memory management guidelines

Gregory Colvin <[EMAIL PROTECTED]> writes: >>> But indeed allocate/construct/deallocate/destroy is more work than >> ^^^^ >> Oyeah. These two absolutely don't belong in allocator, period. Do >> any implementations even use them? Allocators exist to

[boost] Re: Optional, tie, and iterator_adaptor

"Joel de Guzman" <[EMAIL PROTECTED]> writes: > Hi, > > Here's another use-case... > > We are working on an alternative semantic action scheme with Spirit > that will be a lot more easier to use than the current scheme. With this > scheme, the signature of the semantic action will be dependent on t

[boost] Re: Optional, tie, and iterator_adaptor

"Joel de Guzman" <[EMAIL PROTECTED]> writes: > What I am trying very hard to say is to stick to only *ONE* interface > and one concept. Optional is a container. I've never seen a container in C++ which didn't have both a value interface and an element-access interface. How do you propose to ach

RE: [boost] Compile problem with Spirit & CodeWarrior

James W. Walker wrote: > Thanks, that helps, but I still have a question or two. The FAQ says > "it is best to avoid rules as arguments to the parse functions", but > then what are rules good for? How else am I going to do any > nontrivial parsing? Use grammars (see here: http://www.boost.or

Re: [boost] Re: Optional, tie, and iterator_adaptor

--On Sunday, August 31, 2003 1:35 PM -0400 Brian McNamara <[EMAIL PROTECTED]> wrote: So I completely disagree that optionals should mix the interfaces of optional and the wrapped object into one. I think there should be an explicit unwrapping operation. But this is just my opinion, based on n

Re: [boost] Compile problem with Spirit & CodeWarrior

On Aug 31, 2003, at 7:45 AM, Hartmut Kaiser wrote: Please have a look at the FAQ here: http://www.boost.org/libs/spirit/doc/faq.html#scanner_business This should solve your problem. Thanks, that helps, but I still have a question or two. The FAQ says "it is best to avoid rules as arguments to

Re: [boost] Re: Optional, tie, and iterator_adaptor

Daniel Frey <[EMAIL PROTECTED]> wrote: > Joel de Guzman wrote: >> Although I don't see this as problematic: >> >> optional x; >> if (x) >> foo(x); >> >> Or perhaps: >> >> optional x; >> if (!!x) >> foo(x); >> >> We already have an implicit conversion to safe_bo

[boost] Any interest in a string literal selector helper library?

Hi all, I have written a relatively small library which I've found pretty useful in my own projects. I have to deal with std::basic_string objects a lot in my applications, and I almost always write template code so that the same code works with both std::string and std::wstring types. The only

Re: [boost] Regression test page broken

[2003-08-31] Jeff Garland wrote: >On Sun, 31 Aug 2003 09:59:26 +0200, Martin Wille wrote >> Jeff Garland wrote: >> > The regression test page seems to be on a diet >> > >> > http://boost.sourceforge.net/regression-logs/ >> >> You can find some of the other results at >>http://boost.sourc

Re: [boost] Re: Optional, tie, and iterator_adaptor

--On Sunday, August 31, 2003 10:29 AM -0400 Brian McNamara <[EMAIL PROTECTED]> wrote: On Sun, Aug 31, 2003 at 12:34:39AM -0700, Mat Marcus wrote: In this post I will put forward a use-case or two to help see whether something a little different then the current version of optional might be usef

Re: [boost] Re: Optional, tie, and iterator_adaptor

So I completely disagree that optionals should mix the interfaces of optional and the wrapped object into one. I think there should be an explicit unwrapping operation. But this is just my opinion, based on no practical evidence/experience, and I'm sure there are trade-offs either way. I'll expl

[boost] Re: Optional, tie, and iterator_adaptor

Daniel Frey wrote: > Fernando Cacciola wrote: >> My main argument is that if those were allowed, you could write: >> >> optional opt ; >> opt = 1 ; >> int i = *opt ; >> >> and the assymetry didn't look right to me. > > I agree that this looks wrong. What about this syntax: > > optional opt; > *opt

Re: [boost] Re: Optional, tie, and iterator_adaptor

In this post I will put forward a use-case or two to help see whether something a little different then the current version of optional might be useful. I also begin making a case that a Concept like PossiblyUninitializedVariable might be more generally useful than OptionalPointee. As I mentioned i

Re: [boost] Regression test page broken

Jeff Garland wrote: The regression test page seems to be on a diet http://boost.sourceforge.net/regression-logs/ You can find some of the other results at http://boost.sourceforge.net/regression-logs/release However, I'm not sure wether that is "official" already. Regards, m ___

[boost] Re: [boost.variant] It is possible to make a variant LessThanComparable

Hello Eric, "Eric Friedman" <[EMAIL PROTECTED]> wrote > Dirk Schreib wrote: > > [...] > > In this example > > > > typedef boost::variant V; > > V v1 = T1( x ); > > V v2 = T2( y ); > > V v3 = T1( z ); > > > > v1 < v2 should always be true. And v1 < v3 should be the same as T1( x ) < > > T1(

Re: [boost] Re: Optional, tie, and iterator_adaptor

Joel de Guzman <[EMAIL PROTECTED]> wrote: > IMO, this is better: > > optional x; > if (x == none) > foo(x); I meant: optional x; if (x != none) foo(x); Of course. And following Brian's example: if (o != none) do_something(o); else maybe_do

[boost] Re: [boost.variant] It is possible to make a variant LessThanComparable

"David Abrahams" <[EMAIL PROTECTED]> wrote > "Eric Friedman" <[EMAIL PROTECTED]> writes: > > std::set< my_variant, boost::variant_less > > > I had the same thought myself, though I'd be inclined to spend a > little time searching for a better name than "less", since it doesn't > really mean that.

Re: [boost] Re: 1.30.0->1.30.2: no more thread support for Linux?

> > Threading support is on when BOOST_HAS_THREADS is defined, and off when it's > > not, or forced off by defining BOOST_DISABLE_THREADS, you'll find both of > > these mentioned in the configure generated user.hpp (and in the config > > docs). > > So if I my program runs only on systems that I kno

[boost] Re: Optional, tie, and iterator_adaptor

Joel de Guzman wrote: Although I don't see this as problematic: optional x; if (x) foo(x); Or perhaps: optional x; if (!!x) foo(x); We already have an implicit conversion to safe_bool and an operator ! anyway. Keep it. There's nothing wrong with it: o

[boost] Compile problem with Spirit & CodeWarrior

If I try to compile something like rule<>goofy = real_p >> real_p; boolisOK = parse( "12 1.3", goofy, space_p ).full; with CodeWarrior 8.3, I get an error message that I don't understand, reproduced below. If I write the rule inline, like bool isOK = parse( "12 1.3", real_p >> real_p,

Re: [boost] Re: Optional, tie, and iterator_adaptor

On Sun, Aug 31, 2003 at 12:34:39AM -0700, Mat Marcus wrote: > In this post I will put forward a use-case or two to help see whether > something a little different then the current version of optional > might be useful. I also begin making a case that a Concept like > PossiblyUninitializedVariable m

RE: [boost] Compile problem with Spirit & CodeWarrior

James W. Walker wrote: > If I try to compile something like > > rule<>goofy = real_p >> real_p; > bool isOK = parse( "12 1.3", goofy, space_p ).full; > > with CodeWarrior 8.3, I get an error message that I don't > understand, > reproduced below. If I write the rule inline, like > >

Re: [boost] Regression test page broken

On Sun, 31 Aug 2003 09:59:26 +0200, Martin Wille wrote > Jeff Garland wrote: > > The regression test page seems to be on a diet > > > > http://boost.sourceforge.net/regression-logs/ > > You can find some of the other results at >http://boost.sourceforge.net/regression-logs/release > > Ho

Re: [boost] Re: Optional, tie, and iterator_adaptor

Hi, Here's another use-case... We are working on an alternative semantic action scheme with Spirit that will be a lot more easier to use than the current scheme. With this scheme, the signature of the semantic action will be dependent on the rule where it is attached to. This is similar in some s

Re: [boost] Re: [boost.variant] It is possible to make a variantLessThanComparable

David Abrahams wrote: > "Eric Friedman" <[EMAIL PROTECTED]> writes: > >> Ultimately, I do not believe any ordering scheme will provide >> meaningful, straightforward semantics. Assuming I am correct, I >> propose that the variant library offer your ordering scheme -- but >> only as an explicit comp

Re: [boost] Cannot build static library with latest CVS on Linux

[2003-08-30] Jeff Garland wrote: >Replies to self... >> Just did a CVS update and I am now unable to build date_time. This >> is on Linux. I'm looking at the CVS check-ins, but maybe someone >> workon on the build stuff might know right away what's wrong > >Had to roll back the lastest cha

Re: [boost] Cannot build static library with latest CVS on Linux

[2003-08-30] Jeff Garland wrote: >Just did a CVS update and I am now unable to build date_time. This is on >Linux. I'm looking at the CVS check-ins, but maybe someone workon on the >build stuff might know right away what's wrong > >bjam from libs/date_time/test results in: > [snip] > >/u