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' ?
- From: Antony Polukhin <antoshkka at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Fri, 27 Sep 2019 15:32:39 +0300
- Subject: Re: [RFC] Should _GLIBCXX_CONSTEXPR, _GLIBCXX14_CONSTEXPR etc. expand to 'inline' ?
- References: <20190927120244.GX9487@redhat.com>
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 and should we care about such differences?
>