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 1 of 3  [1] 2 3  Next page →

#82759 — Inline functions and locals

I'm curious as to why returning a reference to a local inside an inline
function isn't (apparently) allowed. eg:

#include <iostream>
#include <string>

using namespace std;

inline string &func()
{
        string s = "hello";
        return s;
}



int main()
{
        cout << func() << endl;
        return 0;
}

This causes a compilation warning with clang and when run prints out garbage
as you'd expect if it were a non inline. However surely if the function is
truly inline it should work. Are locals for inlines temporaries created on the 
heap instead of being stored on the same stack as the calling function locals?

[toc] | [next] | [standalone]

#82760

Am 12.01.2022 um 17:34 schrieb Muttley@dastardlyhq.com:
> I'm curious as to why returning a reference to a local inside an inline
> function isn't (apparently) allowed. eg:
> 
> #include <iostream>
> #include <string>
> 
> using namespace std;
> 
> inline string &func()
> {
>          string s = "hello";
>          return s;
> }
> 
> 
> 
> int main()
> {
>          cout << func() << endl;
>          return 0;
> }
> 
> This causes a compilation warning with clang and when run prints out garbage
> as you'd expect if it were a non inline. However surely if the function is
> truly inline it should work. Are locals for inlines temporaries created on the
> heap instead of being stored on the same stack as the calling function locals?

Yes, this is UB because the storage of the function and sometimes
the object you return get destructed. Make it thread_local and then
you can return the object from the function and the function can be
called from any thread. Make it static and lock any operations on
it if you want to have a shared object.

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

#82763

On 1/12/22 11:34 AM, Muttley@dastardlyhq.com wrote:
> I'm curious as to why returning a reference to a local inside an inline
> function isn't (apparently) allowed. eg:
> 
> #include <iostream>
> #include <string>
> 
> using namespace std;
> 
> inline string &func()
> {
>         string s = "hello";
>         return s;
> }
> 
> 
> 
> int main()
> {
>         cout << func() << endl;
>         return 0;
> }
> 
> This causes a compilation warning with clang and when run prints out garbage
> as you'd expect if it were a non inline. However surely if the function is
> truly inline it should work. Are locals for inlines temporaries created on the 
> heap instead of being stored on the same stack as the calling function locals?

Calls to functions declared "inline" have the same semantics as they
would have if not so declared, they can simply be optimized by replacing
the function call with local code, but only if that local code has the
SAME semantics. The following code is equivalent to what the compile is
allowed to do with inline functions. To make this work, I need to
explicitly declare a variable that corresponds to the return value from
the function, but I'm going to have to change it to a pointer rather
than a reference, because this re-write wouldn't work with a reference.
For a great many purposes, references are semantically equivalent to
const pointers, the differences are mainly syntactic. However, for
reasons that will hopefully be clear when you think about it, I can't
use a const pointer OR a real reference in the following re-write:

    int main()
    {
        string *tmp;

        {
            string s = "hello";
            tmp = &s;
        }

        cout << *tmp << endl;
        return 0;
    }

The object `s` in func() and the object `s` in my re-write both have
lifetimes that end when the `}` that terminates the enclosing block is
reached. Dereferencing tmp at any time after the lifetime of the object
it refers to has ended has undefined behavior, for the same reason that
using the reference returned by func() has undefined behavior. So both
pieces of code are bad for the same reason.

I suspect that you thought that the inlined function code would not be
treated as if it were enclosed in a separate block, but that would
change the semantics. Objects declared local to the inlined function are
NOT treated as if they were declared in the block that contains the call
to that function - if they were, that would make them much harder to use.

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

#82764

Muttley@dastardlyhq.com wrote:
> I'm curious as to why returning a reference to a local inside an inline
> function isn't (apparently) allowed. eg:

For all intents and purposes 'inline' (when used in a function definition)
is an instruction for the linker, not the compiler, and should really be
thought as such.

In all likelihood the compiler is going to ignore the keyword when making
inlinining decisions (I don't know if it has ever had any effect with any
compiler). In any case, it doesn't change the semantics of the function.
The function still has all the requirements of a "non-inline" function
(with the exception of the changed linking strategy). You should always
think of "inline" functions as if they weren't inlined (which is a real
possibility, because the standard allows compilers to not actually do the
inlining.)

