I'm working on my own fork of the bsnes SNES emulator to add AngelScript support to it and it's going very well so far. I'm in the midst of trying to prototype out support for defining and controlling GUI components right now. bsnes rolls their own libraries for everything including GUI components which make heavy usage of their own implementation of `shared_pointer<T>`.

I'm curious how best to integrate AngelScript's addref/release tracking system into an existing / established implementation of `shared_pointer<T>`. Perhaps others have come across this problem in their C++ code bases where they're using boost or STL shared or unique pointer? How have you solved this problem, assuming the implementation of `shared_pointer<T>` is off-limits and not modifiable?

For reference, this is the implementation of `shared_pointer<T>` in bsnes: https://github.com/JamesDunne/bsnes-angelscript/blob/master/nall/shared-pointer.hpp

You can force the compiler to generate all the desired template variations and then register those directly to the scripting engine.

For AngelScript you would register a fake shared pointer template class with no implementation and then properly register all the supported "T" types as full class specialisations.

Its probably still possible to make a generic wrapper implementation but it would not be as straight forward as the first option. most methods would end up having several runtime code paths to reinterpret something like a byte buffer into a shared pointer of void* or a shared pointer of shared_pointer_this_base*. Even then you would need to be sure that any classes deriving from shared_pointer_this_base would not generate an address offset for casting to that type.

I just went with template class specialisation when I had a similar issue :(