static_cast interface class to internal engine implementation - c++

Question

I am developing a 3D engine, suppose I have the following interface classes:
class IA {
public:
virtual ~IA() {}
virtual void doSomething() =0;
};
class IB {
public:
virtual ~IB() {}
virtual void bindA( IA* ) =0;
};
If you want to get a hold of an object of type "IA" or "IB" you must get them from a factory that is dependent on the backend API being used (e.g OpenGL).
The function IB::bindA(IA*) needs to access data from the implementation of IA, and to achieve that it does a static_cast to the implementation class and then directly access it's elements.
I was wondering what you think of this particular use of static_cast, do you think it's bad design? or do you think it's ok?.
The engine has to provide the same interface no matter what backend API is being used, so I don't think I could achieve this using virtual functions because I can't know beforehand what is needed by IB from IA.
Thanks :D
Edit
The thing is the engine has the following two classes:
class IHardwareBuffer {
public:
virtual ~IHardwareBuffer() {}
virtual void allocate( .... ) =0;
virtual void upload( .... ) =0;
};
and
class IMesh {
public:
virtual ~IMesh() {}
virtual bindBuffer( IHardwareBuffer* ) =0;
...
};
I "could" merge the IMesh and IHardwareBuffer classes together but that wouldn't make that much sense, since HardwareBuffer is just a "dumb" piece of memory with vertex data in it, and a Mesh is one or two HardwareBuffers with other data around them, like vertex format, material and such.
Having them be separate classes allows client code to have several meshes share a common HardwareBuffer and stuff like that.

Answer 1

It seems to me, that it's actually quite a bad idea from the design point of view.
If you use interfaces (or simulate them, as C++ doesn't have such language structure), you use them to publish these data, which are needed in other places. So if an object implementing IB has to cast IA to something to retreive its data, it's clearly a sign, that either IA publishes not enough data or the object implementing IA should also implement another, wider interface.
It's hard to tell, which option is better (or maybe if there is another), because we don't know the context here. Generally casting should be avoided if really not necessary and it suraly is not necessary here.
Edit:
The engine has to provide the same interface no matter what backend API is being used, so I don't think I could achieve this using virtual functions because I can't know beforehand what is needed by IB from IA. - this is a bad design.
Engine should be written in such way, that it's completely independent of implementation using it and vice versa. This is the whole point of using interfaces, base classes and polymorphism: you should be able to write another engine, swap it with existing one and everything should work without any changes in the implementation.
Edit (in response to comments):
I think, that a lot more clear solution is to cast to another interface, rather than specific implementation, ie:
class A : public IA, public IInternalA
{
// Implementation
};
// Inside B:
void B::Process(IA * a)
{
IInternalA ia = dynamic_cast<IInternalA *>(a);
if (ia != nullptr)
// Do something
}
This way you'll still be able to cut off from the implementation (for example, you'll be able to cut it into two independent parts), but inside your engine all the classes will know enough about each other to work properly.

Answer 2

An object has dynamic type, which can be read at runtime from its vtable, and static type, which is what you declare in the source code.
To safely cast based on dynamic type, use dynamic_cast. If you already know the dynamic type without looking at the vtable, then you can optimize the dynamic_cast into a static_cast. This is may meaningfully improve performance, and there's nothing wrong with doing so, as long as it's valid.
Code which casts to derived class references too often, though, might have issues with separation of concerns. The point of class hierarchies is to generalize.
I would recommend using references, not pointers, because the reference form of dynamic_cast will throw an exception if the cast is invalid. Then you can do something like this:
// Check dynamic type (and throw exception) for debug build only
#ifndef NDEBUG
#define downcast static_cast
#else
#define downcast dynamic_cast
#endif
Iopengl &glenv = downcast< Iopengl & >( myIA );
If you always know the actual dynamic type without going to the vtable (for example a global opengl flag), then the vtable is of course redundant. You could write the whole program with flags and branches replacing virtual dispatch.
The engine has to provide the same interface no matter what backend API is being used, so I don't think I could achieve this using virtual functions because I can't know beforehand what is needed by IB from IA.
As you already said, the abstract base class provides the interface and the derived class calls the backend. Your example is a little sketchy but it looks like IA and IB are interfaces, which you must define a backend-independent way if you are going to meet your goal… regardless of implementation.

Answer 3

OK now I think I understand your problem. You have several backends which have virtually (pun) nothing in common, and you need to use them in an engine that hides their differences.
Now the thing is, if two types have nothing in common, they should not inherit from a common base. And of course hacks like storing their pointers in a void* are just sweeping the dust under the carpet. So let's not do that.
So you need to provide a wrapper for each backend. All wrappers should conform to the same interface, but have nothing in common as far as their implementations are concerned. The factory should return a wrapper.
class IBackendWrapper
{
public:
... backend pure virtual functions ...
};
class OpenGLBackendWrapper : public IBackendWrapper
{
public:
... backend virtual function immplementations in terms of OpenGL ...
private:
... OpenGL data ...
};
class X11BackendWrapper : public IBackendWrapper
{
public:
... backend virtual function immplementations in terms of X11...
private:
... X11 data ...
};
class BackendFactory
{
public:
IBackendWrapper* getbackend();
};
Now your engine can use IBackendWrapper without much concern about concrete backends.
It could happen that each wrapper will be your entire engine, if your 3D abstraction is shallow. Then the engine class will degenerate to a simple forwarder. This is OK.