From: | Kurt Harriman <harriman(at)acm(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Marko Kreen <markokr(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch: Remove gcc dependency in definition of inline functions |
Date: | 2010-02-10 10:17:32 |
Message-ID: | 4B7287BC.7030400@acm.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joachim Wieland | 2010-02-10 10:36:41 | Re: synchronized snapshots |
Previous Message | Marko Tiikkaja | 2010-02-10 10:05:53 | Re: Writeable CTEs and empty relations |