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 . 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. 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.
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
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
participants (2)
-
Christopher Jefferson -
Niels Dekker - address until 2010-10-10