アカウント名:
パスワード:
C#に置き換わり、C++は廃れてしまったりするのでしょうか
そんなことないと信じています。 というか、C#ってC++
30年どころか、100年たっても間違いなく生き残るであろう言語が少なくとも2つはあるでしょう。アセンブラとCです。
これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには
Cが今まで生き延びてきた、そしてこれからも生き延びていけるであろう本質は、後から追加が必要になった機能を全てlibraryに押し込めることができるためです。決して新しい機能のために言語の文法や意味論に手を加え、それゆえに過去のsourceを捨ててしまうようなことをしなかったのが強く効いています。その点では、threadingなんか1996年にとっくに実現されているのです。しかも、それ以前に作られたsourceを一切壊さずに。
似たようなところでは、memory allocatorがあります。Cには汎用的なmemory allocatorとしての意味を持つ要素は一切あ
要がCっぽいというのもありますけど、それ以上に注目すべきはそれらのOSで作られたcomponentが実際にはほかのOSでは一切役に立たなかったことでしょうね。片や完全にCで実装したMach VMはBSDにも移植できたというのに。
C++だけじゃなくてオブジェクト指向の落とし穴なんですが、再利用性なんて形をきっちり決めただけじゃ全然実現できないんです。むしろ、外側から見える形に合わせて再利用元を変更するハメになったりして、本末転倒です。言語を設計する側にとってはもの作りのネタになりますが、その上で何十年も保守しなければならないものを作る側としてはまず採用できません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
ISOってなんか意味あるの? (スコア:2, 興味深い)
よく分からないのですが、今のところ.NETフレームワーク以外に使用されるようなことはなさそうですし、標準でなくていいからMSのほうで勝手にやっていてくれという感じです。
ちなみに、
そんなことないと信じています。
というか、C#ってC++
// Give me chocolates!
Re:ISOってなんか意味あるの? (スコア:1)
ISOになると、各国政府がある程度の後押しをすることになってます。
例えば、おそらくJISにもなるでしょうし、情報処理技術者試験の
選択科目にもなるかもしれません。さらにひょっとしたら、中学や
高校の授業でとりあげられるかもしれません。
今すぐの影響は
100年たっても生き残る言語 (スコア:3, 興味深い)
30年どころか、100年たっても間違いなく生き残るであろう言語が少なくとも2つはあるでしょう。アセンブラとCです。
これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには
Re:100年たっても生き残る言語 (スコア:2, 興味深い)
アセンブラについては CPU が存在している限り消えないでしょうが、
C言語に関してはスレッドもサポートしていない言語が
30年、100年後に生き残っているとは思えません。
もし、残っているとしても、今の COBOL 並みの地位にいると思い
by rti.
Re:100年たっても生き残る言語 (スコア:5, すばらしい洞察)
Cが今まで生き延びてきた、そしてこれからも生き延びていけるであろう本質は、後から追加が必要になった機能を全てlibraryに押し込めることができるためです。決して新しい機能のために言語の文法や意味論に手を加え、それゆえに過去のsourceを捨ててしまうようなことをしなかったのが強く効いています。その点では、threadingなんか1996年にとっくに実現されているのです。しかも、それ以前に作られたsourceを一切壊さずに。
似たようなところでは、memory allocatorがあります。Cには汎用的なmemory allocatorとしての意味を持つ要素は一切あ
Re:100年たっても生き残る言語 (スコア:1)
BeOSはC++で記述されていたと思いましたが....。
NeXTはObjective-Cで記述してたのでは?
ま、どちらもCの記述がそのまま使えるから、要の所はCだ、と言われればそれまでですけど。
Re:100年たっても生き残る言語 (スコア:1)
要がCっぽいというのもありますけど、それ以上に注目すべきはそれらのOSで作られたcomponentが実際にはほかのOSでは一切役に立たなかったことでしょうね。片や完全にCで実装したMach VMはBSDにも移植できたというのに。
C++だけじゃなくてオブジェクト指向の落とし穴なんですが、再利用性なんて形をきっちり決めただけじゃ全然実現できないんです。むしろ、外側から見える形に合わせて再利用元を変更するハメになったりして、本末転倒です。言語を設計する側にとってはもの作りのネタになりますが、その上で何十年も保守しなければならないものを作る側としてはまず採用できません。
Re:100年たっても生き残る言語 (スコア:1)
それ、OOが「害」になった、とまで強く言えるんでしょうか?
もしそうでないなら、OOが有っても無くてもせいぜい同じ、という程度のことでしょうね。
で、便利なものは使います。
Vector(動的配列)「クラス」(のObject)が無かったらウンザリするよね、
毎回似たようなコードを書いてたら日が暮れるよね、
しかも似てるけど違う性質の(つまり兄弟の)クラスとかとも一緒に(=多態して)使いたいよね、
とか言い出したら、せめてOOくらい無いと辛いですね。
もちろん、辛かろうがどうしようが茨の道を歩む「自由」は有りますが。
「再利用性」そのものの神話については、たしかにあれは神話でしかないですね。
しかし、逆にいえば、OOを捨てたところで何かが楽になるわけでも無いわけで。
それに、べつにOO(PL)だからって必ずガチガチの設計&再利用オタクに陥らないとならないわけじゃないです。
>んです。むしろ、外側から見える形に合わせて再利用元を変更するハメになったりして、本末転倒です。
そういうことはCだって生じることでは? Cに関数と構造体が有るからには、
再利用性の問題は、クラス(関数と構造体と幾つかの追加オヤクソクの集成物でしかない)
が有る言語と同じくらいに、ついて回るはずです。
たとえば継承(再利用120%の世界)はイタイから必要最小限にしたほうがいい、ってのは
OO内輪ですら既に言い尽くされた話です。OO人だってそれくらいの自衛策は心得てます。
無策で取り掛かれば火傷するのは、どの言語や方法論(?)だって、同じ。
稀に誤解してる人が居ますが、再利用といっても、実際にゃ大型や中型の部品は土台再利用しにくいんですよね。
振り返って冷静に考えればCoding始める前から判りきってる事ではあるんだけど、
システム全体のアーキテクチャに関わるような大きなObject(のクラス)は、一品物と思ったほうがいい。
そして、逆に小さい部品の再利用性は、有効であることが多い。
あたかもネジや釘のような小さくて「イロ」のついてない部品は再利用しやすい。
ここを押さえていれば、再利用性自体は、そんなに御し難いものになったりはしない、んだけどなあ。
大きな一品物をObject(Class)として作るのは、むしろ再利用性のためじゃなく、
「そのほうがうまくまとまる物」であればObjectにするのが良いぞ、という感じだと思います。
今自分が作ろうとしているプログラムがどういう性質のものであるか、によって決まると思います。
ちょうど、ある処理を関数にする基準を、必ずしも「同じ処理の登場回数の多さ」だけで決めないほうがいい、のと同じです。
#もちろん、小さい部品も、同じような調子で、Objectにするほうが似合うものと、そうでないものとがあります。
余談:
ところでC++以外のOOP言語は、どれくらい親しまれています?
>その上で何十年も保守しなければならないものを作る側としてはまず採用できません
それは変ですね。関数という部品の再利用は、(Cを使ってるからには)肯定されているのではないのですか?