Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #82813
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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