Opinion) Overuse of symbolic constants

[Stephen Sprunk]

All versions of MS-Windows, and all versions of MS-DOS back to 2.0
when they first allowed subdirectories can use the following:

FILE *f = fopen("/foo/bar/foobar.txt","r");

And even system() works if you're not exectuting a brain-dead command.
For example:

system("vi /foo/bar/foobar.txt");

It's amazing how many code samples I see that have code to build path
names differently under DOS/Windows, when these are used strictly for
internal purposes and not for system commands. And it's amazing how
many people are shocked when asked "since when?" and I tell them
"since always".

This was true even for the DOS CLI prior to 5.0 when MS appropriated the
forward slash for command options instead of following unix's dash
convention. While a forward slash may work in most API calls and many apps
today, that doesn't mean MS will continue to support it tomorrow, so using a
backslash is "safer" even if it's not quite as readable ('\\' vs '/') in C
source.

S

 

[Joe Wright]

Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

[SNIP]

From a C99 implementation near you:

#define and &&
#define and_eq &=
#define bitand &
#define bitor |
#define compl ~
#define not !
#define not_eq !=
#define or ||
#define or_eq |=
#define xor ^
#define xor_eq ^=

[SNIP]

The point was not primarily readabilty, but rather to enable
people to
use those operators if their keyboard either did not support some/all of
those characters, or if it was unconviniently difficult to type them.

I suppose not. This business of abusing the preprocessor is typically
done by newbies at play. Have you ever seen any code by a professional
programmer (someone who gets paid for it) using this kind of stuff? I
have not.

As a matter of fact, the first time I saw code for what was
to become the Bourne Shell (circa 1982), it was written exactly like
that except all the #defines were in CAPS.

Ok Nick, I'll assume that was a throwaway. I'm so old I've probably
seen it too and just forgot. Let me ask it another way..

Assuming you are a professional programmer, would you use these
#defines? If you were a teacher, would you recommend them to your
students?

if (A and B or C and D) {} doesn't look like C to me.

 

[Nick Landsberg]

Jakob Bieling wrote:



Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

[SNIP]


From a C99 implementation near you:

#define and &&
#define and_eq &=
#define bitand &
#define bitor |
#define compl ~
#define not !
#define not_eq !=
#define or ||
#define or_eq |=
#define xor ^
#define xor_eq ^=

[SNIP]




The point was not primarily readabilty, but rather to enable
people to
use those operators if their keyboard either did not support
some/all of
those characters, or if it was unconviniently difficult to type them.

I suppose not. This business of abusing the preprocessor is typically
done by newbies at play. Have you ever seen any code by a
professional programmer (someone who gets paid for it) using this
kind of stuff? I have not.

As a matter of fact, the first time I saw code for what was
to become the Bourne Shell (circa 1982), it was written exactly like
that except all the #defines were in CAPS.

Ok Nick, I'll assume that was a throwaway. I'm so old I've probably seen
it too and just forgot. Let me ask it another way..

Assuming you are a professional programmer, would you use these
#defines? If you were a teacher, would you recommend them to your students?

if (A and B or C and D) {} doesn't look like C to me.

You're right, Joe... it don't look like C and it don't
smell like C and it don't taste like C. (Pardons
for the bad grammar but is was to make a point.)

The example *was* about preprocessor abuse and by
a respected developer within the company. Unfortunately,
no one could easily debug the code since we could not
read it as "C". (or easily add functionality to it
since we weren't sure of just about anything at that
point.)

Personally I wouldn't use them.

If I *were* a teacher of C, I would deduct points for
"excessive cuteness" if someone came up with them
(unless it were a quiz on how to abuse the preprocessor P)

 

[Jakob Bieling]

I suppose not. This business of abusing the preprocessor is
typically done by newbies at play. Have you ever seen any code by a
professional programmer (someone who gets paid for it) using this
kind of stuff? I have not.

Me neither, as I have not worked with people who use a keyboard that
does not allow easy access to those characters, and I am sure you have not
either. I did not say that it is commmon practice nor that it should be
encouraged in any way. All I am saying is, that those things primarily exist
to enable people who do not have easy access to those characters, to use
them anyway.

regards

 

[Christian Bau]

Assuming you are a professional programmer, would you use these
#defines? If you were a teacher, would you recommend them to your
students?

if (A and B or C and D) {} doesn't look like C to me.

If you are a professional programmer, and you intend to use them, please
use them in your probational period in a new job, so the company can get
rid of you quickly and at minimal cost.

If I saw this in a code review, I wouldn't know whether to laugh or to
cry. If you checked in this kind of stuff without a code review, you
would get killed.

 

[Peter Koch Larsen]

Right from the time the first edition of K&R was released, the
advantages of using symbolic constants, as opposed to "magic numbers",
has been emphasized ---- and for good reason. I don't dispute that at
all. However, it gets on my nerves when people carry this practice
too far. Consider these examples (from the code written by a
distinguished colleague):

