Why Shouldn't I use C++?

[leichter_jerrold at emc.com (Leichter, Jerry)]

| From time to time on this list, the recommendation is made to never
| user C++ when given a choice (most recently by Crispin Cowan in the
| "re-writing college books" thread). This is a recommendation I do not
| understand. Now, I'm not an expert C++ programmer or Java or C#
| programmer and as you may have guessed based on the question, I'm not
| an expert on secure coding either. I'm also not disagreeing with the
| recommendation; I would just like a better understanding.
| 
| I understand that C++ allows unsafe operations, like buffer overflows.
| However, if you are a halfway decent C++ programmer buffer overflows
| can easily be avoided, true? If you use the STL containers and follow
| basic good programming practices of C++ instead of using C-Arrays and
| pointer arithmetic then the unsafe C features are no longer an issue?
| 
| C and C++ are very different. Using C++ like C is arguable unsafe, but
| when it's used as it was intended can't C++ too be considered for
| secure programming?
You could, in principle, produce a set of classes that defined a
"safe" C++ environment.  Basically, you'd get rid of all uses of
actual pointers, and all actual arrays.  Objects would be manipulated
only through "smart pointers" which could only be modified in limited
ways.  In particular, there would be no way to do arithmetic on such
pointers (or maybe the smart pointers would be "fat", containing
bounds information, so that arithmetic could be allowed but checked), 
arbitrarily cast them, etc.  Arrays would be replaced by objects with
[] operators that checked bounds.

The STL would be an unlikely member of such a world:  It models
iterators on pointers, and they inherit many of the latter's lack
of safety.  (There are "checked" versions of the STL which might
help provide the beginnings of a "safe C++" environment.)

You'd have to wrap existing API's to be able to access them safely.
All the standard OS API's (Unix and Windows), everything in the C
library, most other libraries you are going to find out there - these
are heavily pointer-based.  Strings are often passed as char*'s.
Note that you can't even write down a non-pointer-based C++ string
constant!

But wait, there's more!  For example, we've seen attacks based on
integer overflow.  C++ doesn't let you detect that.  If you really want
your integer arithmetic to be safe, you can't use any of the native
integer types.  You need to define wrapper types that do something
safe in case of an overflow.  (To be fair, even many "safe" languages,
Java among them, don't detect integer overflow either.)

By the time you were done, you would in effect have defined a whole new
language and set of libraries to go with it.  Programming in that
language would require significant discipline:  You would not be allowed
to use most common C++ data types, library functions, idioms, and so on.
You'd probably want to use some kind of a tool to check for conformance,
since I doubt even well-intentioned human beings would be able to do so.

It happens that C++ has extension facilities that are powerful enough
to let you do most, perhaps all, of this, subject to programmer
discipline.  But is there really an advantage, when all is said and
done?
                                                        -- Jerry
                                        [Who uses C++ extensively, and
                                         does his best to make his
                                         abstractions "safe"]

| Ben Corneau