By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,751 Members | 1,065 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,751 IT Pros & Developers. It's quick & easy.

Opinion) Overuse of symbolic constants

P: n/a
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
Nov 14 '05 #1
Share this Question
Share on Google+
60 Replies

P: n/a
> 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).


I consider three important uses for defines or constants:

1. For values that are subject to change.
2. To distinguish a certain usage of a value from other usages, so that
searches are more efficient.
3. More meaningfull names (e.g. PATH_NOT_FOUND instead of a value).

I do not think that the examples shown above fits into any of these usages.

Niels Dybdahl
Nov 14 '05 #2

P: n/a
In comp.lang.c Sandeep Sharma <sa*********@yahoo.com> wrote:

(comp.lang.c only, I don't see clc++ caring much about this)
#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1


I'm dealing with similar code, except that ours look like

#define Splat '*'
#define Andpersand '&'
#define Asterik '*'

Those are verbatim - yes, ampersand and asterisk are misspelled, and
the constants aren't capitalized. I make a point of not using these
at any time in the code that *I* write. And the author is my boss, so
I guess he's "distinguished" too :)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #3

P: n/a
Christopher Benson-Manica <at***@nospam.cyberspace.org> scribbled the following:
In comp.lang.c Sandeep Sharma <sa*********@yahoo.com> wrote: (comp.lang.c only, I don't see clc++ caring much about this)
#define DASH '-'
#define SLASH '/'
#define SINGLE_BYTE 1

I'm dealing with similar code, except that ours look like #define Splat '*'
#define Andpersand '&'
#define Asterik '*' Those are verbatim - yes, ampersand and asterisk are misspelled, and
the constants aren't capitalized. I make a point of not using these
at any time in the code that *I* write. And the author is my boss, so
I guess he's "distinguished" too :)


Your boss obviously hasn't read enough European comics. =)

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"'So called' means: 'There is a long explanation for this, but I have no
time to explain it here.'"
- JIPsoft
Nov 14 '05 #4

P: n/a
Christopher Benson-Manica wrote:
I'm dealing with similar code, except that ours look like

#define Splat '*'
#define Andpersand '&'
#define Asterik '*'


So why don't you:

#define SPLAT Splat
#define AMPERSAND Andpersand
#define ASTERISK Asterik

Cheers,

Kees

:-)

Nov 14 '05 #5

P: n/a


Sandeep Sharma wrote:

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


I use the SLASH definition to distinguish the directory name separator
for Unix vs. Windows:

#ifdef WIN32
#define SLASH '\\'
#else
#define SLASH '/'
#endif
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Common User Interface Services
M/S 2R-94 (206)544-5225
Nov 14 '05 #6

P: n/a
On Wed, 21 Apr 2004, Sandeep Sharma wrote:
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?


I use macros for data that is subject to change or to make the code more
readable. Symbols are just as readable as words so I see no point in two
of the three examples.

However, the SLASH might have a place. I have seen code like:

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

Have you asked the distinguished collegue why the need for the macros? If
they have a good reason maybe a comment in the source code would be
helpful.

I'm guessing they are just blindly following something they were taught
without understanding why.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@whitehouse.gov
Nov 14 '05 #7

P: n/a
"Fred L. Kleinschmidt" <fred.l.kleinschmidt@nospam_boeing.com> writes:
Sandeep Sharma wrote:

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?


I use the SLASH definition to distinguish the directory name separator
for Unix vs. Windows:

#ifdef WIN32
#define SLASH '\\'
#else
#define SLASH '/'
#endif


I find this misleading. I'd prefer

#ifdef WIN32
#define DIR_SEP '\\'
#else
#define DIR_SEP '/'
#endif

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #8

P: n/a
In <Pi*******************************@drj.pf> da*****@NOMORESPAMcs.utoronto.ca.com (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.
The only exception coming to mind is COMMAND.COM (newer command
interpreters are perfectly happy with Unix-style path specifications).

So, in a C context, it's only strings prepared to be passed to system()
that need the distinction. But such strings are typically affected by
much more important portability issues...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #9

P: n/a
sa*********@yahoo.com (Sandeep Sharma) wrote in message news:<4c*************************@posting.google.c om>...
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).


I agree. To be useful, a symbolic name needs to be symbolic -- it
needs to symbolize something. These are roughly equivalent to
comments like:

a=b; /* assign b to a */

that only repeat what's already obvious. To be useful, the symbol
needs to add meaning that isn't obvious without it. A constrast would
be names like the following:

#define switch_char '-'
#define path_sep '/'

which really add meaning, as well as the flexibility of (for example)
allowing a path separator to be changed from '/' to '\\' to ':' as
appropriate.
Later,
Jerry.

--
The universe is a figment of its own imagination.
Nov 14 '05 #10

P: n/a

On Wed, 21 Apr 2004, Sandeep Sharma wrote in comp.lang.c:

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


One possibility I haven't seen anyone mention yet is that while the
abstract *value* of "DASH" will never change, the *type* of "DASH"
may well change: for example, when updating this code to deal with
wide character I/O we write

#define DASH L'-'
#define SLASH L'/'
#define SINGLE_BYTE (sizeof (wchar_t))

(Here SINGLE_BYTE is a misnomer; better to name it SINGLE_CHAR or
something similar.)

A second possibility is that the first couple entries were taken
out of context from a hand-written lexer or parser:

#define DASH '-'
#define SLASH '/'
#define ASSGNOP 1000
#define STAR_ASSGNOP 1001
#define DASH_ASSGNOP 1002
#define PLUSPLUS 1003
[...]

Here we are simplifying the lexer code by making the "dash" token
equal in value to the system's '-' character, and similarly for all
other one-character tokens: multi-character tokens get their own
numerical "token" values, out of the ASCII range.
(This example code is obviously not quite portable; it's implicitly
assuming that '-' and 1000 are distinct values, which is guaranteed
by ASCII but not by Standard C.)

The already-mentioned "platform-independent directory separator"
idea is a common one, too, but I don't see how it explains the presence
of DASH along with SLASH.

HTH,
-Arthur
Nov 14 '05 #11

P: n/a
"Niels Dybdahl" <nd*@fjern.detteesko-graphics.com> wrote:
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).


