java - 如何使用SWIG包装std::function对象？

Question

我已经看到了很多类似的问题，但是还没有找到解决我特定问题的方法。我试图SWIGify一些使用std::function的C++ 11代码，因此可以在Java应用程序中使用它。

我遇到了这样的共享指针:

virtual std::shared_ptr<some::ns::TheThing> getTheThing(unsigned short thingID);

并使用shared_ptr指令成功处理了它们，如下所示:

%shared_ptr(some::ns::TheThing);

我遇到了像这样的共享指针 vector :

virtual std::vector<std::shared_ptr<some::ns::TheThing>> getAllTheThings() const = 0;

并使用如下模板成功处理了它们:

%template(ThingVector) std::vector<std::shared_ptr<some::ns::TheThing>>;

现在，我有一个像这样的方法:

 void registerThingCallback(std::function<void(std::shared_ptr<some::ns::TheThing>) > func);

而且我无法让SWIG正确包装它。我已经尝试过使用％callback，director，％template和％inline功能代码，因为我已经看到了所有这些示例，但是还无法获得任何看起来可行的功能。如果有帮助( sanitizer 和减少)，可以在函数调用周围找到一些上下文:

something_callback.h

#include <functional>

namespace some {
  namespace ns {

    /**
     * Hold some callbacks.
     */
    class ThingCallbacks {
    public:

        /**
         * Registers a callback 
         * @param func The callback function
         */
        void registerThingCallback(std::function<void(std::shared_ptr<some::ns::TheThing>) > func);

    };

  }
}

更新

基于以下Flexo的出色回答，我更接近解决方案。我能够使下面的示例完全按照广告中的说明工作。我尝试将其合并到我的实际代码中，但是遇到了问题。为了扩展我之前的简化示例，这是我对TheThing的定义:

test_thing.h

#ifndef THE_THING_H
#define THE_THING_H

#include <string>

namespace some {
  namespace ns {

    class TheThing {
    public:

        virtual ~TheThing() {};

        virtual unsigned long longThing() const = 0;

        virtual std::string stringThing() const = 0;
    };
  }
}

#endif  /* THE_THING_H */

这是我的.i文件。为了尽可能少地移动部件，我基本上只是将int值和下面答案中提供的代码加倍，然后将它们替换为指向我对象的共享指针。

func_thing_test.i

%module(directors="1") Thing
%include "stl.i"
%include "std_function.i"
%include "std_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="Lsome.ns.typemap(jstype, some::ns::TheThing);") std::shared_ptr<some::ns::TheThing> %{
     *($&1_type*)&j$1 = &$1;
%}


%include "test_thing.h"
%include "thing_callback.h"

%{
#include <memory>

#include "test_thing.h"
#include "thing_callback.h"

%}

%std_function(Functor, void, std::shared_ptr<some::ns::TheThing>);

%{
#include <iostream>
void add_and_print(std::shared_ptr<some::ns::TheThing> thing) {
  std::cout << "here\n";
}
%}

%callback("%s_cb");
void add_and_print(std::shared_ptr<some::ns::TheThing>);
%nocallback;

%inline %{
  std::function<void(std::shared_ptr<some::ns::TheThing>)> make_functor() {
    return [](std::shared_ptr<some::ns::TheThing>){
      std::cout << "make functor\n";
    };
  }

  void do_things(std::function<void(std::shared_ptr<some::ns::TheThing>)> in) {
      std::cout << "inside do things\n";
  }
%}

test_thing.h是我刚刚在上面发布的内容，而thing_callback.h是我在原始问题中发布的代码。所有这些都通过swig，c++和Java链进行编译而没有错误，但是swig似乎在将c++和Java之间的点连接起来时遇到了一些麻烦。它创建了以下三个类:

SWIGTYPE_p_f_std__function__f_std__shared_ptr__some__ns__TheThing____void____void
SWIGTYPE_p_f_std__shared_ptr__some__ns__TheThing____void
SWIGTYPE_p_std__functionT_void_fstd__shared_ptrT_some__ns__TheThing_tF_t

不幸的是，简单的Java主代码中的大多数方法现在都采用或返回了这些对象，这使它们相当不可用。任何想法如何解决这个问题？谢谢!

为了更完整一些细节:我正在使用以下三个脚本来编译和运行代码。参数略有不同，但是我认为这并不重要。在我的末端，它被设置为Eclipse Maven项目。这些脚本位于我项目的根目录中，头文件和Swig文件位于src/main/resources中，java源文件位于src/main/java中，而Java编译的类位于target/classs中。 Eclipse执行Java编译。

swigthing.sh

MODULE_NAME=Thing
PACKAGE=some.ns
OUTDIR=./src/main/java/some/ns
I_FILE=./src/main/resources/func_thing_test.i

mvn clean

