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.
My preferred option would be to try submitting this patch to trunk and see if any tester kicks up a fuss. If any do, then I am happy to introduce some macros.
I don't expect your default constructor to cause any compiler problems. Is it okay to you if I just add the default constructor you're proposing to the trunk? Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center