extern
david nugent
david at csource.oz.au
Sun Jul 15 21:32:09 AEST 1990
In <2569 at dataio.Data-IO.COM> bright at Data-IO.COM (Walter Bright) writes:
><<#define EXTERN extern
><<#define far FAR
><<#define pascal PASCAL
><<
><<What's wrong with extern far pascal foo() vs EXTERN FAR PASCAL foo()?
><Microsoft has decided that for version 6.0, "__far" is better than "far"
><So if you followed the Microsoft "standard", all you have to do is use
><the new set of macros and your code works.
><Then if you would like to port your code to some other machine, you
><can #define FAR to nothing.
>The FAR macro is still entirely unnecessary. To port to a machine that does
>not have far:
>#define far
>To port to the new _far keyword:
>#define far _far
>There is no point to the FAR macro (and the other similar ones).
While technically that's quite correct, I use uppercased macros for
type declarators and moderators purely as a reminder that it isn't
supported in all environments in which the code may be compiled. I
even use EXTERN, VOLATILE, STATIC and a few others, with one include
file "environ.h" which takes care of the specific environment.
I find that it helps in reminding me not to rely on environment
and/or compiler specific features unless I specifically #ifdef the
code. It probably helps make the code more readable too.
--
_______________________________________________________________________________
Unique Computing Pty Ltd Melbourne Australia - Communications Specialists
david at csource.oz.au 3:632/348 at fidonet 28:4100/1 at signet
More information about the Comp.lang.c
mailing list