On Tuesday, April 28, 2026, Jonathan Wakely  wrote:


The interceptor is declared as void, but it actually returns whatever the 'goto' statement returns? Why not declare it as auto or decltype(auto)?



An interceptor function doesn't return. It jumps.

Yes under the hood I have implemented it as two separate functions, a core and a thunk, and the core returns a value to the thunk, but that's all secretive under the hood stuff specific to my GNU patch. The guys at Microsoft or Embarcadero (formerly Borland) might just make it one function. I could have made it be just one function -- and actually I bet I could feed my entire compiler patch into ChatGPT and ask it to make that adjustment, and it might even get it right the first time or 2nd or 3rd time. I like the simplicity though of my implementation.

As far as the C++ programmer is concerned though, the inceptor function just jumps to another function -- and I thought the simplest way to express this would be to give it the signature "void Func(void)" and to use the syntax "goto ->".


 
This is horrible. Why would I ever want to write this? You have to name std::printf inside the interceptor, *and* cast its type to std::printf when you use it? That's horrible.
<snip> 

Why is this horribleness better than just wrapping std::printf in a lambda?
<snip>
 
What's the benefit of your interceptor?



I agree with you on all counts . . . a template lambda with a forwarding parameter pack is supreme over an interceptor function in every way -- including aesthetic horridness and horribleness -- except in cases where you don't know (or don't care about) the signature of the target function... or if you want to write one interceptor which can be used with many different target function signatures.

If you want to be agnostic to the target function signature, you must preserve the stack and all registers that might be used for passing arguments. That's exactly what my interceptor does.

An interceptor will be very useful when dealing with pre-compiled proprietary libraries (for which you don't have the source code or even a header file), and also for dealing with other languages such as Haskell.