Question

I’ve recently come across this rant.

I don’t quite understand a few of the points mentioned in the article:

• The author mentions the small annoyance of delete vs delete[], but seems to argue that it is actually necessary (for the compiler), without ever offering a solution. Did I miss something?

• In the section ‘Specialized allocators’, in function f(), it seems the problems can be solved with replacing the allocations with: (omitting alignment)

  // if you're going to the trouble to implement an entire Arena for memory, // making an arena_ptr won't be much work. basically the same as an auto_ptr, // except that it knows which arena to deallocate from when destructed. arena_ptr<char> string(a); string.allocate(80); // or: arena_ptr<char> string; string.allocate(a, 80); arena_ptr<int> intp(a); intp.allocate(); // or: arena_ptr<int> intp; intp.allocate(a); arena_ptr<foo> fp(a); fp.allocate(); // or: arena_ptr<foo>; fp.allocate(a); // use templates in 'arena.allocate(...)' to determine that foo has // a constructor which needs to be called. do something similar // for destructors in '~arena_ptr()'. 

• In ‘Dangers of overloading ::operator new[]’, the author tries to do a new(p) obj[10]. Why not this instead (far less ambiguous):

  obj *p = (obj *)special_malloc(sizeof(obj[10])); for(int i = 0; i < 10; ++i, ++p)     new(p) obj; 

• ‘Debugging memory allocation in C++’. Can’t argue here.

The entire article seems to revolve around classes with significant constructors and destructors located in a custom memory management scheme. While that could be useful, and I can’t argue with it, it’s pretty limited in commonality.

Basically, we have placement new and per-class allocators — what problems can’t be solved with these approaches?

Also, in case I’m just thick-skulled and crazy, in your ideal C++, what would replace operator new? Invent syntax as necessary — what would be ideal, simply to help me understand these problems better.

Answer 1

Well, the ideal would probably be to not need delete of any kind. Have a garbage-collected environment, let the programmer avoid the whole problem.

The complaints in the rant seem to come down to

1. ‘I liked the way malloc does it’
2. ‘I don’t like being forced to explicitly create objects of a known type’

He’s right about the annoying fact that you have to implement both new and new[], but you’re forced into that by Stroustrups’ desire to maintain the core of C’s semantics. Since you can’t tell a pointer from an array, you have to tell the compiler yourself. You could fix that, but doing so would mean changing the semantics of the C part of the language radically; you could no longer make use of the identity

*(a+i) == a[i] 

which would break a very large subset of all C code.

So, you could have a language which

• implements a more complicated notion of an array, and eliminates the wonders of pointer arithmetic, implementing arrays with dope vectors or something similar.

• is garbage collected, so you don’t need your own delete discipline.

Which is to say, you could download Java. You could then extend that by changing the language so it

• isn’t strongly typed, so type checking the void * upcast is eliminated,

…but that means that you can write code that transforms a Foo into a Bar without the compiler seeing it. This would also enable ducktyping, if you want it.

The thing is, once you’ve done those things, you’ve got Python or Ruby with a C-ish syntax.

I’ve been writing C++ since Stroustrup sent out tapes of cfront 1.0; a lot of the history involved in C++ as it is now comes out of the desire to have an OO language that could fit into the C world. There were plenty of other, more satisfying, languages that came out around the same time, like Eiffel. C++ seems to have won. I suspect that it won because it could fit into the C world.