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).

On Wednesday, 17 September 2014 at 09:21:13 UTC, eles wrote:
>
> 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.

It usually is. I'm not sure what you are talking about. Most containers in C++ (and D) first allocate with an allocator, and then placement construct.

> I sometimes just feel that construction/destruction shall be separated form allocation/deallocation.

Again, it usually is. AFAIK, the only thing is "vanilla new", which conveniently does both for you in a single convenient call. If you want to do *anything* else, then you have to manage both individually.

On Wednesday, 17 September 2014 at 09:21:13 UTC, eles wrote:
> "
> 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.

FWIW, Simula had "new". C++ is B.S.' attempt to marry C with Simula. It's not "designed", but more like "translated", then mutilated a posteriori… Hence the hodgepodge syntax (and semantics).

Very insightful. Sadly, the allocator question is far from solved. I guess this is an area where D can make a difference.

On Wednesday, 17 September 2014 at 12:05:58 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 17 September 2014 at 09:21:13 UTC, eles wrote:
>> "
>> 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.
>
> FWIW, Simula had "new". C++ is B.S.' attempt to marry C with Simula. It's not "designed", but more like "translated", then mutilated a posteriori… Hence the hodgepodge syntax (and semantics).

Bjarne's book about C++ design and evolution is quite good to understand how C's compatibility and other issues drove C++ design.

--
Paulo

On Thursday, 18 September 2014 at 08:14:42 UTC, Paulo  Pinto wrote:
> Bjarne's book about C++ design and evolution is quite good to understand how C's compatibility and other issues drove C++ design.

I guess cfront affected the design a lot by being based on converting the input to C. Not adding a proper module system was a big mistake, but that is OT.

On Thursday, 18 September 2014 at 08:33:53 UTC, Ola Fosheim Grostad wrote:
> On Thursday, 18 September 2014 at 08:14:42 UTC, Paulo  Pinto wrote:
>> Bjarne's book about C++ design and evolution is quite good to understand how C's compatibility and other issues drove C++ design.
>
> I guess cfront affected the design a lot by being based on converting the input to C. Not adding a proper module system was a big mistake, but that is OT.

These issues are touched in the book if I remember correctly.

Quite a few C++ design decisions came from the requirement to fit 1:1 with C toolchains.

Now we need to wait for C++17, or do some marketing that D has them today. :)

--
Paulo

On Thursday, 18 September 2014 at 09:16:39 UTC, Paulo  Pinto wrote:
> These issues are touched in the book if I remember correctly.

Yeah, but I don't have it and hoped you would give me some juicy quotes :).

> Quite a few C++ design decisions came from the requirement to fit 1:1 with C toolchains.

Isn't it funny (or sad) though how the IT sector keeps being bogged down by clogged backwards compatibility issues going all the way back to the 60s and 70s?

> Now we need to wait for C++17, or do some marketing that D has them today. :)

Hm, yes.

Am 18.09.2014 20:10, schrieb "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>":
> On Thursday, 18 September 2014 at 09:16:39 UTC, Paulo  Pinto wrote:
>> These issues are touched in the book if I remember correctly.
>
> Yeah, but I don't have it and hoped you would give me some juicy quotes :).

The book is a few thousand kilometres from my current location. So no chance.

>
>> Quite a few C++ design decisions came from the requirement to fit 1:1
>> with C toolchains.
>
> Isn't it funny (or sad) though how the IT sector keeps being bogged down
> by clogged backwards compatibility issues going all the way back to the
> 60s and 70s?
>

Yes, which is why incremental changes tend to win over disruptive ones.

Then we also have certain technologies that become mainstream and destroy better ones (e.g. C).

All the efforts the programming communities that care about safety now have to spend promoting languages like D to fix the security issues created by it. When more safer languages were already available at the time UNIX spread out of university labs.

--
Paulo