Re: [Boost-users] [value_initialized] when T is const

Subject: Re: [Boost-users] [value_initialized] when T is const
From: Edward Diener (eldiener_at_[hidden])
Date: 2009-09-19 19:22:24

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.