http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #28 from Thomas W. Lynch <dimitrisdad at gmail dot com> 2012-05-04 22:31:36 UTC --- I see that example, I understand it, and I appreciate your writing it. Though we are going a long way from the original "minor bug". Had it not been operator new, but another operator or method it would have correctly assigned the count, as was shown. The argument made was that operator new was different because "the object did not exist", however, it is the "type" that determines the offsets (or as you have artfully pointed out, the 'this' pointers). The type information is known at compile time. The compiler is capable of endowing operator new like other methods. It has been pointed out by a couple of people that the C++ standard says that an object only exists after new finishes, and that is the reason. However, an 'object' in that context is an instance, and yes, the instance does not exist until it is allocated -- but the type information exists before new is called. New is not bared from the standard from seeing the type. So someone else pointed out, that the instance does not exist, so it should not be assigned to. That has probably been the best answer I have heard, however, by convention, allocators do write to an allocated area. In addition, ** the compiler is not flagging access to the object from inside new ** - it allows it - in this case ** it just generates the wrong code ** (and you have artfully explained why). This is a minor bug. So I continue to say it is wrong to close this. Either the compiler should be giving at least an error for illegal access to the object, according to the standard, or the correct type information should be there. I would interpret the standard, and convention, to favor the latter. Currently the compiler does neither - so there is a minor bug. This is a faithful summary of the discussion on the topic, where is your disagreement here?
