On 5/4/23 8:07 PM, Alejandro Colomar wrote:
>>> 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.
Yes, that is a common implementation strategy.
> 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
> reasonable.

Not from the point of the standard since defining "reasonably
compatible" would be ... challenging. Also, unspecified behavior is
usually used within the standard to allow an implementation to select
from a set of options.

What problem would be solved by changing the standard? What would you be
able to do that you can't do today?

Tom.

>
> Cheers,
> Alex
>
>> Tom.
>>