Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-09-11 10:35:44


Hamish Mackenzie <hamish_at_[hidden]> wrote in message
news:1063233042.3122.82.camel_at_lightning.firestream.co.uk...
> On Wed, 2003-09-10 at 17:05, Fernando Cacciola wrote:
> > > Any chance of adding .empty() member? I am not to fussed about this as
> > > it might make code that uses optional< bool > or optional< T * > clearer
> > > but will probably also make optional< std::vector< T > > more confusing.
> >
> > The new optional<> now has ".is_initialized()"
> > for those who won't/can't use safe_bool or operator!
>
> Sweet. Though now you have to get the US and UK to agree on how to
> spell it :-)
>
:-)
I'm from Argentina and I speak Spanish so both spellings
are equally foreign to me. :-)

> > I see your point but I'm not sure if this is a recommended pattern.
>
> It also allows the function to be used with classes without copy
> constructors
>
I don't follow. How so?

> template< typename T >
> void f( const optional< T > & );
>
> restricts T to copyable classes.
>
Why? f() as you wrote it, doesn't.
In fact, in place construction, a new feature of optional<>,
effectively relaxes the CopyConstructible requirement in some
cases.

> I think optional< T > is the middle of three cases
>
> T // Known to exist
> optional< T > // May or may not exist
> null_optional< T > // Known not to exist
>
> null_optional would have the same interface as optional but would
> need no storage overhead.
>
> There would be an implicit constructor to make an optional< T > from
> null_optional< T > and optimised versions of the optional_empty and
> optional_get functions.
>
Hmmm.. what would be the purpose of a _type_ like null_optional<>?
I mean, why would you express the idea as a different type instead of
a different state?
In which way is it better than an uninitialized optional<>?

> > The purpose of allowing some degree of similarity between T and
> > optional<T> is to easy the _manual_ transition from one to the
> > other, but optional<T> is not intended to blindly replace T,
> > as in your example.
>
> Yes this is a problem. It would be handy to have a way to
> check the type so
>
> void f( const optional< some_big_class > & );
>
> would become
>
> template< typename T >
> void f( const T & )
> {
> BOOST_STATIC_ASSERT(
> is_optional_version_of< some_big_class, T >::value );
> ...
> }
>
Why do you want to have a function that receives either
an optional<T> or a T?
The semantics you seek are expressed by variant< T, optional<T> >,
though it looks tautological to me.
Managing this sort of duality is the role of optional<> itself.

Fernando Cacciola


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk