Pointer Casting

0) No, probably not FB material. But for future reference, FB isn't games-specific.

1) The 'i_' tag usually indicates an interface. Usually, interfaces are more likely to be bases than derived classes. You might be doing something a bit strange.

2) Why does plugin x need to *know* it has a plugin_ba? If it's calling an API that gives back a root, it should normally be because it only requires the root-like behaviour of the received plugin (even if it happens to be a plugin_ba).

3) Assuming you can't get around that (and it's common enough that you can't; I imagine that working with DLLs makes it considerably trickier), dynamic_cast is indeed appropriate. The compiler typically suggests reinterpret_cast for things because it's the easiest suggestion to make (it will more or less always compile, but isn't necessarily safe).

4) Casting down the hierarchy is not "safe" in the sense that Bad Things(TM) can happen when the thing isn't actually of the type you "know" it to be. With static_cast or reinterpret_cast (or a C-style cast), that typically produces undefined behaviour. With dynamic_cast, it produces a null pointer. So all you have to do is *check* for a null pointer:

root* thing = callAPI();if (plugin_ba* ba = dynamic_cast<plugin_ba*>(thing)) {  ba->doSomething();} else {  // it's not a plugin_ba; handle the error}

You can also dynamic_cast references. Because there is no such thing as a "null reference", dynamic_cast will instead throw an exception (std::bad_cast) in cases where a reference cast is found at runtime to be invalid.

Much appreciated, that looks to answer my question about both safety and the casting.

The system I am building is similar to eclipse (but with a c++ code base rather than java), the core modules that I construct can easily know about each other however the user constructed modules I need to handle could be almost anything however are all derived from my root interface.

The root interface provides almost no functionality other than name, author etc and an initialise method to let the loaded plugin know about the registry, however the plugins need to be able to convert these root pointers into actual class pointers so that they can use the functionality of the low level classes.

The plugins were all tagged at i_ as each class provides an interface to itself (abstract base class with purely virtual methods) to allow replacement of underlying usage and easy intergration of new modules (just be aware of the existance of the interface not the specific dll implementing it).

So basically the modules I build need to work on only the root pointers for storage / passing but the low level ones need to convert to proper interfaces... much conversion and confusion all round!