[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1272] Re: オブジェクト指向 のOSへの適用(Re: スケジュールについて)



Ryuichi Naitoh wrote:

> > 例えば、API が、overload を許したとしましょう。そうすると、多くの class member function で、
> > 同じ API を使うようになります。すると、それは多くの code の重複を生みます。重複があるという
> > 事は、継承や template による coding の大幅な削減が期待できます。
> 
> API の overload とは、どういうものなんでしょうか?
> どうも、よくわかりません。
> 
> 同じ API を使うというのが、どうコードの重複とつながってくるのでしょう
> か?

API を、int で呼び出すのか call gate にするのか知りませんが、要するに、
一つの API がいく種類かの引数を受け取れると言うことです。そうすると、
class 側では、おなじ code が吐けるようになります。よって、同じ部分は継承
によってまとめることが出来ますから、自然と小さな code になるだろう
と、、、。

最近思うんですが、BTRON2の bottle-neck になってたのは、Name Manger
だったんじゃないかって。
確かそんな物が存在したような気が、、、。(笑)

記憶が正しければ、Access key と実身を結びつけ API に正しい処理方法を教え
る奴です。

この重たい処理を、継承とOOで結構分散できるんじゃないのかなって。
その辺は、気楽に、Next Generation では成そうと思います。
その時は宜しく。(と言うか、一緒に話を楽しみましょう! ^^)



 
> > OSが exception handling 用の stack を提供したとしましょう。これによって、exception
> > handling の為に stack に特別な処理をする必要が無くなり、compiler の修正が少なく単純になりま
> > す。
> 
> 例外処理時のスタックについては、コンパイラは関与しなくとも実装できます。
> (というか、普通例外処理のためにコンパイラは修正する手間はかけないと思う)

えっと、話しているのは、C++の構造化例外のことです。
もし、良く伝わっていなかったとしたら、説明不足でした。すみません。
Borland C++ では、ちなみに、例外処理をするために、SS:[0] 近辺を使用して
います。

だから、bcc をBTRON1に移植しようとすると、結構面倒くさい。
# と、愚痴ってみる、、、。^^;


> どちらにしても、オブジェクト指向と例外処理とは関係ない機能ですね。
> 話の筋道がずれていませんか?

たしか、例外処理のOOに対する貢献の一つは、生成子の中での error trap だ
ったと思います。
生成子は外部「へ」の連絡方法を持っていないので、例外処理が使えないと非常
に困ったことになります。
例えば、object を生成したことはしたけど、実際は、必要な memory が確保で
きていなかった場合とか。

まあ、一般的には error propagation の標準的な方法が確立されたという方が
大きいかな。
僕は、未だに、long/setjmp の方が好きだけど。

 
> > OSが RTTI を支援したとしましょう。そうすると、compiler の dynamic_cast に関する処理がだい
> > ぶん楽になります。
> 
> えーと、RTTI とは何でしょうか?
> コンパイラの型変換に関係のある機能?
> コンパイラを一から作るのでない場合、コンパイラの処理が軽減されてもあま
> り得がないような気がします。
> コンパイラを書き変えるという話だと、別な労力が必要では?

GNU C++ は、dynamic_cast とか使えなかったんでしたっけ?
まあいいや。<こらこら。^^;

RTTI:- "Run-Time Type Identification" | 実行時型識別

これのおかげで、cross-casting とかが安全に行えるらしい。
# あんまり使ったこと無い。(^^;;;;

個人的には、RTTI/exception-handling の switch が標準で on になっている点
は、bcc の嫌いなところ。
これらを off にすると、20Kは program size が小さくなる。
# というのは余談。


 
> BTRON2 の実身 API については、オブジェクト指向というより、UNIX のファ
> イル程度の処理の切り分けだと思います。

ふーむ。
akey を class object ID とみれば、結構、OOだと思うぞ。

> B-Free OS をオブジェクト指向で作った場合、大変な労力が必要になるのは、
> 鈴リさんも分かっていると思います。
> 
> [b-free 1205] で
> 
> > だから、B-free では、
> >  「よっしゃ、もういっちょ最初っから、考え直すで!」
> > か、
> >  「まあ、OOPも良いけど、とりあえず next version まではこのまま行こう」
> > か、どちらかを選択しなきゃいけないわけです。
> >
> > 後者を選択するなら、とりあえず、完成はぐっと近くなるでしょうね。
> > # 逆に前者を選択したら、大変でしょうねぇ。
> 
> と書いてあるくらいですから。

そうなんですよぅ。
やっぱ、これは、Next Generation ですね。:-)


> 
> p----------------------------------------------------------------------q
> | FROM R.Night                                                         |
> | E-mail:                                                              |
> |         rnaitoh@st.rim.or.jp                                         |
> | Key fingerprint = 89 EB 77 95 40 C0 3C CC  37 A1 A7 FA 1C 66 FF D0   |
> b----------------------------------------------------------------------d


-Aki.