
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