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

[b-free: 1186] Re: スケジュールについて




隆一です。


From: makotan@a2.mbn.or.jp
Subject: [b-free: 1183] Re: スケジュールについて
Date: Tue, 31 Mar 1998 03:28:57 +0900 (JST)

> 
> 
> > さて、GCC が C++ の機能を使うには、ランタイムによるサポートが必要にな
> > ります。ランタイムライブラリ自体のソースは C++ に添付されていますから、
> > そのソースを何もない状態で動かすように移植することになるでしょう。
> > GCC のランタイムライブラリは、もっと低レベルの OS の機能を使って実装さ
> > れているわけですが、その OS の機能をエミュレーションすることになります。
> > 普通 GCC は、OS の下で動きますから、ランタイムライブラリをエミューレー
> > ションすることなどは想定されていません。GCC の内部処理と OS の詳しい技
> > 術者を持ってきても、多分、一年がかりの作業になるでしょう。
> 
> えーっとこのあたり勘違いしているようなので...
> C++はCのライブラリの上に作られています。
> だから...C言語が普通に動くのならC++でも動くはずなんですけど...
> まぁ、例外処理まで使いたいって思えば別ですけど。

いえ、勘違いはしていないと思います。
makotan さんは、GCC を調べて、こう書いているのでしょうか?
もし、GCC を調べたことがないならば、ぜひ調べてみることをお勧めします。
なかなか興味深いことがぞろぞろ出てきます。

たとえば、constructor があるクラスを型とする外部変数を宣言した場合、
main より先に外部変数の constructor を呼ぶ必要があります。
GCC の場合だと、コンパイラが main 関数であるかどうかをチェックして、
main 関数の中でユーザのコードを実行する前に特別な関数を呼んで外部変数
の constructor を実行します。

この動作は、GCC 1.x の時にはなかった( C++ と C のコンパイラが別だった
から)のですが、GCC 2.x になると通常の C としてコンパイルした場合でも
行われます。そのため、、B-Free OS の作成している時にコンパイラのバージョ
ンを変えただけで、動かなくなってしまったことがあります(何も実行してい
ないハズの個所で crash してしまった)。

ただ、この辺は、バージョンが違うと動作も違っているみたいです。
最近の GCC (2.7.2)では、main 関数の先頭で特別な関数を呼ぶコードは出て
いませんでした。スタートアップルーチンの方に移動したのかもしれません。

それと、注意しなければいけないのは、OS の中では C のライブラリ関数すら
呼べないということです(C 言語が普通に動く環境ではない)。これも落とし穴
で、場合によっては明示的にライブラリ関数を呼ばなくてもコンパイラが勝手
にライブラリ関数を呼ぶコードを生成してしまうことがあります。特に GCC
の場合、C++ のいろいろな機能をサポートするためにコンパイラが裏でいろい
ろやっていそうです。

C 言語としてだけ使うならば、コンパイラが勝手にライブラリ関数を使わない
ことがある程度期待できます。、明示的にライブラリ関数を呼ばなければ、そ
れほど気にする必要はありません。



> 
> > さらに、オブジェクト指向の場合、ライブラリ化が重要になります。このオブ
> > ジェクト指向のライブラリについては、使う方も作る方もそれなりの労力がか
> > かります。使い物になるオブジェクトライブラリを作るには、2、3年かかるで
> > しょう。ソースの量も、数万ステップを越えるものになります。
> 
> これはオブジェクト指向だから大きくなるとか一概に言えないと思います。
> たしかに...オブジェクト指向のクラスライブラリの作成には手間がかかりま
> すが..だからといって数万ステップを必ずしも越えるものじゃないと思います。

数万ステップというのはかなり控え目に出した数字ですが。。。
まぁ、問題はステップ数より手間(時間)の方ですね。



> > 実際、C++ により OS を書き換えるというのは、UNIX でも試みられたことが
> > あります(system V の後継)。しかし、最終的には C++ への書き換えは失敗し
> > てしまいました。このときは、SUN と AT&T の技術者が共同で作業したはずで
> > す。AT&T といえば、C++ の総本山で、C++ に詳しい技術者もいたはずです。
> > しかしながら、そういうところですら OS を C++ で記述することに失敗した
> > わけです。
> 
> C++に詳しくてもオブジェクト指向に詳しくないとそれほど意味がないと思い
> ます。C言語を知っていても構造化の考え方をわかっていなければCの持つ利点
> を生かせないのと同じです。
> (AT&Tにオブジェクト指向を使える人がいないとは思えませんが...)

もちろん、C++ 言語の知識の他にオブジェクト指向の考えかたも知っている必
要があると思います。でも、そういう知識があっても( SUN と AT&T の技術者
がそういう知識がないとは思えない)、OS の C++ 化に失敗したわけです。



> > 新しいところでは、Windows NT の場合でもウィンドウマネージャに C++ を使っ
> > て、作業が大幅に遅れたということがあります。
> 
> あれは...別の方向から遅れたという話も...

Windows NT については内部事情は当然知らないのですが、「闘うプログラマ」
を読む限り、Window マネージャを C++ で書いたことがスケジュール遅れの理
由のひとつであることは確かみたいです。
(で、C++ で書くことに反対したカトラーに皮肉を言われている記述がありま
したね)


> > こういう事実を見る限り、オブジェクト指向言語、特に C++ で OS を書くの
> > は、時間および作業量が大きくなるであろうことはまず間違いないでしょう。
> > 
> > 
> > また、API (実際にはライブラリになると思いますが)、にオブジェクト指向を
> > 使うことも懐疑的です。アプリケーションを書く時に使いものになるオブジェ
> > クト指向のライブラリを作るのは、非常に大変な作業になります。
> 
> そうですか?
> Delphiもオブジェクト指向のライブラリですよ。
> Javaはクラスライブラリだけしかありませんよ。

