Date: Fri, 17 Apr 2026 11:39:20 +0800 (CST)
At 2026-04-15 22:07:49, "Thiago Macieira" <thiago_at_[hidden]> wrote:
>On Wednesday, 15 April 2026 05:46:02 Pacific Daylight Time Zhao YunShan wrote:
>> 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?
>
>Because those add sufficient new functionality or make some coding tasks
>sufficiently easier or other qualitative adjectives to be worth the cost. The
>problems they are solving are sufficiently common.
Because Interceptors add a critical capability and make coding tasks -- such as hooking, stubbing, tracing, and auto-locking -- sufficiently easier, alongside other qualitative advantages. The problems Interceptor is solving are sufficiently common.
>
>I'm not arguing against adding any new features to the Standard. I am asking
>why *this* one is worth it.
Why did the US send astronauts to the Moon? Why is Musk sending humans to Mars? Why does NASA launch so many satellites? These projects cost a fortune, yet they bring little tangible economic benefit. So, were they worth it?
And you shouldn't be asking me this. You should ask the Java and Python developers¡ªask them if Interceptors are worth it.
Stop asking such subjective questions to anyone, anywhere, anytime. It's completely meaningless.
>
>> >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?
>
>Because code that is already compiled will never call these interceptor
>functions. So you have some callers calling the new functions and some not
>doing so.
>
>--
>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>On Wednesday, 15 April 2026 05:46:02 Pacific Daylight Time Zhao YunShan wrote:
>> 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?
>
>Because those add sufficient new functionality or make some coding tasks
>sufficiently easier or other qualitative adjectives to be worth the cost. The
>problems they are solving are sufficiently common.
Because Interceptors add a critical capability and make coding tasks -- such as hooking, stubbing, tracing, and auto-locking -- sufficiently easier, alongside other qualitative advantages. The problems Interceptor is solving are sufficiently common.
>
>I'm not arguing against adding any new features to the Standard. I am asking
>why *this* one is worth it.
Why did the US send astronauts to the Moon? Why is Musk sending humans to Mars? Why does NASA launch so many satellites? These projects cost a fortune, yet they bring little tangible economic benefit. So, were they worth it?
And you shouldn't be asking me this. You should ask the Java and Python developers¡ªask them if Interceptors are worth it.
Stop asking such subjective questions to anyone, anywhere, anytime. It's completely meaningless.
>
>> >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?
>
>Because code that is already compiled will never call these interceptor
>functions. So you have some callers calling the new functions and some not
>doing so.
>
>--
>Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-04-17 03:39:27