Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #82759 > unrolled thread

Inline functions and locals

Back to article view | Back to comp.lang.c++

Contents

  Inline functions and locals Muttley@dastardlyhq.com - 2022-01-12 16:34 +0000
    Re: Inline functions and locals Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-12 17:38 +0100
    Re: Inline functions and locals James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-12 12:47 -0500
    Re: Inline functions and locals Juha Nieminen <nospam@thanks.invalid> - 2022-01-13 07:00 +0000
      Re: Inline functions and locals "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-13 10:45 +0100
        Re: Inline functions and locals Juha Nieminen <nospam@thanks.invalid> - 2022-01-17 12:55 +0000
          Re: Inline functions and locals David Brown <david.brown@hesbynett.no> - 2022-01-17 15:14 +0100
          Re: Inline functions and locals Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-17 10:24 -0800
            Re: Inline functions and locals David Brown <david.brown@hesbynett.no> - 2022-01-17 19:46 +0100
      Re: Inline functions and locals Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-13 11:08 +0100
        Re: Inline functions and locals Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-13 19:30 -0800
    Re: Inline functions and locals Paavo Helde <eesnimi@osa.pri.ee> - 2022-01-13 12:46 +0200
      Re: Inline functions and locals Muttley@dastardlyhq.com - 2022-01-13 15:38 +0000
    Re: Inline functions and locals Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-13 17:51 -0800
      Re: Inline functions and locals Muttley@dastardlyhq.com - 2022-01-14 11:22 +0000
        Re: Inline functions and locals Öö Tiib <ootiib@hot.ee> - 2022-01-14 04:02 -0800
          Re: Inline functions and locals Manfred <invalid@invalid.add> - 2022-01-14 17:30 +0100
            Re: Inline functions and locals Muttley@dastardlyhq.com - 2022-01-14 16:49 +0000
          Re: Inline functions and locals Muttley@dastardlyhq.com - 2022-01-14 16:40 +0000
            Re: Inline functions and locals Öö Tiib <ootiib@hot.ee> - 2022-01-14 11:28 -0800
            Re: Inline functions and locals "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-14 20:29 +0100
        Re: Inline functions and locals James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-14 08:34 -0500
          Re: Inline functions and locals James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-14 11:26 -0500
            Re: Inline functions and locals David Brown <david.brown@hesbynett.no> - 2022-01-14 18:47 +0100
        Re: Inline functions and locals Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-14 08:43 -0800
          Re: Inline functions and locals Juha Nieminen <nospam@thanks.invalid> - 2022-01-17 05:38 +0000
            Re: Inline functions and locals David Brown <david.brown@hesbynett.no> - 2022-01-17 08:12 +0100
              Re: Inline functions and locals "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-01-16 23:51 -0800
                Re: Inline functions and locals "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-01-16 23:55 -0800
                Re: Inline functions and locals David Brown <david.brown@hesbynett.no> - 2022-01-17 11:35 +0100
              Re: Inline functions and locals Juha Nieminen <nospam@thanks.invalid> - 2022-01-17 09:50 +0000
                Re: Inline functions and locals James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-17 14:39 -0500
                  Re: Inline functions and locals Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 15:34 -0800
                    Re: Inline functions and locals "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-01-17 15:50 -0800
                      Re: Inline functions and locals Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 03:42 -0700
                        Re: Inline functions and locals "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-25 08:48 -0700
            Re: Inline functions and locals Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-16 23:53 -0800
              Re: Inline functions and locals Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 15:29 -0800
      Re: Inline functions and locals Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-17 12:40 +0100
        Re: Inline functions and locals Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-17 10:13 -0800
          Re: Inline functions and locals James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-17 16:15 -0500
            Re: Inline functions and locals Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-17 16:28 -0800
              Re: Inline functions and locals James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-17 22:55 -0500
                Re: Inline functions and locals Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-18 11:32 -0800
                  Re: Inline functions and locals James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-01-18 19:03 -0500
                    Re: Inline functions and locals Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-18 17:22 -0800
          Re: Inline functions and locals Bonita Montero <Bonita.Montero@gmail.com> - 2022-01-18 09:20 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#82806

On 1/17/22 1:13 PM, Andrey Tarasevich wrote:
...
> Um... Once again "only a hint to inline and not mandantory" is 
> completely meaningless wording within the context of a formal document. 
> Such wording should be relegated to a footnote, to explain the etymology 
> of the keyword.

You might disapprove of such a feature, but being a non-mandatory hint
is the primary purpose of this feature. It seems odd to me to mention
the primary purpose of a feature only in a footnote.

