【未完成】RGSS3小探——面向编辑器

yangff

第二节呢？


‘

凭良心说不喜欢Fiber这种严重破坏代码结构的东西……对编码者太不友好了= =，比线程还恶心


──yangff于2012-1-26 20:31补充以上内容’

第七水螰

@orzfly

说到开销……ruby是解释型语言……那么的话eval好像并不会造成太大开销。难道它是先编译成一种过渡代码然后在执行？那样的话每次eval都要编译一次

純解釋器的運作在代碼生成階段以後才與編譯器有所區別，在此之前的詞法分析（tokenization 或  lexical analysis）、語法分析（parsing 或  syntactic analysis）階段都是解釋或編譯必須的過程，lexer 和 parser 都是解釋器、編譯器的組成部分。當 eval 拿到一段字符串後，它需要重新進行詞法分析和語法分析，所以是必然有額外開銷的。對於命令式語言來說，語法分析結束時，解釋器/編譯器將會構建出一個完整的抽象語法樹（AST, abstract syntax tree），而這個樹表示了整個程序的執行流程。此時編譯器將會進入代碼生成階段，抽象语法树會被一次性的轉換為本地彙編或機器代碼；而解釋器則會在整段程序生命週期中保留這棵樹，並通過遍曆這棵樹的節點執行對應該節點的代碼。通常動態語言的抽象語法樹由於具有某些動態性（比如 eval 這樣的元編程操作），都不可能一次性轉換為本地代碼，最多是通過分析 hotspot 進行即時編譯（JIT）。

不過，以上說的是純粹的解釋性實現。Ruby 1.8 及之前的實現是純解釋性實現，也就是所謂的 AST walker，在語法分析結束後直接在語法樹上進行解釋。從 Ruby 1.9 開始，官方的實現採用了 YARV（Ruby 的進程虛擬機），所以 Ruby 代碼會事先被編譯為 YARV 機器碼，之後直接交給虛擬機執行。但無論如何，eval 都逃不過詞法分析、語法分析這兩個階段。

順帶一提，「解释型语言」這樣的說法其實不夠嚴謹，因為語言可以被解釋也可以被編譯 [1]，尤其是在進程虛擬機發展起來以後。編譯性或解釋性不是語言的特性，而是某一個特定的語言實現的特性。像 MRI 就是解釋性實現，YARV 就是帶編譯性的實現。

[1] 比如，C 語言既可以被 GCC 編譯，又可以被 Cint 解釋。Ruby 1.9 的 Ruby 代碼是被編譯為了 YARV 指令。


‘

[@]逸豫[/@]

連send都用上就是不用eval

對於 1.9 來說，send 由於是直接向虛擬機發送消息，所以沒有 eval 的分析時開銷，基本可以看作一種虛擬機的原子操作。在像 Ruby 這種基於 Smalltalk 對象消息模型的語言中，一切方法調用都可以看作是對 send 的調用，只不過通過 send 間接調用時需要用實際傳遞的符號在方法分派表中匹配方法名，而直接用方法名調用則在編譯時就匹配好了。


──第七水螰于2012-1-27 10:16补充以上内容’

orzfly

真是奇怪，明明还有一页。我这水回复一删就看不到第二页了……奇怪的dz

♂雨

看了实在有点头晕......

eve592370698

我还是按照百度百科解释,将纤程理解为面向用户的线程或进程,其重点在于面向用户毕竟Rgss重点是面向业余爱好者而非专业程序员,所以在编程思路上应更加人性化.但是对汉化脚本我特别讨厌纤程这个词因为在形式上一个线程可以包含多个纤程结果容易被人轻视,但实质上线程是才运行程序的最小单位,进一步划分出纤程仅仅是走形式,程序核心并不能识别纤程,一个纤程出现问题整个线程就瘫痪.随着脚本的逐渐复杂,特别是想重写一个脚本,纤程就给人一种特别松散的感觉.

lixiao888

顶下技术帝~~~~

咚小黑

表示看不懂

a1578032454

感觉不是面向编辑器....而是面向天书..一点也看不懂