Opinion) Overuse of symbolic constants

[Sandeep Sharma]

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

[Michael Wojcik]

In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.org> writes:

mw*****@newsguy.com (Michael Wojcik) writes:

It's pretty much utterly beside the point whether the average Windows
user knows that forward slash can be used as a path separator. The
question is whether said user will be confused upon encountering a
forward slash in a path. I don't believe so, and I've seen no
evidence offered to the contrary.
I think others have presented such evidence in this thread.

Yes, and more of it than I expected. I yield on this one. While
I try not to underestimate users, I appear to have erred in the
opposite direction in this case.
In any case, this discussion is off topic and not of much concern to
me personally.

Agreed.

--
Michael Wojcik mi************@microfocus.com

You brung in them two expert birdwatchers ... sayin' it was to keep us from
makin' dern fools of ourselfs ... whereas it's the inherent right of all to
make dern fools of theirselfs ... it ain't a right held by you official types
alone. -- Walt Kelly

[Michael Wojcik]

In article <c6**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:

In <c6*********@news1.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes:

In article <c6**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:

In <c6*************@news.t-online.com> "Jakob Bieling" <ne*****@gmy.net> writes:

> 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.

The good question is whether such people do exist.

I assure you, we exist.

That's the point. C has been available on IBM mainframes for almost 30
years and the people using it didn't wait for C89's trigraphs or C95's
digraphs and iso646.h to solve their terminal-related problems.

Sure, but I was responding to Jakob's query about "people who use a
keyboard that does not allow easy access", and your reply to it. I'm
not claiming that trigraphs, digraphs, and iso646.h were necessary or
a good idea (I don't have strong feelings either way - I've never been
troubled by the "wacky punctuation in a string literal turns out to
be a trigraph" bug, since I never use such punctuation, and I'm not
aware of any other argument against them). I'm just noting that there
are C programmers who have had to cope with C-unfriendly keyboards.

--
Michael Wojcik mi************@microfocus.com

We are subdued to what we work in. (E M Forster)

[Dan Pop]

In <c6*********@news2.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes:

In article <c6**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:

In <c6*********@news1.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes:

>In article <c6**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:
>> In <c6*************@news.t-online.com> "Jakob Bieling" <ne*****@gmy.net> writes:
>>
>> > 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.
>>
>> The good question is whether such people do exist.
>
>I assure you, we exist.

That's the point. C has been available on IBM mainframes for almost 30
years and the people using it didn't wait for C89's trigraphs or C95's
digraphs and iso646.h to solve their terminal-related problems.

Sure, but I was responding to Jakob's query about "people who use a
keyboard that does not allow easy access", and your reply to it. I'm
not claiming that trigraphs, digraphs, and iso646.h were necessary or
a good idea (I don't have strong feelings either way - I've never been
troubled by the "wacky punctuation in a string literal turns out to
be a trigraph" bug, since I never use such punctuation, and I'm not
aware of any other argument against them). I'm just noting that there
are C programmers who have had to cope with C-unfriendly keyboards.

And I have explicitly acknowledged their existence, in the past:

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

The biggest source of problems is gone: the terminals replacing
punctuation characters by accented characters, because they used a 7-bit
character set that had to support various languages using an alphabet
with more than 26 letters.

I have no idea whether brain dead IBM terminals are still being used by
C programmers, OTOH. Back when I had access to an IBM mainframe, the
local setup was perfectly happy with VT100s and was performing all the
necessary character conversions and buffering. And those with an X
server could use the x3270 terminal emulator...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Ross Kendall Axe]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

marcus hall wrote:
| In article <40***************@spamcop.net>,
| Kenneth Brody <ke******@spamcop.net> wrote:
|
|>Stephen Sprunk wrote:
|>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.
|
|
| Come on, be fair.. The problem started before MS-DOS, since CP/M used
| '/' for options before MS-DOS even existed. And CP/M got it from various
| DEC OS's like RSTS and RT11 before that. I don't know if DEC introduced
| the idea, or if they got it from somewhere previous, but by now we'er
| talking about earlier then Unix V6, so DEC can hardly be faulted for not
| following "the one true way".
|
| Marcus Hall
| ma****@tuells.org

Just thumbing through my CP/M manual, I have to say I don't notice any
forward slashes mentioned anywhere (apart from in the name of the OS
:-). Seems all the standard CP/M utilities like their options in square
brackets...
That's not to say that the practice wasn't used in 3rd party CP/M
programs, just not in the system itself.

Ross
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAkuB79bR4xmappRARAiDoAJ9v5I6Bt8mBa7/MuioNpFvXQ0rLAwCePwNb
PXPOrDynSuH19OjELKezPuo=
=gGte
-----END PGP SIGNATURE-----

[Claudio Puviani]

"Ross Kendall Axe" <ro******@blueyonder.co.uk> wrote

Hash: SHA1

