Interface:
template <class T>
class Interface{
public:
typedef T Units;
virtual T get() = 0;
};
Implementation1:
class Implementation1: public Interface<float> {
public:
float get() {
return 0.0f;
}
};
Implementation2:
class Implementation2: public Interface<int> {
public:
int get() {
return 0;
}
};
Container (with errors):
class Container{
private:
Interface* floatGetter;
int n;
Timer::Units* array;
public:
Container(Interface* floatGetter, int n) {
this->floatGetter= floatGetter;
this->n = n;
array = new Timer::Units[n];
}
~Container() {
}
};
For more details, I have a template interface and a derived class from this interface without template. Some other class take an object of the derived class but it takes the object as an interface (in other words, dependency injection). But the type of the interface in this class is defined by the interface implementation. How to implement this idea in C++?
Edit1:
Example:
Interface<float> myInterface1 = new Implementation1();
Interface<int> myInterface2 = new Implementation2();
Container container1 = new Container(myInterface1, 10);
Container container2 = new Container(myInterface2, 10);
I need that container understands interface template argument from its implementation.
OK, first, an explanation of the problem here. What’s required is an interface, that defines a virtual method, used to get a value with a templated type. Since what we want is an interface, the get method has to be virtual. On the other hand, we would like to be able to return different types, so we want to templetize it. However, a virtual method can not be templetized, because the compiler wouldn’t know which instantions of that method to include in the vtable.
One solution is to do what’s done in the question, i.e. templetize the interface class. An important property of template types is that different instantiations of the same class are completely different types. They don’t share a common base, and they’re not convertible to each other. We simply can not have an
Interface<Generic>pointer going around in regular functions, with their get() methods being called. Consider this: Every instantion of the Interface template type has a different signature for the get() method. This means that while that method is being called, different things have to happen on the stack. How could the compiler know which version of the get() method to call (how to prepare the stack for the function call) if all it has is aInterface<Generic>pointer.I can think of two general solutions to that problem.
Remove all template mumbo-jumbo and make the get() method return a type-erased object, such as boost::variant or boost::any. Correct me if I’m wrong here(*), but boost::variant is like a union that remembers which type of the union is assigned, while boost::any is like a void *, but it remembers what type it’s pointing to. This solution path implies two things:
a) The types of the returned objects will be resolved at runtime, and there will be some overhead while manipulating these types.
b) The child classes of Interface will have to manage one of these type-erased objects, making them more complicated.
Take the template mumbo-jumbo to the extreme and refer to Interface objects always in a templetized context, so that the compiler generates the right function calls during the instantiations of those contexts. I gave an example below which follows this path. The example creates a container for holding together different types of Interface<> objects, while enabling the application of templetized functionals (is it correct to call this generally “visitors”?) to them. Note that in that example, the Interface objects with different type parameters are actually kept in different std::lists in that container class, so in the runtime, there’s no need to resolve their types.
Disclaimer: What follows is an overkill…
Here’s how you can have a container of the “interface” template class with different template arguments. I’ve used an std::list to keep the instances, but you can change it.
And the output is:
Well, this really is a huge overkill for most applications, but you asked for it 🙂
If you just want an interface, that can return different things, you could also consider boost.variant. The example above is truly valuable for all the static polymorphism it uses.
EDIT: David has pointed something important, it might be a pitfall, if you, for some reason, assume otherwise. This container doesn’t really stay true to the order of the item insertions. The order of your functional calls might not happen in the order of the insertions of the items, i.e., assume that the iteration will be in a “random” order.
(*) boost::variant and boost::any are discussed here