Overriding the CRT's implementation of _purecall

I'm currently working on a DLL that is an extension to a closed, working project.

I want to catch every pure-call bug, so I googled it up and found out about the _purecall handler. My question is about it's implementation. What's happening behind the scenes? The compiler itself takes my handler function address(if I defined one) and writes it a default value to each row in the v-table before it gets overridden by the class function address itself(after initialization), or it something more complex, involving the CRT and global pointers?

I'm asking this because I don't want my plugin DLL to overwrite the whole application _pu开发者_开发问答recall handlers, of course. Can I be sure that my purecall handler will handle only purecalls in my module?

Thanks!

---

The answer depends heavily on how your compiler implements the purecall handler. If the compiler simply replaces the "pure" function pointers in your virtual function tables, then you're safe from modifying the parent process behaviour.

But some compilers implement custom purecall handlers by calling your handler from the CRT's handler. In this case, the behaviour will depend on how you've built your DLL. If you've statically linked to the CRT, then your DLL will have its own instance of all CRT state. In this case, the compiler implementation is irrelevant. Your purecall handler will not interfere with the parent process.

On the other hand, if you've dynamically linked to the CRT, the behaviour will depend on how the host process was built. If it was dynamically linked to the same version of the CRT as your DLL, then your purecall handler could indeed interfere. But once again, this depends on the compiler implementation. Even if it's calling your hook from the CRT, you could be safe if the CRT maintains different hooks for each module.

In any case, if you want to be safe for sure then you must either statically link your DLL to the CRT or avoid using the purecall handler (an alternative would be to use concrete base classes instead of abstract ones).