Re: Proposal: statefull objects

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-09-03 20:45:49

> > Hi, Fernando
> >
> > >
> > > Hi Gennadity,
> > >
> > > > Hi, Fernando
> > > >
> > > [SNIP]
> > 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).
My understanding is that:

Given definition T* v;
(v internally is an address of ADDRESS)
access to the value through *v involve 2 steps:
1. Access through address in v to get the value address.
2. Access through that address to get the value.

Given definition T v;
(v internally is an address of VALUE)
access to the value through *v involve 1 step:
1. Access through address in v to get the value.

So difference is significant - 2 times more work.

Though I agree - the name is bad.

If optional is implemented using pointers because type T does not 
have default constructor, I do not see a reason to use it at all. I 
would rather use plain pointer, where NULL would meen absent value. 
While for build-in types default constructor exist. If user-defined 
class T has a default constructor it is also worth while using 
optional<T> (value implemented) instead T*. You pay with default 
constructor call. You buy value access efficiency.

> 
> 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.

I agree with you

> > > > [SNIP]

> > 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 ;

First of all in this form it is 2 times more work. You will need to 
call T(U) and than T(T). That by itself sometimes could be 
inacceptable. Another issue is that the difference is handwritten, th 
at will prevent usage of optional in some cases. Example,

Imagine you have existent template function like this:
template<typename T, typename U>
foo( T const& t, U const& u ) {
...
if( t != u )
  t = u;
...
}

optional<T> t; // was T* t; where NULL meant absent value 
U u;

...

if( !t )
  foo( *t, u );

Last line won't compile.

> 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.

Well, I may not like implicit conversions very much either. But given 
the fact that language allows that you can't avoid presence of 
implicit convertion in generic transparent type like optional (at 
least I think it should be transparent - should behave like T*) in my 
opinion.
    
> 
> > 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_g...
> www.gosierra.com

Regards,

Gennadiy.