Question

我目前正在使用swig生成Java代码。

我有两个Swig模块（module1和module2），它们将创建两个包（fr.package1和fr.package2）。 fr.package2的生成类需要使用其他包的生成类。为了实现这一点，我需要将getCPtr()方法的可见性更改为public。

按照documentation中的描述，我在界面文件中添加了：

SWIG_JAVABODY_PROXY(public, public, SWIGTYPE)
SWIG_JAVABODY_TYPEWRAPPER(public, public, public, SWIGTYPE)

在module1中，我也将shared_ptr用于一个类，如下所示：

%module module1

%include <boost_shared_ptr.i>
%inline %{
    #include <boost/shared_ptr.hpp>
%}
%{
    #include "foo.h"
%}
SWIG_JAVABODY_PROXY(public, public, SWIGTYPE)
SWIG_JAVABODY_TYPEWRAPPER(public, public, public, SWIGTYPE)
%shared_ptr(foo)
%include "foo.h"

当我运行swig时，除类getCPtr()外，生成的类对foo具有公共可见性。

为什么我使用%shared_ptr时不起作用？使用getCPtr()时是否可以公开%shared_ptr的可见性？

Answer 1

我们需要解决的第一件事是为什么shared_ptr宏打破了这一点。答案在于shared_ptr宏本身的实际作用。简而言之，它提供了一堆额外的专用类型图，包括javabody类型图，它提供了getCPtr实现以及其他功能。

此答案的下一部分将很快成为关于SWIG内部类型映射匹配逻辑如何工作的讨论。如果您真的不在乎，可以放心地跳过它。

所以最初的问题是，此处为foo提供的额外类型映射“击败”了SWIGTYPE类型映射，因为它们更具体。（SWIGTYPE基本上是任何类型的低优先级通配符，没有更具体的含义）。这立即导致一个显而易见的想法：在两个修改器控制宏中将SWIGTYPE更改为foo。但是，这不起作用，因为我们最终得到了两个相互竞争的%typemap(javabody) foo。在这种情况下，最后一个看到的就是胜利。因此，如果我们将界面更改为如下所示：

%shared_ptr(foo)
SWIG_JAVABODY_PROXY(public, public, foo)
SWIG_JAVABODY_TYPEWRAPPER(public, public, public, foo)

然后，带有public的javabody类型映射胜出。但这可能不是我们想要的，因为毕竟，如果shared_ptr宏正在更改javabody类型映射，则可能是出于某种原因这样做吗？我们可以对两者进行检查，然后查看，但是我目前还没有真正做到这一点，因为总有更好的解决方案。

如果我们查看boost_shared_ptr.i里面的内容，可以发现有一种方法可以控制它提供的javabody的修饰符。如果我们现在将模块设置为：

%module module1
#define SWIG_SHARED_PTR_TYPEMAPS(CONST, TYPE...) SWIG_SHARED_PTR_TYPEMAPS_IMPLEMENTATION(public, public, CONST, TYPE)

%include <boost_shared_ptr.i>

%shared_ptr(foo)

// ...

然后它按您希望的那样工作。请注意，在其他任何东西都没有包含共享指针标头之前，我们的#define才是非常重要的。

更改shared_ptr的getCPtr（）可见性

1 个答案: