Re: Proposal: statefull objects

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-08-30 22:20:38

Hi, Fernando

> 
> Hi Gennadity,
> 
> > Hi, Fernando
> >
> [SNIP]
> > 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 
absolutely
> any actual difference between both implementations in terms of 
performance
> issues while accesing the values.
> 
> If I were to remove the bypass trick -which I won't-, my 
implementation
> would use:  T data ; bool initialized ; just like yours.
> 
> All the particularities you see with the implementation are there 
only to
> 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 
optional
> 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.

> 
> Regards,
> 
> Fernando Cacciola
> Sierra s.r.l.
> fcacciola_at_g...
> www.gosierra.com

Regards, 

Gennadiy.

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