Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-03-07 14:21:50

On Thursday, March 7, 2002, at 01:36 PM, David Abrahams wrote:

> Of course I was proposing the converse of this, and you can implement it
> without any language changes, and it doesn't open the door to undefined
> behavior all over the language the way having T() uninitialized would:
> template <class T>
> inline T uninitialized_value(int2type<false>) // is not scalar
> {
> T x; // undefined behavior, if you really demand it
> return x;
> }

Yeah, this looks interesting.

> And it helps with efficiency, provided your compiler is smart enough to
> optimize away the copy.

It's been my experience that compilers are slow to recognize magic
std::objects, but hey, sometimes that's the best (or only) route!

> The big problem, of course, is that it still invokes undefined behavior.

I don't see this as a big problem. Most platforms today will treat any
scalar as just a bit bucket and happily shuffle any value around. Maybe
you can't do anything but copy it or assign to it, but that seems more
than enough. And if your platform is one of those that really get upset
about certain values of scalars, then just don't use
uninitialized_value! Since "new scalar[n]" already has this behavior,
seems unlikely that it would be a devastating blow.

> If containers had an interface which took a number of elements and an
> inplace-constructor function or function object, we could handle the
> issue straightforwardly. It's too bad there's no way to capture
> "function which constructs a T at this address" in static type info.

Interesting thought.


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