Hey guys, 

I'm trying to develop an engine that supports consoles, as well as all PCs. I also wanted the users in windows, Mac, and Linux to use different graphics libraries. To that end I need to support many different windowing and graphics systems. To deal with that, I simply abstract them using Polymorphism, creating a base class as an interface before I inherit all the actual functions and data in another class. This approach is so far bad for data locality as I have to use pointers to objects and new rather than putting the data directly in arrays. While I'm going to use indirect multi draw and command buffers to alleviate this issue, it's still an issue. And in the case of compiling the libraries statically, I'd have to ship multiple, larger executables.

To reiterate: Is there a way to use dynamic module based Polymorphism without requiring pointers to objects? If not, would the data locality issues be significant enough to warrant just making my libraries static and shipping multiple executables per graphics system (ie: Vulkan, Opengl, and Directx on Windows). 

Run-time polymorphism in C++ is done via pointers and references and there's no way around that. You can be careful about where you allocate the memory, and this can help with data locality, but that's probably not the best way to approach this.

Graphics library choice can be a compile time setting. You can implement a compile-time interface in C++ via the curiously recurring template pattern, if you like. (https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern).

You're wrong about shipping larger executables in the static case. Either the function is used, in which case it's linked into the executable, or it's not, and it's not. If anything the polymorphic case is potentially worse because sometimes it's not easy for the linker to know whether you'll ever call a certain derived function or not.

It's impossible to say whether the data locality issues are significant because it depends entirely on your specific implementation. At one ludicrous extreme, if you just have 1 virtual function call such as DoAllGraphics() and it has a DirectX implementation and an OpenGL implementation, then it is going to have absolutely no effect whatsoever. At the other ludicrous extreme, if you have a virtual HandleVertex function then obviously that's going to be awful. You will want an interface that is sufficiently high level that you are not performing thousands of virtual function calls per second, which may involve some compromises such as code duplication.

5 hours ago, KarimIO said:

Is there a way to use dynamic module based Polymorphism without requiring pointers to objects?

Research SOLID principles. It is one of many patterns that have been realized as major differences between flexible maintainable code and nightmarish code. 

That link is just the starting point. There is an enormous body of literature, also including research papers and conference talks, on the subject.

For this type of library that can be swapped out, the acronym letter D (Dependency Inversion) is most critical, followed by the L (Liskov substitution).  Dependency inversion means all the code is written against the abstract library and not the concrete implementation, so the abstract graphics instead of the D3D or OGL or Vulcan code. The substitution principle means that the actual concrete implementation will work perfectly as long as the abstract library is followed.

25 minutes ago, frob said:

Research SOLID principles. It is one of many patterns that have been realized as major differences between flexible maintainable code and nightmarish code. 

That link is just the starting point. There is an enormous body of literature, also including research papers and conference talks, on the subject.

For this type of library that can be swapped out, the acronym letter D (Dependency Inversion) is most critical, followed by the L (Liskov substitution).  Dependency inversion means all the code is written against the abstract library and not the concrete implementation, so the abstract graphics instead of the D3D or OGL or Vulcan code. The substitution principle means that the actual concrete implementation will work perfectly as long as the abstract library is followed.

I'm, generally, abiding by those principles. I am mostly referring to technical limitations of c++

In that case, you understand why using pointers to objects are a necessity.

This is true of all programming languages for this feature.  You are replacing one set of things with another set of things, therefore you need some form of indirection which can select the proper elements. In C++ that is handled through pointers, including features like the vtable pointer.

3 minutes ago, frob said:

In that case, you understand why using pointers to objects are a necessity.

This is true of all programming languages for this feature.  You are replacing one set of things with another set of things, therefore you need some form of indirection which can select the proper elements. In C++ that is handled through pointers, including features like the vtable pointer.

I suppose I was mostly trying to change the definition of those things rather than swap them out, though at runtime. Thanks though.