rm $OUTDIR/*.*
mkdir -p $OUTDIR

swig -java -c++ -module $MODULE_NAME -package $PACKAGE -outdir $OUTDIR $I_FILE

./compileThingSwigTest.sh

compileThingSwigTest.sh

#!/bin/bash

pushd src/main/resources
g++ -c -std=gnu++11 -fpic \
func_thing_test_wrap.cxx \
-I/usr/lib/jvm/java/include \
-I/usr/lib/jvm/java/include/linux

g++ -shared func_thing_test_wrap.o -o libFunc.so
popd

runThingTest.sh

pushd target/classes
java -Xmx512M -Xms512M -Djava.library.path=. some.ns.test.RunThingTest
popd

最后更新

修复了上面的代码，将正确的参数传递给std_function。现在在问题和答案之间有一个我所追求的完整的工作示例。

Answer 1

尽管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++头文件包含在生成的包装器代码中，然后设置宏以在接口(interface)中使用。在这种使用情况下，SWIG对 C++11 variadic templates的支持实际上对我们没有太大帮助，因此我编写的宏基本上使用C99可变参数宏参数(更好地支持了)重新实现 the default template expansion functionality。巧合的是，这意味着我们正在编写的SWIG代码将在2.x甚至1.3.x版本中使用。 (我使用2.x进行了测试)。即使/当您的SWIG版本确实支持 %template并与 std::function一起使用时，保留该宏仍可用于使它实际可调用的其余粘合。
std:function模板的手动扩展仅限于我们关心的使用位:实际的 operator()和一个可能很方便的复制构造函数。

唯一要做的另一件事是将 operator()重命名为与目标语言相匹配的内容，例如Java重命名它只是一个名为“call”的常规函数​​，或者如果您将Python定位为 __call__或使用tp_slots(如果需要)。

现在，这足以使我们的接口(interface)工作，并向我演示了一点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一起使用，我们的测试接口(interface)文件将变为:

%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相同的问题，只是现在我们希望在宏中更通用地实现它。

事实证明，在这种情况下，因为我们要生成的接口(interface)非常简单，所以我们可以在宏中使用一些技巧使SWIG为我们生成它。

为了完成这项工作，我们需要做的主要事情是设置SWIG Director以提供跨语言多态性，并允许用Java编写的东西实现C++接口(interface)。这是在我的代码中带有后缀“Impl”的类。

为了使Java开发人员“感觉良好”，我们希望仍对C++和Java实现的 std::function对象使用相同的类型。即使 std::function::operator()是虚拟的，我们仍然不希望SWIG导演直接使用该类型，因为按值传递 std::function很常见，因为这会导致 slicing problems类型。因此，当Java开发人员扩展 std::function对象并覆盖 call时，我们需要做一些额外的工作来制作它，以便使用该对象的C++实际上会调用Java实现，因为我们不能仅仅使用Director来自动处理它。

因此，我们所做的工作看起来有些不可思议。如果您构造一个旨在实现 std::function的Java对象，那么将有一个 protected 特殊构造函数。该构造函数保留 swigCPtr成员变量，该变量通常指向一个真正的C++对象为0，而是创建一个实现“Impl”接口(interface)的匿名包装对象，并将所有内容简单地代理回Java对象的 call成员。

在Java中，我们到处都有另一个类型映射也可以应用，只要我们将 std::function对象传递给C++。它的作用是检测我们遇到的情况-一个C++实现的 std::function对象，或者一个Java。在C++情况下，它并没有做任何特殊的事情，并且一切正常进行。在Java情况下，它使用代理对象，并要求C++将其转换回另一个单独的 std::function实例，而该实例将被替换。

这足以使我们在两种语言中都能获得想要的行为，而没有任何一面感到奇怪的东西(除了大量透明地发生的机械提升之外)。

这里要注意的是，自动构造代理对象并非易事。 Java将 dynamic proxy classes作为反射API的一部分，但是这些仅实现接口(interface)，而不扩展抽象类。我尝试使用的一种可能性是Java端的 void call(Object ...args)，它是一个可变参数函数。虽然合法，但这似乎并没有实际覆盖需要的父类(super class)中的任何情况。

我最终要做的是修改 some macros以我想要的方式遍历可变参数宏参数。鉴于我们已经出于其他原因决定使用可变参数C99宏参数，因此这是一个非常明智的解决方案。在我的解决方案中，此机制总共使用了四次，一次在函数声明中，一次在对Java和C++的调用中。 (C++保留了完善的转发属性，Java需要执行类型映射查找，因此每种情况下它们都是不同的)。

还有一个自定义的typemap可以简化一些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进行了稍微扩展，以验证 std::function对象的Java-> C++传递并启用Director:

%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可变参数lambdas可以避免宏预处理器的魔力，我一直在使它们与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类型映射的实现存在问题，它们确实阻止了事情“正常运行”。即使使用“trunk”构建SWIG，也是如此。 ( combining directors and shared_ptr上有一个悬而未决的问题)

不过，我们可以通过在调用 %shared_ptr之后在模块的主.i文件中添加两个附加的typemap来解决此问题:

%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;
%}

这两个类型映射中的第一个实际上是无效代码，因为我们在抽象类中强制将“call”方法抽象化，但是修复此方法的编译比抑制它更容易。第二个类型图很重要。它与普通的“输出”类型图基本相似，因为它创建了一个 jlong，它实际上只是C++指针的表示，即它准备了一个从C++到Java的对象。

请注意，如果您在模块中使用包，则可能需要修改Directorin类型图的描述符属性，或者将其更改为 "L$packagepath/$typemap(...);"或直接手工编写。

这也应该删除现在生成的伪造的“SWIGTYPE_p_sstd__shared_ptr ...”类型。如果您具有返回shared_ptr对象的虚函数，则还需要为其编写Directorout和javadirectorout类型映射。这些可以基于普通的“输入”类型映射。

这足以让我自己进行修改后的 Functor进行简单测试，至少在今天从主干中 checkout 我的SWIG版本时就可以了。 (我对2.0.x的测试失败了，因为这是一个正在进行的工作，所以我没有付出太多努力使其工作)。