Richard Guenther wrote: >> We should optimize away things like: >> >> int *p = new int; >> if (!p) >> cerr << "Could not allocate memory\n"; > > We don't I believe.
That's a missed-optimization, and independent of any attributes on "operator new". It's a property of the new *expression*, not of the implementation of new. If the compiler treats: int *p = new int; any differently from: int &r = *new int; then we're missing an optimization opportunity. > though ;) Well, at least malloc is allowed to return NULL, so unless > we want to force all malloc attributed functions in C++ to throw exceptions > we cannot assume they return non-NULL (just on the basis they have > malloc attribute, that is). Sure, we can have the attribute in C++ mean the same thing it does in C, even if that's not the strongest declaration we can make. That's OK. But, I don't think that even the C meaning is safe in C++ for use with the library declaration of <new>. I'm also somewhat skeptical of the idea that we will never do any optimization on pointer comparisons. What design principle in the compiler is going to keep us from some day introducing the obvious idea that "if modifying *p cannot affect the value of *q, and p and q are of the same type, then p != q"? I think that (a) either we have to weaken the meaning of the attribute in some way, or (b) we let users use this attribute optionally, for their implementations of operator new when they "know" it's OK to do so, but do not actually put it in the standard headers. I'm not arguing that the attribute is meaningless in C++, or does not apply to the libstdc++ implementation; I'm just arguing that putting it into <new> is not safe. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
