Re: [boost] Formal review: Optional library

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-10 19:53:53

"Joel de Guzman" <djowel_at_[hidden]> writes:

> ----- Original Message ----- 
> From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
>
>> > > 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
>> > > interface.  Maybe it's just a different library?
>> >
>> > Or perhaps, optional is just a limited add-on API over the variant?
>> > The low-level  implementation mechanism in place seems to be very
>> > similar and having 2 separate libraries will be redundant, I think.
>> >
>> Not so...
>> The low-level implementation is like a variant ONLY is the wrapped object is
>> not a POD.
>> When you have, say, optional<int>, the implementation uses: struct { int
>> m_value ; bool m_initialized }
>> As a result, value access, via operator*() is more efficient since it
>> doesn't dereference a pointer.
>
> That depends on how the variant is implemented. Which variant
> implementation are you referring to? I'm sorry. I'm confused with
> what you are saying. I can't see why it is more efficient. Neither do
> I see a dereference in any case.

I'm with Joel on this one. It seems to me that no special optimization
should be needed for PODs; all you should need is some aligned storage
in which to construct the contained object and one or more bits to
indicate which of the allowed types (if any) is held there.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution