Now, a critic of Stroustrup's choices

[eles via Digitalmars-d]

Not my goal to bashing or not Stroustrup or to talk too much 
about C++ here, but I found this paper that deals a bit with 
allocators:

http://www.scs.stanford.edu/~dm/home/papers/c++-new.html

(not sure if already posted in the forum).

It criticizes quite heavily the new operator in C++.

It starts with:

"
These are some notes I have on C++'s operator new. Basically, I 
find its syntax downright hateful, and really wish the language 
had dealt more cleanly with allocation and construction. I wish 
one could pass around function pointers to constructors, give 
constructors knowledge of which memory allocators an object was 
allocated with, implement a robust debugging malloc, have safer 
per-class allocators, or per-class allocators that have access to 
constructor arguments. There do exist some slightly gross hacks 
for working around some of the problems. In the end, I show how 
to avoid using operator new at all. More general constructs in 
the language can achieve similar objectives with more 
flexibility. You may find the replacement allocator proposed here 
fairly disgusting. Just keep in mind that something far worse is 
built right into the language.
"

and concludes with:

"
  When a programing language doesn't support some necessary 
operation, one shouldn't simply add new syntax for that specific 
operation. Instead, one should ask, "How can I ammend the 
language to make this operation implementable in a standard 
library?" The answer may be a much simpler, cleaner, and more 
powerful set of mechanisms than the one tailored for a specific 
problem.

C++ needed a way to perform type-safe memory allocation. Such a 
scheme could have been implemented entirely as a library 
function, given the right support. Such support might have 
included ways to infer whether classes have destructors at 
compile time, support for calling constructors directly and even 
taking their addresses, and more. These features might even have 
been useful in more contexts than memory allocation.

Instead, Stroustrup introduced operator new, a disgusting piece 
of syntax inadequate for the job. After many complaints, new's 
functionality was finally extended to include per-class operator 
new[] and placement new, still an imperfect solution.
"

Now, why I am interested in the topic: sometimes I feel like it's 
OK to let the GC manage the memory, but definitely I am not ready 
to give up the deterministic call of destructors. Scoping classes 
for that is kinda ugly if not by default (yes, biased opinion).

But, OTOH, maybe it is a confusion in my head that comes from the 
fact that "constructing" an object means both allocating and 
constructing, while "destructing" means both deallocating and 
destructing. I sometimes just feel that construction/destruction 
shall be separated form allocation/deallocation.

I am not sure about the impact on optimizations, but this will 
simplify delegating memory management to some memory manager of 
choice (I think).