tneff@bfmny0.UU.NET (Tom Neff) (09/19/89)
When one wants to use or not use reserved keywords conditionally
depending on the choice of platform, a portable approach is to use
lookalike non-reserved keywords which are #defined to the null string or
to the reserved keywords as needed, e.g.
#ifdef I86
#define NEAR near
#define FAR far
#else
#define NEAR
#define FAR
#endif
. . .
extern FAR char *idstring;
. . .
int NEAR *gettotal(int xflag)
This is far safer than trying to redefine "near" and "far" themselves.
I cannot sympathize with slightly lazy vendors here.
--
'We have luck only with women -- \\\ Tom Neff
not spacecraft!' *-((O tneff@bfmny0.UU.NET
-- R. Kremnev, builder of FOBOS \\\ uunet!bfmny0!tneff (UUCP)scott@bbxsda.UUCP (Scott Amspoker) (09/19/89)
In article <14694@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: > > #ifdef I86 > #define NEAR near > #define FAR far > #else > #define NEAR > #define FAR > #endif > That is exactly what we ended up doing after we discovered that '#define near' would not work on one compiler. The point I was making was that up until this one compiler came along there was no problem. Compilers that don't support near/far typically don't recognize them as special words anyway. So here we have a case of one compiler that sticks out like a sore thumb. Somebody mentioned once in the group about the "principle of least astonishment". It just never occured to us that: A. A compiler on an architecture that has no concept of near/far would consider near/far meaningful. B. The preprocessor would care at all about anything other than it's own instructions. So we simply changed near to NEAR and far to FAR. Now that we are typing 'near' and 'far' in uppercase we are no longer being lazy (asshole!). -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232