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