Re: [請益] 一個非專業初學者請益如何學習C++

> ==>發信人: [e-mail] (蠍子), 信區: programming
> ※ 引述《[e-mail] (try or test)》之銘言：
> : > Concurrency跟這裡討論的循序化是不一樣的  兩者並不是相反的詞
> : > 循序化就是明確的指定指令執行的內容與程序.
> : 這個討論串的爭議就在 "非循序" .
> : 也就只有 gsj 那麼一句 " OO 是非循序" .
> : 其中一個疑問就是電腦是否能處理 "非循序" 事件 ? 這是底層的細部處
> : 理動作, 而事實上電腦的 interrupt 就是應付非循序事件而來的.
>  如果你主要是回應 gsj 的問題, 那麼在你提出不同 process 的情況時,
>  gsj 已經說這不是他認為 "OO非循序" 的情況了, 如下:
> "我的循序是指 "行程內" 的循序"
> "行程間也是有一個順序規則的"
> "Process 的執行順序會由Scheduler 來排定"
> "(這些東西已經算是OS的議題了，詳情去看看教科書吧)"
> "至於Interrupt  有的是隨機發生(如網路卡、Keyboard)，有的是定時發生(如Timer)"
> "但是ISR內部的執行也是循序"
> "如果它有Task要註冊到Task Queue內執行，它也是循序的"
> [恕刪]
> : > 與循序化相反的是Declarative language, 例如SQL,
> : > 這種language不會列出電腦執行的程序, 只會描述要作的事
> : 不必詳述執行的細節次序, 但要敘述清楚問題項目與結果的 "關係",
> : 如何求解由 compiler/interpreter 去善後. Declarative Language
> : 表面上是跟執行次序無關, 但先得出結果 X , 再混合問題的關係條件
> : 與中間結果得出結果Y, 最後根據 X, Y 與關係條件, 最終得出結果Z,
> : 還是有可能會跟先做 X 還是 先做 Y 這種次序是有關的. 換言之, 前
> : 後次序本身就是一種關係, 先做後做可能會影響結果不同. 宣告某個
> : 段落(或子流程)可以併行或者必須等候某個事件(或條件)成立, 才能
> : 繼續執行, 是兼具 imperative 或 declarative 敘述的特質的.
> : 所謂 導向 (Orientation) 意涵 "主流" "時尚" , 帶有以 XX 為主要
> : 項目的含意. 但這並不表示 "非主流項目" 就完全被排除.
>   直接引用 Booch 在 Object-Oriented Analysis and Design 中的定義,
>   Object Model 的必要條件有:
>         1. Abstraction
>         2. Encapsulation
>         3. Modularity
>         4. Hierarchy
>   非必要條件為:
>         1. Typing
>         2. Concurrency
>         3. Persistence.
>   既然 concurrency 是在非必要條件, 那麼就算 concurrency 確算真的
>   會造成 gsj 所說的 "用非循序的程式設計方式不適合循序的CPU", 又

1. 不受 interrupt 影響的 CPU 執行是循序的, 但有 interrupt 機制的
   CPU 就不全然是循序做事的.
2. 把 interrupt 用 OS 掌管 ISR , 透過 Dispatcher , Process 隔開,
   是在 OS 層之上提供分隔的虛擬執行環境, 這時候的各 process 是併行
   的.

首先, 實體的 processor 有了 interrupt 機制, 其本質就不全然是循序的.
OS 都被歸類有 Concurrent Operation 的成份, 而這種非循序特性還是因應
interrupt 這機制而來的, 這特性並無 "不自然對應" 的現象.

其次, OOPL 在目前的實現形式是架在 OS 之上的 process , 使用者也只是
在個別的 single process 下, 執行其程式, 模組間依舊是同步的 call-
return 或 Synchronous Remote Procedure Call 關係, 在這一點上跟目前
的傳統 PL 是相同的.

但 OO 的 message passing 與 code+data encapsulation 就跨越出不必然
是在 shared memory 架構之上執行的限制, 至少在單機上透過 Virtual 
Memory 隔離的 multi process 間, 其記憶體就不能隨意來往. 假如 OOPL 
子程式間(如某些不透過 interpreter 執行的 OOPL Compiler)是在不同 
process 或 thread 執行時, message passing 的機制(因為使用這個術語
就是有擺脫 synchronous call-return 的習慣涵義), 至少很容易可以透過
外部模組(通常是 OS)同時啟動兩個以上的 server process 併行運作. 因
此架在 OS 之上的 OOPL 有非循序的併行處理能力, 也不儘然是不對稱的.

再進一步, 假如 OS 的 ISR 與 Process Dispatcher 機制被用混合的語言
寫成可配合語言呼叫的模組, 送到 process 外的 message passing 也用 
communication ISR 來處理, 這種 "非循序現象" 就更自然了.

>   跟 OOP 有什麼關係.
> : 命令式語言可以循序化處理, 但也可以宣告某個部分可以併行處理.
>   你在探討的似乎是 "到底要不要把 process model 從 OS 整合成為
>   OOPL 的語法",
>   只是如果把 process model 歸類到 OS 中, 可以廣為大眾所接受,
>   又可以讓 process model 有更大的發展空間,
>   又何必一定要把所有的東西都放到 programming language 中?

想說的是合理又有效率的 "銜接" , 不是誰整合誰.

--
 ◎ Origin: 中央松濤站□bbs.csie.ncu.edu.tw  From: 140.115.6.234