Re: [boost] [utility/value_init] boost::value_initialized<T> direct-initialized?

Subject: Re: [boost] [utility/value_init] boost::value_initialized<T> direct-initialized?
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2010-04-08 16:18:26

Hi Niels,

> Robert Stewart wrote:
>> Given that, I have to agree with Fernando that initialize is
>> merely a superset of value_initialize and can be harder to explain
>> unless it derives from value_initialize (even if it shares nothing
>> from the base and only makes clear that it is a superset).
> 
> Thanks, Robert. But do you mean public inheritance? You know, I once 
> considered having initialized<T> publicly derived from 
> value_initialized<T>: 
> http://lists.boost.org/Archives/boost/2010/03/164356.php 

Let's see:

Given a set 's' and a superset 'S', we derive S from s because by LSP we need to 
be able to substitute s by S. That is, pass an S where an s is asked for.

So, IF initialized<> is indeed a superset of value_initialized<> then the 
derivation that Robert proposed and you attempted at first is definitely correct.

 > But then I
> realized that it would imply that any "initialized" object is also a 
> value_initialized object. While certainly an initialized object does not 
> need to be value-initialized.
> 

So then you realized that in a certain interpretation of the meaning of 
value_initialized<>, it is NOT really a subset of initialized<>.

Why? I think the differnce is in the actual semantics of the name... do we mean 
value_initializED or value_intializaBLE?

Clearly, your view here is that an object value_initialized<> is *specifically* 
having the invariant that its value is neccesarily value initialized, which is 
entirely differnt from saying that its value if neccesarily never left 
uninitialized, so it is *at least* value initialized.

Those are two clearly different classes. If your current interpretation is the 
one to go for, then the issue is very simply settled because then, Eduard's 
request has no place to begin with, and by neccesity we need an entirely new class.

> Therefor I think composition is preferable to public inheritance

I wouldn't put it in those terms.
Depending on what we define these classes to be, one or the other is the only 
correct choice.

Having said all that..

IF we would agree to consider that value_initialized<> guarantess that it can 
only contain a value-initialized object, then your proposal would be definitely 
correct.

OTOH, what's the use of such a class?? I can't see any. Certainly I always 
considered that the invariant is that it cannot be left unitialized rather that 
it cannot be direcly-initialized.

Your other line of argument about const and non-const iterator classes is 
independent and I'll address it on aother post.

Best

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com