I consider three important uses for defines or constants:

1. For values that are subject to change.
2. To distinguish a certain usage of a value from other usages, so that
searches are more efficient.
3. More meaningfull names (e.g. PATH_NOT_FOUND instead of a value).

I do not think that the examples shown above fits into any of these usages.


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 ^=

This is interesting because a co-developer of mine has a standard include
file (predating C99 by a long way) which has:

#define AND &&
#define OR ||
#define NOT !

So I guess there is a fourth category, which the OP's definitions might
fall into: improving readability.
Nov 14 '05 #12

P: n/a
Old Wolf wrote:
.... 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 ^=


This has been in C90 since about 1995. #include <iso646.h>

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Nov 14 '05 #13

P: n/a
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Old Wolf wrote:

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


This has been in C90 since about 1995. #include <iso646.h>


More correctly, this has been in C94 since about 1995. I don't know
if C94 implementations were popular enough to be worth messing with
<iso646.h> if you cared about portable programming.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #14

P: n/a
"Fred L. Kleinschmidt" wrote:
[...]
I use the SLASH definition to distinguish the directory name separator
for Unix vs. Windows:

#ifdef WIN32
#define SLASH '\\'
#else
#define SLASH '/'
#endif


Why bother? Unless you are building a filename to pass to system(),
and that specific command doesn't like '/', the above is superfluous.
(That, and misleading by using the name SLASH rather than something
like PATH_SET.)

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

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Nov 14 '05 #15

