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


Groups > comp.lang.c++ > #82813

Re: Inline functions and locals

From Andrey Tarasevich <andreytarasevich@hotmail.com>
Newsgroups comp.lang.c++
Subject Re: Inline functions and locals
Date 2022-01-17 16:28 -0800
Organization A noiseless patient Spider
Message-ID <ss51ir$86f$1@dont-email.me> (permalink)
References <srmvu4$oie$1@gioia.aioe.org> <srqkvk$3vi$1@dont-email.me> <ss3kjc$sbb$1@dont-email.me> <ss4bkq$e34$1@dont-email.me> <ss4m8r$tk0$1@dont-email.me>

Show all headers | View raw


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

Back to comp.lang.c++ | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web