Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-03-07 19:17:12

This proposal looks good to me.

On Thursday, March 7, 2002, at 06:10 PM, rwgk wrote:

> 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?

Just one nit:

I think this is the wrong question. I can imagine a class with a
non-trivial construction process but a trivial destruction process. For
example a class that must keep a pointer to some part of itself to
satisfy a class invariant. The pointer must be set in a constructor.
But the destructor is a no-op. Such a class should not be used with
uninitialized_flag. That makes
nothing but false security.

I would propose either programmer beware, and have no checks. Or that a
traits be developed that says: this class has a constructor that is a
no-op. It is the construction we're skipping. If the class can't be
constructed with 0 instructions, then we shouldn't be trying to do
that. vector<T>(N, uninitialized_flag) still represents N /constructed/
T's. It's just that their value is indeterminant.


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