From: David Abrahams (dave_at_[hidden])
Date: 2003-02-19 10:30:10
"Fernando Cacciola" <fernando_cacciola_at_[hidden]> writes:
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
>> David Abrahams wrote:
>> > "Peter Dimov" <pdimov_at_[hidden]> writes:
>> >> Joel de Guzman wrote:
>> >>> David Abrahams wrote:
>> >>>> BTW, I just realized that a conversion from variant<T> to
>> >>>> optional<T> could be used to do extraction as well. Maybe it
>> >>>> would be better to ditch extract altogether and just use optional?
>> >>> I think this makes sense. The disadvantage is the overhead of
>> >>> optional just to do "extract"ion.
>> >> That means an extra copy
>> > Really? You can't convert to an optional<T&>?
>> You said "optional<T>" above.
>> It may be possible to use optional<T&> (is it supported?)
> No, it isn't.
> And I don't think it ever will.
> optional<X> intends to represent a value of type X wich is possiblly
> But you can't have X=T& since you can't have an uninitialized reference.
Sorry, that's a broken analogy. You also can't have an uninitialized
object of non-POD class type U, but you allow optional<U>.
> Of course, optional<T&> could have a special meaning, but I can't
> see what would it be. What's the meaning of an optional reference?
> I think there cannot be such a thing.
The same as an optional std::string. Either you have one, or you don't.
>> or optional<
>> reference_wrapper<T> > but this looks like an "obfuscated C++" entry to me
>> compared to T*. What's wrong with it? What does optional<T&> add?
> Exactly. An optional reference is almost like a possibly null pointer,
> except that references
> must be bounded.
> If given a particular design you would need optional<T&>, then you
> definitely need T* instead.
I've my doubts.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk