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

Subject: Re: [boost] [utility/value_init] boost::value_initialized<T> direct-initialized?
From: Niels Dekker - address until 2010-10-10 (niels_address_until_2010-10-10_at_[hidden])
Date: 2010-04-09 15:34:27

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

BTW, personally I prefer to only use public inheritance when the base class
has a virtual destructor (as a rule of thumb). But I think the price of
adding a virtual table to value_initialized<> is simply too high.

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

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

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. Just like it has always 
been up to now.

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

Please do.  :-)

Kind regards,

   Niels
--
Niels Dekker
http://www.xs4all.nl/~nd/dekkerware
Scientific programmer at LKEB, Leiden University Medical Center