Re: [boost] Re: std::complex design (Was: N-Dimensional array library

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.

-Howard