www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Now, a critic of Stroustrup's choices

reply "eles" <eles eles.com> writes:
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).
Sep 17 2014
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Sep 17 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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).
Sep 17 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Sep 18 2014
parent reply "Ola Fosheim Grostad" <ola.fosheim.grostad+dlang gmail.com> writes:
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.
Sep 18 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
Sep 18 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Sep 18 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
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
Sep 18 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
Very insightful. Sadly, the allocator question is far from 
solved. I guess this is an area where D can make a difference.
Sep 18 2014