Template question

[jukoli]

Hi,
I have a function which looks like this:
template <typename Type1, typename Type2>
myfunc(void *dst, void *src);

Two variables:
int datatype1, int datatype2
datatype1 and datatype2 are coding the real type of dst and src (basic
integer types: unsigned char, int ...).
Template parameters Type and Type2 are determined by these 2 variables.

I need to call myfunc with potentially all combinations of datatype1 and
datatype2:
template <typename Type1, typename Type2>
myfunc<unsigned char, unsigned int>(void *dst, void *src);
myfunc<unsigned char, int>(void *dst, void *src);
....

A brute force solution is:
switch(datatype1) {
case UNSIGNED_CHAR:
switch(datatype2) {
case INT:
myfunc<unsigned char, int>(dst, src);
break;
...
}
...
}

I would like to avoid the use of a macro. Does somebody see a clean
solution with templates?

Thanks for your help.

 

[Ian Collins]

Hi,
I have a function which looks like this:
template <typename Type1, typename Type2>
myfunc(void *dst, void *src);

Why are these void* rather than Type1* and Type2*?

 

[Salt_Peter]

Hi,
I have a function which looks like this:
template <typename Type1, typename Type2>
myfunc(void *dst, void *src); // missing return type

Why prevent a compiler from doing its job?
Using void as type-placement is dead logic and bug-ridden.

Let the compiler help you code:

template< typename D, typename S >
void myfunc( D& dst, S& src )
{
// do stuff
}

where types D and S can be anything you require, including dumb
pointers.

#include<string>

int main()
{
int n(99);
std::string s("a short string");
myfunc< int, std::string >(n, s);
}

 

[jukoli]

Salt_Peter a écrit :

Why prevent a compiler from doing its job?
Using void as type-placement is dead logic and bug-ridden.

Because there is a setData(void *data, int type) somewhere else and I
can't remove it.

 

[Salt_Peter]

Because there is a setData(void *data, int type) somewhere else and I
can't remove it.

Who says you need to?
Cast the appropriate parameter to void* when calling setData(...).