Hacker News Reader

Comment by Thorrez | Hacker News Reader

Custom deletion operators are a much much more advanced topic than destructors. Destructors are a basic essential topic all c++ programmers need to know. The vast majority of c++ programmers don't need to know that custom deletion operators even exist.

View on HN

Overloaded delete operators are a relic of a past where malloc() was crummy and inefficient, and almost every object was allocated using new.

Quoting Stroustrup:

Introducing operator new thus made the use of free store more convenient and less error−prone. This increased its use even further so that the C free store allocation routine malloc() used to implement new became the most common performance bottleneck in real systems. This was no real surprise either; the only problem was what to do about it. Having real programs spend 50% or more of their time in malloc() wasn’t acceptable.I found per− class allocators and deallocators very effective. The fundamental idea is that free store memory usage is dominated by the allocation and deallocation of lots of small objects from very few classes. Take over the allocation of those objects in a separate allocator and you can save both time and space for those objects and also reduce the amount of fragmentation of the general free store.

I think almost no one needs custom new and delete today, not only because they are very clunky and obscure, but especially due to the fact that modern C++ features such as move semantics, allocators, std::optional<> and NRVO make them almost redundant and unnecessary.

I had to write my own allocators when I wrote an a postgres language extension in C++ which returned variable length results. This let postgres free the data when it deemed that the result was no longer being used.

It's not just a relic of the past. This was last year.

I'm not talking about allocators or global new/delete, I'm talking about operator new and delete inside of classes, which are arguably almost never used.

Object pools?

I think it's much better to define a pool class and just use methods or static functions to get instances instead of overloading new/delete per class - it's much much more clearer and explicit; having your objects not going through the global new and delete mechanisms is a big gotcha.

Reply on news.ycombinator.com