P: n/a
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...
"Niels Dybdahl" <nd*@fjern.detteesko-graphics.com> wrote:
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).
I consider three important uses for defines or constants:

1. For values that are subject to change.
2. To distinguish a certain usage of a value from other usages, so that
searches are more efficient.
3. More meaningfull names (e.g. PATH_NOT_FOUND instead of a value).

I do not think that the examples shown above fits into any of these

usages.
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 ^=

This is interesting because a co-developer of mine has a standard include
file (predating C99 by a long way) which has:

#define AND &&
#define OR ||
#define NOT !

So I guess there is a fourth category, which the OP's definitions might
fall into: improving readability.


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.

regards
--
jb

(replace y with x if you want to reply by e-mail)
Nov 14 '05 #16

P: n/a

In article <c6**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:
In <Pi*******************************@drj.pf> da*****@NOMORESPAMcs.utoronto.ca.com (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; and when
parsing paths, you need to handle both slash and backslash, so the
macro won't help. It's doubly wrong.

As is often the case, attempting to hide platform-dependent code here
just produces a solution that's less obviously broken.

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

Therefore, it is possible to enjoy further by using under the
Netscape 2.0. However, Netscape will hangup at sometimes. You
should give it up. -- roro
Nov 14 '05 #17

P: n/a
Kenneth Brody <ke******@spamcop.net> writes:
"Fred L. Kleinschmidt" wrote:
[...]
I use the SLASH definition to distinguish the directory name separator
for Unix vs. Windows:

#ifdef WIN32
#define SLASH '\\'
#else
#define SLASH '/'
#endif


Why bother? Unless you are building a filename to pass to system(),
and that specific command doesn't like '/', the above is superfluous.
(That, and misleading by using the name SLASH rather than something
like PATH_SET.)

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");


Disclaimer: I don't write programs for Windows (except under Cygwin,
but that doesn't count in this context.)

If a file name is going to be displayed to a Windows end user, the
user is likely to be confused if the path name contains '/' characters
rather than '\' characters. Confusing users is seldom a good idea.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #18

P: n/a
Jakob Bieling wrote:
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...
"Niels Dybdahl" <nd*@fjern.detteesko-graphics.com> wrote:
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).

I consider three important uses for defines or constants:

1. For values that are subject to change.
2. To distinguish a certain usage of a value from other usages, so that
searches are more efficient.
3. More meaningfull names (e.g. PATH_NOT_FOUND instead of a value).

I do not think that the examples shown above fits into any of these


usages.
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 ^=

This is interesting because a co-developer of mine has a standard include
file (predating C99 by a long way) which has:

#define AND &&
#define OR ||
#define NOT !

So I guess there is a fourth category, which the OP's definitions might
fall into: improving readability.

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.

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 14 '05 #19

P: n/a
Joe Wright wrote:
Jakob Bieling wrote:
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...
"Niels Dybdahl" <nd*@fjern.detteesko-graphics.com> 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.

--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Nov 14 '05 #20

P: n/a
"Kenneth Brody" <ke******@spamcop.net> wrote in message
news:40***************@spamcop.net...
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

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

Nov 14 '05 #21

P: n/a
Nick Landsberg wrote:
Joe Wright wrote:
Jakob Bieling wrote:
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...

"Niels Dybdahl" <nd*@fjern.detteesko-graphics.com> 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.
--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 14 '05 #22

P: n/a
Joe Wright wrote:
Nick Landsberg wrote:
Joe Wright wrote:
Jakob Bieling wrote:

"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:84**************************@posting.google.c om...

> "Niels Dybdahl" <nd*@fjern.detteesko-graphics.com> 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)
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
Nov 14 '05 #23

P: n/a
"Joe Wright" <jo********@comcast.net> wrote in message
news:q5********************@comcast.com...
#define AND &&
#define OR ||
#define NOT ! So I guess there is a fourth category, which the OP's definitions might
fall into: improving readability.
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.


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

