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