The common way is to define our own INLINE definition and have Configure
check for it, define it null if needed, and conditionally include it into a
file
as extern if so.
Sounds like a job for..... BrentDax++!
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
Nicholas Clark
<[EMAIL PROTECTED]> To: Robert Spier
<[EMAIL PROTECTED]>
Sent by: Nicholas cc: Jerome Vouillon
<[EMAIL PROTECTED]>, Mike Lambert <[EMAIL PROTECTED]>,
Clark [EMAIL PROTECTED]
<[EMAIL PROTECTED] Subject: inline functions (was Re:
[netlabs #629] [PATCH] Memory manager/garbage collector
e.org> -major revision)
05/31/2002 07:11
AM
On Tue, May 28, 2002 at 07:54:49AM -0700, Robert Spier wrote:
> We've got enough complicated preprocessor issues right now - I'm
> not sure we want to add another one. Defining perl5ish macros
> will cause too many troubles down the road.
>
> Or... since C99 supports C function inlining (iirc) - we could
> just rely on a C99 compiler....
Many compilers have inline functions in C already. I doubt many are
reliably
C99 enough for us to use them.
[Hell, C89 is still causing some vendors problems, although there is
progress: Solaris 9 will have a conformant fflush()]
Is there any easy clean way we can write functions that will be inlined on
C compilers with inline, but will still work on other compilers
(possibly by (erk) a preprocessing stage to pull out all the inline
definitions to another file, and compile them as conventional functions) ?
That way, we'd get the speed hit we desired on most platforms, but the code
would still run everywhere.
Nicholas Clark
