Boost logo

Boost :

From: Niels Dekker - mail address until 2008-12-31 (nd_mail_address_valid_until_2008-12-31_at_[hidden])
Date: 2007-12-09 17:57:33

David Abrahams wrote:
> reveals
> that
> introduced a failing test of the utility library.

Thanks for reminding me, Dave. The test failure actually indicates that
the MSVC-workaround of value_initialized that I committed a while ago to
the trunk has a bug: when a value_initialized<T> object is copied, the
wrapped T object isn't copied properly. If T has an accessible copy
constructor, it should be called when copy-constructing a
value_initialized<T>. And if T has an accessible copy assignment
operator, it should be called when assigning a value_initialized<T>. I
have just committed a fix for this bug to the trunk:

Luckily the bug wasn't yet released! I mean, it isn't yet in Boost
release version 1.34.1, and I hope we can take it out of the release

The commit (changeset [41942]) aims to fix some other issues as well.
Fernando Cacciola (the owner of value_init) and I also decided to no
longer distinguish between a "workaround version" and a non-workaround
version of value_initialized<T>. Until now the workaround was only for
MSVC. But it has appeared that various other compilers have
value-initialization related issues:

GCC Bug 30111 - Value-initialization of POD base class doesn't
initialize members
GCC Bug 33916 - Default constructor fails to initialize array members
Borland Report 51854 - Value-initialization: POD struct should be

I recently added tests on these issues to value_init_test, and they
caused a test failures on a majority of the test platforms, at

In general, those compilers that don't support value-initialization well
forget to zero-initialize the POD-members of a type T, in some cases...
The workaround is basically as follows: The constructor of
value_initialized<T> stores the bytes of an instance of T in an
aligned_storage::type object, whose bytes are set to zero, followed by a
placement new.

Hopefully the new value_init.hpp will make an end to the test failures.
If so, I hope we can still merge the trunk version with the release
version, 1.35.0.

Kind regards,

Niels Dekker
Scientific programmer at LKEB, Leiden University Medical Center

Boost list run by bdawes at, gregod at, cpdaniel at, john at