(replace y with x if you want to reply by e-mail)
Nov 14 '05 #24

P: n/a
In article <16********************@comcast.com>,
Joe Wright <jo********@comcast.net> wrote:
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.
Nov 14 '05 #25

P: n/a
sa*********@yahoo.com (Sandeep Sharma) wrote in message news:<4c*************************@posting.google.c om>...
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
Nov 14 '05 #26

P: n/a
mw*****@newsguy.com (Michael Wojcik) wrote:
In article <c6**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:
In <Pi*******************************@drj.pf> da*****@NOMORESPAMcs.utoronto.ca.com (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.

Richard

[1] Read: Gates.
Nov 14 '05 #27

P: n/a
Stephen Sprunk wrote:

"Kenneth Brody" <ke******@spamcop.net> wrote in message [...]
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.


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.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+

Nov 14 '05 #28

P: n/a
Kenneth Brody <ke******@spamcop.net> scribbled the following
on comp.lang.c:
Stephen Sprunk wrote:
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.


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 (pa*****@cc.helsinki.fi) ------------- 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
Nov 14 '05 #29

P: n/a
In <c6*************@news.t-online.com> "Jakob Bieling" <ne*****@gmy.net> writes:
"Joe Wright" <jo********@comcast.net> wrote in message
news:q5********************@comcast.com...
>>#define AND &&
>>#define OR ||
>>#define NOT ! >>So I guess there is a fourth category, which the OP's definitions might
>>fall into: improving readability. > The point was not primarily readabilty, but rather to enable peopleto > 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.


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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #30

P: n/a
In <40*****************@news.individual.net> rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
mw*****@newsguy.com (Michael Wojcik) wrote:
In article <c6**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:
> In <Pi*******************************@drj.pf> da*****@NOMORESPAMcs.utoronto.ca.com (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...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #31

P: n/a
In <2q********************@bgtnsc05-news.ops.worldnet.att.net> Nick Landsberg <hu*****@NOSPAM.att.net> writes:
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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #32

P: n/a
In <73******************************@news.teranews.co m> "Stephen Sprunk" <st*****@sprunk.org> writes:
"Kenneth Brody" <ke******@spamcop.net> wrote in message
news:40***************@spamcop.net...
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.


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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #33

P: n/a
"Dan Pop" <Da*****@cern.ch> wrote in message
news:c6**********@sunnews.cern.ch...
encouraged in any way. All I am saying is, that those things primarily existto 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>...


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

(replace y with x if you want to reply by e-mail)
Nov 14 '05 #34

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <40*****************@news.individual.net>
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
mw*****@newsguy.com (Michael Wojcik) wrote:
In article <c6**********@sunnews.cern.ch>, Da*****@cern.ch (Dan
Pop) writes:
> In <Pi*******************************@drj.pf>
> da*****@NOMORESPAMcs.utoronto.ca.com (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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #35

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #36

P: n/a

In article <c6**********@oravannahka.helsinki.fi>, Joona I Palaste <pa*****@cc.helsinki.fi> writes:
Kenneth Brody <ke******@spamcop.net> scribbled the following
on comp.lang.c:
Stephen Sprunk wrote:
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.


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 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
Nov 14 '05 #37

P: n/a

In article <40*****************@news.individual.net>, rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
mw*****@newsguy.com (Michael Wojcik) wrote:
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 mi************@microfocus.com

Any average educated person can turn out competent verse. -- W. H. Auden
Nov 14 '05 #38

P: n/a

In article <c6**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop) writes:
In <c6*************@news.t-online.com> "Jakob Bieling" <ne*****@gmy.net> writes:
"Joe Wright" <jo********@comcast.net> wrote in message
news:q5********************@comcast.com...
> 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.


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. 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 mi************@microfocus.com

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
Nov 14 '05 #39

P: n/a
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>

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+

Nov 14 '05 #40

P: n/a
Michael Wojcik <mw*****@newsguy.com> scribbled the following:
In article <40*****************@news.individual.net>, rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
mw*****@newsguy.com (Michael Wojcik) wrote:
> 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?


This is actually a bit off the topic, but this backslash thing has led
to people thinking that the backslash (\) should be used *everywhere*,
not just in file pathnames. Already we're seeing URLs written as
http:\\www.something.com\something.html, and I've even seen Usenet
article titles such as "Input \ output question". Sooner or later
greengrocers will start writing "Potatoes in 1\2 kg bags" in actual
pen-and-paper.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"A bicycle cannot stand up by itself because it's two-tyred."
- Sky Text
Nov 14 '05 #41

P: n/a
mw*****@newsguy.com (Michael Wojcik) writes:
In article <40*****************@news.individual.net>,
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
mw*****@newsguy.com (Michael Wojcik) wrote:
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?


Do you see slashes in the source code for Windows software, or do you
see it actually displayed when the program runs?

I happen to know that Windows accepts '/' as a path separator, but
only because it's been mentioned in this newsgroup. Most Windows
programs avoid using '/' as a path separator, at least in paths
displayed to the user, and I've never seen any mention of this feature
in Windows documentation. At least one Windows application I use
rejects a path name with '/' characters as invalid, but accepts the
equivalent path name with '\' characters (I suppose that's a bug in
that particular application).

I am a Windows user, but I'm not a Windows programmer. I haven't seen
very much source code intended to run under Windows, and I don't think
I've ever seen any such code that uses a '/' separator.

I'm probably more conscious of these issues than the vast majority of
Windows users, and I'm only peripherally aware that '/' is a valid
path separator.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #42

P: n/a
Joona I Palaste quoted:
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?

In my experience (teaching university students), presenting _any_
sort of pathname to Windows users causes difficulty. Their ability
to comprehend anything but point-and-click has atrophied to the
point of disappearance.
This is actually a bit off the topic, but this backslash thing has led
to people thinking that the backslash (\) should be used *everywhere*,
not just in file pathnames.


Most computer users don't know what "backslash" means. There's about
an even chance they'll type "/" or "\" if asked to type a backslash.

Allin Cottrell
Nov 14 '05 #43

P: n/a
Allin Cottrell wrote:
Joona I Palaste quoted:
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?

In my experience (teaching university students), presenting _any_
sort of pathname to Windows users causes difficulty. Their ability
to comprehend anything but point-and-click has atrophied to the
point of disappearance.
This is actually a bit off the topic, but this backslash thing has led
to people thinking that the backslash (\) should be used *everywhere*,
not just in file pathnames.

Most computer users don't know what "backslash" means. There's about
an even chance they'll type "/" or "\" if asked to type a backslash.


Most computer users know nothing at all about computers, what they
are, where they are or even whether they are currently using one or
more of them. What's your point?

Just curious, what do you teach at university?

We do not and should not expect anything at all from computer users
except that they use computers. They are our market. Bless them.

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 14 '05 #44

P: n/a
Joe Wright wrote:
Most computer users don't know what "backslash" means. There's about
an even chance they'll type "/" or "\" if asked to type a backslash.
Most computer users know nothing at all about computers, what they are,
where they are or even whether they are currently using one or more of
them. What's your point?
My point, following from the discussion of '/' versus '\' in Windows
pathnames, is that the it's moot, because pathnames are simply not
something Windows users conjure with. (Of course I'm not talking
about programmers, but I am talking about reasonably intelligent people
who use a computer every working day.)
Just curious, what do you teach at university?


Economics. When I teach econometrics (economic statistics), the full
effects of point-and-click-ism hit me in the face (i.e. almost total
inability to do anything that involves typing a command of any sort).

Allin Cottrell
Nov 14 '05 #45

P: n/a
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:
Michael Wojcik <mw*****@newsguy.com> scribbled the following:
In article <40*****************@news.individual.net>, rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
mw*****@newsguy.com (Michael Wojcik) wrote:
> 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.

Which software? I don't think I've ever seen something like that except,
perhaps, in GNUed software.
I assume I am not the only Windows user who does. Yet I have never
heard of this confusing a single user.


I have. Personal experience, and I took no notes, so that's no evidence
to anyone but me.
Sooner or later greengrocers will start writing "Potatoes in 1\2 kg bags"


Inconceivable. Unless you mean "Potato's in 1\2 kg bag's".

Richard
Nov 14 '05 #46

P: n/a
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:
>"Joe Wright" <jo********@comcast.net> wrote in message
>news:q5********************@comcast.com...
>
>> > 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.
>
> 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. 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).


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. All this
nonsense was due to one Scandinavian country ISO representatives insisting
on C providing a solution to a no longer existing problem (7-bit ASCII
derived character sets that replaced $, # and certain punctuation
characters by other characters).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #47

