首先：我是Qt和SWIG的新手。目前阅读这两个文档，但这是一个耗时的任务，所以我正在寻找一些破坏者。最好先了解一些事情是否会起作用。
我正在尝试为一些内部软件制定模块化架构。核心组件采用C ++，并通过SWIG暴露给Python，用于实验和新组件的快速原型设计。 Qt似乎有一些我可以用来避免在这里重新发明轮子的类，但是我担心一些比特会如何组合在一起。
具体来说，如果我创建一些C ++类，我需要通过SWIG公开它们。其中一些类可能是Qt类的子类，或者在其公共接口中暴露了Qt的东西。这似乎可能引发一些并发症。
在Python，PyQt和PySide中，Qt已经有两个接口。可能会出于许可的原因使用PySide。关于如何让Qt类的SWIG包装的自定义子类与其中任何一个一起玩得很好，我有多痛苦？我应该提前了解哪些并发症？
答案 0 :(得分：7)
PyQt通过SIP将C ++代码暴露给Python; PySide通过Shiboken这样做。两者都具有与SWIG大致相同的功能（除了它们仅支持“扩展C ++到Python”，而SWIG还有Ruby，Perl，Java等的后端）。 SWIG，SIP和Shiboken都没有设计为彼此互操作。您不能方便地使用SWIG使用Qt所需的C ++扩展来包装任何代码（以支持信号和插槽），我不知道在尝试互操作SIP包装（或Shiboken包装）和SWIG时可能会有什么风险等待您包裹的代码。
为什么，请问，您是否选择使用两种独立且等效的方式来包装C ++代码库的不同部分（Qt通过SIP或Shiboken，其他一切通过SWIG）？如果你仍然可以重新考虑这个奇怪的设计决定，我会认真地建议你这样做。
如果您选择的SWIG是刻在石头上的，那么每当您使用Qt扩展（即插槽或信号）包装C ++代码时，我预测会遇到大麻烦，并且所有相关人员通常都会非常悲惨。如果您选择一种方式进行包装并坚持下去，那么问题应该大大减少。我没有Shiboken的实际经验（这有点太新了，我现在几乎不再做GUI应用程序......我的世界上所有的网络应用程序！ - ），但过去曾使用过SIP这个角色（在它被记录下来之前的回归 - 这些日子在我看来它是精彩记录，并且Shiboken的表面细读给我同样的印象）我可以高度推荐它（事实上，如果我可以选择的话）即使项目中没有涉及Qt代码，它也可能比SWIG更可取。）