C++ Logo


Advanced search

Re: [std-proposals] Drop same sequence of tokens for inline

From: Alejandro Colomar <alx.manpages_at_[hidden]>
Date: Fri, 5 May 2023 02:07:38 +0200

On 5/4/23 21:24, Tom Honermann via Std-Proposals wrote:
> On 5/4/23 1:11 PM, sasho648 via Std-Proposals wrote:
>> So why does inline functions need to have the same sequence of tokens
>> in different TU - imagine in a TU there is a preprocessor define that
>> changes the function definition - it would make sense this not to be UB.
>> In C inline functions have internal linkage - it would make the same
>> sense for C++.

What? C inline functions have the same linkage as any other function:
external by default; internal if you use 'static'.

Here's how you should use inline in C:

// foo.h:
inline int
 return 42;

// foo.c:
extern inline int foo(void);

Here's a great description of how C inline works:

>> Like I don't see a reason requiring inline functions to have the same
>> body - regardless of the statement above.
> 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.

I don't remember all the details of C++'s inline (and they were always
blurry to me, compared to the clear model of C, where the programmer
has more control/understanding of what happens), but IIRC, each TU that
sees the inline function _and_ has a use that's not inlined emits a weak
symbol, so that the linker chooses one of them.

However, as long as the contents are reasonably compatible, I don't see
why it would be problematic. Requiring a token-per-token copy probably
was more preventing programmers doing stupid things than a real need.

Maybe unspecified behavior instead of undefined behavior could be


> Tom.

Received on 2023-05-05 00:07:41