'inline' is an instruction for the linker because it instructs the linker
to do something special with that function signature. (It tells it that
if it finds that function implementation in more than one compilation
unit, rather than give an error for duplicate symbols it should just
choose one of them and discard the rest.)

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

#82765

On 13 Jan 2022 08:00, Juha Nieminen wrote:
> Muttley@dastardlyhq.com wrote:
>> I'm curious as to why returning a reference to a local inside an inline
>> function isn't (apparently) allowed. eg:
> 
> For all intents and purposes 'inline' (when used in a function definition)
> is an instruction for the linker, not the compiler, and should really be
> thought as such.

I guess here you're referring to the only guaranteed feature of 
`inline`, that of allowing multiple definitions of variable or function, 
as long as they're in different translation units.


> In all likelihood the compiler is going to ignore the keyword when making
> inlinining decisions (I don't know if it has ever had any effect with any
> compiler).

Some years ago g++ treated `inline` as an almost absolute inlining 
directive.

That was problematic wrt. header only modules.

I guess it still is, but negative facts about g++ are hard to become 
aware of: the gcc fanboi community tends to assemble like a swarm of 
mosquitoes (including even in this group, which was surprising to me the 
first few times, it was easy to understand for SO but unbelievable here) 
when there's mention of something not 100% hallelujah about gcc.


> In any case, it doesn't change the semantics of the function.
> The function still has all the requirements of a "non-inline" function
> (with the exception of the changed linking strategy). You should always
> think of "inline" functions as if they weren't inlined (which is a real
> possibility, because the standard allows compilers to not actually do the
> inlining.)
> 
> 'inline' is an instruction for the linker because it instructs the linker
> to do something special with that function signature. (It tells it that
> if it finds that function implementation in more than one compilation
> unit, rather than give an error for duplicate symbols it should just
> choose one of them and discard the rest.)

- Alf

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

#82797

Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
> Some years ago g++ treated `inline` as an almost absolute inlining 
> directive.

Does anyone have a reference or documentation that shows that compilers
like gcc, clang, icc and Visual Studio behave differently with respect
to inlining a function depending on whether the function has been marked
as 'inline' or not?

For the longest time I have got the impression that if a compiler sees
the function definition from the call location, it uses a heuristic to
determine whether it will inline the function or not, and this heuristic
completely ignores whether the function has been marked as 'inline'.
However, I could well be wrong. Maybe they use different heuristics
depending on whether that keyword appears or not?

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

#82798

On 17/01/2022 13:55, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
>> Some years ago g++ treated `inline` as an almost absolute inlining 
>> directive.
> 
> Does anyone have a reference or documentation that shows that compilers
> like gcc, clang, icc and Visual Studio behave differently with respect
> to inlining a function depending on whether the function has been marked
> as 'inline' or not?
> 
> For the longest time I have got the impression that if a compiler sees
> the function definition from the call location, it uses a heuristic to
> determine whether it will inline the function or not, and this heuristic
> completely ignores whether the function has been marked as 'inline'.
> However, I could well be wrong. Maybe they use different heuristics
> depending on whether that keyword appears or not?
> 

That is correct, as far as I know.  There are some flags that can
influence inlining, such as whether static functions that are only
called once are always inlined or not, but you rarely use them - enable
an appropriate level of optimisation (-O2 is good for many uses), and
the compiler will probably do a better job than the programmer would at
figuring out the best policy for each function.  The compiler can also
be more flexible (such as partial inlining) than a programmer could specify.

If I want control over inlining (which I occasionally do in my embedded
development), I use gcc's "always_inline" or "noinline" attributes.

If Alf is correct about gcc treating "inline" as "an almost absolute
directive", it must have been a /long/ time ago - gcc 2.95 from pre-C99
days did heuristic-based inlining optimisations, and that's as far back
as I have bothered checking.

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

#82801

