On 3/29/2010 4:14 PM, Niels Dekker - address until 2010-10-10 wrote:
Edward Diener wrote about https://svn.boost.org/trac/boost/ticket/3472
My suggested fix is so simple that it is hard for me to understand why it should take so long for a decision to be made on it unless he was no longer involved.
Fernando Cacciola wrote:
Actually, your fix is NOT so simple, not conceptually.
Edward replied:
I understand that, but I did mean syntax-wise.
But clearly, as my argument shows, value_init can not be used in any situation in which an object including a value_init value is declared as a const object unless you allow the value initialized value to be initialized to something other than its value-initialized default upon construction ( which is my fix ). And since a developer can hardly control how an end-user uses his object, whether as const or non-const, essentially you are telling any developer that value_init is useless to him unless he enforces the fact that his own object which has a value_init value is never const, which in my opinion makes its practical usage much, much less than it conceptually could be.
How many developers do you think want to restrict their own objects to non-const ? But currently value_init is practically useless to them unless they do. Which is fine if you want it that way, but clearly developers wanting a value_init value for a potentially const object will not use it and just revert back to a default constructed object which may be constructed based on an alternative constructor. Which is a shame because value initialization as you have conceived and coded it is much clearer and safer to use.
Edward, you know I agree that it would be useful to have an extra value_inititialized<T> constructor to allow direct-initialization of the wrapped T object. It's just that I'm not entirely sure if it's a good idea to declare it as value_initialized(T const&).
I think it would be a bit safer to add an extra "tag" parameter, to clarify that the constructed object is direct-initialized, instead of value-initialized:
struct direct_initialized_t { };
value_initialized(T const&, direct_initialized_t).
I know you prefer your own proposed constructor, value_initialized(T const &), but does that mean that you're /opposed/ to having value_initialized(T const&, direct_initialized_t) instead?
I do not understand what the extra parameter specifying direct initialization is supposed to do. Making something safer implies that something else is not safe but I can not understand what is not safe with merely 'value_initialized(T const &)'. Because Microsoft, as we both know, has a bug with erroneous calling base class constructors of the type I suggested is not a reason to change code to make it 'safer'. One might as well change all code one writes with more elaborate constructs guaranteeing better 'safeness' from potential compiler bugs. But I do not believe this can ever be a way of doing programming. However if your alternative is the chosen final result, it is better IMO than no way to initialize a value_initialized with a const T value. And if Fernando rejects any way to initialize a value_initialized with its T value I will fully understand also and, as I said, just go back to using default initialization for my needs.