extern

[Steve Resnick]

In article <1990Jul9.190744.1437 at Solbourne.COM> imp at dancer.Solbourne.COM (Warner Losh) writes:
>In article <1990Jul5.044045.1534 at acc.stolaf.edu> hannum at haydn.psu.edu
>(Charles Hannum) writes: 
>>"... preprocessor games, ..."?  It's not a game.  It's a perfectly
>>ligitimate [sic] use of the C preprocessor.  If we weren't supposed
>>to use it, it wouldn't be included (based C's minimalist philosophy).
>
>Yah, right.  And I'd suppose that you think the following is also
>legal and not a "preprocessor game":
>
>#include "pascal.h"
>
>main()
>BEGIN
>	int foo;
>
>	IF (foo) THEN
>	BEGIN
>		WRITE ("Fooing today\n");
>	END
>	ELSE
>	BEGIN
>		WRITE ("No foos today\n");
>	END
>END
>
>The above, while strictly speaking IS 'C' (depending on the defines in
>pascal.h, that is), I'd hate to have to maintain something like that.
>#define EXTERN extern is a gross preprocessor game that should be
>avoided, just as the above cute pascal example should be avoided.
>

I wish the boys in Redmond Washington would adhere to that philosophy.
After spending a weekend debugging some OS/2 code I have learned to loathe
dearly MS's macros. In the OS/2 programmers refrences, Quick Help, and other
MS blessed/produced products they all refer to these "improved" types and 
declarations. an example is:

#define EXTERN extern
#define far FAR
#define pascal PASCAL

What's wrong with extern far pascal foo() vs EXTERN FAR PASCAL foo()?
And why should I use "SEL n" when I mean "unsigned n"? I would bitch a lot
less if I didn't have to have MANY books open to figure out what these silly
things meant! (oddly enough, if I ask MSC to generate protos for my EXTERN
FAR PASCAL functions, they get generated correctly..)
 
Seems like we keep working towards standardization and someone in the infinite
glory wants to change it for us.... *sigh*
 
 Steve

-- 
--------------------------------------------------------------------------------
Steve Resnick -<stever at octopus.COM apple!octopus!stever sun!vsi1!octopus!stever>
408/241-1533 Process Scientific, Inc.
"0x2B|~0x2B THAT is the question!"