On 1/17/2022 4:55 AM, Juha Nieminen wrote:
> Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
>> Some years ago g++ treated `inline` as an almost absolute inlining
>> directive.
> 
> Does anyone have a reference or documentation that shows that compilers
> like gcc, clang, icc and Visual Studio behave differently with respect
> to inlining a function depending on whether the function has been marked
> as 'inline' or not?
> 

Depends on the compiler settings. "By default" GCC considers for 
inlining only those functions that are explicitly declared `inline`.

In order to inline something else one'd need to enable 
`-finline-functions-called-once` (included in `-O1`), 
`-finline-functions`, `-finline-small-functions` (included in `-O2`) and 
so on.

-- 
Best regards,
Andrey Tarasevich

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

#82803

On 17/01/2022 19:24, Andrey Tarasevich wrote:
> On 1/17/2022 4:55 AM, Juha Nieminen wrote:
>> Alf P. Steinbach <alf.p.steinbach@gmail.com> wrote:
>>> Some years ago g++ treated `inline` as an almost absolute inlining
>>> directive.
>>
>> Does anyone have a reference or documentation that shows that compilers
>> like gcc, clang, icc and Visual Studio behave differently with respect
>> to inlining a function depending on whether the function has been marked
>> as 'inline' or not?
>>
> 
> Depends on the compiler settings. "By default" GCC considers for
> inlining only those functions that are explicitly declared `inline`.
> 
> In order to inline something else one'd need to enable
> `-finline-functions-called-once` (included in `-O1`),
> `-finline-functions`, `-finline-small-functions` (included in `-O2`) and
> so on.
> 

The manual is a bit inconsistent here.  Under optimisation options, it
says you need "-fno-inline" to turn off inlining of functions declared
"inline".  Under "An Inline Function is As Fast As a Macro", it says
that no functions are inlined if optimisation is not enabled.

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

#82766

Am 13.01.2022 um 08:00 schrieb Juha Nieminen:

> 'inline' is an instruction for the linker because it instructs the linker
> to do something special with that function signature. ...

If you don't use link-time compiling the linker doesn't even see the
inline-function.

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

#82770

On 1/13/2022 2:08 AM, Bonita Montero wrote:
> Am 13.01.2022 um 08:00 schrieb Juha Nieminen:
> 
>> 'inline' is an instruction for the linker because it instructs the linker
>> to do something special with that function signature. ...
> 
> If you don't use link-time compiling the linker doesn't even see the
> inline-function.
> 

Not true.

Whether the linker sees or doesn't see inline functions is unpredictable 
(and therefore irrelevant). And inline function still has external 
linkage, unless explicit steps are taken to give it internal linkage.

If the compiler decides to generate a regular body for an inline 
function (e.g. because it decided to implement some call sites in this 
TU as regular calls, because address of the function is taken, or simply 
because it felt like it), the linker _will_ definitely see the generated 
function body, just like for any other functions.

And this is actually the purpose of `inline` keyword: tell the linker 
that if it encounters _multiple_ regular bodies of the same inline 
function, it has to discard all but one of them (instead of complaining).

-- 
Best regards,
Andrey Tarasevich

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

#82767

12.01.2022 18:34 Muttley@dastardlyhq.com kirjutas:
> I'm curious as to why returning a reference to a local inside an inline
> function isn't (apparently) allowed. eg:
> 
> #include <iostream>
> #include <string>
> 
> using namespace std;
> 
> inline string &func()
> {
>          string s = "hello";
>          return s;
> }
> 
> 
> 
> int main()
> {
>          cout << func() << endl;
>          return 0;
> }
> 
> This causes a compilation warning with clang and when run prints out garbage
> as you'd expect if it were a non inline. However surely if the function is
> truly inline it should work. Are locals for inlines temporaries created on the
> heap instead of being stored on the same stack as the calling function locals?

Declaring a function inline does not change the semantics of the 
function. In particular, it must not change the lifetime of objects. 
Imagine a RAII mutex lock like std::lock_guard, extending its lifetime 
without programmer's consent might be disastrous.

So even if the function really gets inlined, the compiler must ensure 
the locals are destroyed at exactly the same moment as without inline.

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

#82768

