Re: Preprocessor Push/Pop Idiom, How To?
Francis Glassborow wrote:
In article <4o7h4lFdc1ofU1@individual.net>, Alf P. Steinbach
<alfps@start.no> writes
C++ is the direct descendant of the language where that
convention originated. In C++ the convention /in its
original useful form/ is still very much alive. Bringing the
bastardized incompatible Java form of that convention back
into C++ would be, well, incongruous...
Yes, I completely agree, but I suspect there is another reason
that ALL_CAPS has crept into use for non-preprocessor names. I
think that many early adopters of C++ did not really
understand why ALL_CAPS was used in C for manifest constants.
It was used because that was the convention, then. As it
happens, in C, manifest constants were macros, so the convention
gradually changed to say that macros were all caps, but it
wasn't always that way, and in the early C implementations that
I used, getc was a macro (as it still is in most implementations
today), as was isupper, et al. (including in one implementation
where isupper evaluated its argument twice).
Historically, all caps was originally used for manifest
constants, and whether something was a macro or not was ignored
by the naming convention. Of course, programmers being what
they are, some rather quickly came up with macros that did
really funny things, opened braces, etc. And needed a name
which stuck out for them. All caps was a natural, since nothing
sticks out more. Finally, along came C++, where manifest
constants are not normally macros. Most of the earliest C++ I
saw still used all caps for them, but when the declaration reads
something like "const int CONSTANT = ...", the resemblance with
a variable is so evident... And of course, one man's const is
another man's variable: I've seen C code which had a couple of
global variables that were all caps---they were originally
manifest constants, but evolution lead to their being read from
a configuration file (and as this was classical, pre-ISO C, they
weren't even declared const).
The convention of putting constants in all caps seems to go very
far back; I'd seen it in PL/1 before ever having seen C.
Luckily, we learn from history, or at least, some of us do.
Today, of course, when every application is configurable in
twenty different ways, there's really no such thing as a
manifest constant---it will be read from a configuration file
tomorrow.
When they converted from using the pre-processor to using
const type definitions for manifest constants they just
transferred the original name. Of course there was another
pressure to do this, it meant that legacy C code could be
'improved' by replacing
#define VAR 3
with
int const VAR(3);
and all the uses would remain working. I understand the
reasoning here but think that it is misplaced, just leave the
original and the code will work as intended.
What really irritates the h*** out of me is code such as:
enum colour {RED, BLUE, GREEN};
enumerators were never written as all caps in C (or not by
programmers who understood the divide between the
pre-processor and other names) but, of course, once you start
using all caps for manifest constants you obviously should do
the same for enumeration constants.
And integral constants declares as int:-).
Learn why things are done rather than simply see the
superficial and you will write code that is less vulnerable to
the pre-processor.
I think you've got the historical aspect wrong, but as I say,
most of us have learned from history, and have stopped repeating
the same mistake.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]