Digest for comp.lang.c++@googlegroups.com - 5 updates in 1 topic

comp.lang.c++@googlegroups.com

Google Groups

Topic digest
View all topics

• Inline functions and locals - 5 Updates

Inline functions and locals

Juha Nieminen <nospam@thanks.invalid>: Jan 13 07:00AM > 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.)

"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Jan 13 10:45AM +0100 On 13 Jan 2022 08:00, Juha Nieminen wrote:   > 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.     > 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

Bonita Montero <Bonita.Montero@gmail.com>: Jan 13 11:08AM +0100 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.

Paavo Helde <eesnimi@osa.pri.ee>: Jan 13 12:46PM +0200 > 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.

Muttley@dastardlyhq.com: Jan 13 03:38PM On Thu, 13 Jan 2022 12:46:39 +0200 >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.

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.