On Thu, 13 Jan 2022 12:46:39 +0200
Paavo Helde <eesnimi@osa.pri.ee> wrote:
>12.01.2022 18:34 Muttley@dastardlyhq.com kirjutas:
>> I'm curious as to why returning a reference to a local inside an inline
>> function isn't (apparently) allowed. eg:
>> 
>> #include <iostream>
>> #include <string>
>> 
>> using namespace std;
>> 
>> inline string &func()
>> {
>>          string s = "hello";
>>          return s;
>> }
>> 
>> 
>> 
>> int main()
>> {
>>          cout << func() << endl;
>>          return 0;
>> }
>> 
>> This causes a compilation warning with clang and when run prints out garbage
>> as you'd expect if it were a non inline. However surely if the function is
>> truly inline it should work. Are locals for inlines temporaries created on
>the
>> heap instead of being stored on the same stack as the calling function
>locals?
>
>Declaring a function inline does not change the semantics of the 
>function. In particular, it must not change the lifetime of objects. 
>Imagine a RAII mutex lock like std::lock_guard, extending its lifetime 
>without programmer's consent might be disastrous.

Good point.

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

#82769

On 1/12/2022 8:34 AM, Muttley@dastardlyhq.com wrote:
> I'm curious as to why returning a reference to a local inside an inline
> function isn't (apparently) allowed. eg:
> 
> #include <iostream>
> #include <string>
> 
> using namespace std;
> 
> inline string &func()
> {
>          string s = "hello";
>          return s;
> }
> 
> 
> 
> int main()
> {
>          cout << func() << endl;
>          return 0;
> }
> 
> This causes a compilation warning with clang and when run prints out garbage
> as you'd expect if it were a non inline. However surely if the function is
> truly inline it should work. 

Um... You are seriously confused. This is a rather widespread 
misconception that keyword `inline` has something to do with "inlining" 
function code at the call site.

1. "Declaring function as inline" and "embedding (inlining) function 
code at a specific call site" are two completely different, independent, 
unrelated things. In your example you simply declared a function as 
`inline`, yet in your post you seem to be talking about embedding at a 
specific call site. This makes no sense at all.

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. By using `inline` you can provide multiple definitions of 
functions (or variables) in your program and still not get those 
"multiple definitions" complaints from the linker. That's the only thing 
keyword `inline` does. That's what it is for.

3. Compiler decisions about embedding function code at a specific call 
site is made independently at each call site. These decisions are not in 
any way related to keyword `inline`. Even when a specific calls is 
embedded, it still preserves the "normal" unembedded semantics of the 
call. Local variables are destroyed at the same spot as they would be 
destroyed in a normal call. You can't return references to automatic 
variables from functions, period.

So, again, you seem to be mixing to completely unrelated matters. Don't 
do this.

> Are locals for inlines temporaries created on the
> heap instead of being stored on the same stack as the calling function locals?

Strange question. Yes, they _are_ stored on the same stack. But why does 
it matter? The language says that automatic variables are gone once the 
function finishes working. That's all you need to know. Especially when 
it comes to such non-trivial objects as `std::string`, whose lifetime is 
not really limited by storage duration, but rather by 
construction/destruction timeline.

-- 
Best regards,
Andrey Tarasevich

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

#82771

On Thu, 13 Jan 2022 17:51:45 -0800
Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>On 1/12/2022 8:34 AM, Muttley@dastardlyhq.com wrote:
>> I'm curious as to why returning a reference to a local inside an inline
>> function isn't (apparently) allowed. eg:
>> 
>> #include <iostream>
>> #include <string>
>> 
>> using namespace std;
>> 
>> inline string &func()
>> {
>>          string s = "hello";
>>          return s;
>> }
>> 
>> 
>> 
>> int main()
>> {
>>          cout << func() << endl;
>>          return 0;
>> }
>> 
>> This causes a compilation warning with clang and when run prints out garbage
>> as you'd expect if it were a non inline. However surely if the function is
>> truly inline it should work. 
>
>Um... You are seriously confused. This is a rather widespread 
>misconception that keyword `inline` has something to do with "inlining" 
>function code at the call site.
>
>1. "Declaring function as inline" and "embedding (inlining) function 
>code at a specific call site" are two completely different, independent, 
>unrelated things. In your example you simply declared a function as 

