plugin system implementation : dynamic_cast through invisible classes

[typograph]

Hello,

I've been writing a program, which works with some special type of files : namely files, containing "pages". Since there are several formats for that type of things, and I'm not likely to know all, I wanted to make the program extensible through external plugins (in shared libraries).

I decided that a plugin will return a pointer to a "general file" object, which, in turn, will contain some "general pages". There are several distinct possible types of pages, so those are declared as interfaces. So (in principle) a plugin would subclass "general page", and then subclass that one with specific intefaces, like:

class SpecialPage : public GeneralPage;
class SpecialPageType1 : public SpecialPage, public Type1;
class SpecialPageType2 : public SpecialPage, public Type2;
 

The GeneralPage contains information about the page type, but Type1 and Type2 are separate classes, to allow for the above-mentioned scheme without the "diamond" inheritance.

But now I can't make this thing work, since the following cast produces NULL

GeneralPage * page = getGeneralPage(...);
 // The function actually returns a dynamic_cast<GeneralPage*>(SpecialPage*)
if (page->type() == type1)
 Type1 * page1 = dynamic_cast<Type1*>(page);
 

The type seems to exists only in the plugin itself, and I don't seem to be able to export that one too (I'm using gcc).

So, question: am I missing something, or it is indeed not possible, and I should rethink the design?

[weaknessforcats]

GeneralPage * page = getGeneralPage(...);
// The function actually returns a dynamic_cast<GeneralPage*>(SpecialPage*)
if (page->type() == type1)
Type1 * page1 = dynamic_cast<Type1*>(page);

First things first: When you cast in C++ you are either calling a relic C function with a void* argument or your C++ design is weak.

Second: dynamic_cast requires RTTI which in turn requires the compiler to keep a database on every object with virtual functions so it knows what the real type is. This is very expensive and I advise against using this thing unless you are firefighting.

Third: dynamic cast only works with classes that have virtual functions. Otherwise, you already know the type.

Fourth: dynamic_cast will not permit unsafe casts. That is, you can cast a pointer to a derived type to a pointer to a base type but not the other way. Going the other way, the base pointer would be casted to a type that has more data and methods than the base object. Using those methods would then cause a crash. Hence, when you cast from a base pointer to a derived pointer, you always get NULL.

Have you considered:

class class SpecialPageType1 :public Type1
{
    private:
        General* theSpecialPage;
};
 

where SpecialPage : public GeneralPage ??

You could create a SpecialPage object and reference it in your SpecialPageType1 class.

If this is to be object-oriented, then all methods you execute using a SpecialPageType1 object must be Type1 methods:

GeneralPage* g = new SpecialPage;
Type1* obj = new SpecialPageType1(g);
 

and now you need no casts at all.

[RRick]

Hence, when you cast from a base pointer to a derived pointer, you always get NULL.

That's not always true. If you have a base pointer that actually points to a derived class, then you use dynamic cast to convert from a base pointer to a derived pointer. For more info, see http://en.wikipedia.org/wiki/Dynamic_cast

Dynamic_cast can deal with multiple inheritance, but there are several caveats. The "diamond" structure you talked about is one. Maybe there is a problem with interfaces, but I can't say for sure (and I don't see why).

The base class definitely needs a virtual method, and many sources stress making the base class destructor virtual. This kills two birds with one stone. You get RTTI, and you solve the splitting issues with destructors.

[weaknessforcats]

That's not always true. If you have a base pointer that actually points to a derived class,

Yes. I guess I wasn't clear about that. I was thinking of a base pointer to a base object.

[typograph]

Dynamic_cast can deal with multiple inheritance, but there are several caveats. The "diamond" structure you talked about is one. Maybe there is a problem with interfaces, but I can't say for sure (and I don't see why).

The base class definitely needs a virtual method, and many sources stress making the base class destructor virtual. This kills two birds with one stone. You get RTTI, and you solve the splitting issues with destructors.

The real problem in this case seems to be the shared library boundary. dynamic_cast fails because the typeid is unknown to it. If you compile the "SpecialPage" classes in, everything works. I tried to follow the quidelines GCC has in it's FAQ about shared libraries, but it doesn't help.

I came up with a (really dirty) workaround, where the GeneralPage class has a virtual abstract function, casting the typed base into void, that can be afterwards reinterpreted in the main program, if the page type is known. The function has, of course, to be implemented in each SpecialPageType# class. The solution works, although I don't like it too much.

Is there really no way to get RTTI information across shared library boundaries?

[typograph]

Have you considered:

class class SpecialPageType1 :public Type1
{
    private:
        General* theSpecialPage;
};
 

where SpecialPage : public GeneralPage ??

You could create a SpecialPage object and reference it in your SpecialPageType1 class.

This, unfortunately, doesn't allow me to create an array of pages, independently of their type. And if I create several arrays, I'll have poor compatibility, in case I discover later that there can be one more page type I didn't think of.

And solving the array problem by making GeneralPage a base of Type#, either leads to duplicating the common code for all SpecialPage types, or to diamond inheritance.

Maybe I'm missing some other obvious solution... I will be happy to know about such a design.