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 a Interface<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.
#include<boost/fusion/container/vector.hpp>
#include<boost/fusion/algorithm.hpp>
#include<boost/mpl/transform.hpp>
#include<boost/mpl/contains.hpp>
#include<boost/utility/enable_if.hpp>
#include<boost/type_traits/add_reference.hpp>
#include<list>
#include<algorithm>
#include <iostream>
using namespace boost;
template <class T>
class Interface{
public:
typedef T Units;
virtual T get() = 0;
};
class Implementation1: public Interface<float> {
public:
float get() {
return 0.0f;
}
};
class Implementation2: public Interface<int> {
public:
int get() {
return 5;
}
};
template<class element>
struct to_list {
typedef std::list<Interface<element> *> type;
};
template<class elementVector>
struct to_containers {
typedef typename mpl::transform<elementVector,to_list<mpl::_1> >::type type;
};
class Container{
typedef fusion::vector<int,float> AllowedTypes;
typename to_containers<AllowedTypes>::type containers;
public:
template<class type> typename enable_if<mpl::contains<AllowedTypes,type>,void>::type
/*void*/ add(Interface< type/*included in AllowedTypes*/ > & floatGetter) {
fusion::deref(fusion::find<typename to_list<type>::type >(containers))
/*<type> container*/.push_back(&floatGetter);
}
template<class functional>
void apply(functional f) {
fusion::for_each(containers,applyFunctional<functional>(f));
}
private:
template<class functional>
struct applyFunctional {
functional f;
applyFunctional(functional f): f(f){}
template<class T> void operator()(T & in) const {
std::for_each(in.begin(), in.end(),f);
}
};
};
struct printValueFunctional {
template<class element>
void operator()(Interface<element> * in) const {
std::cout<<"Hi, my value is:"<<in->get()<<"\n";
}
};
int main() {
Implementation1 impl1;
Implementation2 impl2;
Interface<float> &myInterface1 = impl1;
Interface<int> &myInterface2 = impl2;
Container container;
container.add(myInterface1);
container.add(myInterface2);
container.apply(printValueFunctional());
return 0;
}
And the output is:
Hi, my value is:5
Hi, my value is:0
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
