Extensible architecture using Abstract Factory and template metaprogramming [closed] - c++

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm currently working on my master thesis and it seems I cannot find a satisfying solution to the following problem. The idea here is to design a small library that should abstract from the underlying APIs (such as DirectX11 and OpenGL4). It is not required for two or more APIs to coexist in the same application, so I could theoretically write a bunch of preprocessor directives to discriminate among them, however this will blow my code and, of course, it is not extensible at all.
The abstract factory seems very handy, however it seems that I cannot find a way to make it work with templates.
Let's start...
I have an abstract class Factory whose purpose is to instantiate the objects needed by the application to work, such as Resources and Context. The former is used to load resources at runtime, while the latter is used to render the 3D scene.
Both Resources and Context are abstract because their implementation depends on the underlying API.
class Factory{
public:
virtual Resources & GetResources() = 0;
virtual Context & GetContext() = 0;
}
Resources class will load the resources needed, and return objects of type Texture2D and Mesh. Again, those classes are abstract since they depend on the specific API.
Let's say that i'm working with DirectX11 and OpenGL4.5. For each of those APIs I have the classes above derived, respectively DX11Factory, DX11Resources, DX11Context, DX11Texture2D, DX11Mesh and so on. The class they extend are pretty obvious. Fair enough.
The trivial way to design the interface of the class Resource is the following:
class Resources{
public:
Texture2D LoadTexture(const wstring & path) = 0;
Mesh LoadMesh(const wstring & path) = 0;
}
The class DX11Resource will implement the methods above and everything would work just fine... except that if I wanted to support a new resource type in the future like TextureCube (and from a software engineer point of view, I will for sure. Right now I don't care), I'll have to declare a new method TextureCube LoadTextureCube(...) in the interface the library user will actually use, that is Resources. This will mean that I`ll have to implement that method in every single derived class (open-closed principle FTW!).
My very first idea to solve this problem was the following:
class Texture2D{...}
class Resources{
public:
template<typename TResource>
virtual TResource Load(const wstring & path) = 0; // :(
}
namespace dx11{
class DX11Texture2D: public Texture2D{...}
class DX11Texture2DLoader{...}
template<typename TResource> struct resource_traits;
template<> struct resource_traits<Texture2D>{
using type = DX11Texture2D;
using loader = DX11Texture2DLoader; //Functor type
}
class DX11Resources{
public:
template<typename TResource>
virtual TResource Load(const wstring & path){
return typename resource_traits<TResource>::loader()( path );
}
}
}
So if I need to support a new type of resource I could simply declare a new resource_traits inside the proper namespace (and of course the new resource abstract and concrete type) and everything would work. Unfortunately virtual template methods are not supported (and for a very good reason, imagine what would happen writing something like this
Resources * r = GrabResources(); //It will return a DirectX9 object
r->Load<HullShader>(L"blah"); //DX9 doesn't support HullShaders, thus have no resource_traits<HullShader>
So basically the compiler won't be able to perform a proper substitution and it will point out an error to a class the user wasn`t even aware of.
)
I have thought about other solutions but none of them satisfy my needs:
1. CRTP
I can use this:
template <typename TDerived>
class Resources{
public:
template <typename TResource>
TResource Load(const wstring & path){
return typename TDerived::resource_traits<TResource>::loader()( path );
}
}
I think this will work, however Resources<TDerived> cannot be returned by the Factory object simply because TDerived is not known (and the final programmer shouldn`t anyway).
2. RTTI
class Resources{
template <typename TResource>
TResource Load(const wstring & path){
return *static_cast<TResource *>( Load(path, typeid(TResource).hash_code()) );
}
virtual void * Load(const wstring & path, size_t hash) = 0;
}
In the derived class I have to implement the pure virtual method above and then, using an if-then-else cascade I can instantiate the resource I need or return a nullptr if that particular API doesn't support it. This will work for sure but it is ugly and of course it forces me to rewrite the implementation whenever I want to support a new resource type (but at least it will be just one class)!
if( hash == typeid(Texture2D).hash_code()) // instantiate a DX11Texture2D
else if (...)...
3. Visitor
Taking advantage of the Visitor pattern. This method acttually won't help me at all, but I leave it here just in case (I always think about the visitor whenever I see a never-ending if-then-else cascade with integrated downcast, like in the previous point :) ).
template <typename TResource> resource_traits;
template<> resource_traits<Texture2D>{
using visitable = Texture2DVisitable;
}
struct Texture2DVisitable{
Texture2D operator()(const wstring & path, Loader & visitor){
return visitor.Load(path, *this);
}
}
template<typename TResource>
TResource Resources::Load(path){
return typename resource_traits<TResource>::visitable()(path, *this);
}
Using this approach Resources now have to declare a pure virtual method for every resource it can load like Texture2D Resources::Load(path, Texture2DVisitable &) = 0. So, again, in case of new resources I have to update the entire hierarchy accordingly... at this point I would use the trivial solution at the beginning.
4. Others?
Have I missed something? What approach should I prefer? I feel like i'm overcomplicating stuffs, as always!
Thanks in advance and sorry for my poorly-written wall-o-text!
ps: Get rid of the Resource class in first place is not an option since its real purpose is to prevent the loading of the same resource over and over. It is basically a huge flyweight.

Answer 1

This problem really boils down to the whole "virtual function template" problem. Basically, the solution (whatever it is) has to take a compile-time information (e.g., template argument), turn it into run-time information (e.g., value, type-id, hash-code, function-pointer, etc.), go past the run-time dispatch (virtual call), and then turn that run-time information back into compile-time information (e.g., which piece of code to execute). By understanding this, you'll realize that the most direct solution is to use that "RTTI" solution, or a variation thereof.
As you point out, the only real problem with that solution is that it is "ugly". I agree that it is a bit ugly and that other than that, it's a nice solution, especially the fact that the modifications needed when adding a new supported type is localized only to the implementation (cpp files) associated to the class that you are adding that support to (you really could not hope for anything better than that).
As for the ugliness, well, that's something you can always improve on with some trickery, but there will always be some ugliness to it, especially the static_cast which cannot be removed because you need a way to emerge from the run-time dispatch back to a statically typed result. Here is a possible solution that relies on the std::type_index:
// Resources.h:
class Resources {
public:
template <typename TResource>
TResource Load(const wstring & path){
return *static_cast<TResource *>(Load(path, std::type_index(typeid(TResource))));
}
protected:
virtual void* Load(const wstring & path, std::type_index t_id) = 0;
}
// DX11Resources.h:
class DX11Resources : public Resources {
protected:
void* Load(const wstring & path, std::type_index t_id);
};
// DX11Resources.cpp:
template <typename TResource>
void* DX11Res_Load(DX11Resources& res, const wstring & path) { };
template <>
void* DX11Res_Load<Texture2D>(DX11Resources& res, const wstring & path) {
// code to load Texture2D
};
// .. so on for other things..
void* DX11Resources::Load(const wstring & path, std::type_index t_id) {
typedef void* (*p_load_func)(DX11Resources&, const wstring&);
typedef std::unordered_map<std::type_index, p_load_func> MapType;
#define DX11RES_SUPPORT_LOADER(TYPENAME) MapType::value_type(std::type_index(typeid(TYPENAME)), DX11Res_Load<TYPENAME>)
static MapType func_map = {
DX11RES_SUPPORT_LOADER(Texture2D),
DX11RES_SUPPORT_LOADER(Texture3D),
DX11RES_SUPPORT_LOADER(TextureCube),
//...
};
#undef DX11RES_SUPPORT_LOADER
auto it = func_map.find(t_id);
if(it == func_map.end())
return nullptr; // or throw exception, whatever you prefer.
return it->second(*this, path);
};
There are some variations to this (such as having member functions instead of free functions for the loaders, or using non-template functions instead of specialization, or both of these modifications), but the basic idea is that to add a new supported type, all you do is add it to the list of supported types (the DX11RES_SUPPORT_LOADER(SomeType)) to the list and create the code as a new function (only in the cpp file). There is still a bit of ugliness in there, but the header file is clean, and the ugliness in the virtual "Load" is "O(1)" in complexity, meaning that you don't add ugliness for every new type, it's constant bit of ugly code (instead of the if-else sequence, where the amount of ugly code is proportional to the number of types supported). Also, this has the side benefit of being faster in doing the dispatching (with hash table). Also, using type_index is important to avoid collisions with the hash values of two types (you don't lose the info on which typeid was used to create the hash value).
So, all in all, my recommendation is to go with the "RTTI" solution, and do what you can or want to remove some of the ugliness or inefficiencies associated to it. The most important thing is to keep the interface (header, class declaration) of the derived class as clean as possible to avoid having to add anything to it in the future (you definitely don't want that class to expose, in its declaration, what types of resources it supports via function declarations or something, otherwise, you have to recompile the world every time to add one).
N.B.: If you need to avoid using the RTTI (e.g., -fno-rtti option), then there are ways to work around that problem, but it's out of the scope of this question.