Penitent's corner

[woodb...@gmail.com]

I was until today laboring under the idea that I needed to
mark all non-template functions in header files as inline.
Then I read on reddit/learnprogramming:

"Almost all templates and constexpr values are implicitly inline. Also any function defined inside a class."

It's the last part about functions defined inside a class that
I didn't know or had forgotten. I've now updated my software:
https://github.com/Ebenezer-group/onwards

and tested that this is kosher with both gcc and clang. Removing
the superfluous inline keywords didn't make any difference to
the size of the text segments for gcc 8.2, but for clang 7.0 it
led to a bit smaller text segments.

I'm encouraged by these events and ask for further review of my software.


Brian
Ebenezer Enterprises - "The L-RD is near to the brokenhearted; He saves the contrite in spirit. Many are the afflictions of the righteous, but the L-RD delivers him from them all." Psalms 34:18-19
http://webEbenezer.net

[Alf P. Steinbach]

On 17.11.2018 21:58, woodb...@gmail.com wrote:
> I was until today laboring under the idea that I needed to
> mark all non-template functions in header files as inline.
> Then I read on reddit/learnprogramming:
>
> "Almost all templates and constexpr values are implicitly inline. Also any function defined inside a class."

That's very wrong, pure disinformation.

A function defined inside a class is implicitly `inline`, yes.

However, a freestanding function template is not, and a `constexpr` is not.

If you fully specialize a function template you don't get an `inline`
function, unless you add the keyword `inline`. So you can easily run
into multiple definition errors. It depends on what you do.

If you take the address of a not explicitly inlined `constexpr` value in
two different translation units, you get two different addresses. If you
do that with an `inline` value you get the same address.

> It's the last part about functions defined inside a class that
> I didn't know or had forgotten. I've now updated my software:
> https://github.com/Ebenezer-group/onwards
>
> and tested that this is kosher with both gcc and clang. Removing
> the superfluous inline keywords didn't make any difference to
> the size of the text segments for gcc 8.2, but for clang 7.0 it
> led to a bit smaller text segments.
>
> I'm encouraged by these events and ask for further review of my software.

Hm, encouraged by disinformation that Seems To Work™.


Cheers!,

- Alf

[woodb...@gmail.com]

On Saturday, November 17, 2018 at 3:20:47 PM UTC-6, Alf P. Steinbach wrote:
> On 17.11.2018 21:58, woodb...@gmail.com wrote:
> > I was until today laboring under the idea that I needed to
> > mark all non-template functions in header files as inline.
> > Then I read on reddit/learnprogramming:
> >
> > "Almost all templates and constexpr values are implicitly inline. Also any function defined inside a class."
>
> That's very wrong, pure disinformation.
>
> A function defined inside a class is implicitly `inline`, yes.
>
> However, a freestanding function template is not, and a `constexpr` is not.

Well, I have some freestanding function templates that aren't
marked as inline and neither gcc 8.2 or clang 7.0 say anything
about that. I'm not sure it's a problem.

>
> If you fully specialize a function template you don't get an `inline`
> function, unless you add the keyword `inline`. So you can easily run
> into multiple definition errors. It depends on what you do.
>
> If you take the address of a not explicitly inlined `constexpr` value in
> two different translation units, you get two different addresses. If you
> do that with an `inline` value you get the same address.
>
>
> > It's the last part about functions defined inside a class that
> > I didn't know or had forgotten. I've now updated my software:
> > https://github.com/Ebenezer-group/onwards
> >
> > and tested that this is kosher with both gcc and clang. Removing
> > the superfluous inline keywords didn't make any difference to
> > the size of the text segments for gcc 8.2, but for clang 7.0 it
> > led to a bit smaller text segments.
> >
> > I'm encouraged by these events and ask for further review of my software.
>
> Hm, encouraged by disinformation that Seems To Work™.
>

I don't know if the author intended to muddy the waters.
At any rate, it was helpful to me in that some of it was
accurate.


Brian

[Öö Tiib]

On Saturday, 17 November 2018 23:20:47 UTC+2, Alf P. Steinbach wrote:
> On 17.11.2018 21:58, woodb...@gmail.com wrote:
> > I was until today laboring under the idea that I needed to
> > mark all non-template functions in header files as inline.
> > Then I read on reddit/learnprogramming:
> >
> > "Almost all templates and constexpr values are implicitly inline. Also any function defined inside a class."
>
> That's very wrong, pure disinformation.
>
> A function defined inside a class is implicitly `inline`, yes.
>
> However, a freestanding function template is not, and a `constexpr` is not.

The constexpr has been implicitly inline all the time. [dcl.constexpr]

[Alf P. Steinbach]

No.

The paragraph you refer to does not support your claim.

Since you fail to provide a quote I must /guess/, and I think this is
the part you focused on, from C++17 §10.15.1/1:

“A function or static data member declared with the constexpr
specifier is implicitly an inline function or variable”

That does not cover ordinary `constexpr` variables.


Cheers & hth.,

- Alf

[Juha Nieminen]

Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
> That does not cover ordinary `constexpr` variables.

For that you would need an "extern constexpr" variable, which I don't
think would make any sense.

On that note, I have for long puzzled about the behavior and distinction
between a const integral and, for example, a const floating point value.
A "const int" that's initialized with a compile-time constant is (and AFAIK
has always been) pretty much equivalent to the modern "constexpr int".
In other words, it can be used wherever a compile-time constant is required.
However, "const double" is not (nowadays you would have to use
"constexpr double" for that).

[Alf P. Steinbach]

On 19.11.2018 14:09, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.stein...@gmail.com> wrote:
>> That does not cover ordinary `constexpr` variables.
>
> For that you would need an "extern constexpr" variable, which I don't
> think would make any sense.

No, you don't need an `extern` variable to see the difference. You can
take the address of a `constexpr` variable. That's all you need to have
an observable difference between inline and not.

> On that note, I have for long puzzled about the behavior and distinction
> between a const integral and, for example, a const floating point value.
> A "const int" that's initialized with a compile-time constant is (and AFAIK
> has always been) pretty much equivalent to the modern "constexpr int".
> In other words, it can be used wherever a compile-time constant is required.
> However, "const double" is not (nowadays you would have to use
> "constexpr double" for that).

I don't understand it either.

But the arguments I've seen have had to do with cross-compilation and
how the compiler, in such a case, would be unreasonably required to
emulate every target system in order to produce 100% perfect values.
Though no explanation of why such perfect values would be required. Or
why, then, one could use e.g. the templated constant trick in C++03.


Cheers!,

- Alf

[woodb...@gmail.com]

In that case, it seems like it would be better if the

standard said:

A function or static data member declared with the constexpr

specifier is implicitly an inline function or static data member.


Brian
Ebenezer Enterprises
http://webEbenezer.net