This is the mail archive of the guile@cygnus.com mailing list for the guile project.


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

Re: guile: going the way of DEATH



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
- they slowed down the compiler a lot the last time I tried them (1990)
- everyone is used to macros
- although macros do cause troubles, with a little discipline, you can
  write macros that are pretty trouble-free

But maybe we should give them a try.

> 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.

If we want to use inline functions, then we need to put the
definitions in a header file, which all users of those functions
#include.  However, we should also be able to take their addresses, so
they need to be present as normal functions in the library as well.

>From the GCC manual:

       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.