Re: New release of the Dynace OO extension to C
Nick Keighley wrote:
too true. Too scarily true. You have to known most of the language,
the pitfalls, in order to do maintenance on a large C++ code base. I
like to confine my usage of templates to just the STL (at least to
but I don't have this choice if my predecessor was crazy about
At least you *can* know the entire C++ language because it has been
standardized and tons of books have been written about it.
In a large C project there will inevitably be many coding conventions
and metaparadigms which exist for the sole reason of getting around the
limitations of the C programming language (eg. related to memory
management and safety, or to object-oriented programming), and which in
many cases would be unnecessary in C++ (if the C++ project has been well
Thus when you start reading C code written by someone else, you will
have to guess which coding conventions he was using (how many people
document their coding conventions, even in larger projects?), or else
you won't understand half of what's going on.
In the worst cases there will be "clever" tricks all over the place,
eg. related to using preprocessor macros to generate code, using opaque
pointers to simulate modularity (and this "opaqueness" can extend to the
person reading the code trying to understand what's going on), etc. In
many large C projects there will be a kind of "metalanguage" built on
top of C in order to get around the limitations of the language. In
order to understand the program you will need to understand this
metalanguage. This might not always be very easy because of how this
"metalanguage" has been constructed (ie. by abusing obscure preprocessor
On the other, worse extreme, there will be no coding conventions, no
attempt at modularity, no "metalanguage", but just straightforward
spaghetti code which will be next to incomprehensible to anyone else
than the writer himself (and even to him for just a few months).
It's not like large C++ projects would not have coding conventions and
"metaparadigms", but the language helps keeping their amount at minimum,
especially when dealing with basic things like modularity, memory
management and safety. Thus there's less "extra stuff" to learn on a
per-project basis when you start studying some (well-written) C++ program.
As an example, if I need inside a function some fast ordered data
container for a few thousands of elements (and the container must be
local eg. because the function must be thread-safe), in C there will be
approximately as many solutions as there are programmers, each one
creating their own special data container written in C, and each one
using their own personal coding conventions in order to avoid memory
leaks and other memory-related problems. An outsider reading the code
will have to acquaint himself with that person's data structure and how
it's used and how that person uses it.
In C++, however, I would simply use a std::set or std::map in a
completely straightforward and simple way, with nothing special. Anybody
who knows how to use those data containers will be able to easily
understand the code. There are no hidden coding conventions or
metaparadigms in order to get around limitations in the language. It's
just plain and straightforward code, easy to understand, using a data
container which any experienced C++ programmer will be familiar with. No
such luck in C.
Thus the "simplicity" of C is mostly an illusion. This "simplicity"
only makes the code more complicated. C offers no tools which everyone
would be familiar with.