Douglas Gregor said:
> The formal review of Fernando Cacciola's Optional library begins today
> and runs until the end of Wednesday, December 18.
>
> The Optional library provides a class template "optional" that either
> contains a value of type "T" or contains no value (i.e., having a value
>
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
> Douglas Gregor said:
> > The formal review of Fernando Cacciola's Optional library begins today
> > and runs until the end of Wednesday, December 18.
> >
> > The Optional library provides a cla
Title: RE: [boost] Formal review: Optional library
From: Fernando Cacciola [mailto:[EMAIL PROTECTED]]
>>
>> * I'm unsure about the presence of "initialized()". On the one hand, the
>> duplication in features (compared to "get/peek() == 0") is so
- Original Message -
From: "Glen Knowles" <[EMAIL PROTECTED]>
To: "'Boost mailing list'" <[EMAIL PROTECTED]>
Sent: Monday, December 09, 2002 6:42 PM
Subject: RE: [boost] Formal review: Optional library
> From: Fernando Cacciola [mailto:[EMAIL
Fernando Cacciola said:
> "William E. Kempf" <[EMAIL PROTECTED]> wrote in message
>> * I believe there should be an "optional& operator=(T const& v)".
>>
> This would break the pointer-semantics:
>
> optional opt ;
>
> opt = 3 ;
>
> instead of
>
> *opt = 3 ;
>
> as it is currently the required syn
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> The conversion to bool for a smart pointer unambiguously refers to the
> NULL state of the pointer wrapped.
> In the case of optional, a conversion to bool will be ambiguous in those
> cases were the wrapped T in optional<> is bool itself.
On the oth
Fernando Cacciola writes:
>
> - Original Message -
> From: "Glen Knowles" <[EMAIL PROTECTED]>
> To: "'Boost mailing list'" <[EMAIL PROTECTED]>
> Sent: Monday, December 09, 2002 6:42 PM
> Subject: RE: [boost] Formal r
OK, I've been thinking about the interface a bit more and want to voice
some other opinions. First, why were pointer semantics chosen at all?
Why couldn't you have gone with value semantics?
optional foo()
{
//...
}
void bar(int value)
{
//...
}
optional res = foo();
if (res.initialized(
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 09, 2002 7:48 PM
Subject: Re: [boost] Formal review: Optional library
>
> Fernando Cacciola said:
> > "William E. Kempf" <[EMAI
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 9:23 AM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[EMAIL PR
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > I don't think that optional is an important use case (outside of
> > generic contexts) since optional is simply a tri-state type with
an
> > inconvenient interface.
> >
> Good point. I've been using optional long before tribool existed.
> Now I migh
- Original Message -
From: "Anthony Williams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 9:46 AM
Subject: Re: [boost] Formal review: Optional library
> Fernando Cacciola writes:
> >
&g
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 3:33 PM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[EMAIL PRO
Fernando Cacciola said:
>> Fernando Cacciola said:
>> > "William E. Kempf" <[EMAIL PROTECTED]> wrote in message
>> >> * I believe there should be an "optional& operator=(T const& v)".
>> >>
>> > This would break the pointer-semantics:
>> >
>> > optional opt ;
>> >
>> > opt = 3 ;
>> >
>> > instead
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> I understand your reasoning, but what do you suggest?
I suggest that we need not give much weight to optional when designing
optional's interface.
> Leaving optional inherently unsafe?
Unsafe? The conversion from optional to bool might be confusing
- Original Message -
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> optional<> is trying to model using C++ a concept that
> it is not really covered by the language, that of uninitialzed values.
> It uses pointer semantics *just* because pointers are the only sort of
> C++ objects wh
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 12:43 PM
Subject: Re: [boost] Formal review: Optional library
> OK, I've been thinking about the interface a bit more and want
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 4:26 PM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[EMAIL
- Original Message -
From: "Joel de Guzman" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 5:21 PM
Subject: Re: [boost] Formal review: Optional library
>
> - Original Message -
> Fr
"Joel de Guzman" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>
>
>
>> optional<> is trying to model using C++ a concept that
>> it is not really covered by the language, that of uninitialzed values.
>> It uses pointer semantics *just*
- Original Message -
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> - Original Message -
> From: "Joel de Guzman" <[EMAIL PROTECTED]>
> > Hi,
> >
> > Probably a dumb question but allow me to ask anyway:
> >
> > Wouldn't a more generic variant class do what the
> > optional is t
Fernando Cacciola said:
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>> OK, I've been thinking about the interface a bit more and want to
>> voice some other opinions. First, why were pointer semantics chosen
>> at all? Why couldn't you have gone with value semantics?
>>
>> optional foo()
>> {
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
> "Joel de Guzman" <[EMAIL PROTECTED]> writes:
>
> > - Original Message -
> > From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> >
> >
> >
> >> optional<> is trying to model using C++ a concept that
> >> it is not re
- Original Message -
From: "Joel de Guzman" <[EMAIL PROTECTED]>
> - Original Message -
> From: "David Abrahams" <[EMAIL PROTECTED]>
> > optional captures the zero/one distinction, which, as its analogy to
> > pointers makes clear, is a very useful one. A type which can contai
- Original Message -
From: "Joel de Guzman" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 7:04 PM
Subject: Re: [boost] Formal review: Optional library
>
> - Original Message -
>
- Original Message -
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > > optional captures the zero/one distinction, which, as its analogy to
> > > pointers makes clear, is a very useful one. A type which can contain
> > > any number of different types would have a much more complicated
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 4:18 PM
Subject: Re: [boost] Formal review: Optional library
> [snipped]
>
> But I do see reasons to want to keep with a sm
- Original Message -
From: "Joel de Guzman" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 6:47 PM
Subject: Re: [boost] Formal review: Optional library
>
> - Original Message -
> Fr
- Original Message -
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > Hmmm, I'm not sure if I agree with this. T can very well be
> > uninitialized in the variant when nil_t is in effect. Then
> > nil_t can just be struct nil_t {}; which costs nothing to initialize.
> > Why is optional
"Joel de Guzman" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>
>> > > optional captures the zero/one distinction, which, as its analogy to
>> > > pointers makes clear, is a very useful one. A type which can contain
>> > > any number
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> I still don't like to think of optional<> as a container, so I still
> don't like this reset.
Do you really think of auto_ptr and shared_ptr as containers? They
seem to have little or nothing in common with any of the standard
containers.
> My m
> > > That's why it hands you a pointer to the value, because you can test
the
> > > pointer
> > > for NULL; but that's it.
> > > IOWs, the pointer returned by optional is conceptually a handle, not a
> > > pointer.
> > > That's why I like the member function peek() much better than get().
> >
> >
From: "Joel de Guzman" <[EMAIL PROTECTED]>
>
> Or perhaps, optional is just a limited add-on API over the variant?
Or perhaps optional is just a limited API over a container?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/b
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> I still don't like to think of optional<> as a container, so I still don't
> like this reset.
I don't see why. reset() has nothing to do with containership; it's a
generic shorthand for reconstructing an object in place.
void X::reset(args)
Effects
- Original Message -
From: "Joel de Guzman" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 8:53 PM
Subject: Re: [boost] Formal review: Optional library
>
> - Original Message -
> Fr
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>
> value() is there just because the proxy() fails to convert to T&;
> and the proxy is needed by the deep-constantess,
What is wrong with
T & operator*();
T const & operator*() const;
?
> Of course, it can be argued that if you wanted
> to convey
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 9:53 PM
Subject: Re: [boost] Formal review: Optional library
> [SNIP]
>
> "Joel de Guzman" &l
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> Currently, the non-POD case implementation goes like this:
>
> (this is a sketch actually)
>
> template
> class optional1
> {
> optional1 ( T const& v ) { p = new (buffer.address()) T(v) ; }
>
> T const& operator *() { return *p; } // Dereferen
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 10:00 PM
Subject: Re: [boost] Formal review: Optional library
> "Fernando Cacciola" <[EMAIL P
- Original Message -
From: "Tanton Gibbs" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 10:10 PM
Subject: Re: [boost] Formal review: Optional library
> > > > That's why it hands you a
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 10, 2002 7:04 PM
Subject: Re: [boost] Formal review: Optional library
>
> Fernando Cacciola said:
>
> > But if I wrote:
> >
> &
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 11:14 AM
Subject: Re: [boost] Formal review: Optional library
> "Fernando Cacciola" <[EMAIL
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 10:21 AM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[EMAI
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > > Currently, you can change the value of the optional directly without
any
> > > performance
> > > penalty like this: *opt = new_val, so I don't see any real need for
> > reset().
> >
> > Not correct, *opt has undefined behavior when opt is uninitia
Fernando Cacciola said:
>> As did I in the interface I proposed elsewhere. My complaint wasn't
>> actually the lack of an operator=(), but of the lack of any way to
>> reassign the value in an efficient and uniform manner.
>>
> But what's wrong with: *opt = new_value?
> This is as efficient and a
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>>
>> There's no need to store p. You can just use
>> static_cast(buffer.address())
>>
> Yes.. I just shown the pointer explicitely.
> The result of the static_cast<> is a pointer, so to obtain a reference (for
> the operator*) you need to 'actually'
Fernando Cacciola said:
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>> Fernando Cacciola said:
>> > Eventually, I realized that value semantics are not really
>> appropiate to deal
>> > with unininitialized states since it blurs the distinction between
>> testing against other values and testin
Fernando Cacciola said:
> From: "Joel de Guzman" <[EMAIL PROTECTED]>
>> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>>
>> > > Hmmm, I'm not sure if I agree with this. T can very well be
>> > > uninitialized in the variant when nil_t is in effect. Then
>> > > nil_t can just be struct nil_t {}; wh
"Fernando Cacciola" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "David Abrahams" <[EMAIL PROTECTED]>
> To: "Boost mailing list" <[EMAIL PROTECTED]>
> Sent: Tuesday, December 10, 2002 10:00 PM
> Subject: Re: [b
These are some conclusions from the review so far:
(A)
There is particular (mis) feature in optional which is wrongly
documented (as Peter and William showed me), but
which is also incorrect.
The expression
*opt=x;
is currently always well defined regardless the initialization state of
'opt'.
I
Fernando Cacciola said:
> These are some conclusions from the review so far:
>
> (A)
> There is particular (mis) feature in optional which is wrongly
> documented (as Peter and William showed me), but
> which is also incorrect.
>
> The expression
>
> *opt=x;
>
> is currently always well defined re
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
[...]
> Conclusion: I will adopt William's reset, leaving operator*() return
> a reference to the optional value *only* if it is initialized
> (independently of whether opt is const or not).
>
> Therefore, the proxy is not needed. And so value() isn't n
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 2:00 PM
Subject: Re: [boost] Formal review: Optional library
>
> [snipped]
>
> I like what this is sounding like, but think
> However, I'm still unconvinced that uninitialized optionals should compare
> false,
> and even though, you can always compare optional values (via operator*),
so
> I see no benefit in defining relational operators directly (thus these
> operators
> will be poisoned)
Shouldn't unitialized optiona
- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 12:46 PM
Subject: Re: [boost] Formal review: Optional library
> "Fernando Cacciola" <
Based on the coments made by reviewers, this is the new interface:
template
class optional
{
optional () ;
explicit optional ( T const& val ) ;
optional ( optional const& rhs ) ;
~optional() ;
// This is provided ONLY to allow implicit conversions from
// optional to op
- Original Message -
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > It's trivial to make that a free function like get. Or further, to make
> > a subset API for optional.
> >
> You can certainly do the same with variant. The point is that with
> optional<> it is *easier*.
> With optio
> optional opt0(1);
> optional opt1(2);
> (opt0 == opt1) // true
I would not have any problem with this returning false. In the normal ptr
world:
char c, d;
char* p, *q;
p = &c;
q = &d;
if( p == q ) // false
People expect it to compare memory locations, not initialization status.
Therefore, I w
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
> >> It's trivial to make that a free function like get. Or further, to
> >> make a subset API for optional.
> >>
> > You can certainly do the same with variant. The point is that with
> > optional<> it is *easier*.
> > Wi
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 2:22 PM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[EMAIL
Tanton Gibbs said:
>> optional opt0(1);
>> optional opt1(2);
>> (opt0 == opt1) // true
>
> I would not have any problem with this returning false. In the normal
> ptr world:
> char c, d;
> char* p, *q;
> p = &c;
> q = &d;
>
> if( p == q ) // false
>
> People expect it to compare memory locations,
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
[...]
> (1) deep-constantness:
>
> I Followed David Abraham's suggestion and decoupled
> constantness of the optional<> object with that of
> the value being wrapped.
> This is how pointers and most smart pointers work, so
> the pointer semantic should
- Original Message -
From: "Joel de Guzman" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 5:18 PM
Subject: Re: [boost] Formal review: Optional library
> - Original Message -
> From:
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> >
> > You should consider providing operator<<(std::ostream&, optional), too.
> >
> Interesting...
> The idea is that if the optional is uninitialized, it outputs something
like
> "[NULL]",
> else forwards to T::operator <<(), right?
>
> I agree it is
"William E. Kempf" <[EMAIL PROTECTED]> writes:
> Tanton Gibbs said:
>>> optional opt0(1);
>>> optional opt1(2);
>>> (opt0 == opt1) // true
>>
>> I would not have any problem with this returning false. In the normal
>> ptr world:
>> char c, d;
>> char* p, *q;
>> p = &c;
>> q = &d;
>>
>> if( p == q
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> [...]
>> (1) deep-constantness:
>>
>> I Followed David Abraham's suggestion and decoupled
>> constantness of the optional<> object with that of
>> the value being wrapped.
>> This is how pointers and most s
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 5:49 PM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[E
- Original Message -
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > And my point, again, is that you can easily add an *easier* API
> > that does exactly like your optional API *over* the variant. My
> > concern is primarily about redundancy of code. I don't see any
> > reason why the
> optional a();
> optional b();
> optional c(1);
> optional d(2);
> optional e(2);
>
> assert(a == b); // both uninitialized
> assert(a != c); // one uninitialized
> assert(c != d); // both initialized to different values
> assert(d == 3); // both initialized to same value
>
> However, not all
David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>> Tanton Gibbs said:
optional opt0(1);
optional opt1(2);
(opt0 == opt1) // true
>>>
>>> I would not have any problem with this returning false. In the
>>> normal ptr world:
>>> char c, d;
>>> char* p, *q;
>>>
- Original Message -
From: "Tanton Gibbs" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 5:22 PM
Subject: Re: [boost] Formal review: Optional library
> > optional opt0(1);
> > optional opt
David Abrahams said:
> "Peter Dimov" <[EMAIL PROTECTED]> writes:
>
>> From: "Fernando Cacciola" <[EMAIL PROTECTED]>
>> [...]
>>> (1) deep-constantness:
>>>
>>> I Followed David Abraham's suggestion and decoupled
>>> constantness of the optional<> object with that of
>>> the value being wrapped.
>>>
- Original Message -
From: "Peter Dimov" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 5:47 PM
Subject: Re: [boost] Formal review: Optional library
> From: "Fernando Cacciola" <[EMA
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 11, 2002 6:45 PM
Subject: Re: [boost] Formal review: Optional library
> David Abrahams said:
> > "Peter Dimov" <[EMAIL
> [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
> [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 the
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
- 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 PROTE
- 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" <[EMAI
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
- 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" <[EMA
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
"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
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
> [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:
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
> [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 cons
- 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" <[E
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
1 - 100 of 107 matches
Mail list logo
