On 13 May 2010, at 15:14, Niels Dekker - address until 2010-10-10 wrote:
On 2010-05-13 12:32, Christopher Jefferson wrote:
I just wanted to make people away of a suggested patch to value_initialized, explicitly adding the default constructor, copy constructor and operator=, given in https://svn.boost.org/trac/boost/ticket/4213 .
First of all, sorry for causing the regression failure. It was caused by my commit [61883], which added initialized<T>, and reimplemented value_initialized<T> in terms of initialized<T>: https://svn.boost.org/trac/boost/changeset/61883
Please note that this commit hasn't yet been merged to the release branch. You see, there are no value_init_test failures at http://www.boost.org/development/tests/release/developer/utility.html So it's merely a trunk issue.
The default constructor is necessary for clang and comeau (in strict mode) to allow const value_initialized values without an explicit value. I believe this is correct behaviour, but other compilers are more lack.
I believe this patch is small and should work fine, but I know that this has been a very sensitive bit of code in the past, prone to kicking up minor compiler problems.
Your value_initialized() default constructor is fine with me, but personally I'd rather not have the user-defined copy constructor and operator=. You know, value_initialized<T> does not need to be CopyConstructible or CopyAssignable. That just depends on whether T is.
Sorry, I thought the user-defined copy constructor and operator= were necessary to stop tests failing, the default constructor is all that's really important. Yes, please apply the default constructor to trunk. Chris