#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

It is one thing to use symbolic constants with meaningful (and in some
cases, abstract) names, but methinks that use of symbolic constants in
this way is a complete waste. Let us take the first example. Either
the definition of DASH will never change (in which case it's usage is
superfluous) or the definition of DASH will change in the future (in
which case it will be completely misleading).


Any opinions?

--SS

Apart from the fact that using the preprocessor in this context is
horrible, the above makes sense if the code could eventually be ported
to unicode.
In this case the code would look something like:

stdchar const dash(CHAR_T('-'));

where CHART would be a preprocesser define:

#if defined(WIDE_CHAR_USE)
# define CHAR_T(_x) L#x
#else
# define CHAR_T(_x) x
#endif

Regards
Peter

 

[Richard Bos]

Which means that in Windows, you can generally use the forward slash
when generating paths, so there's no need for the macro;

You both forget something. Windows _functions_ may be able to understand
forward slashes; but Windows _users_ are, in most cases, incapable of
comprehending that the backslash is not a god[1]-given holy marking.
Ditto, but less so, under Unix. Thus, for human-readable output, you
must use the system-sanctified species of slash.

Richard

[1] Read: Gates.

 

[Kenneth Brody]

This was true even for the DOS CLI prior to 5.0 when MS appropriated the
forward slash for command options instead of following unix's dash
convention.

Well "since always" includes "prior to 5.0". ;-)

The problem goes all the way back to MS-DOS 1.0 using slashes for command-
line flags. Then, when 2.0 allowed subdirectories, they were stuck.

While a forward slash may work in most API calls and many apps
today, that doesn't mean MS will continue to support it tomorrow, so using a
backslash is "safer" even if it's not quite as readable ('\\' vs '/') in C
source.

I don't think that even MS has the balls to break that compatibility.

 

[Joona I Palaste]

Kenneth Brody <[email protected]> scribbled the following

I don't think that even MS has the balls to break that compatibility.

They're MS. They'd rather see UNIX adopt \ as a directory separator.
Erm, wait, scratch that. They'd rather not see UNIX at all.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"You have moved your mouse, for these changes to take effect you must shut down
and restart your computer. Do you want to restart your computer now?"
- Karri Kalpio

 

[Dan Pop]

Me neither, as I have not worked with people who use a keyboard that
does not allow easy access to those characters, and I am sure you have not
either. I did not say that it is commmon practice nor that it should be
encouraged in any way. All I am saying is, that those things primarily exist
to enable people who do not have easy access to those characters, to use
them anyway.

The good question is whether such people do exist. 20 years ago, they
did, but back then there was no <iso646.h>...

Dan

 

[Dan Pop]

Which means that in Windows, you can generally use the forward slash
when generating paths, so there's no need for the macro;

You both forget something. Windows _functions_ may be able to understand
forward slashes; but Windows _users_ are, in most cases, incapable of
comprehending that the backslash is not a god[1]-given holy marking.
Ditto, but less so, under Unix. Thus, for human-readable output, you
must use the system-sanctified species of slash.

In portable code, the file names are specified by the user. If the user
gets confused by his own input, there is very little the programmer can
do...

Dan

 

[Dan Pop]

As a matter of fact, the first time I saw code for what was
to become the Bourne Shell (circa 1982), it was written exactly like
that except all the #defines were in CAPS.