> The proper wording describing the purpose and intent of `inline` should 
> say something along the lines of "the purpose of `inline` keyword is to 
> make the definition of a function with external linkage visible in all 
> translation units without triggering an ODR violation".

Could you show me how you would use inline for the purpose of violating
the ODR rules, where there's no more appropriate way to achieve the same
objective? Allowing you do do so was certainly not the purpose of 'inline'.

[toc] | [prev] | [next] | [standalone]

#82813

On 1/17/2022 1:15 PM, James Kuyper wrote:
> On 1/17/22 1:13 PM, Andrey Tarasevich wrote:
> ...
>> Um... Once again "only a hint to inline and not mandantory" is
>> completely meaningless wording within the context of a formal document.
>> Such wording should be relegated to a footnote, to explain the etymology
>> of the keyword.
> 
> You might disapprove of such a feature, but being a non-mandatory hint
> is the primary purpose of this feature. It seems odd to me to mention
> the primary purpose of a feature only in a footnote.

That is false. The primary purpose of this feature is, again, is 
consistent between functions and variables: facilitate support for 
multiple definitions of the the same entity with external linkage 
(variable or function) across multiple TUs (see below)

>> The proper wording describing the purpose and intent of `inline` should
>> say something along the lines of "the purpose of `inline` keyword is to
>> make the definition of a function with external linkage visible in all
>> translation units without triggering an ODR violation".
> 
> Could you show me how you would use inline for the purpose of violating
> the ODR rules, where there's no more appropriate way to achieve the same
> objective? Allowing you do do so was certainly not the purpose of 'inline'.

Um... This is some rather strange wording: "use inline for the purpose 
of violating the ODR rules". Where did you get this? ODR rules, 
obviously, are aware of `inline` and inclusive of `inline`. Nobody's 
talking about "violating" them here in any formal way.

What I'm referring to is rather obvious from the above discussion.

The primary purpose of the feature is this: the whole problem, the whole 
objective is provide us with a feature, that would let us write

   unsigned foo = 42;

   void bar()
   {
   }

in a header file and then include this file into multiple TUs.

A naive attempt to do this will result in ODR violations: multiple 
definitions of entities with external linkage.

(`static` might be seen as workaround for the function, but we don't 
want that. External linkage is the point here. For whatever reason, we 
want a function with unique address identity for the whole program.)

So, we need a feature that will
1) suppress the ODR violations, and
2) ensure the unique address/storage identity for both the variable and 
the function.

And (drum roll) that is achieved through `inline`

   inline unsigned foo = 42;

   inline void bar()
   {
   }

Done. End of story. And no point any "hints" or "embedding of function 
call sites" come into this picture. They are completely irrelevant.

As a side note, of course, the reason we want this is to expose full 
function body to the compiler in all TUs, thus helping the compiler to 
fully analyze the function, optimize its usage and optimize surrounding 
code based on its knowledge of function's internal behavior. The actual 
"embedding of function call sites" is just one [minor] part of this 
process.

How the compiler will implement the required spec is its own business, 
but as we all know the most popular approach today is to just push the 
problem over to the linker and let it silently eliminate the unnecessary 
copies.

This implementational approach is what justifies referring to `inline` 
as an "ODR defeater" informally. That's basically what `inline` does: it 
tells the linker that instead of complaining about multiple definitions 
it has to shut up and just mop things up quietly.

That is the prime purpose of `inline`. Has always been. All these 
stories about the "hint" is just a mumbo-jumbo, which probably only 
persists in standard text out of respect to someone who originally 
introduced it.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#82814

On 1/17/22 7:28 PM, Andrey Tarasevich wrote:
...
> Um... This is some rather strange wording: "use inline for the purpose 
> of violating the ODR rules". Where did you get this? ODR rules, 
> obviously, are aware of `inline` and inclusive of `inline`. Nobody's 
> talking about "violating" them here in any formal way.

You're talking about 'inline' as a way of getting around those rules. If
'inline' didn't exist, then those rules obviously couldn't cite it as an
exception, and what you're claiming is the primary purpose of 'inline'
would be a violation of those rules. That purpose is expressed by
inserting an exception for 'inline' into those rules.

> What I'm referring to is rather obvious from the above discussion.
> 
> The primary purpose of the feature is this: the whole problem, the whole 
> objective is provide us with a feature, that would let us write
> 
>    unsigned foo = 42;
> 
>    void bar()
>    {
>    }
> 
> in a header file and then include this file into multiple TUs.

Declaring them with internal linkage would achieve the same benefit.

