[Please do not mail me a copy of your followup]
<
http://legalizeadulthood.wordpress.com/2009/07/30/c-code-smells/>
A recent security bulletin from Microsoft highlights the dangers of
certain constructs in C++. These constructs constitute a set of code
smells for C++. In this post, I'll describe what I consider to be C++
code smells and how to deal with them.
Pretty standard pet peaves, and as usual, it's pretty easy to find an
exception or two.
: void *
:
: Typeless pointers, or pointers to void — void *, are vestigal
: leftovers from C++’s compatability with C. If you are calling
: into some API that uses typeless pointers, you should immediately
: wrap that typeless construct into a strongly typed construct.
It's true that void* doesn't belong in a high-level API, but
nevertheless void* is important in low-level code. For example, if
you're writing a container class template, you may want to write it as
a thin wrapper around a type-unsafe data structure library - unless
you want to inflict template bloat on your libraries users.
Note that the low-level data structure library would naturally have an
API that uses typeless pointers, though only a few typesafe wrapper
template libraries should use that API.
"Never write type-unsafe code" is unrealistic in some kinds of
projects. "Restrict type-unsafe code to a few small-as-possible areas"
is much more realistic.
As for the (void) parameter list, true, I don't normally use it, as I
normally code in C++ only these days. But one of the main design
objectives for C++ was interoperability with C, and as the author
notes, in C the situation is different - using () means something
different to (void).
If a header may be #included into a C project, the function
declarations *MUST* use "(void)" for empty parameter lists, and even
for headers that are C++-only, some of the readers may be much more
familiar with C than C++. If your code is read by both C and C++
programmers then it is () which is potentially ambiguous (to human
readers), whereas (void) means the same in both languages and avoids
any possible confusion.