作業系統用 OOP 來寫不好嗎?
泡泡
在課堂上老師有提到， Windows NT 的程式是用物件導向
的方法來寫，這也是 NT 跑得比較慢的原因之一，
(當然，它還有其化很多慢的原因)，
作業系統可以說是分秒必爭的軟體，
真的不適合用 OOP 的方法來寫嗎 ?
--
（ ）
︶︶╯︶╯
[32m / [35m / [36m /
[32m ◢◣ [36m◢◣ [31m / [33m / [34m / [37m / 下雨了...
[32m ◢██◣ [36m◥◣
[32m ◢████◣ [36m◥◣
[m [1;33m※ 來源:‧輔大美少女夢工場 bbs.svdcc.fju.edu.tw‧[FROM: TS1-PPP-02.fju.] [m
滿腦袋醬糊...
==> nothi...@bbs.svdcc.fju.edu.tw (泡泡) 在 oop 版提到:
: 在課堂上老師有提到， Windows NT 的程式是用物件導向
: 的方法來寫，這也是 NT 跑得比較慢的原因之一，
: (當然，它還有其化很多慢的原因)，
: 作業系統可以說是分秒必爭的軟體，
: 真的不適合用 OOP 的方法來寫嗎 ?
不會吧... NT不素用OO觀念寫成的吧...
看看那郭捷徑就豬到了呀...
OS/2是用OO的觀念寫成的, 不慢呀...
以前還看過一本書, 大致上是教如何用Assembly寫OO呀...
Loser
--
睡。醒【萬芳】 【曲：中島美雪 詞：許常德】
愛 永遠都不睡 始終清醒 心疼不歇
我好想妳 不論日日夜夜
反反覆覆 深深切切
愛 別讓我等太久
嵐雲
==> 在 Lose...@vlsi1.iie.ncku.edu.tw (滿腦袋醬糊...) 的文章中提到:
: ==> nothi...@bbs.svdcc.fju.edu.tw (泡泡) 在 oop 版提到:
: : 在課堂上老師有提到， Windows NT 的程式是用物件導向
: : 的方法來寫，這也是 NT 跑得比較慢的原因之一，
: : (當然，它還有其化很多慢的原因)，
: : 作業系統可以說是分秒必爭的軟體，
: : 真的不適合用 OOP 的方法來寫嗎 ?
: 不會吧... NT不素用OO觀念寫成的吧...
: 看看那郭捷徑就豬到了呀...
@#$@$#!
: OS/2是用OO的觀念寫成的, 不慢呀...
: 以前還看過一本書, 大致上是教如何用Assembly寫OO呀...
: Loser
Zombie Chuang
On 14 Jun 1998 23:14:43 GMT, 嵐雲 wrote:
=>==> 在 Lose...@vlsi1.iie.ncku.edu.tw (滿腦袋醬糊...) 的文章中提到:
=>: ==> nothi...@bbs.svdcc.fju.edu.tw (泡泡) 在 oop 版提到:
=>: : 在課堂上老師有提到， Windows NT 的程式是用物件導向
=>: : 的方法來寫，這也是 NT 跑得比較慢的原因之一，
=>不是!
=>: : (當然，它還有其化很多慢的原因)，
=>: : 作業系統可以說是分秒必爭的軟體，
=>: : 真的不適合用 OOP 的方法來寫嗎 ?
=>: 不會吧... NT不素用OO觀念寫成的吧...
=>: 看看那郭捷徑就豬到了呀...
=>誰跟你講用 oop 寫出來的桌面系統, 就會有 oo 的東西啊?
=> @#$@$#!
呵，他本來是提用OO 方法寫，如果寫出來的不是OO 的東西.... 那......:-)
不過，當然OO 並不一定要寫出OO-GUI ..... 就是了....
--
別吵，我在思考
殭屍的死人窩 OS/2 資訊站http://grave.dorm13.nctu.edu.tw
殭屍 u852...@cc.nctu.edu.tw
嵐雲
==> 在 "Zombie" <nospam. 的文章中提到:
: =>誰跟你講用 oop 寫出來的桌面系統, 就會有 oo 的東西啊?
: => @#$@$#!
: 呵，他本來是提用OO 方法寫，如果寫出來的不是OO 的東西.... 那......:-)
NT 的 object , 是指一些東西, 如 process, memory, filesystem,
access-token,
等有的沒的, 用 object 的觀念來 implement,
讓整個程架構清楚點, 容易維護 , debug, 擴充,
到 api 層次, 根本就看不到 nt 是否是以 object 觀念建置,
更別提實際操作, UI 等東西了...
: 不過，當然OO 並不一定要寫出OO-GUI ..... 就是了....
0083
【 在 Lose...@vlsi1.iie.ncku.edu.tw (滿腦袋醬糊...) 的大作中提到: 】
: 不會吧... NT不素用OO觀念寫成的吧...
: 看看那郭捷徑就豬到了呀...
: OS/2是用OO的觀念寫成的, 不慢呀...
: 以前還看過一本書, 大致上是教如何用Assembly寫OO呀...
Thanks...
--
[m [1;34m※ 來源:‧動物狂歡樂園 bbs.ee.ttit.edu.tw‧[FROM: pc40-18.dorm.tt] [m
Weber
==> 在 EightCloud@phoenix (嵐雲) 的文章中提到:
: ==> 在 "Zombie" <nospam. 的文章中提到:
NT 要橫跨 x86, Alpha, PowerPC 等 CPU 平台, 不用 OO 是自找麻煩的.
它又有 Sub-System 的觀念, 可支援 Dos, Win32 等 sub-system. 而其
I/O Manager 為應付不同 CPU 的定址法, 用 OO 來解決.
詳情去翻 "Inside Windows NT" second edition.
(我買的時候, 天龍老闆直誇這本是好書, 但會買的人很少, 賣相蠻差的.
聞之, 一則以喜, 一則以憂,
喜的是: 由此可知, 國內還沒幾個人在搞 Window NT Driver, 等 WDM 一殺出來,
又有一堆 hardware 廠商要找人寫 WDM Driver.
憂的是: 大多數人還是不重視 Kernel 技術, 基礎沒打好, 想要超越老外很難,
整天喊著要提振軟體工業, 卻沒幾家公司肯向下扎根.)
: : 不過，當然OO 並不一定要寫出OO-GUI ..... 就是了....
ms...@oboe.cs.nchu.edu.tw
0083 (Bruns...@bbs.ee.ttit.edu.tw) 提到:
: : 以前還看過一本書, 大致上是教如何用Assembly寫OO呀...
: 喔？可以告訴我是哪本書好嗎？ 我想去買....
以前的Borland Turbo Assembler manual裡頭有提到一章 O_O
我那本是差不多五六年前的了...
Chinese
--------------------------------------------------------------------------------------------
舉雙手雙腳贊成，請多多使用國產的OODBMS產品 WOO-DB 吧
現有免費download, http://www.selab.org.tw。 若嫌download太慢
請寄 xkc...@iii.org.tw 索取光碟片
嵐雲
==> 在 WeiPo@phoenix (Weber) 的文章中提到:
: ==> 在 EightCloud@phoenix (嵐雲) 的文章中提到:
: : 難道 fortran compiler 用 c++ 的 oop 寫, 就應該有 oo,
: : NT 的 object , 是指一些東西, 如 process, memory, filesystem,
: : access-token,
: : 等有的沒的, 用 object 的觀念來 implement,
: : 讓整個程架構清楚點, 容易維護 , debug, 擴充,
: : 到 api 層次, 根本就看不到 nt 是否是以 object 觀念建置,
: : 更別提實際操作, UI 等東西了...
: NT 要橫跨 x86, Alpha, PowerPC 等 CPU 平台, 不用 OO 是自找麻煩的.
: 它又有 Sub-System 的觀念, 可支援 Dos, Win32 等 sub-system. 而其
: I/O Manager 為應付不同 CPU 的定址法, 用 OO 來解決.
: 詳情去翻 "Inside Windows NT" second edition.
交大四年級在學校書局買的 :)
micro-kernel, 有助於 跨平台 (加上 HAL),
nt subsytem, 有 win32, os/2, posix,
dos 不是 subsytem, 還是在 second edition 有大改變?
不過這些和 oo 有絕對的關係嗎?
我不清楚...
Jiang-Shing Wang
> : access-token,
> : 等有的沒的, 用 object 的觀念來 implement,
> : 讓整個程架構清楚點, 容易維護 , debug, 擴充,
> : 到 api 層次, 根本就看不到 nt 是否是以 object 觀念建置,
> : 更別提實際操作, UI 等東西了...
> NT 要橫跨 x86, Alpha, PowerPC 等 CPU 平台, 不用 OO 是自找麻煩的.
> 它又有 Sub-System 的觀念, 可支援 Dos, Win32 等 sub-system. 而其
> I/O Manager 為應付不同 CPU 的定址法, 用 OO 來解決.
呃, NT 的 kernal object 和 object-orient 的 object 似乎不太
相同.(如有錯, 煩請指正) 我覺得充其量只算的上是 abstract data
type, 透過 Win32 API 來操作, 不具備繼承, 多型等等性質, 距離
OO 還有一段距離.
一個 OS 要更輕易的跨多 CPU 平台, 清晰且層次分明的分層絕對有
很大的幫助.
ed...@ms7.accmail.com.tw
In <3P72Nb$4...@csie.nctu.edu.tw>, WeiP...@csie.nctu.edu.tw (Weber) writes:
> NT 要橫跨 x86, Alpha, PowerPC 等 CPU 平台, 不用 OO 是自找麻煩的.
> 它又有 Sub-System 的觀念, 可支援 Dos, Win32 等 sub-system. 而其
> I/O Manager 為應付不同 CPU 的定址法, 用 OO 來解決.
這些 sub-system 需要用到繼承?
Cheng-jen Tang
Weber wrote in message <3P72Nb$4...@csie.nctu.edu.tw>...
>==> 在 EightCloud@phoenix (嵐雲) 的文章中提到:
>: ==> 在 "Zombie" <nospam. 的文章中提到:
>: : =>誰跟你講用 oop 寫出來的桌面系統, 就會有 oo 的東西啊?
>: : 呵，他本來是提用OO 方法寫，如果寫出來的不是OO 的東西.... 那......:-)
>: 難道 fortran compiler 用 c++ 的 oop 寫, 就應該有 oo,
>
> NT 要橫跨 x86, Alpha, PowerPC 等 CPU 平台, 不用 OO 是自找麻煩的.
> 它又有 Sub-System 的觀念, 可支援 Dos, Win32 等 sub-system. 而其
> I/O Manager 為應付不同 CPU 的定址法, 用 OO 來解決.
這下真的是在抬槓了
Weber, 你這不是在教壞小孩嗎﹖
第一,UNIX 下看來有一大堆人在自找麻煩了
第二,OS 就是OS, 它們的 API 是 support OO 也好 不 support OO 也好 跟它們是不是用 OO
關係似乎不大
再說 WDM (Windows Driver Model) 在我看來和OO關係也不大
網上這些個 DCOM / CORBA 高手們一定都已經會了
基本觀念是一樣的嘛 你要說 WDM 是 CBP (Component Based Programming) 還合理
一點
大概有人看到這又要抬槓了 CBP 不就是 OOP 嗎 ﹖
抱歉,不是﹗記得OOP的三個特性嗎﹖
舉個例子吧﹕在COM裡, Polymorphism 是不存在的(不要和aggregation搞混了)
在CBP裡要求的是﹕極低的耦合性(Coupling)以及極高的內聚性(Cohesion),(希望中
文沒錯)
這些在 OLE/COM, CORBA, WDM models裡都可以看到
> 憂的是: 大多數人還是不重視 Kernel 技術, 基礎沒打好, 想要超越老外很難,
> 整天喊著要提振軟體工業, 卻沒幾家公司肯向下扎根.)
>
基礎沒打好 的確是個大問題
Weber, 不要誤會了 我真的不是在說你,我們打基礎的地方是一樣的 而且我的基礎差你太多了
四眼的王蟲
"Cheng-jen Tang" <ct...@cat.syr.edu> wrote:
>1. Single Inheritance is considered as the "STANDARD" inheritance. And
>multiple inheritance is usually considered an improper class hierarchy
>design solution. The combination of composite objects and delegation is
>superior to multiple inheritance.
MI 是好還是不好爭議很大, 沒有 MI 的話有些地方實在是很麻煩,
最近 comp.lang.c++.moderated 有一系列的文章在討論 MI 是否是
必要的, 標題是 "Guru of the week #37: Multiple Inheritance", 我引
其中 Bjarne Stroustrup 對這問題的回答:
yMI is not necessary, it can always be replaced by a workaround
involving SI and a bit of delegation.
Similarly, SI is not necessary, it can always be replaced by
a workaround involving a bit of delegation.
These workaround can be painful, though. Occationally, very painful.
Especially if you have to understand and extend a system.
For examples of MI and discussion, see Stroustrup: "The C++
Programming
Language (3rd Edition)" (yes, I know Herb has already done that,
but he didn't ask the question just for his own edification):
sections 12.2.4, 12.4, 14.2.2, 15.2.5, 24.3.2, and 25.4.1
(or simply use the index :-)
四眼的王蟲
--
生命是在黑暗中閃爍的光
Cheng-jen Tang
Yeah, that is for sure.
In the C++ society, MI is treat as a SPECIAL feature.
Many people tend to/do argue whether C++ is a TRUE OOPL or not.
四眼的王蟲 wrote in message <35872f6d...@168.95.195.16>...
>"Cheng-jen Tang" <ct...@cat.syr.edu> wrote:
>
>>1. Single Inheritance is considered as the "STANDARD" inheritance. And
>>multiple inheritance is usually considered an improper class hierarchy
>>design solution. The combination of composite objects and delegation is
>>superior to multiple inheritance.
>
>MI 是好還是不好爭議很大, 沒有 MI 的話有些地方實在是很麻煩,
>最近 comp.lang.c++.moderated 有一系列的文章在討論 MI 是否是
>必要的, 標題是 "Guru of the week #37: Multiple Inheritance", 我引
>其中 Bjarne Stroustrup 對這問題的回答:
>
>yMI is not necessary, it can always be replaced by a workaround
>involving SI and a bit of delegation.
>
>Similarly, SI is not necessary, it can always be replaced by
>a workaround involving a bit of delegation.
This seems very confusing.
It is similar to say "Inheritance" is not necessary.
That is also right.
After all, not only SI or MI, all other characteristics (of OOPL) can
somewhat work around. :)
However, thanks for your input.
>
>These workaround can be painful, though. Occationally, very painful.
>Especially if you have to understand and extend a system.
>
>For examples of MI and discussion, see Stroustrup: "The C++
>Programming
>Language (3rd Edition)" (yes, I know Herb has already done that,
>but he didn't ask the question just for his own edification):
>
> sections 12.2.4, 12.4, 14.2.2, 15.2.5, 24.3.2, and 25.4.1
>
>(or simply use the index :-)
>
>四眼的王蟲
>
>--
>生命是在黑暗中閃爍的光
Thanks again.
My intention is to try to draw people's (at least, in this newsgroup)
attention
from PL/IDE issues (such like VC MFC VCL OWL DCOM CORBA BCB VB Delphi DDK
SDK...)
to the programming issue.
I learned that people in U.S. tend to build the programming/design concept
rather than
learning PL/IDE. They are just tools, aren't they ?
四眼的王蟲
>Yeah, that is for sure.
>In the C++ society, MI is treat as a SPECIAL feature.
>Many people tend to/do argue whether C++ is a TRUE OOPL or not.
那 Eiffel 呢? Eiffel 也是有 MI 的, 你總不會說 Eiffel 也不是
TRUE OOPL 吧.
四眼的王蟲
Cheng-jen Tang
You must have known the reason why people argue whether C++ is an
OOPL or not. Does that have anything to do with MI ?
First, I use C++ all the time. I don't care it is a TRUE OOPL
or not.
Second, MI is A feature. It doesn't lead to a conclusion such that
a language possessing this feature is (or not) an OOPL.
However, inheritance is.
Third, even though there is a rather clear definition of
what OOPL is, it is not like a trivial mathematics theorem proofing.
In the end, it is still a philosophical view of how thing SHOULD be
but MUST be.
From the view of the point of the software evolution, especially
in the software engineering, a design tool usually tends to be
designed in a way that which criteria needs to be met to make the
users easier to follow some certain rules.
We can even predict that from ASM -> B -> C -> C++ -> ? that criteria
will keep growing. (BTW, should it be Dxxxxx ? Ha! just kidding.)
四眼的王蟲 wrote in message <3588fe2...@168.95.195.16>...
>On Wed, 17 Jun 1998 17:49:09 -0400, "Cheng-jen Tang"
><ct...@cat.syr.edu> wrote:
>
>>Yeah, that is for sure.
>>In the C++ society, MI is treat as a SPECIAL feature.
This means "they would try to defend it."
Usually, if you are not convinced, you would not be able to defend
the argument you tended to support. (That's why lawyers make so much money)
>>Many people tend to/do argue whether C++ is a TRUE OOPL or not.
^
I should have put a "BTW," here.
Sorry for the misleading.
>
>那 Eiffel 呢? Eiffel 也是有 MI 的, 你總不會說 Eiffel 也不是
^^ ?? ^^ ??
>TRUE OOPL 吧.
Without "也", the answer is "不會說 Eiffel 不是 TRUE OOPL"
The reason, many people believe so. :>
And it does meet the criteria of OOPL, at least, many people believe so.
>
>四眼的王蟲
Hey, it seems very important to you whether C++ is a TRUE OOPL or not.
Can you tell me why ?
I always just take it as a tool to implement SW which designed using OOD.
I might be missing something here.
Cheng-jen Tang
四眼的王蟲 wrote in message <3588fe2...@168.95.195.16>...
>On Wed, 17 Jun 1998 17:49:09 -0400, "Cheng-jen Tang"
><ct...@cat.syr.edu> wrote:
>
>>Yeah, that is for sure.
>>In the C++ society, MI is treat as a SPECIAL feature.
>>Many people tend to/do argue whether C++ is a TRUE OOPL or not.
>
>那 Eiffel 呢? Eiffel 也是有 MI 的, 你總不會說 Eiffel 也不是
>TRUE OOPL 吧.
>
>四眼的王蟲
Since you mentioned Eiffel, I would like to express my view about this
language.
The goal of Eiffel actually is very similar, pretty much the same in some
sense,
to what I am doing.
The Client and Supplier in component/connector model are requester, and
provider.
However, I tried to introduce another role which, obviously, is the
connector
who is also abstracting the transitions, and the combination of transitions
by other
groups of component/connector set. (In other words, function calls)
The Eiffel is also focusing, or has a "Useful side effect", in their words,
on
the "Software component reuse".
As I said before, the component connecting mechanism is not necessary to be
a programming language.
Eiffel still treats the programming language (a formal methodology) as the
main mean
to describe the transitions (for existing components).
From this point of the view it has no big difference from C++, or others
(OOPL).
And FYI, if MI can make an argument in C++, same in the Eiffel.
Cheng-jen Tang
四眼的王蟲 wrote in message <3589ba06...@168.95.195.16>...
>"Cheng-jen Tang" <ct...@cat.syr.edu> wrote:
>我並不在意 C++ 是不是 TRUE OOPL 這種爭議, 如你所說的
>Programming Language 只是個 tool 而已, 重要是它有沒有符合
>我們的需要. 只不過你的上一封 post 讓我以為你是在強調
>C++ 不是 OOPL 的觀點, 又以這觀點引申到 MI 上, 所以
>我才提出 Eiffel 做反例, 這樣看來是我誤解你的意思.
>
>我了解 MI 有一些潛在的問題, programmer 也有可能在不
>適合用 MI 的時候誤用 MI, 但也有些時候用 MI 比用
>composition + delegation 更方便更適合的時候, 斷言 MI
>就比較不好, 我覺得是抹殺掉了 MI 的優點了.
>
>四眼的王蟲
>
I got your point.
However, the problem also lies here, as you indicated.
Just like this discussion, I just use C++, C, OOPL as classes.
Suppose you agree with this,
class C++ is-a class C, and class C++ is-a class OOPL.
Although MI is (suggested to be) appropriate when 2 base classes are
orthogonal, which does not really meet here.
I believe you can understand what I really mean.
If the "orthogonal" is applied, either saying "class C++ is-a class C", or
"class C++ is-a class OOPL" sounds incomplete.
Incompleteness usually cannot be tolerated by CS people, although it is fine
with me, hey! I am an engineering guy.
In their view, only A ) B , and B ( A is the only way A = B.
(See, another inconsistency is here due to the improper assumption, which
rule out the correctness of the SI. However, why I am trying to say is "if a
PL is an OOPL, then it can be only an OOPL to make it a TRUE OOPL" is the
view of those CS PL people. Odd ? Isn't it ?)
That is why I pointed out the "TRUE" issue.
Another way of looking it, which I was advised by my colleague, the
tolerance of implementing error is reduced.
This problem occurred due to the huge project design, which you might want
to refer Monte Caro (?) seeding tech. about this issue.
Since I am no expert in error tolerance implementation issues, just leave it
here.
四眼的王蟲
"Cheng-jen Tang" <ct...@cat.syr.edu> wrote:
>You must have known the reason why people argue whether C++ is an
>OOPL or not. Does that have anything to do with MI ?
[snip]
>Hey, it seems very important to you whether C++ is a TRUE OOPL or not.
>Can you tell me why ?
>I always just take it as a tool to implement SW which designed using OOD.
>I might be missing something here.
我並不在意 C++ 是不是 TRUE OOPL 這種爭議, 如你所說的
Programming Language 只是個 tool 而已, 重要是它有沒有符合
我們的需要. 只不過你的上一封 post 讓我以為你是在強調
C++ 不是 OOPL 的觀點, 又以這觀點引申到 MI 上, 所以
我才提出 Eiffel 做反例, 這樣看來是我誤解你的意思.
我了解 MI 有一些潛在的問題, programmer 也有可能在不
適合用 MI 的時候誤用 MI, 但也有些時候用 MI 比用
composition + delegation 更方便更適合的時候, 斷言 MI
就比較不好, 我覺得是抹殺掉了 MI 的優點了.
四眼的王蟲
--
生命是在黑暗中閃爍的光
我愛Bbsterm2.0
: : 在課堂上老師有提到， Windows NT 的程式是用物件導向
: : 的方法來寫，這也是 NT 跑得比較慢的原因之一，
: : 作業系統可以說是分秒必爭的軟體，
: : 真的不適合用 OOP 的方法來寫嗎 ?
: 看看那郭捷徑就豬到了呀...
: OS/2是用OO的觀念寫成的, 不慢呀...
: 以前還看過一本書, 大致上是教如何用Assembly寫OO呀...
用Assembly寫 OO ??
不可能吧！
OO 強調的是 Information Hiding
Assembly 最大的能力就是直接取址，直搗核心，所有東西無所遁形
用 Assembly 寫 OO ?可以嗎？？
--
[m [1;37m※ 來源:‧燦爛陽光 bbs.sunny.org.tw‧[FROM: Annex2-51.cc.fcu.edu] [m