...
> (`static` might be seen as workaround for the function, but we don't 
> want that. External linkage is the point here. For whatever reason, we 
> want a function with unique address identity for the whole program.)

Why? I can imagine unusual circumstances where that might be needed, but
I wouldn't expect it to be a common need. Note that an inline function
is only required to have a unique address if it has external linkage or
module linkage (9.2.7p6). If having a single unique address was the main
purpose of 'inline', why would it even be permitted to declare an inline
function with internal linkage? You could have functions with internal
linkage if you don't need a unique address, and 'inline' functions, with
inherently external linkage, if you do need a unique address. If that's
the primary purpose, why didn't they it that way?

...
> That is the prime purpose of `inline`. Has always been. All these 
> stories about the "hint" is just a mumbo-jumbo, which probably only 
> persists in standard text out of respect to someone who originally 
> introduced it.

That's a ridiculous suggestion. That's not how standards get written. If
getting around the ODR rules was even an important secondary purpose for
'inline', there would have been some mention of it somewhere in 9.2.7.

That ridiculous suggestion isn't even consistent with the immediately
preceding sentence. If the person who originally introduced it had a
different conception of the purpose, one that the standard pays only lip
service to, then by definition the purpose you refer to has not "always
been" the prime purpose. There had to have been at least a short period
of time (as I understand it, that "short" period of time has been
decades long) during which the purpose it originally was introduced for
remained the primary purpose.

[toc] | [prev] | [next] | [standalone]

#82820

On 1/17/2022 7:55 PM, James Kuyper wrote:
> On 1/17/22 7:28 PM, Andrey Tarasevich wrote:
> ...
>> Um... This is some rather strange wording: "use inline for the purpose
>> of violating the ODR rules". Where did you get this? ODR rules,
>> obviously, are aware of `inline` and inclusive of `inline`. Nobody's
>> talking about "violating" them here in any formal way.
> 
> You're talking about 'inline' as a way of getting around those rules. If
> 'inline' didn't exist, then those rules obviously couldn't cite it as an
> exception, and what you're claiming is the primary purpose of 'inline'
> would be a violation of those rules. That purpose is expressed by
> inserting an exception for 'inline' into those rules.

When I'm talking about `inline` as an "ODR suppressor" or "defeater", 
I'm not talking about the exact formal ODR as it is defined in C++ 
standard. I'm referring to the general/basic/primitive linker-level idea 
of ODR: "if you have two identical symbols in you object files, you end 
up with multiple definition error from the linker".

>> What I'm referring to is rather obvious from the above discussion.
>>
>> The primary purpose of the feature is this: the whole problem, the whole
>> objective is provide us with a feature, that would let us write
>>
>>     unsigned foo = 42;
>>
>>     void bar()
>>     {
>>     }
>>
>> in a header file and then include this file into multiple TUs.
> 
> Declaring them with internal linkage would achieve the same benefit.

No it won't. In that case they won't have external linkage, meaning that 
they will not refer to the same entity everywhere in the program. I 
think I made it clear that this is part of the objective as well.

> ...
>> (`static` might be seen as workaround for the function, but we don't
>> want that. External linkage is the point here. For whatever reason, we
>> want a function with unique address identity for the whole program.)
> 
> Why? I can imagine unusual circumstances where that might be needed, but
> I wouldn't expect it to be a common need. 

For variables the common need is obvious. (I'm surprised I have to even 
mention it.)

At the same time, I agree that for functions it is much less important 
and common.

But if this were just about inline functions, chances are nobody would 
even bother. However, in C++ the primary driver for this functionality 
is not really inline functions at all. It is templates. 99.9% of the 
pressing need for this "ODR suppressing" functionality comes from 
templates. Implicit instantiation of templates faces the very same 
issues: external linkage and multiple definitions, conflicting with the 
"basic" idea of ODR I described above. Templates are the primary driver 
behind that "gratuitously-overgenerate-then-discard" approach relied 
upon by modern implementations.

(There were alternative implementations, intended to avoid 
"overgeneration" and to play nice with "basic ODR", e.g. Sun Solaris C++ 
compiler, but AFAIK none of them survived.)

(C++ also provides you with facilities for explicit "manual" 
instantiation of templates, which are, curiously, quite similar to C's 
approach to `inline`. But I hope it is clear to everyone that C++ 
templates would never take off without their _implicit_ instantiation 
mechanics.)

