首先：我对 Qt 和 SWIG 都是新手。目前正在阅读这两个文件的文档，但这是一项耗时的任务，因此我正在寻找一些剧透。预先知道某件事是否行不通是件好事。
我正在尝试为一些内部软件制定模块化架构。核心组件采用 C++ 语言，并通过 SWIG 暴露给 Python，以便进行新组件的实验和快速原型设计。 Qt 似乎有一些类我可以用来避免在这里过多地重新发明轮子，但我担心其中一些部分如何组合在一起。
具体来说，如果我创建一些 C++ 类，我需要通过 SWIG 公开它们。其中一些类可能是 Qt 类的子类，或者在其公共接口中公开了 Qt 内容。这似乎可能会引起一些并发症。
Python 中已经有两个 Qt 接口：PyQt 和 PySide。出于许可原因可能会使用 PySide。我希望让 Qt 类的 SWIG 包装的自定义子类与其中任何一个很好地配合，会有多痛苦？我应该预先了解哪些并发症？
PyQt 通过以下方式将 C++ 代码公开给 PythonSIP; 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++ 代码时都会遇到很大的麻烦，并且对于所有相关人员来说通常都是非常痛苦的时间。如果你选择one如果能用正确的方式包裹并坚持下去，问题应该会大大减少。我没有使用 Shiboken 的实际经验（它有点太新了，而且我现在几乎不再做 GUI 应用程序了……我的世界都是 Web 应用程序！-），但过去曾在这个角色中使用过 SIP（早在它被正式记录之前——现在在我看来，它是出色地文档中，对 Shiboken 的粗略细读给了我同样的印象），我可以高度推荐它（事实上，如果我可以选择它，它可能是一个比 SWIG 更好的选项，即使项目中不涉及 Qt 代码）。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
