Hrvoje> Martin Buchholz <martin(a)xemacs.org&gt; writes: Hrvoje> [...] Hrvoje> I've been told that in C++ `inline' means `static inline'. Do all C++ Hrvoje> compilers grok `static inline'? In standard C++, `inline' does not affect the extern-ness of a function. If different translations units have definitions for an external inline function, they must be identical. Older C++ implementations considered `extern inline' illegal. I guess that adds to the number of distinct inline implementations - we're up to 6 now! Yes, in C++ you can have an extern inline function with a static variable declared within it, and all the inline functions in different translation units share that static variable! Hrvoje> I think it is. And it's especially important to *document* what it Hrvoje> means. The annoying thing about the INLINE confusion is that it crops Hrvoje> up time and again, by different people and with different code. OK. I'm convinced. I'll implement this, if there are no further objections. Again, the proposal: 1. Rename INLINE to INLINE_HEADER. 2. Document the two approved ways of creating inline functions - in .h files, using INLINE_HEADER, and in .c files, using `static inline'.

kkm> Some time ago, Martin Buchholz wrote... kkm> MSVC has `__inline' but no `inline'. This means that I'll have to put kkm> #define inline __inline kkm> in the s/ file. Is it clean? I think yes, just what do you think about this. I agree. You'll also need to define INLINE (to be renamed INLINE_HEADER very soon). It is very likely that #define INLINE static inline will work. But if there is a mechanism like gcc's for having non-inlined inline functions defined externally, that could be used to avoid generating multiple function bodies if an inline function is not inlined (e.g. during debugging). This is purely an object code size optimization, however - the suggested definition for INLINE will very likely work, and will work very well when optimizing. Whatever you do, try to test with C and C++. Martin

Some time ago, Olivier Galibert wrote... configure if it ran on Windows would generate the same config.h again and again. MS competitors, thanks Bill, supply exactly 0 (zero) different compilers. (On the other hand, off sarcasm, I must admit that MSVC is really a good compiler). In Windows, I have config.h (shipped, not configure-generated), s/windowsnt.h and m/windowsnt.h. My hands are itchy to do 2 of them in. It does not make any difference for me which 2. Olivier's vote recorded :) Big K