Brian McNamara <[EMAIL PROTECTED]> wrote:
> It's been pointed out before, but to re-emphasize it: from a
> type-theoretic standpoint, it is not the case that optional-isa-T.
> Rather T-isa-optional. (Dog-isa-Animal because Animal has more
> possible values.) I don't mind the suggestive conceptua
Joel de Guzman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Fernando Cacciola <[EMAIL PROTECTED]> wrote:
>
> >> Even if I agree with you that an optional should not be a T,
> >> an optional is definitely not a pointer to T.
> >>
> > Definitely!
> > If HTML had blinking banners I th
[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
[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( nilable(3) ) );
>do_something( adapt( fo
On Monday, Sep 1, 2003, at 14:48 America/Denver, David Abrahams wrote:
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,
aft
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
>
> Wel
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 ch
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
"Joel de Guzman" <[EMAIL PROTECTED]> writes:
>> My system was written in Python, but you might be able to adapt the
>> general idea to C++.
>
> Hmmm, nice! How does it handle iteration like x -> a* and the optional
> x -> a?
It doesn't because I didn't believe in *E*BNF; you'd have to be a
littl
> 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...
___
Unsubscr
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, d
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
Joel de Guzman <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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!
>
Well, we would
--On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola
<[EMAIL PROTECTED]> wrote:
Joel de Guzman <[EMAIL PROTECTED]> wrote in message
One can think of an optional as conceptually a specialized but
nevertheless, *IS-A* T, with the added specialization that it can
be in a dead-uninitial
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,
Fernando Cacciola <[EMAIL PROTECTED]> wrote:
>> Even if I agree with you that an optional should not be a T,
>> an optional 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
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 h
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 semantic
--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:
boost::tie(*
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 nilable and T with different code,
> > which is exactly what I'm trying to avoid.
>
>
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
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
> prac
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:
>
>PossUninit
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
> PossiblyUninitialize
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
> s
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 t
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 cur
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.
--
J
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:
> >>
> >> optional x;
> >> if (x)
> >> foo(x);
> >>
> >> Or perhaps:
> >>
> >> optional x
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]
> Brian McNamara <[EMAIL PROTECTED]> wrote:
>
> > Offhand, the "pointer interface" for reading the value of an optional
> > seems good to me. Being able to say
> >
> >optional x;
> >...
> >if( x ) foo( *x );
>
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
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
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
"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
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
- Origina
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_a
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::variant V;
>> V v1 = T1( x );
>> V v2 = T2( y );
>> V v3 = T1( z );
>>
>> v1 <
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 co
> 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 runt
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
>> set or find(first, last, v) is supposed to d
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! 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 nilable and T with differe
--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" i
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_polymorphic based on compiler pro
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 implementatio
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
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:
>
>
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 nilable seamlessly, but doing things the other way around
> might be an improvement.
Agreed.
> > [Brian McNamara]
> > I was originally arguing wi
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 nilable 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
consisten
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 set
or
> find(first, last, v) is supposed to do; variant_less or variant_
> [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 Guz
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
Brian McNamara <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 31, 2003 at 09:12:59PM -0600, Dave Gomboc wrote:
>>> The point is that optional is not a T, and most notably, a template
>>> function will never perform the coercion. Replace the lines like
>>>B b = get<2>(args);
>>> in your example with
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.
On Sun, Aug 31, 2003 at 09:12:59PM -0600, Dave Gomboc wrote:
> > The point is that optional is not a T, and most notably, a template
> > function will never perform the coercion. Replace the lines like
> >B b = get<2>(args);
> > in your example with real calls to, e.g.
> >do_something( ge
> Here's a (contrived) example of how the implicit conversion breaks
> generic code:
>
[example snipped]
>
> The point is that optional is not a T, and most notably, a template
> function will never perform the coercion. Replace the lines like
>B b = get<2>(args);
> in your example with rea
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=detail&atid=107586&aid=798357&group_id=7586
Category: None
Group: None
Status: Open
Resolution: None
Pr
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
w
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 pe
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 no
> practical evidence/experience, and I'
David Abrahams <[EMAIL PROTECTED]> wrote:
> "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 a
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 i
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->
64 matches
Mail list logo
