Hi groups,
I'm about to embark on a new project and for maximum portability we've
been asked to code it in the common subset of C and C++.
That's a nonsensical request. Seriously. How is a (potentially
crippling) subset of C and C++ any more *portable* than straight C or C
++? It's like asking someone to code in the common subset of Ada and
Pascal. Just because the intersection between C and C++ is usably
larger doesn't make it any more sane to do.
Is this code going to be compiled as both C and C++? If so, why?
What's the driver for that? What's the perceived benefit? If all
you've been given is some mumblage about "portability", ask the
dipstick who's telling you to do this to provide you with solid
numbers showing greater support across platforms for the subset as
opposed to straight C or C++; otherwise he's just making shit up and
setting you up for failure.
If you honestly need C++ features (classes, templates, STL, etc.),
then write C++. If you don't, then write C. It's perfectly okay to
have a project that consists of both C and C++ files, you just have to
structure your builds appropriately and pay attention to linkage
rules. But for the love of God, don't try to mix the two in the same
source file. That way lies nothing but heartburn.
Can anyone suggest any good documents that might help us? Lists of
gotchas to avoid, that sort of thing?
As others have mentioned, avoid using C++ reserved words as
identifiers (namespace, new, delete, etc.). Realize that the
declaration
int f();
means different things to C and C++ (in C++, f is understood to take
no parameters, whereas in C, f is understood to take an unspecified
number of parameters).
Harbison & Steele's "C: A Reference Manual", 5th ed., has a section on
C++ compatibility in just about every chapter. You might find that
useful.
But again, it's really better to write in C *or* C++, not a crippled
subset of the two.