で、それらのクラスライブラリを作るのにどの位の時間がかかりました?
まともに使えるライブラリを作る手間、それが問題なんです。もちろん、クラ
スライブラリを作れないということは思っていません。



> > オブジェクト指向のライブラリは、個々の関数がクラスという関係でつながり
> > があります。個々の関数のことを考えればいいライブラリに比べ、クラス階層
> > という別の見方でも考えなければいけないオブジェクト指向ライブラリを構築
> > するのは、作り直しを何回も行う必要があるでしょう。MCF などを見ると、何
> > 回作り直されたか。。。。
> 
> あれは...元々のクラス構成が悪かったんですよ。

そう。多分、クラス構成が悪いんでしょう。
多分、開発者はオブジェクト指向の知識もない人だったんでしょう。



> > # 再利用できる、というのはオブジェクト指向のウリなのに。
> > # 肝心のライブラリが変わったんじゃ再利用もあったもんじゃない。
> 
> 勘違いしていると思います。
> 
> たとえば、VCL1で作ったアプリが10本あればそれはVCLを再利用してい
> ると言えます。オブジェクト指向の再利用というのはそういった意味です。
> 確かに、VCL2になってVCL1と互換性が全くなくなったのであれば問題で
> すが...互換性を維持させるための方法としてCORBAを提案したのに...

いや、だから文脈がずれているんですよ。
プロジェクトとしてスケジュールが遅れているという問題に対して、
CORBA を採用するというのは、私としては賛成し難いものがあります。



> MFCは一般的に最悪のクラスライブラリといわれています。
> そのMFCをクラスライブラリの代表みたいに書くのはやめてください。

でも、MFC が一番使われているのでは?
そういえば、Borland の C++ コンパイラでも MFC を使えるようですね。



> まえに別のところで話していたことがあるのですが...
> 
> オブジェクト指向やCASEツールを初めて導入したプロジェクトが失敗したときに
> 多くの技術者がそういった「新たに導入したもの」を悪者にするということを話
> していました
> 
> でも、その後しばらくその技術を使っていくうちにプロジェクトは成功に向かっ
> ていったそうです。
> 
> その時の結論というのは単純でした。
> 「ある程度開発したところで一度そのプロジェクトのいいところ・悪いところを
> 検証して悪いところをざっくばらんに話し合って解決しましょう」という感じの
> ものでした。

私の言っていることは、この話とは矛盾していません。
makotan さんの話は、オブジェクト指向を使って成功するには、プログラマが
オブジェクト指向を知らないとダメということを示唆しています。

多分、makotan さんが出した話は、アプリケーションの場合だと思います。言
語処理系の中身を知る必要がないアプリケーションを、オブジェクト指向で作
るときでさえ、ちゃんとした知識がないとプロジェクトは失敗してしまうとい
うことです。

# でもなー、オブジェクト指向を初めて導入したプロジェクトで失敗するのは
# 当然な気もする。そのプロジェクトを担当したプログラマたちは、プロジェ
# クト参加時、オブジェクト指向についてどのくらいの知識があったのでしょ
# うか? 


そして、OS の作成にオブジェクト指向言語を適用するのは、さらに大変です。
なにしろ、アプリケーションの場合には知る必要がなかった言語処理系の中身
を知らないと動かないんですから。



> B-freeがオブジェクト指向OSを目指すか否かは今後の話しだいだと思いますが、
> いま、ここでこれだけオブジェクト指向に対して悪い印象を与えるというのはあ
> まりよくないと思います。

でも、オブジェクト指向の利点ばかりを言っているのもフェアじゃありません。
makotan さんは、これまでのメイルを読む限り、オブジェクト指向を好ましい
と思っているように思います。それはオブジェクト指向を採用した場合のリス
クを考えた上でのことでしょうか?

オブジェクト指向もひとつの技術にすぎません。長所もあるし欠点もある。
オブジェクト指向を使ったからといって、魔法のようにプロジェクトが進むわ
けではありません。

クラスライブラリどころか C 言語のライブラリすら使えない環境でオブジェ
クト指向言語を使うのは、あまり利点がないと思います。
逆に、ちゃんとしたクラスライブラリがある環境で、アプリケーションを作る
場合には凄く利点があるとも思います(それでも、オブジェクト指向とクラス
ライブラリの知識があることが前提ですが)。

オブジェクト指向を使って開発する場合の大変さは、開発の対象によって変わ
ると思います。アプリケーション < クラスライブラリ < OS の順で大変さが
増えてくるのではないでしょうか?


makotan さんがオブジェクト指向を採用することがプロジェクトの成功への道
だと信じているならば、説得するのに一番効果的なのは作ってみることです。
不完全とはいえ、動く中心核のソースがあり、フリーで使える Linux という
開発環境もあります。そこまであるんですから、C++ を使って書いてみること
自体はそれほど努力することなくできるはずです。
もし、それができないというならば、なぜできないかを考えてみてください。
おそらく、それは私がオブジェクト指向を採用するのに反対する理由と同じも
のです。

私は、私の技量を知っています。もし、私が C++ でオブジェクト指向の OS 
を書けと言われたら、かなりの時間がかかると思うのです。
(もちろん、私がオブジェクト指向のプログラマとして高いレベルというわけ
ではないですが)



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