On 5/5/23 10:16 AM, Alejandro Colomar wrote:
> Hi Tom,
>
> On 5/5/23 08:26, Tom Honermann via Std-Proposals wrote:
>> 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?
> No, I don't really have any problems with it, and am not asking for a
> change in the standard. I was wanted to understand why C++ needs to
> make undefined behavior some things that are well-defined in C, since
> normally it's the other way around.

Inline functions in C have a restriction that is not present in C++.
 From N3096 <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf>
6.7.4p2:

    An inline definition of a function with external linkage *shall not
    contain a definition of a modifiable object with static or thread
    storage duration*, and shall not contain a reference to an
    identifier with internal linkage.

It seems C and C++ chose different tradeoffs.

Tom.

>
> Cheers,
> Alex