Date: Wed, 15 Apr 2026 15:57:59 +0200
On 4/15/26 14:46, Zhao YunShan via Std-Proposals wrote:
>
> At 2026-04-15 01:00:42, "Thiago Macieira" <thiago_at_[hidden]> wrote:
>>On Tuesday, 14 April 2026 06:31:22 Pacific Daylight Time Zhao YunShan via Std-
>>Proposals wrote:
>>> First, replacing function symbol at link time is a proven approach; g++
>>> --wrap has been doing this for years. Promoting this compiler flag feature
>>> to a native language feature would enhance code readability and make it
>>> effortless for developers to apply. Why not do it?
>>
>>Why does it have to be a *Standard* feature? I'm not doubting the usefulness,
>>I'm just asking whether it needs to be in the Standard.
> If you're asking whether it's mandatory to add Interceptors to the C++ standard, the answer is definitely no.
> But I have a question for you in return:
> C can technically achieve everything C++ does, so why is C++ considered necessary?
> C++98 can do everything C++11 does, so why do we even need C++1x, C++2x, and beyond?
Every feature added to the standard comes with a cost: The cost of discussing
the proposal, the cost of reviewing the wording, the cost of updating the LaTeX
source with the approved wording, the cost of implementing the feature in all
compilers, the cost of maintenance etc.
For every single feature, WG21 (the C++ standardization committee) needs to
have a clear picture about the use-cases and benefits of a feature that
would offset its inherent cost.
Anything that needs more support from the linker needs to be treated
super-carefully; there are plenty of (possibly niche) platforms that
are non-Windows, non-Linux, and non-MacOS.
Of course, at the end of the day, whether a given feature provides
enough bang-for-the-buck is a rather subjective judgment call, but
a proposal wishing to survive needs to present both the "bang" part
and the cost part as transparently as possible, to enable everybody
to make an informed judgment call.
>>See also Sebastian's reply, showing there are different interception techniques
>>for different conditions, none of which the Standard is aware of. There's no
>>way to have a *single* native language feature that will work for all of those
>>conditions. So is it worth standardising one way of interception that doesn't
>>always work?
>
> The solutions I proposed are all implemented purely at the language code level (except for the process of swapping function symbols/names, but I assume that isn't too difficult). If older compilers support this code, why would the differences in OS linking methods you mentioned even come into play?
Having an actual implementation (not an assumption of "isn't too difficult")
helps, too.
Jens
>
> At 2026-04-15 01:00:42, "Thiago Macieira" <thiago_at_[hidden]> wrote:
>>On Tuesday, 14 April 2026 06:31:22 Pacific Daylight Time Zhao YunShan via Std-
>>Proposals wrote:
>>> First, replacing function symbol at link time is a proven approach; g++
>>> --wrap has been doing this for years. Promoting this compiler flag feature
>>> to a native language feature would enhance code readability and make it
>>> effortless for developers to apply. Why not do it?
>>
>>Why does it have to be a *Standard* feature? I'm not doubting the usefulness,
>>I'm just asking whether it needs to be in the Standard.
> If you're asking whether it's mandatory to add Interceptors to the C++ standard, the answer is definitely no.
> But I have a question for you in return:
> C can technically achieve everything C++ does, so why is C++ considered necessary?
> C++98 can do everything C++11 does, so why do we even need C++1x, C++2x, and beyond?
Every feature added to the standard comes with a cost: The cost of discussing
the proposal, the cost of reviewing the wording, the cost of updating the LaTeX
source with the approved wording, the cost of implementing the feature in all
compilers, the cost of maintenance etc.
For every single feature, WG21 (the C++ standardization committee) needs to
have a clear picture about the use-cases and benefits of a feature that
would offset its inherent cost.
Anything that needs more support from the linker needs to be treated
super-carefully; there are plenty of (possibly niche) platforms that
are non-Windows, non-Linux, and non-MacOS.
Of course, at the end of the day, whether a given feature provides
enough bang-for-the-buck is a rather subjective judgment call, but
a proposal wishing to survive needs to present both the "bang" part
and the cost part as transparently as possible, to enable everybody
to make an informed judgment call.
>>See also Sebastian's reply, showing there are different interception techniques
>>for different conditions, none of which the Standard is aware of. There's no
>>way to have a *single* native language feature that will work for all of those
>>conditions. So is it worth standardising one way of interception that doesn't
>>always work?
>
> The solutions I proposed are all implemented purely at the language code level (except for the process of swapping function symbols/names, but I assume that isn't too difficult). If older compilers support this code, why would the differences in OS linking methods you mentioned even come into play?
Having an actual implementation (not an assumption of "isn't too difficult")
helps, too.
Jens
Received on 2026-04-15 13:58:02