any relies on an interface with pure virtual functions. For a header-only library this does not bode well when used in a shared-library + sanitizers or other runtime instrumentation:
If a module instantiates any and sends it to another module, the typeid and vtable of obj_block will not be the same. In practice this works, because they have the same layout, but sanitizer like address or ub, and likely other runtime instrumentation will issue a warning or error that we're calling methods of module_a.so:obj_block via a pointer to module_b.so:obj_block.
Ideally we would place obj_block's vtable in a so ourselves, but this is a header-only library, so no-can't-do.
To support this, we should implement our own custom vtable, which does not contain RTTI.
anyrelies on an interface with pure virtual functions. For a header-only library this does not bode well when used in a shared-library + sanitizers or other runtime instrumentation:If a module instantiates any and sends it to another module, the typeid and vtable of
obj_blockwill not be the same. In practice this works, because they have the same layout, but sanitizer like address or ub, and likely other runtime instrumentation will issue a warning or error that we're calling methods ofmodule_a.so:obj_blockvia a pointer tomodule_b.so:obj_block.Ideally we would place
obj_block's vtable in a so ourselves, but this is a header-only library, so no-can't-do.To support this, we should implement our own custom vtable, which does not contain RTTI.