rjhansen

It significantly predates the C++11 standard.

Most of the smartpointers in the modern C++ standard weren't official until TR1 in 2003; even then, a lot of compilers took a long time to catch up. Prior to 2003, the only smartpointer in the C++ standard was std::auto_ptr, which had some really unpleasant semantics.

There were two basic choices: go with a smartpointer library like Boost or Loki, or go with the Boehm-Demers-Weiser GC. The GC route was pretty easy and minimal pain, while Boost and Loki were moving targets. A lot of places went with the more stable BDWGC instead.

If that's straight-up bog-standard ANSI C++, then yes, there's a memory leak.

But, to put my Devil's Advocate hat on a moment: the environment could be GCed and new could be overridden to return a GCed pointer, as opposed to a naked pointer. (There are lots of good GCs for C++ -- see, e.g., http://www.hboehm.info/gc/)

One of the great things about C++ is how thoroughly you can customize the system using operator overloading. One of the big drawbacks about C++ is that without knowing the precise environment in which the code is operating, you really don't know what 'new' does. Or any other operator, for that matter. :)

As an observation, that's trivial: as an apologia, it's inadequate.

I'm judging the author on what he said, not what other people think he really meant to say. If you change what the author said to be "C, C++ and Java are written in different ways," then sure, the author's right. But that's not what the author wrote, and what the author wrote is unsupportable.

Anybody who calls C, C++, and Java three of the most different programming languages out there is someone who has never tried LISP, Prolog, or SQL.

He also flat says "C++ OOP has nothing to do with Java-like OOP", which is just not true. To name two big, major things, Liskov substitution and class invariants both work the same way when modeling Java and C++ code.

He also has some strange beliefs about the total supremacy of the compiler when it comes to writing Assembly. Compilers are great tools (as my buddy Doug says, "a compiler is an expert system for creating Assembly"), but like all expert systems they've got holes in their game. In the long run the compiler will eat your lunch, but in the small run the human can still prevail. I've written Assembly that out-performs compiled code for ~100 lines; I know several others who have done likewise.

The author seems to have a lot of technical understanding of the C++ language, but not very much in the way of wisdom about it.