Path: utzoo!attcan!uunet!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: #defines....
Message-ID: <2562@dataio.Data-IO.COM>
Date: 3 Jul 90 00:49:42 GMT
References: <37786@genrad.UUCP> <33133@ut-emx.UUCP>
Reply-To: bright@Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 34

In article <33133@ut-emx.UUCP> petrilli@walt.cc.utexas.edu (Chris Petrilli) writes:
<Hope this clarifies it... if someone can thing of another time where you HAVE
<to use the pre-processor, I'd like to know, I might be misusing/abusing 
<C++.


You need the preprocessor's help if you wish to insert __FILE__ and __LINE__s
in the right spots. Using inline functions doesn't work because the __FILE__
and __LINE__ will expand to where the inline function is defined, not where
it is used. For example:

    // Part of a package to track storage allocation
    #define malloc(n)	mem_malloc(n,__FILE__,__LINE__)
    #define new		((__file__ = __FILE__),(__line__ = __LINE__)),new

Another use that I find particularly useful:

    #if !(MSDOS || __OS2__)
    #define cdecl
    #define near
    #define far		/* make extended keywords go away	*/
    #endif

Or how about conditionally making static functions global:

    #ifdef DEBUG
    #define STATIC	/* make STATIC functions appear in .MAP file	*/
    #else
    #define STATIC static
    #endif

    STATIC int near function() { ... }

In other words, I think the preprocessor is here to stay.