Path: utzoo!censor!isgtec!robert
From: robert@isgtec.UUCP (Robert Osborne)
Newsgroups: comp.lang.c
Subject: Re: #define OR ||
Message-ID: <281@isgtec.UUCP>
Date: 2 Feb 90 19:54:09 GMT
References: <33948@ucbvax.BERKELEY.EDU> <1941@gmdzi.UUCP>
Reply-To: robert@isgtec.UUCP (Robert Osborne)
Organization: ISG Technologies Inc., Mississauga, Ontario
Lines: 39

In article <1941@gmdzi.UUCP> wittig@gmdzi.UUCP (Georg Wittig) writes:
>>Besides, even if you *do* have the ability to run the preprocessor seperately,
>>doing so will destroy lots of potentially-useful information (like #defined
>>error codes, etc.)
>I like *partial* preprocessing :-) What did I say the other day? Let the
>machine do the dirty work ... If you could see the myriads of #define's and
>#ifdef's in my code!
If you need myriads of defines and ifdef's, your not letting the machine do
the dirty work -- writing lots of defines and ifdefs *IS* dirty work!

>>Well, if I want to do that on VMS, first I have to port "awk"...
>I don't understand why you *must* do it in VMS; why don't you copy your
>programs to UNIX?
Nice attitude Georg!   What if one doesn't have UNIX?  If one is writing a
program that must run under VMS copying programs to UNIX isn't much help.

>This is the old slogan: UNIX users always *know* what they do; C users always
>*know* what they do. To my experience, practice and the discussions in
>comp.lang.c prove the contrary. So why not help them to avoid some common
>pitfalls by defining some adequate macros?
You are missing the point entirely Georg,  redefining the language using
macros is one of the biggest pitfalls there is.  From your flippant
responses to the critisims of your method I see you don't care about who has
to maintain your code, or what machine/OS they have to maintain it on.
That's ok but some of us do or have to care!

As an aside,  how many people actually get caught by & vs && or = vs ==?
I know I have been caught a couple of times by =/==, but never by a &/&& or
a |/||.

>To summarize, I see that some of my concrete suggestions were not optimal, but
>I don't depart from the principle that programmers should be supported by
>making some language constructs clearer and by avoiding typical pitfalls of the
>language.
Programmers should avoid typical pitfalls of the language.  Programmers
should also write code that is clear, concise, and maintainable.  Your
macros fail on all three of these counts.
-- 
Robert A. Osborne   {...uunet!mnetor,...utzoo}!lsuc!isgtec!robert