The Bourne Shell is older than that (it was the shell of Unix V7, released
at about the same time as K&R1) and it got these macros (and others, a lot
uglier, to hide the C's execution control syntax) by including "algol.h".

The result was something no one ever wanted to maintain...

Dan

 

[Dan Pop]

This was true even for the DOS CLI prior to 5.0 when MS appropriated the
forward slash for command options instead of following unix's dash
convention. While a forward slash may work in most API calls and many apps
today, that doesn't mean MS will continue to support it tomorrow, so using a
backslash is "safer" even if it's not quite as readable ('\\' vs '/') in C
source.

As far as I know, ever since MSDOS 2.0, MS OSs used / internally and \
only in the user interface. It's a bit late for them to change...

Dan

 

[Jakob Bieling]

The good question is whether such people do exist. 20 years ago, they
did, but back then there was no <iso646.h>...

Good point .. and as I have no knowledge about any other type of
keyboard other than the German and the US layout, I cannot tell if there is
not some kind of keyboard that does not have those keys. Maybe for a
different system, other than IBM compatible, that has a completely different
keyboard, but still has a C++ compiler .. just speculating, tho. But if it
does exist somewhere out there, those guys and girls using it sure will be
glad to have iso464.h

regards

 

[Keith Thompson]

In <[email protected]>

In <[email protected]>
(e-mail address removed) (Darrell Grainger) writes:
However, the SLASH might have a place. I have seen code like:

#ifdef WINDOWS
#define SEPERATOR '\\'
#else
#define SEPERATOR '/'
#endif

It was probably written by someone ignoring both English and Windows.

In most contexts, Windows accepts the forward slash as path separator.

Which means that in Windows, you can generally use the forward slash
when generating paths, so there's no need for the macro;

You both forget something. Windows _functions_ may be able to understand
forward slashes; but Windows _users_ are, in most cases, incapable of
comprehending that the backslash is not a god[1]-given holy marking.
Ditto, but less so, under Unix. Thus, for human-readable output, you
must use the system-sanctified species of slash.

In portable code, the file names are specified by the user. If the user
gets confused by his own input, there is very little the programmer can
do...

If the file names are specified by the user, the issue doesn't arise;
re-displaying whatever the user provided is entirely reasonable.
(Mapping the user's input to a more canonical form may or may not be
reasonable; it depends on the circumstances.)

Obviously we're talking about non-portable code with file names
provided or constructed by the program. In that context, it makes
sense to use something that's not going to confuse the user; under
Windows, that means using '\\' rather than '/' as the path separator.
It may not matter if the program never shows any file names to the
user, but a future version of the program may do so even if the
current one doesn't -- or a future version may try to pass a file name
to the command interpreter. (Or there might be some other obscure
circumstances in Windows where '/' and '\\' are not equivalent as path
separators; I'm not assuming there are, but I wouldn't bet against
it.)

 

[Dan Pop]

Obviously we're talking about non-portable code with file names
provided or constructed by the program.

In this case, even the file name construction algorithm is platform
specific, so there is nothing to be achieved by hiding the path separator
behind a macro (the topic of this thread). Use the native convention
on each platform.

Dan

 

[Michael Wojcik]

Which means that in Windows, you can generally use the forward slash
when generating paths, so there's no need for the macro;

You both forget something. Windows _functions_ may be able to understand
forward slashes; but Windows _users_ are, in most cases, incapable of
comprehending that the backslash is not a god[1]-given holy marking.
Ditto, but less so, under Unix. Thus, for human-readable output, you
must use the system-sanctified species of slash.

I don't believe this. I see pathnames in Windows software every day
that use slashes, or a mix of slashes and backslashes, for path
separators in various contexts. I assume I am not the only Windows
user who does. Yet I have never heard of this confusing a single
user.

I suspect this is just idle luser bashing. Anyone care to provide
any evidence whatsoever that presenting a pathname with slashes to
a Windows user causes difficulty?

 

[Michael Wojcik]

Kenneth Brody <[email protected]> scribbled the following



They're MS. They'd rather see UNIX adopt \ as a directory separator.

OK, I enjoy bashing MS and Windows as much as the next fellow, but
seriously, this is never going to change. It'd break compatibility
all over the place. MS is still providing sufficient compatibility
to run many ancient DOS programs; they're not going to screw with
something this basic.


--
Michael Wojcik (e-mail address removed)

It's like being shot at in an airport with all those guys running
around throwing hand grenades. Certain people function better with
hand grenades coming from all sides than other people do when the
hand grenades are only coming from inside out.
-- Dick Selcer, coach of the Cinci Bengals

 

[Michael Wojcik]

The good question is whether such people do exist.

I assure you, we exist. As recently as 1998 I was writing C using a
keyboard (attached to an IBM 5250 terminal) that did not have square
brackets. I didn't use iso646.h, because long before 1994 we had
programmed the terminals to insert square-bracket characters as
terminal macros (a two-keystroke operation). The macros replaced a
four-key sequence that required entering the hex codes for the square
brackets in the current EBCDIC code page - they're not part of the
base EBCDIC code set - and remembering what those hex codes were in
the first place.


--
Michael Wojcik (e-mail address removed)

Be sure to push the button of the bottom, and push the button of the
settlement page indicated next only once, there is fear of the bottom
rhinoceros multiplex lesson money. -- Sukebe Net

 

[Kenneth Brody]

Michael Wojcik wrote:
[...]

You both forget something. Windows _functions_ may be able to understand
forward slashes; but Windows _users_ are, in most cases, incapable of
comprehending that the backslash is not a god[1]-given holy marking.
Ditto, but less so, under Unix. Thus, for human-readable output, you
must use the system-sanctified species of slash.

I don't believe this. I see pathnames in Windows software every day
that use slashes, or a mix of slashes and backslashes, for path
separators in various contexts. I assume I am not the only Windows
user who does. Yet I have never heard of this confusing a single
user.

I suspect this is just idle luser bashing. Anyone care to provide
any evidence whatsoever that presenting a pathname with slashes to
a Windows user causes difficulty?

<raising_hand>

Over here!

Well, not exactly "causing difficulty", but over the years our tech
support people have gotten reports about errors which displayed a
filename using forward slashes, wondering if that was the cause of
the problem.

</raising_hand>