Date: Fri, 17 Apr 2026 10:02:11 -0700
On Friday, 17 April 2026 03:43:00 Pacific Daylight Time Zhao YunShan wrote:
> > - it is a static facility, many would prefer runtime configuration
>
> That's another subjective assertion. Being able to implement both static and
> runtime features is progress. Use whichever you prefer.
This was direct feedback consequence of how you described the feature syntax:
there was no way to intercept at runtime, if the compiler didn't see the
declaration.
This is why you must write the paper. It's not clear how it's going to work.
You may have thought of things that you didn't express well in the email and
thus the rest of us are only seeing a limited subset of the capability.
> Reflection is less efficient than Interceptors. By the way, we are
> discussing Interceptors, so why did you bring up Reflection? It feels like
> you're not really familiar with either of them.
Why are they less efficient? Reflection happens entirely at compile time, so it's
as efficient as any compiled code can be, including inlining. Interception can't
catch inlined calls, because they have been inlined.
The reason Sebastian brought this up is that one typical case of
"interception" is to create mock classes for testing, so one can verify that
the right functions are called, the expected arguments are passed,
preconditions and postcondition are met, etc. Having the ability to reflect an
existing class and automatically create a mock would be extremely useful.
And yet this is not always possible to do, if one can't replace the class that
is being called, buried deep inside layers of code. Intercepting the class at
runtime would be useful.
> > - they may badly interact with libraries
>
> Function calls within a single thread are executed sequentially, unless the
> code written in the Interceptors has bugs or serious logic issues.
What do threads have to do with libraries here? The point was that libraries
already compiled are calling functions that they are calling. Without
recompilation, they will not see the interception described in C++ - see the
point above about how this is a consequence of how you described the feature.
To intercept already-compiled and in particular already-linked code, you need
a different construct, or at the very minimum help from the dynamic linker and
a delineation of the limitations of where this would apply.
> > - it is a static facility, many would prefer runtime configuration
>
> That's another subjective assertion. Being able to implement both static and
> runtime features is progress. Use whichever you prefer.
This was direct feedback consequence of how you described the feature syntax:
there was no way to intercept at runtime, if the compiler didn't see the
declaration.
This is why you must write the paper. It's not clear how it's going to work.
You may have thought of things that you didn't express well in the email and
thus the rest of us are only seeing a limited subset of the capability.
> Reflection is less efficient than Interceptors. By the way, we are
> discussing Interceptors, so why did you bring up Reflection? It feels like
> you're not really familiar with either of them.
Why are they less efficient? Reflection happens entirely at compile time, so it's
as efficient as any compiled code can be, including inlining. Interception can't
catch inlined calls, because they have been inlined.
The reason Sebastian brought this up is that one typical case of
"interception" is to create mock classes for testing, so one can verify that
the right functions are called, the expected arguments are passed,
preconditions and postcondition are met, etc. Having the ability to reflect an
existing class and automatically create a mock would be extremely useful.
And yet this is not always possible to do, if one can't replace the class that
is being called, buried deep inside layers of code. Intercepting the class at
runtime would be useful.
> > - they may badly interact with libraries
>
> Function calls within a single thread are executed sequentially, unless the
> code written in the Interceptors has bugs or serious logic issues.
What do threads have to do with libraries here? The point was that libraries
already compiled are calling functions that they are calling. Without
recompilation, they will not see the interception described in C++ - see the
point above about how this is a consequence of how you described the feature.
To intercept already-compiled and in particular already-linked code, you need
a different construct, or at the very minimum help from the dynamic linker and
a delineation of the limitations of where this would apply.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-04-17 17:02:17