P: n/a

In article <ln************@nuthaus.mib.org>, Keith Thompson <ks***@mib.org> writes:
mw*****@newsguy.com (Michael Wojcik) writes:

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?
Do you see slashes in the source code for Windows software, or do you
see it actually displayed when the program runs?


Both. This is particularly true with console-mode software, but it's
frequently true of GUI-mode as well.
I happen to know that Windows accepts '/' as a path separator, but
only because it's been mentioned in this newsgroup.
And you believe this is generally true of Windows users because?
Most Windows
programs avoid using '/' as a path separator, at least in paths
displayed to the user
And your evidence for this is what?
At least one Windows application I use
rejects a path name with '/' characters as invalid, but accepts the
equivalent path name with '\' characters (I suppose that's a bug in
that particular application).
Yes, it is. For example, OpenFile() in Windows 3.1 had this problem,
and MS considered it a bug; see MS KB article Q111588.
I am a Windows user, but I'm not a Windows programmer. I haven't seen
very much source code intended to run under Windows, and I don't think
I've ever seen any such code that uses a '/' separator.
Which tells us pretty much nothing.
I'm probably more conscious of these issues than the vast majority of
Windows users, and I'm only peripherally aware that '/' is a valid
path separator.


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.

In fact, from what I've seen, Windows users show significant facility
at compensating for all sorts of potentially confusing UI elements.
Windows is full of them, after all.

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