marcus hall wrote:
| In article <40***************@spamcop.net>,
| Kenneth Brody <ke******@spamcop.net> wrote:
|
|>Stephen Sprunk wrote:
|>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.
|
|
| Come on, be fair.. The problem started before MS-DOS, since CP/M used
| '/' for options before MS-DOS even existed. And CP/M got it from various
| DEC OS's like RSTS and RT11 before that. I don't know if DEC introduced
| the idea, or if they got it from somewhere previous, but by now we'er
| talking about earlier then Unix V6, so DEC can hardly be faulted for not
| following "the one true way".
|
| Marcus Hall
| ma****@tuells.org

Just thumbing through my CP/M manual, I have to say I don't notice any
forward slashes mentioned anywhere (apart from in the name of the OS
:-). Seems all the standard CP/M utilities like their options in square
brackets...
That's not to say that the practice wasn't used in 3rd party CP/M
programs, just not in the system itself.

Um... the square brackets indicated optional arguments. You didn't actually type
the brackets. :-)

Claudio Puviani

[Claudio Puviani]

"Ross Kendall Axe" <ro******@blueyonder.co.uk> wrote

Hash: SHA1

marcus hall wrote:
| In article <40***************@spamcop.net>,
| Kenneth Brody <ke******@spamcop.net> wrote:
|
|>Stephen Sprunk wrote:
|>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.
|
|
| Come on, be fair.. The problem started before MS-DOS, since CP/M used
| '/' for options before MS-DOS even existed. And CP/M got it from various
| DEC OS's like RSTS and RT11 before that. I don't know if DEC introduced
| the idea, or if they got it from somewhere previous, but by now we'er
| talking about earlier then Unix V6, so DEC can hardly be faulted for not
| following "the one true way".
|
| Marcus Hall
| ma****@tuells.org

Just thumbing through my CP/M manual, I have to say I don't notice any
forward slashes mentioned anywhere (apart from in the name of the OS
:-). Seems all the standard CP/M utilities like their options in square
brackets...
That's not to say that the practice wasn't used in 3rd party CP/M
programs, just not in the system itself.

Um... the square brackets indicated optional arguments. You didn't actually type
the brackets. :-)

Claudio Puviani

[Joona I Palaste]

Claudio Puviani <pu*****@hotmail.com> scribbled the following
on comp.lang.c:

"Ross Kendall Axe" <ro******@blueyonder.co.uk> wrote

Just thumbing through my CP/M manual, I have to say I don't notice any
forward slashes mentioned anywhere (apart from in the name of the OS
:-). Seems all the standard CP/M utilities like their options in square
brackets...
That's not to say that the practice wasn't used in 3rd party CP/M
programs, just not in the system itself.

Um... the square brackets indicated optional arguments. You didn't actually type
the brackets. :-)

I'd bet a lot of users still tried to, though, and were surprised at why
it didn't work.
I've seen my fair share of Commodore 64 BASIC programs that begin by
printing "<CLR>" (literally, as in a less than sign, C, L, R, and a
greater than sign) to the screen, followed by the introductory text.
The writer of the program copied it from a magazine listing where
"<CLR>" was used as a transcript of the CLR control character, which
could be typed by hand on a Commodore 64 but which wasn't printed very
well on paper. The magazine was bound to have an introductory paragraph
about transcripts of control characters, that they were not to be typed
literally, but many readers ignored it when typing in the programs.
I was once in the Finnish science center Heureka and went over to a
computer running a cuneiform scripting program. The program displayed
a menu:
"Please select your language:
Finnish: type 1 + enter
Swedish: type 2 + enter
English: type 3 + enter"
At least one person *insisted* that the choice must be made by first
typing the digit 1, 2 or 3, then by typing the plus sign "+", and
finally by pressing enter.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge

[Goran Larsson]

In article <xY**********************@news4.srv.hcvlny.cv.net> ,
Claudio Puviani <pu*****@hotmail.com> wrote:

Um... the square brackets indicated optional arguments. You didn't actually type
the brackets. :-)

Have you actually used CP/M? The CP/M manuals use curly braces to indicate
optional arguments. The arguments that you type in on the command line are
enclosed in square brackets or start with a $ sign (older utilities).

Examples from the "CP/M Plus Command Summary":

A>DEVICE LPT [XON,9600]
A>DEVICE CONSOLE [COLUMNS=40,LINES=16]
A>DIR [EXCLUDE] *.DAT
A>DIR [DRIVE=ALL USER=ALL] TESTFILE.BOB
A>MAC SAMPLE $PB AA HB SX -M
A>SET MYFILE.TEX [PASSWORD=MYFIL]
A>SET [DEFAULT=password]
A>SET [CREATE=ON,UPDATE=ON]

MicroSofts langauages for CP/M (F80, M80, L80...) did use the slash to
introduce program options, where they got this from I don't know (but
it certainly wasn't from CP/M).

--
Göran Larsson http://www.mitt-eget.com/

[Claudio Puviani]

"Goran Larsson" <ho*@invalid.invalid> wrote

Claudio Puviani <pu*****@hotmail.com> wrote:

Um... the square brackets indicated optional arguments. You didn't actually type the brackets. :-)
Have you actually used CP/M?

Well, I used it regularly from 1980 to 1984 and I still have 3 functional CP/M
computers (not "other" computers with CP/M cartridges). Does that count?
The CP/M manuals use curly braces to indicate
optional arguments. The arguments that you type in on the command line are
enclosed in square brackets or start with a $ sign (older utilities).

Examples from the "CP/M Plus Command Summary":

A>DEVICE LPT [XON,9600]
A>DEVICE CONSOLE [COLUMNS=40,LINES=16]
A>DIR [EXCLUDE] *.DAT
A>DIR [DRIVE=ALL USER=ALL] TESTFILE.BOB
A>MAC SAMPLE $PB AA HB SX -M
A>SET MYFILE.TEX [PASSWORD=MYFIL]
A>SET [DEFAULT=password]
A>SET [CREATE=ON,UPDATE=ON]
CP/M Plus (or 3.0) was a too-little-too-late response from Digital Research after
CP/M had already lost the war. CP/M 2.2 is the version that had captured the
maket when there was a market to capture and it's still the baseline that all
CP/M software development targeted. Its commands were different from CP/M Plus,
as you can see at: http://www.gaby.de/cpm/manuals/archi...2htm/index.htm

You'll also note that the original documentation did use square brackets to
indicate optional arguments.
MicroSofts langauages for CP/M (F80, M80, L80...) did use the slash to
introduce program options, where they got this from I don't know (but
it certainly wasn't from CP/M).

Since CP/M itself didn't enforce any delimiters, programs used whatever they
wanted. Some used slashes, some use dashes, some used nothing at all.

Claudio Puviani

[Goran Larsson]

In article <YE**********************@news4.srv.hcvlny.cv.net> ,
Claudio Puviani <pu*****@hotmail.com> wrote:

Well, I used it regularly from 1980 to 1984 and I still have 3 functional CP/M
computers (not "other" computers with CP/M cartridges). Does that count?
Sure.
Since CP/M itself didn't enforce any delimiters, programs used whatever they
wanted. Some used slashes, some use dashes, some used nothing at all.

Yes, but the programs delivered with CP/M never used / for options.
Programs delivered with CP/M 2 prefer to use $ for options.
Programs delivered with CP/M 3 prefer to use [ and ] for options.
Programs sold by MicroSoft opted to use / for options.

Blaming CP/M for MicroSoft's use of / for options is wrong. The blame
must be somewhere else, probably DEC as MicroSoft used DECsystem 10
to cross compile their CP/M programs.

--
Göran Larsson http://www.mitt-eget.com/

[Michael Wojcik]

[Followups set to alt.folklore.computers, where this is topical. AFC
readers: this thread sprang out of a discussion of path separator
characters, and has now become a shouting match over where Microsoft
got the idea to use the forward slash as an option separator, and
then fell back on the backslash as a path separator.]
In article <Hx********@approve.se>, ho*@invalid.invalid (Goran Larsson) writes:

In article <YE**********************@news4.srv.hcvlny.cv.net> ,
Claudio Puviani <pu*****@hotmail.com> wrote:

Since CP/M itself didn't enforce any delimiters, programs used whatever they
wanted. Some used slashes, some use dashes, some used nothing at all.

Yes, but the programs delivered with CP/M never used / for options.
Programs delivered with CP/M 2 prefer to use $ for options.
Programs delivered with CP/M 3 prefer to use [ and ] for options.
Programs sold by MicroSoft opted to use / for options.

Blaming CP/M for MicroSoft's use of / for options is wrong. The blame
must be somewhere else, probably DEC as MicroSoft used DECsystem 10
to cross compile their CP/M programs.

"Blame" seems a bit harsh, since slash as an option separator was
already established by VMS when MS-DOS 1.0 came out.[*] Blame
Microsoft instead for a poor choice of path syntax in MS-DOS 2.0.
Since they already used the VMS syntax for options, they might as
well have adopted its syntax for paths, rather than trying for some
weird mix of VMSisms and half-assed Unixisms and ending up with two
crucial punctuation characters that many users (apparently) can't
reliably distinguish.

In any case, MS-DOS 1.0 was basically a rebranding of Seatle
Computer Systems' QDOS, wasn't it? Did QDOS use the slash as an
option delimiter? It might not have even been Microsoft's choice.

[*] I'm assuming here that VMS's use of slash as option separator
dates back earlier than MS-DOS 1.0. VMS 1.0 was released in 1978,
but I didn't use it myself before 1986, so I couldn't say.

--
Michael Wojcik mi************@microfocus.com

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