Niels Dekker - address until 2010-10-10 wrote:
Edward Diener wrote:
I like the idea of using value_initialized for a variable to initialize a value to its value intialized value when no initial value is given. But if an initial value is subsequently given it does not work if the T is a const type. Was this intended ?
I think so, yes. (Nit picking: a subsequently given value is not an initial value!)
Agreed. Phrasing it better I should have said in the second sentence: 'But if a value is subsequently set it does not...etc.'
It can be argued that if one is specifying a const type and one wants to initialize the object of that type to a non-value initialized value, simply do not use boost::value_initialized.
Yes, I think so too. (I'm sorry!)
It would seem that this limitation could be lifted if the boost::value_initialized template had a constructor which enabled one to initialize the value in cases where initialization to a value initialized state was not desired. Then, despite T being a const type, one could initialize the variable to a specific value in the constructor, while keeping the current semantics which disallow changing the value of a const type once it has been initialized.
Of course, technically speaking, a constructor could be added to value_initialized<T> that accepts a T argument, and copies its value. But if so, value_initialized<T> would no longer guarantee to always deliver value-initialized objects. Wouldn't that be a drawback?
I don't see it as a big drawback but perhaps my viewpoint is limited to what I feel I need. The documentation would simply explain that when the constructor is not used, the guarantee holds, but when the constructor is used the object is no longer value initialized but constructed passing the value to the object type's constructor. This would still allow value_initialized to have its original intended effect, while providing a little extra functionality. You could even provide the constructor only for top-level const T ( through the 'Structure Selection' technique as outlined in section 9.4 of the "C++ Template Metaprogramming Book" ), since it is not needed for non-const types whose value can be subsequently set in any of the three ways outlined in the current documentation ( I agree 'get' is best ). Of course this is a one-off situation purely to allow a top-level const value to be initialized to something other than its value_initialized state. I like one-off situations as little as the next programmer, so if there is a better general solution it should be pursued. But right now I don't see one for the problem I outlined.
BTW There's still a fix of a "const issue" of value_initialized underway. Please have a look: https://svn.boost.org/trac/boost/ticket/2548
I do not see how this fixes the situation I outlined in my original OP. That I can get the value back as const T & for a const value_initialized object and T & for a non-const value_initialized object does not help me at all. If T would still be some top-level const, I could not modify it subsequently. Would you please explain how the change made in that ticket solves the problem I have outlined ? I want to emphasize again the point of my original OP. Using value_initialized in a template class or template function where the type of the value_initialized variable is a parameterized type always fails if: 1) The parameterized type is passed as a top-level const. 2) The value_initialized variable needs to be set to anything other than its value_initialized value. I think number 2) above is a very probable situation. Perhaps the situation where a parameterized type can be passed as const or non-const is too rare and therefore it is not worth looking at value_initialized for a "solution". In that case one solution is that if the programmer of the template accepts either a const or non-const value, value_initialized should only be used if the value is guaranteed to never being changed from its value_initialized state. That is a very rare sitution to say the least. Another solution, more onerous programatically, is that the programmer use a value_initialized variable for the non-const type but a normal const variable set to an immediate value for the const type using template metaprogramming. Brrr, that really complicates the programmer's template design. I did design a template class I am coding to use value_initialized and afterward, when I was testing it, realized that when a const type gets used there is no way of setting the value_initialized value to a non-value_initialized value either during the construction of the object or subsequently. Since my template class is meant to be used by end-users, and I don't want to control the constness of the type passed as a template parameter, value_initialized can't be used by me as it currently exists.