Bug 2590 – Deallocator is not called if constructor fails.

The following test case leaks memory: import std.c.stdlib; class C { new(size_t size) { writefln("In new"); return malloc(size); } this() { writefln("In constructor"); throw new Exception("Exception in ctor"); } ~this() { writefln("in destructor"); } delete(void* p) { writefln("In delete"); free(p); } } void main() { try { auto c = new C; } catch {} } ---- In new In constructor Deallocator should be called to free the memory.

I'm pretty sure this bug is invalid. http://herbsutter.com/2008/07/25/constructor-exceptions-in-c-c-and-java/ As Herb says, "destructors only run on successfully constructed objects."

He is talking about constructors/destructors, not allocators/deallocators. I totally agree the destructor must not be called on a partially constructed object. Conversely, the memory that has been successfully allocated for an object needs to be properly deallocated even if the constructor fails. On the other hand, if overloaded new/delete are going to be removed from the language, the problem will pass away.

(In reply to comment #2) > He is talking about constructors/destructors, not allocators/deallocators. I > totally agree the destructor must not be called on a partially constructed > object. Conversely, the memory that has been successfully allocated for an > object needs to be properly deallocated even if the constructor fails. > > On the other hand, if overloaded new/delete are going to be removed from the > language, the problem will pass away. When one uses class allocators/deallocators, it's basically like taking memory management into one's own hands. The current behavior seems reasonable, because 'delete' is never invoked on the object (which is necessary for a custom deallocator to be used).

> The current behavior seems reasonable, because > 'delete' is never invoked on the object (which is necessary for a custom > deallocator to be used). I don't think it is reasonable. Why should I bother to call the deallocator manually while the allocator is called automatically? Think about object creation as a transaction consisting of two operations: allocation and construction. If construction fails, allocation should be automatically rolled back.

(In reply to comment #4) > > The current behavior seems reasonable, because > > 'delete' is never invoked on the object (which is necessary for a custom > > deallocator to be used). > > I don't think it is reasonable. Why should I bother to call the deallocator > manually while the allocator is called automatically? Think about object > creation as a transaction consisting of two operations: allocation and > construction. If construction fails, allocation should be automatically rolled > back. But the allocator is *not* called automatically, strictly speaking. 'new' is your call to the allocator. Since you use malloc() instead of the garbage collector, 'delete' then becomes necessary. Under normal circumstances, an exception thrown during construction wouldn't leak memory because the garbage collector would eventually collect it; in your code, you took on the task of manually allocating and deallocating memory for objects of class C. It makes sense to me that such custom allocation would entail finer management of exceptional situations.

(In reply to comment #5) > > But the allocator is *not* called automatically, strictly speaking. 'new' is > your call to the allocator. Since you use malloc() instead of the garbage > collector, 'delete' then becomes necessary. > > Under normal circumstances, an exception thrown during construction wouldn't > leak memory because the garbage collector would eventually collect it; in your > code, you took on the task of manually allocating and deallocating memory for > objects of class C. It makes sense to me that such custom allocation would > entail finer management of exceptional situations. Not that I disagree this bug is obsolete, but what would you call delete on? With the failed construction, you never got a pointer to the class data. If class allocators were to be saved, I think the correct behavior on a failed constructor should be to call the deallocator.

(In reply to comment #6) > > Not that I disagree this bug is obsolete, but what would you call delete on? > With the failed construction, you never got a pointer to the class data. > > If class allocators were to be saved, I think the correct behavior on a failed > constructor should be to call the deallocator. Fair point. I didn't realize that it's impossible to hold onto the pointer.

Though D is going to deprecate new/delete operators, it is worth noting that the rule under discussion was adopted by C++ 15 years ago. From "Counting Objects in C++" article by Scott Meyers (http://blog.csdn.net/LYH_Studio/archive/2006/08/11/1051927.aspx): "For many years this was a hole in the draft C++ language specification, but in March 1995 the C++ Standards committee adopted the rule that if, during a new expression, the invocation of operator new succeeds and the subsequent constructor call throws an exception, the runtime system must automatically deallocate the memory that operator new allocated. This deallocation is performed by operator delete, the deallocation analogue of operator new."

A better formatted text: http://www.drdobbs.com/cpp/184403484

While the bug report seems valid, allocator / deallocators are deprecated, hence going to close this.