Let C++ always use inline functions (patch)

Jochen Küpper jochen@fhi-berlin.mpg.de
Tue Jun 13 15:56:00 GMT 2006


"Brian Gough" <bjg@network-theory.co.uk> writes:

> Jochen Küpper writes:
>  > It replaces the old test for "HAVE_INLINE" by a test for that macro
>  > /or/ C++:
>  > ,----
>  > | -#ifdef HAVE_INLINE
>  > | +#if (defined HAVE_INLINE) || (defined __cplusplus)
>  > `----
>  > 
>  > This is ok, as a C++ compiler is required by the standard to handle
>  > "inline".
>
> Good point, I hadn't really thought about that.  A few questions:
>
> - what does the C++ standard say about "extern inline" compared with
> "inline"

In C++ global inline functions must always be defined in the same
compilation unit as their declaration. By default "inline" means
"extern inline" -- if not explicitly declared static.

This is the case in GSL already (and probably required by C as well).

> - is it affected by the extern "C" { .. } around these definitions

Wohoo -- dunno for sure.

Stroustrup "The C++ Programming language", special edition 2004, p.206:
,----
| An /extern "C"/ directive specifies the linkage convention (only)
| and does not affect the semantics of calls to the function. ...
`----

In my understanding this means that only the linkage-name is altered,
nothing else. 

> - have you tried this on any other compilers

Other than? ;)

No, I only have GCC. Maybe someone could try this on one of these
compile-farms around? Is that possible?

Anybody here still using a DEC-, IBM-, PG-, or Sun-compiler or such?

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gsl-discuss/attachments/20060613/77f12dc6/attachment.sig>


More information about the Gsl-discuss mailing list