This is now the third edition of this critique; it has
been four years since the last edition. The main
factor to precipitate a new edition is that there are
now more environments and languages available
that rectify the problems of C++. The last edition
was addressed to people who were considering
adopting C++, in particular managers who would
have to fund projects. There are now more choices,
so comparison to the alternatives makes the critique
less hypothetical. The critique was not meant as an
academic treatise, although some of the aspects
relating to inheritance, etc., required a bit of
technical knowledge.
The critique is long; it would be good if it were
shorter, but that would be possible only if there were
less flaws in C++. Even so, the critique is not
exhaustive of the flaws: I find new traps all the time.
Instead of documenting every trap, the critique
attempts to arrange the traps into categories and
principles. This is because the traps are not just one
off things, but more deeply rooted in the principles
of C++. Neither is the critique a repository of ‘guess
what this obscure code does’ examples.
One desired outcome of this critique is that it
should awaken the industry about the C++ myth and
the fact that there are now viable alternatives to C++
that do not suffer from as many technical problems.
The industry needs less hype and more sensible
programming practices. No language can be perfect
in every situation, and tradeoffs are sometimes
necessary, but you can now feel freer to choose a
language which is more closely suited to your needs.
The alternatives to C++ provide no silver bullet, but
significantly reduce the risks and costs of software
development compared to C++. The alternatives do
not suffer under the complexities of C++ and do not
burden the programmer with many trivialities which
the compiler should handle; and they avoid many of
the flaws and inanities of C/C++.
The language events which have made an update
desirable are the introduction of Java, the wider
availability of more stable versions of Eiffel, and the
finalisation of the Ada 95 standard. Java in
particular set out to correct the flaws of C++, and
most sections in the original critique now make
some comment on how Java addresses the problems.
Eiffel never did have the same flaws as C++, and
has been around since long before the original
critique. Eiffel was designed to be object-oriented
from the ground up, rather than a bolt-on. Java
offers better integration with OO than C++. Now
that there are language comparisons in the critique
the arguments are less hypothetical, and the
criticisms of C++ are more concrete.
