Boost logo

Boost :

From: rwgk (rwgk_at_[hidden])
Date: 2002-03-07 18:10:21

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> Yes, that's the definition of trivial destructor, but it's just not
> right criterion for deciding whether members must be initialized in
> constructor. For example, one member might be a type with a trivial
> destructor but whose constructor does something important that
can't be
> skipped.


The current rules for the initialization of scalars are
god-given. There are ample ways for someone writing a
class to provide a constructor that does nothing.


In the context of initializing elements of a container I am
trying to follow the path of least additional complexity,
minimum restrictions, maximum generality and full backward

Minimum restrictions:

Take the example of std::vector<T> vec(). If vec goes out
of scope, there is a loop with size() iterations from
vec.begin() to vec.end() that calls delete for each element
of the vector.
If we suppress the construction of the elements, where
could we get into trouble later (assuming that the user has
explicitly requested uninitialized initialization and is
therefore responsible for other side effects)?
Isn't the answer: Only if T has a non-trivial destructor?
What else could go wrong?

Maximum generality:

The new approach should work for any type, built-in or
user-defined, given the current rules for the
initialization of scalars, even if the designer has not
thought about the initialization problem.
    If the designer cares, he can make a conscious effort
    to meet the minimum requirements for instantiating a
    container of uninitialized values; if the designer
    does not care but the type lends itself "naturally" to
    uninitialized initialization, why shouldn't it just

Full backward compatibility:

Instantiation of a container with uninitialized values
should be an additional constructor that does not interfere
with the established std::vector or std::valarray

Least additional complexity:

- The additional constructor should be intuitive.
- It should be safe.
- It should be easy to implement.
- A portable implementation should be easy.

A proposed solution that meets all the requirements:

  struct uninitialized_flag {};

  template <typename T>
  class vector
      // ...
      vector(size_t n) // shown here to illustrate what happens under
the hood
        // allocator is called here
        std::uninitialized_fill_n(begin(), n, T());
        size_ = n;
      vector(size_t n, uninitialized_flag)
        // allocator is called here
        size_ = n;
      // ...
      // ...
      size_t size_;
      // ...

  The only extension of the current standard that is needed
  to allow for a portable implementation is that
  has_trivial_destructor<T> must be available.

Example implementation:
(also available at, currently branch

Most relevant files:
Look for "no_initialization_flag".

These types are used (i.e. tested) in a major application.

Note that the array family does not include a direct competition
for std::vector or std::valarray. Therefore the extension proposed
above is still relevant (to me, anyway).

Portability (with a few simple hacks related to

VC6 (well, this is cheating, the safety check is simply turned off)
Codewarrior 7, Win32
gcc 3.0.x
EDG 238
EDG 240
EDG 243
EDG 245


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