Re: Preprocessor Push/Pop Idiom, How To?
Robert Kindred wrote:
[]
enum colour {RED, BLUE, GREEN};
So do you have a standard for enums? I would like to somehow
differentiate them from variables.
Why? What's the difference between:
enum Color { red, blue, green } ;
,
typedef int Color ;
Color const red = 0 ;
Color const blue = 1 ;
Color const green = 2 ;
and
typedef int Color ;
Color red ; // read from configuration file.
Color blue ; // read from configuration file.
Color green ; // read from configuration file.
?
(More than once, I've had the first evolve to the third.)
I just like to know. I also like my type declarations
capitalized, not just because I have been beaten into
submission, but because I like the ready recognition.
I agree that typenames should be distinctive. You can't parse
C++ without knowing which names name types, and which don't.
And of course, changing something that was a type name to
something that isn't just doesn't work---it means a major
rewrite.
I don't want to denigrate what works for you, but do
you have any programs that run for long periods of time?
In theory, yes. In practice, I think very few actually run for
more than about five years without someone rebooting the
machine, or at least restarting the program.
In the case of constants being read from files, there is the
danger that a freshly started program may not agree with a
long-running program on what "red" means, if the configuration
file has been changed.
Obviously, if a program is designed to run for more than a day
or two, you have a facility which allows rereading the
configuration file on the fly. Programs don't run for five or
more years without a single change in the configuration.
But of course, this is a potential problem, which has to be
addressed. Making sure that all of the machines in the network
have the same configuration file can be a real pain. My usual
solution is to use text formats between processes, so that the
numeric value of red can be different from one machine to the
next. But its not always possible.
Of course, enum's aren't the only things that can suffer from
this problem. Any time you upgrade just about anything in the
server, you have to arrange to understand the previous version
as well, because there's no way that you'll be able to get all
of the clients to upgrade simultaneously. It's part of a bigger
problem.
To me, your constants are not very constant.
They aren't. But they once were, and for many users, still are,
and I don't want to have to change the code in all of those
users. (In response to another poster: I'd never design a
system from the start with a set of such non-const global
variables. If I knew from the start that I might have to
support configuration, I'd have used something like
Color::red(), to keep all of my options open. But as you
probably know, if they ask you to change only one thing, that
will be the one thing you didn't consider as possibly
configurable.)
Finally, I like to get a compile error when I have a typo,
such as an "=" where I meant to put "==". I only get this
with constants.
Well, something like "if ( 1 == i )" just looks too wierd for my
taste. And any decent compiler will warn if you write "if ( i =
1 )".
As an aside, I have adopted the rule I found in the ACE
library of putting a trailing underscore on private data
members. Just another quick recognition.
That's a different issue; member variables have different scope
and impact than other variables, so it's often worth identifying
them. In an ideal world, we'd always have perfect names, which
expressed exactly what the thing was that they were naming, and
no additional conventions would be necessary. I'm not that good
at naming things, however, and most of the people I've worked
with aren't either. So occasional little helpers can be useful.
(I name my member variables myXxx, or ourXxx for static members.
Unless the naming conventions where I work say otherwise;
prefixing m_ or s_ isn't bad either. IMHO, using just a trailing
_ isn't distinguishable enough from extra white space.)
My point was slightly different: that the information being
encoded shouldn't be significant in this case. You do what you
are supposed to do with "red", and you don't worry about whether
others can write it or not. You're encoding information that
isn't relevant to your use.
In spite of all this, I really don't like Hungarian notation.
There's Hungarian, and there's Hungarian. I'm all in favor of
names containing as much information as is reasonably possible.
All I'd say is
1) it must be significant information, not incidental
information---whether the name represents a long or an int
is incidental, whether it is a serial number, a counter or
some arithmetic quantity isn't, and
2) it must be readily understandable---you shouldn't need two
pages for a list of all of the "encodings" used.
IMHO, encoding enum constants (or other constants) in a special
manner violates the first rule---it encodes information that you
shouldn't need, and that is libiable to change in future
versions.
--
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! ]