Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-07 10:39:22

----- Original Message -----
From: "Howard Hinnant" <hinnant_at_[hidden]>

> > I disagree. Not that there isn't a problem, but I think you've
> > misperceived its nature. The built-ins are not the problem: we have
> > way to create an uinitialized built-in, but I believe that
> >
> > quite nicely why double() /must/ initialize its result.
> Thanks for the link. It is a very nice write up that I was not aware
> of. And I was very interested to learn some of the history which I
> ignorant of. But I think we'll just have to agree to disagree. I
> think the wrong decision was made.

Just out of curiosity, what do you think the alternative could have

    int f(double); // 1
    int x = f(double()); // 2

In line 2 above, if double() produced an uninitialized value f(double())
would have produced undefined behavior. Would you have advocated that
double() produces an undefined-but-copyable value?

Maybe we should just make a magic library function which does that:


would produce a value whose copies the compiler can optimize away.

> But it has been made, and I respect
> that. There's no going back. And since there is no going back, I see
> little reason to debate the decision with the benefit of 20/20
> hindsight. Had I been in the position to contribute to this decision
> when it was made, it is quite likely I would have made the same
> I believe the way forward is to create new containers and elements
> take advantage of the flexibility in C++ and do not zero initialize.
> It's not that much work.
> template <class T>
> struct cart_complex
> {
> T real;
> T imag;
> cart_complex() {}
> cart_complex(const T& r, const T& i = T())
> : real(r), imag(i) {}
> ...
> };
> ...
> cart_complex<double>* vec = new cart_complex<double>[1000];

This is close to what I've been advocating in that the knowledge about
skipping intialization is located in the class itself.


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