SWIG：公共函数中使用的私有 typedef
我经常给我的类一个私有 typedef 来引用它们自己，如下所示：
class MyClass {
private:
typedef MyClass Self;
public:
void DeepCopyFrom(const Self& other);
...
};
我现在使用 SWIG 包装我的 C++ 代码，它抱怨这样的 typedef：
error: ‘typedef class MyClass MyClass::Self’ is private
导致此错误的包装器代码如下所示：
SWIGINTERN PyObject *_wrap_MyClass_DeepCopyFrom(PyObject *SWIGUNUSEDPARM(self), PyObject *args) {
PyObject *resultobj = 0;
MyClass *arg1 = (MyClass *) 0 ;
MyClass::Self *arg2 = 0 ;
(...)
编译器错误发生在最后一个线，省略号上方。
有没有办法告诉 SWIG 不要使用私有 typedef，而只使用完整的类型名称？
I often give my classes a private typedef to refer to themselves, as follows:
class MyClass {
private:
typedef MyClass Self;
public:
void DeepCopyFrom(const Self& other);
...
};
I'm now wrapping my C++ code using SWIG, which complains about such typedefs:
error: ‘typedef class MyClass MyClass::Self’ is private
The wrapper code that causes this error looks like:
SWIGINTERN PyObject *_wrap_MyClass_DeepCopyFrom(PyObject *SWIGUNUSEDPARM(self), PyObject *args) {
PyObject *resultobj = 0;
MyClass *arg1 = (MyClass *) 0 ;
MyClass::Self *arg2 = 0 ;
(...)
The compiler error happens on that last line, above the ellipsis.
Is there any way to tell SWIG to not use private typedefs, and instead just use the full type name?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我建议保持简单（r）：只需删除 typedef 并写入类名即可。
如果您真的讨厌这样做，您可以告诉 SWIG
%ignore“损坏的”方法，然后使用调用真实方法的包装方法来%extend类。除非您绑定的类和方法的数量相对于您的总代码库来说很小，否则这种治疗方法可能比疾病本身更糟糕。I suggest keeping it simple(r): just remove the typedefs and write the class name instead.
If you really hate that, you could tell SWIG to
%ignorethe "broken" methods and then%extendthe classes with wrapper methods calling the real ones. Unless the number of classes and methods you are binding is small relative to your total codebase, this cure is probably worse than the disease.默认情况下，SWIG 不会处理任何 typedef 或声明或
private部分中的任何内容。因此，它假设（当它看到const Self&时）Self是来自标头或其他内容的某种未知类型，它保持原样并生成带有以下内容的包装器代码：自我留在了那里。问题是这个包装器代码是类的外部函数，并且由于MyClass::Self是私有的，因此编译器会生成错误。我的代码也发生过同样的事情：我必须做的就是在public部分中声明 typedef 或将Self重写为MyClass< /代码>。将 typedef 更改为public对我来说最有意义。SWIG by default will not process any typedef or declaration or anything in a
privatesection. Therefore, it assumes (when it seesconst Self&) thatSelfis some unknown type from a header or something else, it leaves it as such and generates wrapper code with theSelfleft in there. The problem is that this wrapper code is a function external to the class, and sinceMyClass::Selfis private, your compiler generates an error. I've had the same thing happen to my code: what I had to do was either declare the typedef in apublicsection or to rewriteSelfasMyClass. Changing the typedef topublicmakes the most sense to me.我很少见过私有 typedef，但我想就封装的想法而言，它没有任何问题。但是，如果您有一个使用 typedef 的公共函数，那么这不会使 typedef 成为您接口的一部分吗？
我想您可以在某些成员函数或私有成员函数接口中使用私有 typedef。但是，如果您想在公共方法上使用它，则 typedef 也必须是公共的才有意义。
我不知道标准对这个主题有何规定，但我猜它是为数不多的灰色地带之一。我认为它取决于编译器如何处理类中 typedef 的实现，您可以确定在公共方法中使用私有 typedef 是否可以接受（或者根本可以接受）。为了安全起见，我还是公开一下吧。
如果您担心暴露 typedef，那么不要在任何公共成员函数的原型中使用它（但这仍然可能被某些编译器拒绝）。如果您担心名称冲突，请不要担心，因为任何外部代码都必须使用实际的类名来解析范围。
我认为您可能对封装的想法有点太过分了。
I have rarely if ever seen a private typedef, but I guess there is nothing wrong with it with respect to the idea of encapsulation. However, if you have a public function which uses the typedef, then doesn't that make the typedef part of your interface?
I would imagine that you could use a private typedef inside some member functions or private member function interfaces. But if you want to use it on a public method, it only makes sense that the typedef be public as well.
I don't know what the standard says about the subject, but I would guess it is one of the few gray areas. I would assume that it is dependent on the compiler's implementation on how to handle typedefs in a class that you determine if it is even acceptable to use a private typedef in a public method (or even acceptable at all). To be safe, I would just make it public.
If you are worried about exposing the typedef, then don't use it in any public member function's prototype (and still that might be rejected by some compiler). If you are worried about name-clashes, don't, because any outside code will have to resolve the scope with the actual class name anyways.
I think you simply might have taken the encapsulation idea a bit too far.
当您需要不透明类型时，请使用不完整的类（并在实现文件中完成它，而不是头文件）。
但在您的特定示例中，在我看来不应该使用不透明类型。
When you need an opaque type, use an incomplete class instead (and complete it in your implementation file, not header file).
But in your particular example, it doesn't look to me like an opaque type should be used.