inline (Re: guile: going the way of DEATH)

[Telford Tendys <telford@triangle.triode.net.au>]

> Inline functions are great because the compiler will type-check them
> for you, and you get local variables, etc.  But I have tended to shy
> away from them, because:
> - they only work on GCC

Actually, at lest the DEC VMS compiler also supports inline functions
but <grin> supports a different syntax. I suspect that other compilers
will eventually have to come to the party as well.

> - they slowed down the compiler a lot the last time I tried them (1990)

Any use of optimising slows the compiler, if you want fast compile,
turn the optimiser off, if you want fast code turn it on.

> - everyone is used to macros

Speak for yourself.

> - although macros do cause troubles, with a little discipline, you can
>   write macros that are pretty trouble-free

``with a little discipline'' roughly translating to mean, its up
to you to do everything right because you get no typechecking
as the cpp substitutes blindly. This is not to say that I'm a great
fan of total strictness regarding typechecks but if the compiler can
help me find mistakes then it is quite nice.

> > Even a dose of `-finline-functions' will probably clean up a lot of
> > the gh_ functions without changing the source one jot.
> 
> -finline-functions doesn't inline functions across compilation units.

True, I hadn't thought about that.

>        This combination of `inline' and `extern' has almost the effect of a
>     macro.  The way to use it is to put a function definition in a header
>     file with these keywords, and put another copy of the definition
>     (lacking `inline' and `extern') in a library file.  The definition in
>     the header file will cause most calls to the function to be inlined.
>     If any uses of the function remain, they will refer to the single copy
>     in the library.
> 
> So the definitions in the header file need to be `inline' and
> `extern', while the definitions in the library need to be ordinary.
> Oh, and you have to make sure all this works properly when you're not
> using GCC.  Sounds like a case for some serious CPP grunging.

This all seems pretty good. I'm currently using `inline' and `static'
for my stuff because I hardly ever take the address of a function, however
I can see why `inline' and `extern' is better for the library.

Regarding pre-processor macros, my current method is:

#define SI_DECL(x) static inline x __attribute__ ((unused)); static inline x

SI_DECL( ix_T locate_row_block( row_locator_T r ))
{
	return(( r & MATRIX_BLOCK_BLOCK_MASK ) >> MATRIX_BLOCK_INDEX_BITS );
}

But for the gh_ library, something along the lines of this should be OK:

#define EI_DECL(x) extern inline x

Along with some test to see if the compiler supports `inline' and
conditional codes, etc...

	- Tel

PS: Out of curiosity... [1] how many C compilers really are currently
    compatible with guile? (don't say they all are, I won't believe you!)
    [2] How many people are not using gcc? Are there good reasons to
    not use gcc or is it just what happened to be available at the time?