[Proto]

I have the following method

template <int number> methodA(int *x){
blablabla

}

That is called by a number of different methods B,C,D. Each method B,C,D managed a different number of parameters itself

template<int number> methodB(int *x, int* y, int*z){

methodA<number>(x);
}
template<int number> methodC(int *x, int* y){

methodA<number>(x);
}
template<int number> methodD(int *x){

methodA<number>(x);
}

What I want to do is to create a generic caller, such that ideally I could do

genericCaller(methodName, parameterList){
methodName<512>(parameterList);

}

What is the proper procedure for doing this? BTW default parameters are not an option, since these functions are just an example, in reality each method signature is vastly different.

Now that I read about it this is not really a template usage question, but whatever More like how to pass method names and parameter lists as parameters themselves.

Ps: if possible I'd prefer the solution to be in pure C rather than C++

 

[Proto]

Well, i know that I can do that, but in fact the complete generic caller method would be something like

callermethodA(int x, int n){
 switch(n){
   case 1: methodA< 1>(x);
   case 2: methodA< 2>(x);
   case 4: methodA< 4>(x);
   case 8: methodA< 8>(x);
   case 16: methodA< 16>(x);
   ...
 }
}

And all the way up to a bunch of power of 2's. If I separate it among all the functions that need this, it will result in A LOT of code redundancy once i do callerMethodB, callerMethodC and all the caller methods I'll need, so I wanted to use a single caller function to avoid this. I know that this way of doing things is a little twisted and non conventional, but I really need to do it this way, since this is some sort of code preprocesing of a set of functions that I will be running on a specialized device, so I don't really mind doing a little more work on the CPU side in order to improve performance on the specialized device, but at the same time I don't want to bloat my code with 20 lines that repeat themselves a lot.

 

[Proto]

you should just pass int number as a function argument, instead of using templates. it'll be faster than using the switch statement like you're doing.
(using templates creates completely new functions for every different template parameter, and it'll cause cpu cache clutter. furthermore, the switch statement would eliminate the benefit from using templates.)

I know. I'm doing it like that because I'm using a GPU/CUDA, and in a GPU branching (eg. if, else, switch and friends) are quite expensive operands when predication is not possible, so using templates that way, and letting the compiler create new functions for each case I will have to handle is actually more optimal (the wonders of stream programming). So what I want to do is to leave the branching in the CPU so the GPU can just go ahead and use a single function per execution. Geez, I KNOW what I'm doing (well, not really, I still need to know how to pass method names and parameter lists as arguments, but that seems to be what your link is about ).

 

[Proto]

Another question, is there possible to define argument lists in C, I think in Python something similar was possible

something like
void method1(unknown type and number of arguments){
method2(just forward the arguments here);

}

I thought about defining an array of void pointers, passing that as a reference and within method1 do the casting of the elements, and then pass them to method2, but I don't know whether there's an easier way.

Something like

void method1(void** args){
method2((int*)args[0], (char*)args[1]);

}

 

[Proto]

Well, in that case it is a different application since it receives a one type kind of array, and the only thing it does is being a button factory method, which receives button names as input and outputs buttons. My example is more similar to preprocessor and a forwarding function. Like a callback function, but not quite

The way I'm doing it with a a void** array actually works, but I'm sure that I'm breaking more than one design pattern with that, and making a hell-to maintain kind of code by tying all the call forwards to a set of particular method signatures. Hence why I'd prefer some kind of: just forward whatever parameters you receive to the next method kind of solution. Aw well, maybe encapsulating them al in one structure could work. It will be one hell of a structure though.