Re: How to avoid complex switches?
On Mar 28, 6:32 pm, none <""mort\"@(none)"> wrote:
I have a class that takes a few template parameters:
template<typename A, typename B, typename C,typename D>
class MyClass {
// ...
};
The types A,B,C and D are selected from a user specified input file
(properties file):
A = 1
B = 2
C = 1
D = 3
I then parse this file an need to create MyClass with the correct types:
void createMyClass (int a, int b, int c, int d) {
switch ( a ) {
case 1 :
typedef test::Green ColorType;
switch ( b ) {
case 1 :
typedef test::Water MediumType;
switch ( c ) {
case 1 :
typedef test::Linear InterpolationType;
MyClass<ColorTyper, MediumType, InterpolationType > myClass;
break;
case 2 :
typedef test::Cubic InterpolationType;
MyClass<ColorTyper, MediumType, InterpolationType > myClass;
break;
default :
}
break;
I suspect that this is more a results of some trimming you've
done for posting, but that last switch is neither legal (since
case doesn't create a scope, you have multiple definitions) nor
useful (since as soon as you declare the variable myClass, you
quit the scope, and it ceases to exist or be accessible.
For the rest... others have already pointed out that you need
to instantiate all of the possible template code. If that's
acceptable, then something simple along the lines of
struct TypeId
{
int a;
int b;
int c;
int d;
};
std::map<TypeId, Factory const*> factory_map;
would do the trick (with all of the obviously necessary
additional functions, an operator< for TypeId, etc.)
Otherwise, one solution that I've occasionally found useful for
this sort of thing is to place each template instantiation in a
separate DLL, and load only one of the DLL's according to the
data found in configuration file. Usually, it's simpler to just
instantiate everything in the main program, but if the set of
possible types is open (someone might add one in the future),
the DLL solution adapts more easily, and if the instantiations
are really, really big, and your program needs all the memory it
can get, the DLL solution should reduce the memory footprint of
the code.
--
James Kanze