[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1330] C++ のお話 (Re: b-free:1205についてのコメント (1/2))
隆一です。
# まぁ、C++ についての議論は、すでにあちこちで行われているので、あまり新
# 味はないと思うんですが。。。
From: Hideaki Suzuki <h1suzuki@bridgew.edu>
Subject: [b-free: 1318] Re: b-free:1205についてのコメント (1/2)(Re: オブジェクト指向のOSへの適用)
Date: Fri, 10 Apr 1998 19:10:18 -0400
...[snip]...
> > それから、えーとえーと、例外処理や多重継承、テンプレート機能、それから
> > 名前空間などがバージョンが上がるごとに追加されていきましたが、こういう
> > 機能は追加するようネものではないものと思います。
> > 機能を追加するときに、どういうように追加するかという吟味はもちろんした
> > と思います。
> > しかし、言語全体のデザインという点ではどうでしょうか? 初めからデザイ
> > ンがよかったら、機能を追加するようなことは必要ないと思いません?
>
> Design については、Cの段階から再設計し直したと考えて良いでしょう。
いや、C++ は単なる C の拡張であって、再設計とまではやっていないと思い
ます。
根拠として、Stroustrup の "Data Abstruction in C" という論文の中での註
釈を挙げておきます。
---------------------
(前略)
また、この言語は D とは呼べない。それは、この言語が C の拡張であって、
C の基本構造に固有の問題点を取り除こうという試みではないからである。
C++ という名前は、古い C から変化し発展する性質をよく表わしている。
(後略)
---------------------
> Class を使えるようにするために、しかし no overhead を掲げて、色々な実装
> 項目をどのように実現するか手探りで行ったものと思います。
> その課程で問題点がたぶん大量にでてきたでしょうから、一つずつ慎重に解決し
> ようとした結果が、徐々に機能を追加するという形になったのだと思います。
> で、最近になってようやく一通りのことが終わったので、「標準」が決定したの
> ではないかな。
うーん、むしろ違う応用分野で、種々雑多な要求が出てきて、その解決のため
に言語仕様を徐々に拡張してきたのだと思いますけど。オーバーヘッドをなる
べく低くしようという方針はあると思うけど、そのオーバヘッドの考えかたは
人によってかなり違いがありますから、設計方針としてはあまり当てにならな
いものだと思います。
* たとえば、例外処理の処理方式についての議論だと、
Michael Tiemann (GNU C の人)が、実行時のオーバーヘッドが
少ないという案を出したのに対し、Stroupstrup は例外処理を
使わない場合に例外処理以外の機能にオーバーヘッドがないと
いう案を出しています。
template も同様で、template を使うと実行性能は落ちないか
わりに、オブジェクトの量は増えてしまいます。
鈴木さんも書いていますが、最終的に拡張していった結果 C++ がどうなるの
かは最初の時点 (Class 付きの C) では、見えていなかったと思います。
問題は、C++ は異なった応用分野に対して八方美人的に拡張してきたという点
です。今では C++ は、PL/I 的な言語仕様になってしまったと思います。
対照的に Java では、言語仕様を拡張しないように設計者は頑張っているみた
いですね。
言語に限らず、ソフトウェアやハードウェアの機能を拡張するということはよ
くある話です。その拡張を繰り返した結果どうなるかという話は、TRON チッ
プの話でもよく出てきましたね。
> まあ、Stroustrup が(たぶん冗談で)「なぜ、C++は++Cじゃないの
> か?」と何かで問いかけていましたが、早い話「C++を評価すると、Cに還元
> できる」という話なんですよ。その一方で(副作用で)C+1になってると。
>
> 元々のC++の始まりも構造体を拡張してOOPを実現しようと言う話から始ま
> ったわけですし、最初のC++処理系も、Compiler ではなくC++からCへの
> 変換 program でしたよね。
CFront のことを言っているのでしたら、今でも CFront のやっていることは、
C++ から C への変換でしょう。CFront というプリプロセッサが、C++ の言語
仕様の影響したかどうかまではわからないです。
> だから、言語設計という観点で手探りであったとしても不思議はないと思いま
> す。
うーん、私は、言語仕様にとって生まれがどうこうという話はあまり関係ない
と思っていて、言語設計で徐々に機能を追加するという方針は良くないと思っ
ているんですけど。。。
> # Lisp の上に色々な言語を載せるようなもんだな。
Lisp は拡張という点で無節操にやってきたせいで、泥玉のような言語と言わ
れています。
C++ も Lisp と同じく無節操に機能を拡張してきたということでしょうか?
# だとしたら、私もそう思います :-P
> > Stroustrup の書いた C++ 言語の本を見ると、版が上がるごとにページ数が大
> > 幅に増えています。
> >
> > # おかげで読む気力が萎えてしまう(笑)
>
> でも、あれって、大部分は class library の話ですよね?
> 僕だって、全然、すべて把握しているわけではないです。
1,000 ページになろうという本で、半分がライブラリの話だとしても、半分は
言語の話であるわけで大変であることに違いはないですよ :-)
# 3rd ed. では、テンプレートライブラリについての記述も増えているようで
# すね。
それに、ライブラリにしても、C++ を使う上では読むべき話だし。
> > 更にこれらの機能を追加するごとに新しい構文が追加されているおかげで、コ
> > ンパイラの作成者は大変です(もちろん、ソースプログラムを読む方も大変で
> > す。何とかして (泣) )。
>
> それは思う。(笑)
> でも、構文の追加点は些細な部分も多いですから、program 書く方にとっては全
> 然しんどくない気がしますが。むしろ、冗長さをどんどん避けられる方向に言語
> が改良されましたから、書く方にとっては楽になってきてますね。
うーん、よくわからないなあ。
C++ が機能を拡張したことによって、どこが楽になったんでしょうか :-?
(追加された機能を使わなければ、書く労力は今までと変わらないという話だっ
たら、納得できます)
> > そのうち、ガーベジコレクションやスレッドも入るんじゃなかろうか?
> > (また新しい構文が増えるんだろうなあ)
>
> ははは。(無いと良いですね。^_^;;)
> そう言えば、どっかの本に、CやC++にゴミ集めを導入することに関する論文
> があったな。
> "Advanced Topics in Programming Language" だったかなんか。
> 題名は忘れちゃったけど、、、。(この本手元にない)
> 流し読みしかしてないけど、けっこう、over-head を少なくして可能ならしいで
> すよ。その本では、malloc の変わりになるものを library で提供する形で実現
> していたと思います。
>
> # 詳細が欲しければ調べますけど、、、。
まぁ、ガーベッジコレクションあたりが、インクリメンタルに拡張していった
C++ の限界でしょう。Stroustrup 自身、C++ の言語仕様にガーベッジコレク
ションを(効率的に)導入するのは困難だと言っていますから。
あとは、インクリメンタルなコンパイルやパーシステント(persistent)なオブ
ジェクトあたりが C++ に入るかどうかですね。環境に依存する機能ですから、
C++ という言語仕様には入りにくいですけど、C++だとリンカの例もあるし。。。
> > 余談ですけど、C++ は決して C 言語の欠点をなくそうというものではないん
> > ですよね。C++ への進化は C 言語の拡張への努力であって、C 言語の欠点を
> > 消そうという努力ではない。
>
> Cの欠点というのは言うなれば「何でも出来てしまう」ということですよね。
> そういう事を欠点で意味するなら、そうですね。:-)
> まあ、C++では型検査とかが厳しくはなってはいますが。
というか、C++ が C 言語の拡張であって欠点をなくそうというものではない、
という話は、言語設計者自身がもっている C++ についての考えですね。
逆に、Java だと C の欠点もなくそうというところまで踏み込んでいるみたい
です(もちろん、それが成功しているかどうかは別の話です)。
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