So, whether you consider inline functions with external linkage 
necessary or not is not really that important. The 
"gratuitously-overgenerate-then-discard" approach would still be there 
anyway - for templates. And once it's there, you basically get inline 
functions with external linkage for free, just for the sake of formal 
completeness.

> Note that an inline function
> is only required to have a unique address if it has external linkage or
> module linkage (9.2.7p6). If having a single unique address was the main
> purpose of 'inline', why would it even be permitted to declare an inline
> function with internal linkage? 

"Having a single unique out-of-line body" is probably better wording. 
Having a single unique address naturally comes with it.

As for why inline functions with internal linkage are permitted... 
There's simply no reason to prohibit it. `static inline` is redundant, 
but there's no reason to spend effort to introduce a rule that would 
prohibit it. There lots and lots of such redundant yet legal constructs 
in C++.

> You could have functions with internal
> linkage if you don't need a unique address, and 'inline' functions, with
> inherently external linkage, if you do need a unique address. If that's
> the primary purpose, why didn't they it that way?

Again, that would lead to a more complicated specification of this 
specifier without any tangible benefits. No need to do that.

Here's an immediately available example for you: variables again. Note 
that `static inline` is _obviously_ redundant with namespace-scope 
variables. There's no need to involve any "woulds", "whatifs" or 
contrived scenarios here. `static inline` is obviously and 
unconditionally redundant with variables today, right now, everywhere. 
Yet, this is perfectly legal

   /* Namespace scope */
   static inline unsigned n = 42;

You can start asking your "why?" questions now. "Why do they allow 
this?" "Why is it legal?" To me the answer is natural and obvious: why 
not? No harm done, no need to overcomplicate things. This has always 
been one of the cornerstone principles in thois language's design.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#82821

On 1/18/22 2:32 PM, Andrey Tarasevich wrote:
...
> You can start asking your "why?" questions now. "Why do they allow 
> this?" "Why is it legal?" To me the answer is natural and obvious: why 
> not? No harm done, no need to overcomplicate things. This has always 
> been one of the cornerstone principles in thois language's design.

When you're claiming that what it actually says in 9.2.1p2 is
irrelevant, and stuff that it says nowhere in 9.2.7 is actually the
primary purpose of the 'inline' specifier, then you're going to need
better arguments than those. Having confirmed that you don't have any,
I'm going to leave this discussion - it's not going anywhere.

[toc] | [prev] | [next] | [standalone]

#82822

On 1/18/2022 4:03 PM, James Kuyper wrote:
> On 1/18/22 2:32 PM, Andrey Tarasevich wrote:
> ...
>> You can start asking your "why?" questions now. "Why do they allow
>> this?" "Why is it legal?" To me the answer is natural and obvious: why
>> not? No harm done, no need to overcomplicate things. This has always
>> been one of the cornerstone principles in thois language's design.
> 
> When you're claiming that what it actually says in 9.2.1p2 is
> irrelevant, and stuff that it says nowhere in 9.2.7 is actually the
> primary purpose of the 'inline' specifier, then you're going to need
> better arguments than those. Having confirmed that you don't have any,
> I'm going to leave this discussion - it's not going anywhere.

Sigh... It appears that I'm trying to prove that Earth is round at a 
meeting of Flat Earth Society. "You're going to need better arguments 
than those", they say... )))

Sorry, boys, but to prevent any further time-wasting I'm going to have 
to pull the rank here: at this point just study, take notes and commit 
to memory what I said above. If you feel that you need extra 
rationale/argumentation to better understand the material - you'll find 
all that later (leave to you as an exercise).

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#82818

Am 17.01.2022 um 19:13 schrieb Andrey Tarasevich:
> On 1/17/2022 3:40 AM, Bonita Montero wrote:
>> Am 14.01.2022 um 02:51 schrieb Andrey Tarasevich:
>>
>>> 2. Keyword `inline` has absolutely nothing to do with embedding 
>>> function code at the call site. The purpose of `inline` keyword is to 
>>> allow you to defeat ODR restrictions for a function (or a variable) 
>>> with external linkage. ...
>>
>> That's true for inline-variables but for inline-functions only parti-
>> tially. For inline functions inline is also a hint for the compiler
>> to inline the code in the calling code. But this is only a hint and
>> not mandantory.
> 
> Um... Once again "only a hint to inline and not mandantory" is 
> completely meaningless wording within the context of a formal document. 
> Such wording should be relegated to a footnote, to explain the etymology 
> of the keyword.
> 
> Currently, this is essentially a defect in the standard, which only 
> serves to confuse people.

You're simply an idiot who can't accept the world like it is.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c++

csiph-web