From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-08-30 22:20:38
> Hi Gennadity,
> > Hi, Fernando
> > BUT the implementation should be
> > value-based not pointer based, to eliminate dereferensing.
> Actually, the implementation is somewhat confusing because I intend
> optional<T> to bypass T's default constructor. It shouldn't be
> any actual difference between both implementations in terms of
> issues while accesing the values.
> If I were to remove the bypass trick -which I won't-, my
> would use: T data ; bool initialized ; just like yours.
> All the particularities you see with the implementation are there
> support the bypassing of T::T().
Look what I sad in http://groups.yahoo.com/group/boost/message/16898
Basic idia is by default it should be value-like implementation. If
you can't provide Default constructor - use different "instantiation"
policy. One alternative could be based on placement new.
> >Here what
> > I did. Compiled and tested on MSVC and sun workshop
> > [SNIP]
> I'm sure about your new assign method. It changes the semantic of
> too much, since being a template member
> I could do:
> optional<int> opt ;
> *opt = 3.14 ;
> I don't think I like it.
C++ allows you to write int i = 3.14. If there is converstion between
U and T ( so you can write T t = u;), we should be able to do this:
optional<T> t; *t = u; In other case it will become even more strict
limitation then DefaultContructable.
> Fernando Cacciola
> Sierra s.r.l.
P.S. As comment to another message in the thread: We could think
about possibility to provide implicit conversion through constructor
to support return semantic. But I would not support solution that
allows t = value and *t = value
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk