RE: [boost] Re: Proposal: statefull objects

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-09-03 15:46:07

----- Original Message -----
From: Gennadiy E. Rozental <rogeeff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 31, 2001 12:20 AM
Subject: [boost] Re: Proposal: statefull objects

> 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 accessing 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.
>
I don't think this is a trivial "instantiation" policy.
It is an *implementation choice* policy, and I don't think I like to let the
user choose between implementations unless there is a *significant*
difference between choices; which is not the case.

Besides, I don't see why you want to have two implementations.
It looks like you assume that accessing a variable which is held through a
pointer using dereferencig is more expensive than accessing the variable
directly. Actually, unless your compiler optimizer is smart enough to keep
variables in registers for subsequent accesses, this is not true. That is,
there isn't any overhead in dereferencing a pointer. In fact, all variables
are implicitly pointers which are implicitly dereferenced when they are
accessed (except, as I said, that the optimizer managed to keep them in a
register, which is very unusual).

Regarding a policy-based debug/release scheme, I'm still trying to analyze
its large scale engineering impact.
I don't really like a traditional preprocessor-based approach, but in the
meantime I'll be conservative and stick to it.

> >
> > >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.
>
Actually, there is no limitation here. If there is a valid conversion
between U and T you can
always do:  optional<T> t ; *t = (T)u ;
Besides,
  I REALLY DON'T LIKE *THIS KIND* OF IMPLICIT CONVERSIONS.

Just as I would recommend anyone never to write
  int i = 3.14, but eventually, int i = boost::numeric_cast<int>(3.14),
I won't support this implicit conversions in optional, not even those
supported by the language.

> 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
>
Same comments as above.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com