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-09 16:47:10

Hi Niels,

>>> You know, I once considered having initialized<T> publicly derived 
>>> from value_initialized<T>:
>>> http://lists.boost.org/Archives/boost/2010/03/164356.php
> 
> Fernando Cacciola wrote:
>> 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.
> 
> Thank, Fernando. I know the LSP is a very important OO principle. But are
> you saying that Bacon Cheeseburger Pizza is a vegetarian meal, just because
> it's a superset thereof?
> 
LOL, certainly not.

What I meant to say is that in our case, the choice between your patch vs 
inheritance is expressing, in reality, two completely different things (instead 
of being just a design decision). I just attempted to argue why and how.

> BTW, personally I prefer to only use public inheritance when the base class
> has a virtual destructor (as a rule of thumb).

I do too.

> But I think the price of
> adding a virtual table to value_initialized<> is simply too high.

Absolutely.

Anyway, as I said, by choosing one or the other, in this case, we are defining 
two totally different abstractions, so IMO, the decision should have nothing to 
do with the technical convenience but with what we want these things to be.

>>> 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?
> 
> Good question. Currently, boost::value_initialized<T> requires that T is
> "value-initializable" (i.e., DefaultConstructible), in order to construct
> value_initialized<T>. When you're adding the proposed
> value_initialized(const T&) constructor (ticket #3472), 
> value_initialized<T>
> will no longer require that T is value-initializable, in order to construct
> value_initialized<T>. Sounds counter-intuitive to me.
> 
> [snip]
> 
>> 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.
> 
> C'mon, your boost::value_initialized<T> has been around for more than 7
> years, and now you think it has always been useless??
> 
See my next response.. that'll clarify my statement.

>> Certainly I always considered that the invariant is that it cannot be 
>> left unitialized rather that it cannot be direcly-initialized.
> 
> I thought the purpose of value_initialized<> was to provide a generic 
> way to
> do value-initialization; and to

> guarantee that the constructed object is indeed value-initialized. 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Please correct me if I'm wrong.
> 
I can't say that you are wrong, because clearly that is a perfectly valid 
interpretation. OTOH, I really never intended the purpose to be that :)
That's why I said that I couldn't see uses for a class that is strictly *value* 
initialized instead of value initialized *by default at the very least* (which 
was my intention.. just that it never ended up uninitialized)

If I had, then as I said before, I would have instantly reacted to Eduard's 
request arguing that what he wanted was perfectly fine but did not belong to my 
class

> Anyway, I also think it makes code analysis (reviewing Boost user code)
> easier when the reviewer 

 > can safely assume that a value_initialized<T>
> object 
 > always originates from value-initialization.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (1)

> Just like  
 > it has always been up to now.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (2)

OK, what you just said totally settles it IMO :)

At the very least *you* are assuming, or always assumed, (1), and the actual 
code I wrote was indeed 'forcing' that assumtion. (because of (2))

So it doesn't matter what my intention was, nor that I think I should have added 
the direct-initializer Eduard requested. That class has always been comunicating 
something else: (1), so I don't really have a responsible choice now but to add 
initialized<> as a new thing.

I don't think I would ever use value_initialized<> INSTEAD of initialized<>, but 
that's just me.

Having said that...

your specific implementation of these two classes are exactly what I would have 
done, so, please go ahead and commit your patch.

Best

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