This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] Should _GLIBCXX_CONSTEXPR, _GLIBCXX14_CONSTEXPR etc. expand to 'inline' ?
On 27/09/19 15:32 +0300, Antony Polukhin wrote:
On Fri, Sep 27, 2019, 15:02 Jonathan Wakely <jwakely@redhat.com> wrote:
Currently we have lots of code that has:
inline _GLIBCXX14_CONSTEXPR void
foo()
When the macro expands to 'constexpr' the 'inline' is redundant,
because constexpr implies inline.
For older standards we could make it expand to 'inline' instead of
'constexpr' and then we don't need the sometimes-redundant 'inline'
there.
I'm in favour of this change.
This would be a change if we have some functions that are *not*
declared 'inline' for older standards, but become inline when they're
constexpr functions. I'm not aware of any cases like that.
It may also add inline to template functions that do not have explicit
inline on them otherwise. Does the GCCs optimizer uses an explicit inline
as a hint for function inlining
Yes, it does, although I think that's a mistake.
and should we care about such differences?
I was assuming that most functions that are suitable for 'constexpr'
will be small and simple enough that they should already be marked
'inline'.
However, for C++20 that's definitely not true, because nearly every
function is inline! There are certainly lots of function templates in
<algorithm> which are not currently inline.
We could make _GLIBCXX_CONSTEXPR, _GLIBCXX14_CONSTEXPR and
_GLIBCXX17_CONSTEXPR expand to inline, but not _GLIBCXX20_CONSTEXPR,
but that somewhat weakens the argument for making the change.