She felt increasingly (vision or nightmare?) that, though people are
important, the relations between them are not, and that in particular
too much fuss has been made over marriage; centuries of carnal
embracement, yet man is no nearer to understanding man. -- E M Forster
Nov 14 '05 #48

P: n/a
mw*****@newsguy.com (Michael Wojcik) writes:
In article <ln************@nuthaus.mib.org>, Keith Thompson
<ks***@mib.org> writes:

[...]
I happen to know that Windows accepts '/' as a path separator, but
only because it's been mentioned in this newsgroup.


And you believe this is generally true of Windows users because?


I'm guessing. No, I don't think that most Windows users read this
newsgroup, but I'm guessing, based on my own experience, that most
Windows users aren't aware that '/' is a valid path separator.
(Probably a lot of Windows users aren't aware that '\' is a valid path
separator.)
Most Windows
programs avoid using '/' as a path separator, at least in paths
displayed to the user


And your evidence for this is what?


I've never seen a Windows program (excluding Cygwin and other Unix
emulation layers) display a directory path using '/' as a path
separator, except perhaps when it had been entered by the user. This
is, of course, anecdotal evidence, not proof.

[...]
I'm probably more conscious of these issues than the vast majority of
Windows users, and I'm only peripherally aware that '/' is a valid
path separator.


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.

In any case, this discussion is off topic and not of much concern to
me personally. I have nothing to offer but anecdotal evidence.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #49

P: n/a
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
Nov 14 '05 #50

60 Replies

This discussion thread is closed

Replies have been disabled for this discussion.