虽然 SWIG 本身不提供 std_function.i，但我们可以通过一些工作自己构建一个。我在这里的回答是我的previous of mine answer 的更通用版本，针对特定实例并针对 Python 来查看这个问题。我将对其进行多次迭代，为通用 std::function 包装定义一个 %std_function 宏。
我假设您希望通过包装 std::function 实现四件事，这成为我们的主要要求：
- 我们希望能够从 Java 代码中调用
std::function 对象。
- 包装后的
std::function 对象需要像任何其他对象一样被传递，包括在任一方向跨越语言边界。
- 应该可以在 Java 中编写
std::function 对象，可以将其传递回 C++，而无需修改适用于 std::function 对象的现有 C++ 代码（即维护 std::function 跨语言的类型擦除）
- 我们应该能够使用指向函数类型的 C++ 指针在 Java 中构造
std::function 对象。
我将完成这些工作并展示我们如何实现这一目标。在可能的情况下，我也会使解决方案语言不可知。
出于讨论的目的，我正在掩盖您问题的shared_ptr 部分，它实际上并没有改变事情，因为您已经让shared_ptr 工作，实际上也足以在这种情况下使用它，它只会让我的例子不必要地冗长。
我正在努力的解决方案实际上是以 SWIG 中现有的 shared_ptr 支持为模型的。我整理了一个测试界面来说明它的使用方式：
%module test
%include "std_function.i"
%std_function(Functor, void, int, double);
%{
#include <iostream>
%}
%inline %{
std::function<void(int,double)> make_functor() {
return [](int x, double y){
std::cout << x << ", " << y << "\n";
};
}
%}
基本上要使用它，您需要做的就是包含文件“std_function.i”，然后使用宏%std_function，它的参数为：
%std_function(Name, Ret, ...)
您要包装的std::function 模板的每个实例化调用一次，其中Name 是您要在Java 中调用的类型，Ret 是返回类型，然后剩余的（可变参数）参数是输入到您的功能。所以在我上面的测试界面中，我基本上是想包装std::function<void(int,double)>。
编写“std_function.i”的第一个版本实际上并不太棘手。满足基本工作要求 #1 和 #2 您只需要：
%{
#include <functional>
%}
%define %std_function(Name, Ret, ...)
%rename(Name) std::function<Ret(__VA_ARGS__)>;
%rename(call) std::function<Ret(__VA_ARGS__)>::operator();
namespace std {
struct function<Ret(__VA_ARGS__)> {
// Copy constructor
function<Ret(__VA_ARGS__)>(const std::function<Ret(__VA_ARGS__)>&);
// Call operator
Ret operator()(__VA_ARGS__) const;
};
}
%enddef
这会在生成的包装代码中包含一次 C++ 头文件，然后设置宏以在接口中使用。在这种使用场景中，SWIG 对C++11 variadic templates 的支持实际上对我们不是很有帮助，因此我编写的宏基本上使用 C99 可变参数宏参数（得到更好的支持）重新实现了the default template expansion functionality。巧合的是，这意味着我们正在编写的 SWIG 代码将适用于 2.x 甚至某些 1.3.x 版本。 （我用 2.x 测试过）。即使/当您的 SWIG 版本确实具有与 std::function 一起使用的 %template 支持时，保留此宏对于使其实际可调用的其余粘合剂仍然有用。
std:function 模板的手动扩展仅限于我们在使用时关心的部分：实际的operator() 和可能派上用场的复制构造函数。
唯一要做的另一件事是将operator() 重命名为与目标语言匹配的名称，例如对于 Java，将其重命名为一个名为“call”的常规函数，或者如果您将 Python 定位为 __call__ 或在需要时使用 tp_slots。
这足以让我们的界面工作，为了演示它我写了一点Java：
public class run {
public static void main(String[] argv) {
System.loadLibrary("test");
test.make_functor().call(1,2.5);
}
}
我使用的编译器：
swig2.0 -Wall -c++ -java test.i
g++ -Wall -Wextra -std=c++11 test_wrap.cxx -o libtest.so -I/usr/lib/jvm/default-java/include/ -I/usr/lib/jvm/default-java/include/linux -shared -fPIC
javac run.java
LD_LIBRARY_PATH=. java run
它成功了。
此时，要求 #4 很容易从列表中划掉。我们需要做的就是告诉 SWIG 在std::function 中有另一个构造函数，它接受兼容的函数指针：
// Conversion constructor from function pointer
function<Ret(__VA_ARGS__)>(Ret(*const)(__VA_ARGS__));
然后我们可以将它与 SWIG 中的%callback mechanism 一起使用，我们的测试接口文件变为：
%module test
%include "std_function.i"
%std_function(Functor, void, int, double);
%{
#include <iostream>
void add_and_print(int a, double b) {
std::cout << a+b << "\n";
}
%}
%callback("%s_cb");
void add_and_print(int a, double b);
%nocallback;
%inline %{
std::function<void(int,double)> make_functor() {
return [](int x, double y){
std::cout << x << ", " << y << "\n";
};
}
%}
我们用来调用它的 Java 是：
public class run {
public static void main(String[] argv) {
System.loadLibrary("test");
test.make_functor().call(1,2.5);
new Functor(test.add_and_print_cb).call(3,4.5);
}
}
此时我们编译和运行同样成功。
（请注意，此时创建一些以名称“SWIGTYPE_p_f_...”开头的 Java 类是正常且可取的 - 这些包装了指向函数构造函数的指针使用的“指向函数”类型和回调常量）
要求 #3 是事情开始变得棘手的地方。本质上，我们遇到了与我之前回答 on making SWIG generate an interface in Java 相同的问题，但现在我们希望在更通用的宏中执行此操作。
事实证明，在这种情况下，因为我们想要生成的界面相当简单，我们可以在宏中使用一些技巧来让 SWIG 为我们生成它。
为了完成这项工作，我们需要做的主要事情是设置 SWIG 控制器以提供跨语言多态性并允许用 Java 编写的东西实现 C++ 接口。这是在我的代码中使用后缀“Impl”生成的类。
为了让 Java 开发人员“感觉正确”，我们希望仍然对 C++ 和 Java 实现的 std::function 对象使用相同的类型。即使 std::function::operator() 是虚拟的，我们仍然不希望 SWIG 主管直接使用该类型，因为通过值传递 std::function 很常见，这将导致类型 slicing problems。因此，当 Java 开发人员扩展我们的 std::function 对象并覆盖 call 时，我们需要做一些额外的工作，以便使用该对象的 C++ 实际上调用 Java 实现，因为我们不能只使用导向器来处理它自动。
所以我们所做的看起来有点奇怪。如果您构造一个旨在实现std::function 的Java 对象，那么就有一个特殊的受保护构造函数。此构造函数保留swigCPtr 成员变量，该变量通常指向一个真实的C++ 对象为0，而是创建一个实现“Impl”接口的匿名包装对象，并将所有内容简单地代理回Java 对象的call 成员。
我们也有另一个类型映射，在 Java 中，我们将 std::function 对象传递给 C++ 的任何地方。它的作用是检测我们有哪种情况——一个 C++ 实现的 std::function 对象，还是一个 Java 对象。在 C++ 的情况下，它没有什么特别的，一切都照常进行。在 Java 案例中，它接受代理对象并要求 C++ 将其转换回另一个单独的 std::function 实例，而该实例被替换。
这足以让我们在两种语言中都获得我们想要的行为，而不会让任何一方感到奇怪（除了透明发生的大量机械提升）。
这里的问题是自动构造代理对象并非易事。 Java 有 dynamic proxy classes 作为反射 API 的一部分，但这些只实现接口，不扩展抽象类。我尝试使用的一种可能性是 Java 端的 void call(Object ...args)，它是一个可变参数函数参数。虽然这是合法的，但这似乎并没有真正覆盖超类中的任何需要的情况。
我最终做的是调整 some macros 以按照我想要的方式迭代可变参数宏参数。这是一个相当明智的解决方案，因为我们已经出于其他原因决定使用可变参数 C99 宏参数。这种机制在我的解决方案中总共使用了四次，一次在函数声明中，一次在 Java 和 C++ 的委托调用中。 （C++ 保留了完美的转发属性，而 Java 需要执行类型映射查找，因此它们在每种情况下都是不同的）。
还有一个自定义类型映射来简化一些 Java 代码 - 在 void 函数中编写 return other_void_function(); 是不合法的，因此如果不是这样，我们将需要特殊情况下的 void 函数。
让我们看看现实中的样子。首先是我用于测试的 run.java，它只是对前面的示例稍作修改，添加了 std::function 对象的 Java 实现。
public class run extends Functor {
public static void main(String[] argv) {
System.loadLibrary("test");
test.make_functor().call(1,2.5);
new Functor(test.add_and_print_cb).call(3,4.5);
Functor f = new run();
test.do_things(f);
}
@Override
public void call(int a, double b) {
System.out.println("Java: " + a + ", " + b);
}
}
经过上述所有更改后，std_function.i 现在明显变大了：
%{
#include <functional>
#include <iostream>
#ifndef SWIG_DIRECTORS
#error "Directors must be enabled in your SWIG module for std_function.i to work correctly"
#endif
%}
// These are the things we actually use
#define param(num,type) $typemap(jstype,type) arg ## num
#define unpack(num,type) arg##num
#define lvalref(num,type) type&& arg##num
#define forward(num,type) std::forward<type>(arg##num)
// This is the mechanics
#define FE_0(...)
#define FE_1(action,a1) action(0,a1)
#define FE_2(action,a1,a2) action(0,a1), action(1,a2)
#define FE_3(action,a1,a2,a3) action(0,a1), action(1,a2), action(2,a3)
#define FE_4(action,a1,a2,a3,a4) action(0,a1), action(1,a2), action(2,a3), action(3,a4)
#define FE_5(action,a1,a2,a3,a4,a5) action(0,a1), action(1,a2), action(2,a3), action(3,a4), action(4,a5)
#define GET_MACRO(_1,_2,_3,_4,_5,NAME,...) NAME
%define FOR_EACH(action,...)
GET_MACRO(__VA_ARGS__, FE_5, FE_4, FE_3, FE_2, FE_1, FE_0)(action,__VA_ARGS__)
%enddef
%define %std_function(Name, Ret, ...)
%feature("director") Name##Impl;
%typemap(javaclassmodifiers) Name##Impl "abstract class";
%{
struct Name##Impl {
virtual ~Name##Impl() {}
virtual Ret call(__VA_ARGS__) = 0;
};
%}
%javamethodmodifiers Name##Impl::call "abstract protected";
%typemap(javaout) Ret Name##Impl::call ";" // Suppress the body of the abstract method
struct Name##Impl {
virtual ~Name##Impl();
protected:
virtual Ret call(__VA_ARGS__) = 0;
};
%typemap(maybereturn) SWIGTYPE "return ";
%typemap(maybereturn) void "";
%typemap(javain) std::function<Ret(__VA_ARGS__)> "$javaclassname.getCPtr($javaclassname.makeNative($javainput))"
%typemap(javacode) std::function<Ret(__VA_ARGS__)> %{
protected Name() {
wrapper = new Name##Impl(){
public $typemap(jstype, Ret) call(FOR_EACH(param, __VA_ARGS__)) {
$typemap(maybereturn, Ret)Name.this.call(FOR_EACH(unpack, __VA_ARGS__));
}
};
proxy = new $javaclassname(wrapper);
}
static $javaclassname makeNative($javaclassname in) {
if (null == in.wrapper) return in;
return in.proxy;
}
// Bot of these are retained to prevent garbage collection from happenign to early
private Name##Impl wrapper;
private $javaclassname proxy;
%}
%rename(Name) std::function<Ret(__VA_ARGS__)>;
%rename(call) std::function<Ret(__VA_ARGS__)>::operator();
namespace std {
struct function<Ret(__VA_ARGS__)> {
// Copy constructor
function<Ret(__VA_ARGS__)>(const std::function<Ret(__VA_ARGS__)>&);
// Call operator
Ret operator()(__VA_ARGS__) const;
// Conversion constructor from function pointer
function<Ret(__VA_ARGS__)>(Ret(*const)(__VA_ARGS__));
%extend {
function<Ret(__VA_ARGS__)>(Name##Impl *in) {
return new std::function<Ret(__VA_ARGS__)>([=](FOR_EACH(lvalref,__VA_ARGS__)){
return in->call(FOR_EACH(forward,__VA_ARGS__));
});
}
}
};
}
%enddef
并且 test.i 被略微扩展以验证 Java -> C++ 传递 std::function 对象并启用导向器：
%module(directors="1") test
%include "std_function.i"
%std_function(Functor, void, int, double);
%{
#include <iostream>
void add_and_print(int a, double b) {
std::cout << a+b << "\n";
}
%}
%callback("%s_cb");
void add_and_print(int a, double b);
%nocallback;
%inline %{
std::function<void(int,double)> make_functor() {
return [](int x, double y){
std::cout << x << ", " << y << "\n";
};
}
void do_things(std::function<void(int,double)> in) {
in(-1,666.6);
}
%}
这与前面的示例一样编译和运行。值得注意的是，我们已经开始编写大量 Java 特定代码 - 尽管如果您以 Python 为目标，该设计将适用于其他语言，但使用 Python 特定功能解决其中一些问题要简单得多。
有两点我想改进：
-
使用 C++14 可变参数 lambda 来避免我用来使它们与 C++11 兼容的宏预处理器魔法。如果你有 C++ 14，%extend 构造函数变为：
%extend {
function<Ret(__VA_ARGS__)>(Name##Impl *in) {
return new std::function<Ret(__VA_ARGS__)>([=](auto&& ...param){
return in->call(std::forward<decltype(param)>(param)...);
});
}
}
如预期的那样将此宏与std::shared_ptr 一起使用时，宏本身不需要更改。然而，应用的 javadirectorin 和 directorin 类型映射的实现存在问题，这确实会阻止事情“正常工作”。即使从“主干”构建 SWIG 也是如此。 （combining directors and shared_ptr有一个悬而未决的问题）
不过，我们可以通过在调用 %shared_ptr 之后在我们模块的主 .i 文件中添加两个额外的类型映射来解决这个问题：
%shared_ptr(some::ns::TheThing);
%typemap(javadirectorin) std::shared_ptr<some::ns::TheThing> "new $typemap(jstype, some::ns::TheThing)($1,false)";
%typemap(directorin,descriptor="L$typemap(jstype, some::ns::TheThing);") std::shared_ptr<some::ns::TheThing> %{
*($&1_type*)&j$1 = &$1;
%}
这两个类型映射中的第一个实际上是死代码，因为我们在抽象类中强制“调用”方法是抽象的，但修复此方法的编译比抑制它更容易。第二个类型图很重要。它与普通的“out”类型映射基本相似，因为它创建了一个jlong，它实际上只是一个 C++ 指针的表示，即它准备了一个从 C++ 到 Java 的对象。
请注意，如果您在模块中使用包，则可能需要修改directorin 类型映射的描述符属性，修改为"L$packagepath/$typemap(...);" 或简单地手动编写。
这也应该删除现在生成的虚假“SWIGTYPE_p_sstd__shared_ptr...”类型。如果您有返回 shared_ptr 对象的虚函数，您还需要为它们编写directorout 和javadirectorout 类型映射。这些可以基于正常的“in”类型映射。
这足以让我自己使用修改后的Functor 进行简单测试，至少在我今天从主干中检出的 SWIG 版本中。 （我对 2.0.x 的测试失败了，因为这是一个已知的正在进行的工作领域，所以我没有花太多精力让它工作）。