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!)
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? 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 Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center