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 16:16:02 +0200
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.


Received on 2023-05-05 14:16:05