|
Boost : |
From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2002-12-10 17:39:48
----- Original Message -----
From: "Joel de Guzman" <djowel_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Tuesday, December 10, 2002 7:04 PM
Subject: Re: [boost] Formal review: Optional library
>
> ----- Original Message -----
> From: "David Abrahams" <dave_at_[hidden]>
>
>
> > "Joel de Guzman" <djowel_at_[hidden]> writes:
> >
> > > ----- Original Message -----
> > > From: "Fernando Cacciola" <fernando_cacciola_at_[hidden]>
> > >
> > >
> > >
> > >> 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 which has a clear uninitialized state.
> > >
> > > Hi,
> > >
> > > Probably a dumb question but allow me to ask anyway:
> > >
> > > Wouldn't a more generic variant<T0, T1...TN> class do what the
> > > optional is trying to do? I feel that optional<T> is just a variant<T,
nil_t>
> > > in disguise. Correct me if I'm wrong.
> >
> > Someone once said that if a theorem in Physics involves numbers other
> > than zero, 1, or infinity, it's lacking in purity.
>
> :-) Cool!
>
> > 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.
Fernando Cacciola
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk