Yeah, C++ does try to be helpful, and all of those automatic copy
constructor, assignment operator and destructor implementations screw
up royally when confronted with pointers
I think that those are newbie problems. The rules for those three
"default implementations" are simple and match what C does for
structs. Use the standard containers, make a habit of forbidding
copying of objects which make no sense copying, and remember the
"explicit" keyword, and you will rarely have problems with this.
(and being able to use
pointers is basically the whole reason for bothering to write anything
in C or C++ in the first place).
Is it? I rarely use pointers in C++ as anything but a kind of
object reference, and mostly because I am forced to.
I use C++ because it is an expressive language with static typing,
which has access to all the hundreds of libraries with a C API on my
(Unix) machine. And because it is fun to use.
I use Python because it is an expressive language with dynamic typing,
which has access to the most important libraries with a C API on my
(Unix) machine. And because it is fun to use.
Code which relies on these default
method implementations is almost certain to be rife with memory leaks
and double-free bugs. So instead of being a convenience, they become a
painfully easy way of writing code that silently does some very, very
wrong things.
I have worked with old code with those kinds of bugs.
It's simple to check and fix. If a class has pointer members of the
Has-A type, the constructors, operator= and destructor have to handle
them (or be suppressed). If they don't, the code is broken.
If you grasp the concept of invariants, it's hard to get wrong. An
object of type Foo has a number of valid states. You have to make sure
there are no ways to create a Foo which is in an invalid state, or
destroying one without cleaning up its state. The best way is usually
to construct it from members which make similar guarantees, e.g. the
standard containers.
Other things like methods (including destructors!) being non-virtual
by default also make C++ code annoyingly easy to get wrong (without it
obviously looking wrong).
The other side of the coin is that you can write tiny classes in C++
with *no overhead*. If my class Foo can be implemented as an integer,
it doesn't need to be slower or take more space than an integer. It
can have value semantics, live on the stack etc, like an integer.
I assume Java programmers avoid such types, and I assume it decreases
type safety in their programs.
Ok, it could have been the other way around so that there was a
"nonvirtual" keyword ... but on the other hand I use inheritance in
C++ about as often as in Python, i.e. almost never.
The whole design of C++ is riddled with premature optimisation of
speed and memory usage in the default settings, instead of choosing
safe defaults and providing concise ways of allowing the programmer to
say "I know optimisation X is safe here, please use it".
"Premature optimization" is a phrase which is always useful as a
weapon, isn't it?
But yeah, I think we can agree about this, at least: when you program
in both Python and C++, it is painfully obvious that C++ never
sacrifices speed or correctness, and it is painfully obvious that the
programmer pays a price for this. Compare ... maybe, for example, the
C++ standard library's very detailed and general iterator and
algorithm concepts with things like Python's str.split and str.join. A
function which takes a list of strings plus a delimiter and returns a
string would be unthinkable in the C++ standard library.
That said, C++ code has one *huge* benefit over ordinary C code, which
is scope-controlled deletion of objects, and the associated Resource-
Acquisition-Is-Initialisation model.
Yes, RAII is one big advantage over any other language I know of.
Compared to good old C, I can come up with many others.
I was going to say something about C++ versus Java here, but the fact
is I haven't written more than a few pages of Java since it came out.
The language (or the culture around it) seems to want to isolate itself
from the rest of the world -- unlike C++ and Python.
/Jorgen
]