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.
--
http://www.jwwalker.com/
___
Unsubscribe other changes:
David Abrahams [EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] writes:
Now, unlike YACC, Spirit has iteration (kleene, plus, optional)
Here's a more or less the complete suite of patterns and the
corresponding semantic-action signatures:
r ::= a b-F(tupleA, B)
Brian McNamara [EMAIL PROTECTED] wrote:
I should mention in passing that, while in general I think implicit
conversions are bad news and should be avoided whenever reasonable, I
do think the conversion to bool is an exceptional case, simply because
it is already so deeply ingrained in C++
Brian McNamara [EMAIL PROTECTED] wrote:
On Sun, Aug 31, 2003 at 10:41:15AM -0700, Mat Marcus wrote:
also interesting, although I think that readability suffers. I'd give
up bool conversion and operator! to avoid the need for ~ if that would
reasonably solve the muddling issues. But perhaps
On Mon, Sep 01, 2003 at 09:03:17AM +0800, Joel de Guzman wrote:
Do it the ref, tuple and variant way: get(). But get(), as an
element-access interface, should return a reference, not a pointer, as
it does currently.
Clearly I had not been paying enough attention earlier in the thread; I
was
Bugs item #798357, was opened at 2003-09-01 02:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=107586aid=798357group_id=7586
Category: None
Group: None
Status: Open
Resolution: None
Here's a (contrived) example of how the implicit conversion breaks
generic code:
[example snipped]
The point is that optionalT is not a T, and most notably, a template
function will never perform the coercion. Replace the lines like
B b = get2(args);
in your example with real calls
On Sun, Aug 31, 2003 at 09:12:59PM -0600, Dave Gomboc wrote:
The point is that optionalT is not a T, and most notably, a template
function will never perform the coercion. Replace the lines like
B b = get2(args);
in your example with real calls to, e.g.
do_something( get2(args) )
Here's a patch to depth_first_search.hpp that allows a buffer parameter to be
used with depth_first_search(). I'm also including a patch to
depth_first_search.html to update the documentation. The patches apply to CVS
revision 1.37 of depth_first_search.hpp, and 1.14 of depth_first_search.html.
Brian McNamara [EMAIL PROTECTED] wrote:
On Sun, Aug 31, 2003 at 09:12:59PM -0600, Dave Gomboc wrote:
The point is that optionalT is not a T, and most notably, a template
function will never perform the coercion. Replace the lines like
B b = get2(args);
in your example with real calls to,
Janusz Piwowarski wrote:
Hi,
As in subject: first line, first character.
Fixed, thanks!
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[Dave Abrahans]
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 achieve that with optional?
It darn well shouldn't be a container, it should be a concrete type! ;-)
[Joel de Guzman]
Peter Dimov wrote:
When there is one and only one strict weak ordering (equality) for a
type, not using operator and operator== because some users might have
different expectations is misguided. It is pretty clear what setvariant
or
find(first, last, v) is supposed to do; variant_less or
Dave Gomboc wrote:
[snip]
I don't like get() because I cannot write x.get() when x is a POD. This
would mean I have to support nilableT and T with different code,
which is exactly what I'm trying to avoid.
Why not overload boost::get again for optional? This would certainly improve
On Mon, Sep 01, 2003 at 12:13:11AM -0600, Dave Gomboc wrote:
I've been trying to set things up so that code is written for T that can
then also use nilableT seamlessly, but doing things the other way around
might be an improvement.
Agreed.
[Brian McNamara]
I was originally arguing with
Eric Friedman wrote:
But suppose I have a variant v3, with content of a different type (call it
T3). Then the assignment v1 = v3 is far more complicated (we can't use
T1::operator=) and, without double storage, far more dangerous. The single
storage implementation behaves as follows:
Howard,
Howard Hinnant wrote:
[snip]
If you will mail me a complete condensed demo, I'll take a look. I
downloaded boost 1.30.2 but was unable to find boost/variant.
-Howard
Thanks for offering your assistance. Variant will make its debut in 1.31.
Thus, you'll need to work from Boost CVS
Alexander Nasonov
Eric Friedman wrote:
But suppose I have a variant v3, with content of a different type (call
it
T3). Then the assignment v1 = v3 is far more complicated (we can't use
T1::operator=) and, without double storage, far more dangerous. The
single
storage implementation
Eric Friedman wrote:
If I understand you correctly, earlier versions of variant did precisely
what you describe. Unfortunately, the assumption you make is false in
general. See http://aspn.activestate.com/ASPN/Mail/Message/boost/1311813.
Eric
Well, is_polymorphicT based on compiler
--On Sunday, August 31, 2003 9:56 PM -0400 Brian McNamara
[EMAIL PROTECTED] wrote:
As for the use-case with the function returning a pair of iterators
that we'd like to assign to optionals via a tie(), I think there
should also be a different method in the interface which returns the
hole in
Eric! You DA Man!
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
Eric Friedman [EMAIL PROTECTED] wrote:
Dave Gomboc wrote:
[snip]
I don't like get() because I cannot write x.get() when x is a POD. This
would mean I have to support nilableT and T with different
Hi,
I haven't followed this thread completely, but I have a question.
I'm working on Win 2k, and I'm using VC++ 7.1. Building
boost with this toolset, do I need to specify something to make it
thread-safe?
TIA,
Viv
- Original Message -
From: John Maddock [EMAIL PROTECTED]
To: Boost
Eric Friedman wrote:
Peter Dimov wrote:
When there is one and only one strict weak ordering (equality) for a
type, not using operator and operator== because some users might
have different expectations is misguided. It is pretty clear what
setvariant or find(first, last, v) is supposed to do;
I haven't followed this thread completely, but I have a question.
I'm working on Win 2k, and I'm using VC++ 7.1. Building
boost with this toolset, do I need to specify something to make it
thread-safe?
Actually you need to do more than that - you need to compile Boost against
the same runtime
Subject: [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
David Abrahams wrote:
Dirk Schreib [EMAIL PROTECTED] writes:
I would like a variant to be LessThanComparable if all
BoundedTypes are LessThanComparable.
In this example
typedef boost::variantT1, T2, ..., TN V;
V v1 = T1( x );
V v2 = T2( y );
V v3 = T1( z );
v1 v2 should
I'm asking for voting for the new name of dynamic_any. Please, give you
preference.
Here is my discussion about the name with Kevlin Henney ( and empty prefix
- Kevlin, - me)
--- cut ---
Have you had any more thoughts on an alternative name? Something like
adaptable_any or extensible_any?
I
Thanks for your reply.
I've created my own vcproj (VC++ 7.1 project) for building the libs that I
need,
and I've used the /MD flag which is the multithread- and DLL-specific
versions flag (used also for my application),
which means that everything is fine, right?
Thanks a lot,
Viv
- Original
Peter Dimov [EMAIL PROTECTED] writes:
Eric Friedman wrote:
Peter Dimov wrote:
When there is one and only one strict weak ordering (equality) for a
type, not using operator and operator== because some users might
have different expectations is misguided. It is pretty clear what
setvariant or
This hasn't happened yet. Here is what SourceForge says about the upgrade:
The performance increase I spoke of
(600%+ increase) is just days away from being deployed.The new
systems are now in place, additional electrical power has been added to
our colocation cage, and the Linux boxes are in
Joel de Guzman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Fernando Cacciola [EMAIL PROTECTED] wrote:
Hi Mat,
Thanks for the input.
optional is now out on the field and it is the only utility of its kind
I've ever seen in C++, at least in real use. This has the drawback
Brian McNamara [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Sun, Aug 31, 2003 at 09:58:45AM +0800, Joel de Guzman wrote:
Fernando Cacciola [EMAIL PROTECTED] wrote:
Hi Mat,
Thanks for the input.
optional is now out on the field and it is the only utility of its
Joel de Guzman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Brian McNamara [EMAIL PROTECTED] wrote:
Offhand, the pointer interface for reading the value of an optional
seems good to me. Being able to say
optionalint x;
...
if( x ) foo( *x );
seems like a
Fernando Cacciola [EMAIL PROTECTED] wrote:
First of all, let's not confuse syntax with semantics.
optional HAS strict value semantics.
No it does not. The accessors have pointer behavior!
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
Joel de Guzman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Daniel Frey [EMAIL PROTECTED] wrote:
Joel de Guzman wrote:
Although I don't see this as problematic:
optionalint x;
if (x)
foo(x);
Or perhaps:
optionalint x;
if (!!x)
Fernando Cacciola [EMAIL PROTECTED] wrote:
vector::begin returns an object with operators * and -,
yet these objects are not pointers, and once that is learned,
people do not think they are pointers.
Huh? pointer semantics (behavior) does not mean that they
have to be pointers.
--
Joel de
Brian McNamara [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Mon, Sep 01, 2003 at 09:03:17AM +0800, Joel de Guzman wrote:
Do it the ref, tuple and variant way: get(). But get(), as an
element-access interface, should return a reference, not a pointer, as
it does currently.
Fernando Cacciola [EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] wrote in message
There's a lot of experience with it in other languages. Why not leverage
that? Haskell::Maybe for instance.
Do you know of anything else besides Haskell?
No.
I don't, and I took the time to
Fernando Cacciola [EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] wrote in message
Direct initialization: opt = 1
seems right since this operation is never undefined.
This would mirror variant's interface.
Ok.
Direct value accesing via implicit conversion: int i = opt
seems
Mat Marcus [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
Brian McNamara [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Sun, Aug 31, 2003 at 12:34:39AM -0700, Mat Marcus wrote:
[snipped]
So, here's an idea for something completely new which maybe helps fit
your requirements. I start with the motivating example:
PossUninitVarIter
Brian McNamara [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
Joel de Guzman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
Eric Friedman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Dave Gomboc wrote:
[snip]
I don't like get() because I cannot write x.get() when x is a POD. This
would mean I have to support nilableT and T with different code,
which is exactly what I'm trying to avoid.
Why not
--On Monday, September 01, 2003 2:57 PM -0300 Fernando Cacciola
[EMAIL PROTECTED] wrote:
Mat Marcus [EMAIL PROTECTED] wrote in message
[snip]
After reading the documentation more carefully I learned that
optional models pointer behavior. I spelled out how the code might
look:
On Monday, Sep 1, 2003, at 11:31 America/Denver, Joel de Guzman wrote:
Fernando Cacciola [EMAIL PROTECTED] wrote:
vector::begin returns an object with operators * and -,
yet these objects are not pointers, and once that is learned,
people do not think they are pointers.
Huh? pointer semantics
Template libraries, especially those employing expression templates,
take a long time to compile. As an example, one of the example files
for FC++ (parser.cpp) takes about 10 minutes to compile on a blazingly
fast machine with tons of RAM.
I would like to reduce the compile-time. I solicit any
Fernando Cacciola [EMAIL PROTECTED] wrote:
Even if I agree with you that an optionalT should not be a T,
an optionalT is definitely not a pointer to T.
Definitely!
If HTML had blinking banners I think I'd use one to state this :-)
Nor should it model a pointer. That was my point and the
Gregory Colvin [EMAIL PROTECTED] wrote:
On Monday, Sep 1, 2003, at 11:31 America/Denver, Joel de Guzman wrote:
Fernando Cacciola [EMAIL PROTECTED] wrote:
vector::begin returns an object with operators * and -,
yet these objects are not pointers, and once that is learned,
people do not
Joel de Guzman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Fernando Cacciola [EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] wrote in message
Direct value accesing via implicit conversion: int i = opt
seems wrong because this is the operation that can lead to
Gregory Colvin [EMAIL PROTECTED] writes:
Conforming containers had better use them.
I'm sorry, but I think that's flat wrong. What do you suppose that
entry in column 2 of the allocator requirements table (20.1.5) means,
after all?
It means any value returned by construct, destroy, or
I've just uploaded the preliminary version of my XML library to Yahoo
files
section as xml_library.zip. Comments are welcome.
I think it's very nice, and I can already think of some code that could be
made much clearer using this...
___
Brian McNamara [EMAIL PROTECTED] writes:
Template libraries, especially those employing expression templates,
take a long time to compile. As an example, one of the example files
for FC++ (parser.cpp) takes about 10 minutes to compile on a blazingly
fast machine with tons of RAM.
Which
On Thu, 28 Aug 2003 16:19:24 +0200, Douglas Gregor wrote:
On Thursday 28 August 2003 08:20 am, Daniel Frey wrote:
utility/tie was moved to tuple, so should we remove the obsolete
docs/references in utility now?
Please do.
Done. I also updated the Revisited ..., but there is some checksum
Alexander Nasonov wrote:
Eric Friedman wrote:
If I understand you correctly, earlier versions of variant did precisely
what you describe. Unfortunately, the assumption you make is false in
general. See
http://aspn.activestate.com/ASPN/Mail/Message/boost/1311813.
Eric
Well,
[Eric Friedman]
Why not overload boost::get again for optional?
It might be a good idea for other reasons, but it doesn't solve the problem
I'm trying to solve.
[Brian McNamara]
do_something( adapt( 3 ) );
do_something( adapt( nilableint(3) ) );
do_something( adapt(
[Fernando Cacciola]
The most fundamental point is that being Haskell a pure functional
language there is no possibly undefined behaviour to worry about,
so Maybe doesn't need to address this issue as optional does.
... and later ...
I account the possibly undefined behavior of accesing an
Joel de Guzman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Fernando Cacciola [EMAIL PROTECTED] wrote:
Even if I agree with you that an optionalT should not be a T,
an optionalT is definitely not a pointer to T.
Definitely!
If HTML had blinking banners I think I'd use one
58 matches
Mail list logo
