On 12/16/2009 8:21 AM, Tom Lane wrote:
I would only suggest that the cleanest coding would be#ifdef USE_INLINE static inline foo(...) ... #else ... non-inline definition of foo #endif ie, go ahead and rely on autoconf's definition (if any) of "inline" and add a policy symbol USE_INLINE to determine whether to use it.
That would work for gcc and MSVC. But it wouldn't allow for configuring an alternative keyword (like __forceinline) or added magic (like inserting an __attribute__ or __declspec) to silence warnings for some compiler which we don't know about yet.
The proposed PG_INLINE coding conflates the symbol needed in the code with the policy choice.
Everyone is familiar with this idiom: first test whether a pointer is NULL, before dereferencing it. We don't use a separate flag to say whether the pointer is NULL.
Another possibility would be to call the policy symbol HAVE_INLINE, but that (a) risks collision with a name defined by autoconf built-in macros, and (b) looks like it merely indicates whether the compiler *has* inline, not that we have made a choice about how to use it.
In the new 3rd edition of the patch, I've changed the name to inline_quietly. If not too many people hate this new name, I can undertake a new career naming tablets for Apple. :) 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
