Swift 与 C++ 互操作性的讨论

2020年10月17日

Swift GitHub repo 更新的一份文档讨论了 Swift 与 C++ 之间 API 层面互操作性的设计和权衡。

讨论前提

假设会对 Swift 的语言特性和标准库进行修改:

  • 所提出的修改必须符合 Swift 的目标和理念。也就是说提出的修改必须有合理的理由被 Swift 社区接受。例如,在 Apple 平台上对 ABI 进行破坏兼容性的变更不可能被接受
  • 对 Swift 语言或标准库进行 fork,或在没有 fork 的情况下创建一门方言(并因此导致改变 Swift 的目标、理念、安全性和工效设计)同样不会被考虑或讨论

假设会对 C++ 代码、工具链、标准库实现以及 runtime 环境进行有限的修改:

  • 必须要考虑此类修改的成本。对于需要控制完整工具链的用户而言,为 C++ 进行 ABI 兼容方面的变更也许会被接受。但对于整个社区来说这不是必需,因此这种改动只会被视为优化

目标

对于 API 用户来说,互操作性应该在各方面最大限度的透明化:API 设计和效率提升、编辑器集成和工具,以及性能。对于 API 开发商来说,互操作性不应成为重大的额外负担,并允许 API 开发商对导入的 API 进行组织。

API 设计和效率提升主要是指使用 Swift 的开发者不会感受到原生 Swift API 和导入的 C++ API 之间具有差异。

例如,虽然在 Swift 中可以编写自定义哈希表,但很少这样做,大多数代码都使用Set和 Dictionary。因此,当把使用std::unordered_map或 flat_hash_map类型的 C++ API 导入 Swift 时,如果继续使用这些 C++ map 类型,这样的写法在 Swift 中看起来就会很怪异。

编辑器集成和工具方面的设计会参考 Swift 与 Objective-C 互操作性的机制。即在可能的范围内,所有的编辑器操作对互操作都应有良好的支持,例如如果调用"rename function"函数进行重构,就应该在 Swift 和 C++ 代码中重命名所有定义、声明和用法。

性能方面,当在 Swift 中使用 C++ API 时,理想情况下和在 C++ 中使用保持一致的性能特征。

事实上,上面提到的目标存在某方面的冲突。例如 API 工效设计和性能之间的冲突。如果在 API 边界自动将 C++ 类型桥接到相应的 Swift 类型,则可以提供更符合工效设计理念的 API,不过这样的类型转换会造成较大的 CPU 开销。

文档还详细阐述了许多暂定的设计方案,详情点此查看

展开阅读全文
4 收藏
分享
加载中
精彩评论
从入门到重新入门
2020-10-18 15:43
5
举报
一门iOS开发人员都不大喜欢用的语言。。。
2020-10-18 11:42
2
举报
“例如,在 Apple 平台上对 ABI 进行破坏兼容性的变更不可能被接受”。啊这,Swift不是每个版本都一定会破坏吗?
2020-10-18 00:53
2
举报
最新评论 (9)
我*~!尼ma,又改?
2020-10-20 20:41
0
回复
举报
`Swift`相比`Objective-C`的缺点是不能和`C++`混编。
2020-10-19 09:31
0
回复
举报
还是好好优化 ObjC ,做好 ObjC/C 和 Swift 的API 边界类型转换吧。
2020-10-18 17:41
0
回复
举报
从入门到重新入门
2020-10-18 15:43
5
回复
举报
一门iOS开发人员都不大喜欢用的语言。。。
2020-10-18 11:42
2
回复
举报
谁说的额,撸swif代码比oc爽多了。唯一不太友好的就是对c++
2020-10-21 14:56
0
回复
举报
您好,请问为什么不能用java开发ios应用?java转swift开发ios有的吗?
2020-10-18 08:45
0
回复
举报
这个沙雕不会是机器人吧,哪里都有!
2020-10-20 09:23
0
回复
举报
“例如,在 Apple 平台上对 ABI 进行破坏兼容性的变更不可能被接受”。啊这,Swift不是每个版本都一定会破坏吗?
2020-10-18 00:53
2
回复
举报
更多评论
9 评论
4 收藏
分享
返回顶部
顶部