1
sherlocktheplant 2015-10-14 01:01:17 +08:00
应该不会有这么蠢的设计 swift 作者就是 llvm 最初的作者
|
2
Ixizi OP @sherlocktheplant 别应该啊 … 郁闷
|
3
ipconfiger 2015-10-14 01:14:24 +08:00
胡扯!
|
4
Perry 2015-10-14 01:16:39 +08:00 via iPhone
并不关心,反自己用着舒服就可以了
|
5
msg7086 2015-10-14 01:33:29 +08:00
你说反了。明明有现成的编译器组件,为何还要从头重写一遍?
GCC 也好 LLVM 也好,都是分前后端,先转码成一种中间形态,然后再转译成汇编和机器码的。 如果 Swift 是 Obj-C 的一个变种环境,那么做成 Swift -> Obj-C -> 汇编 我不觉得有什么不妥。 |
6
rainex 2015-10-14 02:29:32 +08:00
@sherlocktheplant
是不是这种搞法没细看,但这搞法倒也有先例, C++ Builder 就是先把代码翻译成 Pascal ,用成熟的 Delphi 编译器来生成 Windows 的可执行代码,估计还是有时间和维护成本的问题,不然要说做写编译器,当时 Borland 公司里可是一帮好手,未必比 Apple 弱。 @msg7086 缺点还是有的,多转换一步肯定要慢一点,除非代码量少, C++ Builder 的用户为这个没少骂。 因为这话题,又想起 Anders Hejlsberg 来了,真是个天才。 |
8
dorentus 2015-10-14 08:43:58 +08:00 via iPhone
Swift 一堆 Objective-C 无法支持的特性和数据结构,怎么先编译成 Objective-C ……
|
9
jiyee 2015-10-14 09:17:04 +08:00
如果成立,那 iOS 7 为啥不能用...
|
10
wxl1380610 2015-10-14 09:21:44 +08:00
@jiyee 好有道理
|
11
sherlocktheplant 2015-10-14 09:34:28 +08:00
@Ixizi
我反正搜了很多资料都没提到 swift 编译成 objective-c 的 |
12
sherlocktheplant 2015-10-14 09:38:23 +08:00
|
13
Ixizi OP @sherlocktheplant 上 stackoverflow 地址..
swift 和 objective c 用的同一套 runtime?... |
15
sherlocktheplant 2015-10-14 09:48:23 +08:00
|
16
sherlocktheplant 2015-10-14 09:53:42 +08:00
@rainex
@Ixizi 这里找到一篇讲详细编译过程的 swift 是编译成一种他们自己设计的中间语言 swift intermediate language 再编译成 LLVM IR 再编译成机器码 http://arstechnica.com/apple/2014/10/os-x-10-10/22/ |
17
fo2w 2015-10-14 10:30:57 +08:00
LLVM 那哥们是什么人......
他做什么我都觉得是对的.... |
18
dorentus 2015-10-14 10:33:53 +08:00
@sherlocktheplant 但其实它脱离 Objective-C runtime 也一样可以运行。
|
19
onevcat 2015-10-14 17:20:25 +08:00 1
@Ixizi 编译分为前端和后端,对于 Swift 来说,和 Objective-C 编译上的区别主要在前端(废话...后端的话 LLVM 能编译的语言都是一样的...)。 Swift 编译器先把 Swift 源码转换为 SIL ,就是上面 @sherlocktheplant 说的 Swift Intermediate Language 。 SIL 基本就是对 Swift AST 的组织,然后中间多了一步从 SIL 优化生成 LLVM IR 。到这里之后的后端的话,是和 objc 的处理基本是一样的,因为输入的同样是 LLVM IR 。
转换成 Objective-C 的说法简直是无稽之谈... |
21
cdfmr 2015-10-14 21:39:22 +08:00
@rainex BCB 在编译过程中并没有先翻译成 Pascal ,只是其使用的 RAD 库是 Pascal 语言编写的 VCL 。 BCB 编写的程序,一般由用户代码、 C++运行时、 Pascal 运行时和 VCL 这几部分链接而成,这让很多使用 C++而有优越感的人不爽,高贵的 C++居然需要其它语言编写的库来支撑,因此一直有人建议 Borland 使用 C++重写 VCL 。 BCB 编译器生成的代码运行效率不慢,真慢的话,大部分还是用户代码的原因,比如初学者滥用控件,却因不知控件内部的实现机制导致一些没必要的系统开销,非编译器之原因。
|
22
rainex 2015-10-15 02:22:48 +08:00
@cdfmr
@sherlocktheplant 我都是猜测哈,说 c++builder 和 delphi 的例子,是类比 swift 和 objc ,至于翻译,直接从一种高级语言翻译成另一种高级语言是没必要的,毕竟高级语言代码只是对人友好,对编译器没意义,先都翻译成中间代码(中间代码这个没标准,自家定义),下一步再让编译器产生可执行目标代码即可, c++ builder 里, c++项目里可以用 pascal 写的控件,可以加入用 pascal 写的 unit 代码(但我记得反过来就不行, delphi 里不认 c++builder 代码,由此可以佐证 c++builder 对 delphi 语法和编译部分的依赖,换句话说,后者成前者子集了), swift 和 objc 的关系我觉得也类似,我理解题主所说的也是类似意思,苹果没必要把 swift 翻译成 objc 的明文,出个中间代码就行了,短平快,先让 objc 的编译技术积累发挥一些价值,将来有精力了让 swift 的编译再完备起来。 |