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