Wikipedia says otherwise:

https://en.wikipedia.org/wiki/Inline_function

"It serves as a compiler directive that suggests (but does not require) that 
the compiler substitute the body of the function inline by performing inline 
expansion, i.e. by inserting the function code at the address of each function 
call,"

Perhaps you're the one who's getting confused?

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

#82772

On Friday, 14 January 2022 at 13:22:31 UTC+2, Mut...@dastardlyhq.com wrote:
> On Thu, 13 Jan 2022 17:51:45 -0800 
> Andrey Tarasevich <andreyta...@hotmail.com> wrote: 
> >On 1/12/2022 8:34 AM, Mut...@dastardlyhq.com wrote: 
> >> I'm curious as to why returning a reference to a local inside an inline 
> >> function isn't (apparently) allowed. eg: 
> >> 
> >> #include <iostream> 
> >> #include <string> 
> >> 
> >> using namespace std; 
> >> 
> >> inline string &func() 
> >> { 
> >> string s = "hello"; 
> >> return s; 
> >> } 
> >> 
> >> 
> >> 
> >> int main() 
> >> { 
> >> cout << func() << endl; 
> >> return 0; 
> >> } 
> >> 
> >> This causes a compilation warning with clang and when run prints out garbage 
> >> as you'd expect if it were a non inline. However surely if the function is 
> >> truly inline it should work. 
> > 
> >Um... You are seriously confused. This is a rather widespread 
> >misconception that keyword `inline` has something to do with "inlining" 
> >function code at the call site. 
> > 
> >1. "Declaring function as inline" and "embedding (inlining) function 
> >code at a specific call site" are two completely different, independent, 
> >unrelated things. In your example you simply declared a function as
> Wikipedia says otherwise: 
> 
> https://en.wikipedia.org/wiki/Inline_function 
> 
> "It serves as a compiler directive that suggests (but does not require) that 
> the compiler substitute the body of the function inline by performing inline 
> expansion, i.e. by inserting the function code at the address of each function 
> call," 
> 
> Perhaps you're the one who's getting confused?

Wikipedia is (in kind of populist/politician manner) saying very same thing
that Andrey said. Read the Wikipedia article carefully (and as whole). 
Does the sentence you quoted say that functions that you have declared
inline will be inlined, ever?

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

#82775

On 1/14/2022 1:02 PM, Öö Tiib wrote:
> On Friday, 14 January 2022 at 13:22:31 UTC+2, Mut...@dastardlyhq.com wrote:
>> On Thu, 13 Jan 2022 17:51:45 -0800
>> Andrey Tarasevich <andreyta...@hotmail.com> wrote:
>>> On 1/12/2022 8:34 AM, Mut...@dastardlyhq.com wrote:
>>>> I'm curious as to why returning a reference to a local inside an inline
>>>> function isn't (apparently) allowed. eg:
>>>>
>>>> #include <iostream>
>>>> #include <string>
>>>>
>>>> using namespace std;
>>>>
>>>> inline string &func()
>>>> {
>>>> string s = "hello";
>>>> return s;
>>>> }
>>>>
>>>>
>>>>
>>>> int main()
>>>> {
>>>> cout << func() << endl;
>>>> return 0;
>>>> }
>>>>
>>>> This causes a compilation warning with clang and when run prints out garbage
>>>> as you'd expect if it were a non inline. However surely if the function is
>>>> truly inline it should work.
>>>
>>> Um... You are seriously confused. This is a rather widespread
>>> misconception that keyword `inline` has something to do with "inlining"
>>> function code at the call site.
>>>
>>> 1. "Declaring function as inline" and "embedding (inlining) function
>>> code at a specific call site" are two completely different, independent,
>>> unrelated things. In your example you simply declared a function as
>> Wikipedia says otherwise:
>>
>> https://en.wikipedia.org/wiki/Inline_function
>>
>> "It serves as a compiler directive that suggests (but does not require) that
>> the compiler substitute the body of the function inline by performing inline
>> expansion, i.e. by inserting the function code at the address of each function
>> call,"
>>
>> Perhaps you're the one who's getting confused?
> 
> Wikipedia is (in kind of populist/politician manner) saying very same thing
> that Andrey said. Read the Wikipedia article carefully (and as whole).
> Does the sentence you quoted say that functions that you have declared
> inline will be inlined, ever?
> 

