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


Jim Blandy <jimb@red-bean.com> writes:

> 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

And any C++ compiler.  I think it's prudent to write C code that will
compiler with a C++ compiler's stronger type safety.  We build scwm w/
C++ every now and again and find some bugs each time.

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

Compilers are better now.

> - everyone is used to macros

Come on... everyone *dislikes* macros!

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

But they're a total pain to debug.  inline functions are easy to reason
about in the debugger.

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

If you're replacing macros with inline functions, why do you care about
being able to take the address of the function.  In C++, at least,
an inline function whose address is taken will have a copy generated out 
of line, too, without any extra effort.

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

This seems roughly the same as the C++ rule.

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

That's the hardest part -- providing for non GCC compilers while still
getting the benefits of the inline extension and not creating a
maintenance nightmare where a macro def'n and its corresponding inline
function are manually kept in sync.

Greg