Re: Patch: Remove gcc dependency in definition of inline functions
От | Bruce Momjian |
---|---|
Тема | Re: Patch: Remove gcc dependency in definition of inline functions |
Дата | |
Msg-id | 200911301206.nAUC6IX28849@momjian.us обсуждение исходный текст |
Ответ на | Re: Patch: Remove gcc dependency in definition of inline functions (Marko Kreen <markokr@gmail.com>) |
Ответы |
Re: Patch: Remove gcc dependency in definition of inline
functions
|
Список | pgsql-hackers |
Marko Kreen wrote: > On 11/29/09, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Kurt Harriman <harriman@acm.org> writes: > > > (Does anybody still use a C compiler that doesn't support > > > inline functions?) > > +1 for modern C. > > > The question isn't so much that, it's whether the compiler supports > > inline functions with the same behavior as gcc. At minimum that > > would require > > * not generating extra copies of the function > > * not whining about unreferenced static functions > > How many compilers have you tested this patch against? Which ones > > does it actually offer any benefit for? > > Those are not correctness problems. Compilers with non-optimal or > missing 'inline' do belong together with compilers without working int64. > We may spend some effort to be able to compile on them, but they > should not affect our coding style. > > 'static inline' is superior to macros because of type-safety and > side-effects avoidance. I'd suggest event removing any HAVE_INLINE > ifdefs and let autoconf undef the 'inline' if needed. Less duplicated > code to maintain. The existence of compilers in active use without > working 'inline' seems quite hypothetical these days. I thought one problem was that inline is a suggestion that the compiler can ignore, while macros have to be implemented as specified. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: