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