Re: [boost] Patch to value_initialized

Subject: Re: [boost] Patch to value_initialized
From: Christopher Jefferson (chris_at_[hidden])
Date: 2010-05-13 10:28:45

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