java 模板参数_函数作为模板参数传递

模板参数可以按类型(typename T)或值(int X)进行参数化 .

模仿一段代码的“传统”C方法是使用一个仿函数 - 也就是说，代码在一个对象中，因此该对象赋予代码唯一类型 .

使用传统函数时，此技术不会指示特定函数 - 而是仅指定许多可能函数的签名 . 所以：

template

int do_op(int a, int b, OP op)

{

return op(a,b);

}

int add(int a, int b) { return a + b; }

...

int c = do_op(4,5,add);

不等同于仿函数案例 . 在此示例中，do_op是针对其签名为int X(int，int)的所有函数指针实例化的 . 编译器必须非常积极地完全内联这种情况 . (我不会排除它，因为编译器优化已经非常先进 . )

告诉我们这段代码不能满足我们想要的一种方法是：

int (* func_ptr)(int, int) = add;

int c = do_op(4,5,func_ptr);

仍然是合法的，显然这没有内联 . 要获得完整的内联，我们需要按值进行模板化，因此该函数在模板中完全可用 .

typedef int(*binary_int_op)(int, int); // signature for all valid template params

template

int do_op(int a, int b)

{

return op(a,b);

}

int add(int a, int b) { return a + b; }

...

int c = do_op(4,5);

在这种情况下，每个实例化的do_op版本都使用已经可用的特定功能进行实例化 . 因此，我们希望do_op的代码看起来很像“返回b” . (Lisp程序员，不要傻笑！)

我们还可以确认这更接近我们想要的，因为这样：

int (* func_ptr)(int,int) = add;

int c = do_op(4,5);

将无法编译 . GCC说：“错误：'func_ptr'不能出现在常量表达式中 . 换句话说，我无法完全扩展do_op，因为你没有在编译器时给我足够的信息来知道我们的操作是什么 .

因此，如果第二个例子真的完全内联我们的op，而第一个不是，那么模板有什么用呢？它在做什么？答案是：类型强制 . 第一个例子的这个riff将起作用：

template

int do_op(int a, int b, OP op) { return op(a,b); }

float fadd(float a, float b) { return a+b; }

...

int c = do_op(4,5,fadd);

那个例子会奏效！ (我并不认为这是好的但是......)发生的事情是do_op已经模仿了各种函数的签名，每个单独的实例化都会编写不同类型的强制代码 . 所以do_op与fadd的实例化代码类似于：

convert a and b from int to float.

call the function ptr op with float a and float b.

convert the result back to int and return it.

相比之下，我们的by-value案例需要在函数参数上进行精确匹配 .