Date: Sun, 24 Aug 2025 23:01:01 -0700
On Sunday, 24 August 2025 22:57:10 Pacific Daylight Time Tiago Freire wrote:
> One thing that strikes a nerve with me is that if you declare a function
> inline neither MSVC or GCC actually inline anything, as far as I was able
> to observe only clang seems to respect the keyword.
Yeah, because the inline keyword does not control inlining. It controls the
emission of the out-of-line copy (namely, that there doesn't need to be one).
> You actually need to use a non-portable compiler specific keyword in order
> to (pretty please with sugar on top, just freaking do it and) actually get
> it to do what you want. There's already a keyword that exists in the
> standard to do this job, and it is complete BS to have to use a different
> non-portable one to make things work. I think the standard can be made
> normative in this regard, as well as offer additional mechanisms that if a
> function inputs are all constant expressions, the result itself should also
> be a constant expression.
Ask compiler developers and they will tell you that people frequently get
always_inline wrong. The compiler has a lot of information available and will
inline what it thinks is worth inlining.
I agree on the constexpr-if-constexpr-inputs case.
> One thing that strikes a nerve with me is that if you declare a function
> inline neither MSVC or GCC actually inline anything, as far as I was able
> to observe only clang seems to respect the keyword.
Yeah, because the inline keyword does not control inlining. It controls the
emission of the out-of-line copy (namely, that there doesn't need to be one).
> You actually need to use a non-portable compiler specific keyword in order
> to (pretty please with sugar on top, just freaking do it and) actually get
> it to do what you want. There's already a keyword that exists in the
> standard to do this job, and it is complete BS to have to use a different
> non-portable one to make things work. I think the standard can be made
> normative in this regard, as well as offer additional mechanisms that if a
> function inputs are all constant expressions, the result itself should also
> be a constant expression.
Ask compiler developers and they will tell you that people frequently get
always_inline wrong. The compiler has a lot of information available and will
inline what it thinks is worth inlining.
I agree on the constexpr-if-constexpr-inputs case.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Platform & System Engineering
Received on 2025-08-25 06:01:08