Hi Thiago,

On 5/4/23 21:57, Thiago Macieira via Std-Proposals wrote:
> On Thursday, 4 May 2023 12:24:47 PDT Tom Honermann via Std-Proposals wrote:
>> Taking the address of a (inline or otherwise) function in one
>> translation unit must produce a pointer equivalent to that produced in
>> another translation unit; they must both point to the same function.
>> Thus, you can't have different implementations in different translation
>> units.
>
> C solves this in a different way. In my opinion, C's inline is much more
> cumbersome and limited, but probably was required to deal with limitations of
> compilers.

C's inline is probably lighter on the linker, which needs to see only one
definition.

About it being cumbersome: you only need to stick an 'extern inline'
prototype in a TU. I wouldn't call that cumbersome.

I prefer the C inline because:

- It incentives that programmers write a 1:1 correspondence between .c and
   .h files, so code is more organized.

- You can analyze the assembler output of the compiler to see what's the
   generated code, and you know exactly where to look for it.

>
> Non-static inline functions in C that didn't get inlined place a call to an
> out-of-line copy that the compiler will not emit for you, unlike in C++. It's
> the developer's responsibility to define that. On one hand, it allows the
> developer to emit more complex but more optimised implementations for that
> case. On the other hand, that is hardly ever needed, but does require the
> emission of that out-of-line copy whether it was needed or not.

The linker can get rid of it if it was unused, if you use link-time
optimizations.

>
> If you take the address of such a function, you simply get the address of that
> out-of-line copy. Note how there's no sign of f's presence in
> https://c.godbolt.org/z/Y6a6r1j68

Since inline functions would normally be defined in header files, I would find
it noisy if my assembler files got spammed with definitions of inline functions
from some library for example.

>
> As for static variables inside inline functions, they are static and won't get
> merged across TUs. That's probably not what you want, and yet this is not ill-
> formed in C (see https://c.godbolt.org/z/Y3T7PnqKW).

Not ill-formed, but produces a warning even without enabling warnings; I would
say that's not a footgun ;). Maybe a footgun that warns you before shooting...

In fact, I got loads of warnings from a library that decided it was a good
idea to redefine memcpy(3) as a static inline function (wtf?), when I used
memcpy(3) in an inline function of mine.

<https://bugs.ruby-lang.org/issues/18893>

Note of the day: 'static' in 'static inline' still means the same as in
non-inline functions: the function has internal linkage. Nothing else.
Don't use functions with internal linkage in header files, which are by
definition non-internal. The most benign problem you can have with static
inline is bloated binaries, but it can be worse.

>
> In my opinion, C's implementation is a loaded machine gun pointing downwards
> where your feet generally are. Experts will use that well and miss shooting
> themselves in the foot, but non-experts won't. C++'s implementation is much
> nicer and safer.

Let's agree to disagree :)

Cheers,
Alex

>