Moreover, if someone wants to learn programming from Wikipedia, good 
luck to them. But don't expect me to trust their code.

James Kuyper gave very clear explanations of the OP's mistake.

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

#82778

On Fri, 14 Jan 2022 17:30:37 +0100
Manfred <invalid@invalid.add> wrote:
>On 1/14/2022 1:02 PM, Öö Tiib wrote:
>> On Friday, 14 January 2022 at 13:22:31 UTC+2, Mut...@dastardlyhq.com wrote:
>>> On Thu, 13 Jan 2022 17:51:45 -0800
>>> Andrey Tarasevich <andreyta...@hotmail.com> wrote:
>>>> On 1/12/2022 8:34 AM, Mut...@dastardlyhq.com wrote:
>>>>> I'm curious as to why returning a reference to a local inside an inline
>>>>> function isn't (apparently) allowed. eg:
>>>>>
>>>>> #include <iostream>
>>>>> #include <string>
>>>>>
>>>>> using namespace std;
>>>>>
>>>>> inline string &func()
>>>>> {
>>>>> string s = "hello";
>>>>> return s;
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> int main()
>>>>> {
>>>>> cout << func() << endl;
>>>>> return 0;
>>>>> }
>>>>>
>>>>> This causes a compilation warning with clang and when run prints out
>garbage
>>>>> as you'd expect if it were a non inline. However surely if the function is
>
>>>>> truly inline it should work.
>>>>
>>>> Um... You are seriously confused. This is a rather widespread
>>>> misconception that keyword `inline` has something to do with "inlining"
>>>> function code at the call site.
>>>>
>>>> 1. "Declaring function as inline" and "embedding (inlining) function
>>>> code at a specific call site" are two completely different, independent,
>>>> unrelated things. In your example you simply declared a function as
>>> Wikipedia says otherwise:
>>>
>>> https://en.wikipedia.org/wiki/Inline_function
>>>
>>> "It serves as a compiler directive that suggests (but does not require) that
>
>>> the compiler substitute the body of the function inline by performing inline
>
>>> expansion, i.e. by inserting the function code at the address of each
>function
>>> call,"
>>>
>>> Perhaps you're the one who's getting confused?
>> 
>> Wikipedia is (in kind of populist/politician manner) saying very same thing
>> that Andrey said. Read the Wikipedia article carefully (and as whole).
>> Does the sentence you quoted say that functions that you have declared
>> inline will be inlined, ever?
>> 
>
>Moreover, if someone wants to learn programming from Wikipedia, good 
>luck to them. But don't expect me to trust their code.

Wikipedia tends to range from the uselessly sparse to the uselessly complex.
The article on discrete fourier transforms for example is pages of dense
mathematics probably written by post grad students or lecturers trying to 
out-do each other in how obtuse they can be. I wrote an implementation in C
including comments that was 20 lines of code. Go figure.

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

#82776

On Fri, 14 Jan 2022 04:02:21 -0800 (PST)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Friday, 14 January 2022 at 13:22:31 UTC+2, Mut...@dastardlyhq.com wrote:
>> On Thu, 13 Jan 2022 17:51:45 -0800 
>> Andrey Tarasevich <andreyta...@hotmail.com> wrote: 
>> >On 1/12/2022 8:34 AM, Mut...@dastardlyhq.com wrote: 
>> >> I'm curious as to why returning a reference to a local inside an inline 
>> >> function isn't (apparently) allowed. eg: 
>> >> 
>> >> #include <iostream> 
>> >> #include <string> 
>> >> 
>> >> using namespace std; 
>> >> 
>> >> inline string &func() 
>> >> { 
>> >> string s = "hello"; 
>> >> return s; 
>> >> } 
>> >> 
>> >> 
>> >> 
>> >> int main() 
>> >> { 
>> >> cout << func() << endl; 
>> >> return 0; 
>> >> } 
>> >> 
>> >> This causes a compilation warning with clang and when run prints out
>garbage 
>> >> as you'd expect if it were a non inline. However surely if the function
>is 
>> >> truly inline it should work. 
>> > 
>> >Um... You are seriously confused. This is a rather widespread 
>> >misconception that keyword `inline` has something to do with "inlining" 
>> >function code at the call site. 
>> > 
>> >1. "Declaring function as inline" and "embedding (inlining) function 
>> >code at a specific call site" are two completely different, independent, 
>> >unrelated things. In your example you simply declared a function as
>> Wikipedia says otherwise: 
>> 
>> https://en.wikipedia.org/wiki/Inline_function 
>> 
>> "It serves as a compiler directive that suggests (but does not require) that 
>
>> the compiler substitute the body of the function inline by performing inline 
>
>> expansion, i.e. by inserting the function code at the address of each
>function 
>> call," 
>> 
>> Perhaps you're the one who's getting confused?
>
>Wikipedia is (in kind of populist/politician manner) saying very same thing
>that Andrey said. Read the Wikipedia article carefully (and as whole). 
>Does the sentence you quoted say that functions that you have declared
>inline will be inlined, ever?

What do you think "inserting the function code at the address of each
function call" means?

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

#82780

On Friday, 14 January 2022 at 18:40:41 UTC+2, Mut...@dastardlyhq.com wrote:
> On Fri, 14 Jan 2022 04:02:21 -0800 (PST) 
> =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote: 
> >On Friday, 14 January 2022 at 13:22:31 UTC+2, Mut...@dastardlyhq.com wrote: 
> >> On Thu, 13 Jan 2022 17:51:45 -0800 
> >> Andrey Tarasevich <andreyta...@hotmail.com> wrote: 
> >> >On 1/12/2022 8:34 AM, Mut...@dastardlyhq.com wrote: 
> >> >> I'm curious as to why returning a reference to a local inside an inline 
> >> >> function isn't (apparently) allowed. eg: 
> >> >> 
> >> >> #include <iostream> 
> >> >> #include <string> 
> >> >> 
> >> >> using namespace std; 
> >> >> 
> >> >> inline string &func() 
> >> >> { 
> >> >> string s = "hello"; 
> >> >> return s; 
> >> >> } 
> >> >> 
> >> >> 
> >> >> 
> >> >> int main() 
> >> >> { 
> >> >> cout << func() << endl; 
> >> >> return 0; 
> >> >> } 
> >> >> 
> >> >> This causes a compilation warning with clang and when run prints out 
> >garbage 
> >> >> as you'd expect if it were a non inline. However surely if the function 
> >is 
> >> >> truly inline it should work. 
> >> > 
> >> >Um... You are seriously confused. This is a rather widespread 
> >> >misconception that keyword `inline` has something to do with "inlining" 
> >> >function code at the call site. 
> >> > 
> >> >1. "Declaring function as inline" and "embedding (inlining) function 
> >> >code at a specific call site" are two completely different, independent, 
> >> >unrelated things. In your example you simply declared a function as 
> >> Wikipedia says otherwise: 
> >> 
> >> https://en.wikipedia.org/wiki/Inline_function 
> >> 
> >> "It serves as a compiler directive that suggests (but does not require) that 
> > 
> >> the compiler substitute the body of the function inline by performing inline 
> > 
> >> expansion, i.e. by inserting the function code at the address of each 
> >function 
> >> call," 
> >> 
> >> Perhaps you're the one who's getting confused? 
> > 
> >Wikipedia is (in kind of populist/politician manner) saying very same thing 
> >that Andrey said. Read the Wikipedia article carefully (and as whole). 
> >Does the sentence you quoted say that functions that you have declared 
> >inline will be inlined, ever?
> What do you think "inserting the function code at the address of each 
> function call" means?

That means inlining. Does "suggests (but does not require) inlining" mean
that it will be inlined?

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web