Bruce Momjian wrote:
Peter Eisentraut wrote:
On m?n, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote:
I thought one problem was that inline is a suggestion that the compiler
can ignore, while macros have to be implemented as specified.
Sure, but one could argue that a compiler that doesn't support inline
usefully is probably not the sort of compiler that you use for compiling
performance-relevant software anyway. We can support such systems in a
degraded way for historical value and evaluation purposes as long as
it's pretty much free, like we support systems without working int8.
The issue is that many compilers will take "inline" as a suggestion and
decide if it is worth-while to inline it --- I don't think it is inlined
unconditionally by any modern compilers.
Right now we think we are better at deciding what should be inlined than
the compiler --- of course, we might be wrong, and it would be good to
performance test this.
Just to clarify, this patch doesn't add new inline functions or
convert any macros to inline functions. At present, PostgreSQL
header files define four functions as inline for gcc only. This
patch merely opens up those existing inline functions to be used
with any compiler that accepts them, not just gcc. If this goes
well, it may be a preparatory step toward future adoption of more
inline functions and fewer macros.
Regards,
... kurt
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
