delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/11/10/09:46:46

Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE327218D@probe-2.Acclaim-Euro.net>
From: Shawn Hargreaves <ShawnH AT Probe DOT co DOT uk>
To: djgpp AT delorie DOT com
Subject: Re: Can't inline routines from other moudles
Date: Tue, 10 Nov 1998 14:36:34 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Reply-To: djgpp AT delorie DOT com

Hans-Bernhard Broeker writes:
> AFAIK, the optimal method for inlining functions across module 
> borders is the 'extern inline' extension provided by DJGPP: you 
> duplicate the function in the *header file* for that module, and 
> mark it as 'extern inline', while keeping the normal version 
> inside the module .c file. 

I agree, but there are some nasty pitfalls with this method. 
Duplicating the same code in both your header and source files is 
very ugly, and prone to error if you forget to keep the two versions 
in sync when making a change, but if you only put it in the header 
your code will break during non-optimising compiles, or if you ever 
try to take the address of the function.

IMHO the best solution is what I used in Allegro, which is to use the 
preprocessor to generate both versions. At the top of allegro.h I write:

    #ifndef __INLINE__
    #define __INLINE__ extern inline
    #endif

My inline routines are all then declared as __INLINE__, but I also 
add a dummy file to the library called inline.c, which just #defines 
__INLINE__ to nothing before including allegro.h. This trick allows 
one file to include separately compiled versions of the inline 
routines from a header, without needing two copies of the code..


	Shawn Hargreaves.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019