This is the mail archive of the gsl-discuss@sourceware.cygnus.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gsl inline question


Hmmm, this does get confusing and we haven't even mentioned __inline__
yet ;-)

HAVE_INLINE is purely for the user and only plays a role in the gsl_*.h
header files. Perhaps the following bit from the manual will help,

@node Inline functions
@section Inline functions

The @code{inline} keyword is not part of ANSI C, only C++. Since the
library header files conform to the ANSI standard this prevents the use
@code{inline}. The library does not export any inline function
definitions by default. However, for many frequently used functions
there are equivalent inline definitions which can be turned on by
defining the macro @code{HAVE_INLINE} when compiling an application

>   Wait! Maybe you are saying that the '#define inline' will only affect
> the implementation .c file; that the exported .h file doesn't include the
> config.h file, and so it doesn't know whether or not to use 'inline' ??

The #define inline   trick does not work for exported header files.
Consider the following situation:

Suppose the header file gsl_math.h had #define inline    at the top, via
config.h, and the header file contained code like,

   inline double GSL_MAX_DBL (double a, double b) { return a > b ? a : b
}

which became 

   double GSL_MAX_DBL (double a, double b) { return a > b ? a : b }

If this header file is included in two parts of the user's program it
will lead to a duplicate definition error at link time.  Adding an
"extern" does not help (try it). Prefixing the function definition with
static would get rid of the link time error, but at the cost of putting
the function definition into every .o file.

The simplest solution is that the user compiles their code -D
HAVE_INLINE to select either the correct inline or non-inline
definitions in the header files.

>   For what it's worth, the way HAVE_INLINE's are used in gsl_math.h does
> makes a lot of sense to me, but there you are going between inline's and
> macro's.

Yes, the non-inline part of the header file defines macros here, for a
bit of extra efficiency. We could have left out the macros and fallen
back to the non-inline version of the function instead.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]