C++ VS Java

>>165
1.2以降、あまり変更はされてない。

>ほぼ同時期に生まれ
どちらも、開発者内輪での発表、公式アナウンス、公式仕様書リリース
までかなり時間的な幅がありますね。C++なんて最初はCのマクロで作られていたとか...
要するに共にCでの開発で感じた基本的問題の為にCを元に新たな言語を作ろう
として結構長い時間（２０年近く）かかって作られたって漢字。
ほぼ同時期（CやPascal系での開発ブーム（SDI計画？）が終わって一息の頃）
に考えられた言語であると言ってもいいと思います。
C++はCでは高級言語にしては小回りが効く反面トリッキーすぎる
（つまり暗黙の型同一視や変換がゴロゴロ転がっている）ロジック
にならざるを得ない場合が多く、結果的にバグ頻出でやってられないワ
という反省から、
JavaはCで大人数で共同開発するのは規模的な限界が有り過ぎという反省
から生まれたものでしょう。

JAVAよりC++のほうが十年以上早いわけだが

なんだかんだいって、Javaに見られる文法・ライブラリ選択、実装面の技法の
完成度から察して、あれが５年や１０年の準備期間も無しに１９９５年のアナ
ウンスから１年程度でリリースすることが出来る代物なのか、よーく考えて
みようね。
Java開発プロジェクトは数十人から数百人の専門家による延べ数万時間以上
の討議のもとに作成された未曾有の大プロジェクトであったと想像される。

全体的な文意には同意も否定もしないけど、「延べ数万時間」では中規模程度で
とても大規模とはいえないと思われ。

「延べ数万時間」ってことは「延べ1万日」くらいってことで「延べ30年」となって30人で１年か。
たいしたことないな。

ちなみにOakは1990年からだっけ？

ごく最近のことであってその気になれば史実を知ることも可能なのだろうから、
「XXXなのだからYYYであったはずダニ！」みたいな観念的歴史創造主義を
持ち出すのはちょっと気持ち悪い。。。

JavaはC++より前に作られたんですよ。C++はJavaのパクリ。

JavaはCより前に作られたんですよ。CはJavaのパクリ。

我々はK&RとBjarneに補償と賠償を要求するニダ！！

>>167
http://www.ils.unc.edu/blaze/java/javahist.html

January 15, 1991
"Stealth Project" (as named by Scott McNealy) brainstorming
meeting in Aspen with Bill Joy, Andy Bechtolsheim,
Wayne Rosing, Mike Sheridan, James Gosling and Patrick Naughton.

February 1, 1991
Gosling, Sheridan, and Naughton begin work in earnest.
Naughton focuses on "Aspen" graphics system, Gosling on
programming language ideas, Sheridan on business development.

今後予想される167の発言
Javaの構想はC++より以前か同時期であったと想像される。
しかもすでにほぼ完成していた。(70%)

C言語を拡張しようという試みはそれこそ１９８０年代頃から盛んに為されて
いただろうよ。特に標準ライブラリが大規模開発のボトルネックになっていたり
やはり古典的な構造体だけじゃ現実の問題に現われる複雑なロジックを記述する
のには向かないという認識はC言語（等の古典的な構造化言語）による開発全盛期
の時代であった１９８０年代の共通の認識だったと思う。こういった問題を回避
する為の技法を集める人が出てきてそれがJavaやC++の源流になっていることは
確か。C++の場合は当初はプリプロセッサをインテリジェントにしたもので対応し
ようということで、割合と早くからβ版（仕様も含む）に相当するものが出回った。
しかしJava（の源流）となるもののほうは、ウリは蓄積したライブラリを整理
統合し標準ライブラリを置き換えるというもので、これはかなり時間がかかって
いる。膨大なソースコードの統計を取る作業が必要だから。
言語文法拡張は９０年代のリリース直前にC++の影響を受けて急遽行ったとさえ
いえる。（ポインタ概念の除去は重要なセールスポイント）

中身の無い長文を書くのもなかなか疲れるな。

脳内Javaが昔からあったんだと主張するなら脳内Cはもっと遡るだろうよ

この理論で行けばあらゆる高級言語は大昔から考えられていた事になるな。

ニダの出番ニダ

C言語のコンパクトな記述能力を最大限に評価しそれをより複雑で大規模なものに
対応できるように努力し改良されたものがC++。
コンパクトな記述性をやや犠牲にしながらも、C言語との上位互換性を最大限に
維持し、同時に少人数による短期集中開発だけでなく、大人数による中長期持
続的開発の分野ではCやC++言語がかなり弱い欠点を補う為の対策を施して作ら
れたものがJava。
.NETの３言語（VB.NET J#.NET C#.NET)も基本的にはこの流れを汲むもの。
で、いいよね？

C#は、Cが考案される１０００年以上前から
ヨーロッパの一部で使用されていたものだが？

　Ｃってウィンドウ作れないじゃん。死ね。

>>182
第３章　Windowsのプログラムを作ってみる
http://www.kumei.ne.jp/c_lang/bcc/index.html

>>180
よくねぇよ。それなら何でJavaはVMを使ってるんだ？
Javaは元々は家電等への組み込みを目的とした言語だった。
だから「マルチプラットフォーム」を意識した作りになってる。
ま、そのころはまだJavaとは呼ばれて無かったかもしれんが。

>>183
それはAPIだろ
C単体でできないなら意味ないじゃん

>>185
JavaもAPIなしではできないよ






え？AWTやSwingは標準だからどこでもできるって？
何かにつけてJ2EEとかいいだす人達だからJ2MEがあるって知らないと思わなかったYO！

まあjava房の大半はAPIと言語の区別なんて
気にもしたことなさそうだな。

>>186-187
Javaっていったときには、APIも含んでるんだよ。

>>188
どのAPI?
C++ ももう少しライブラリが整備されてもイイよね。
GPL じゃないやつで。

boostは？

標準。J2SE だろ。

C++を使用して作成したライブラリ、を使用していない Java(+API)と
C++を比較しようや。

>>192
なんで？
そしたら、C++の場合はアセンブラで記述されたものを含んだらだめなんだよね？

>>189
環境が決められないからだめでしょ。

>>187
> まあjava房の大半はAPIと言語の区別なんて
> 気にもしたことなさそうだな。
java.langパッケージはアレだからな。

>>192
JavaはObjectクラスやStringクラスがないと話にならないのだが、
ObjectクラスなどもAPIと呼ぶべきだというのか？

というかコアAPIというものだな。
コアAPIは標準仕様

>>197
Object やら String が無いと言語仕様を書き直さないといけないねぇ…

言語とAPIの区別ができない人なのかな？

>>198
何ゆーてんの？

>>198
C++は言語とAPIとがべつもんだけど
言語の中にAPIが統合されている言語を知らんのか？

JAVA自身でVM作れるようになってから出直して来てください

お前が作ってみろよ。
おっと、JavaCC使うとかいうのはなしだぜ

VM on VM って最近は結構よくある手法なんですけど

>>190
boost は良いですよね。
net とか inet とかのネームスペースのライブラリも出てくるといいんだけど。
昔で言うなら sokect ライブラリ（←今もか）。
OS 毎の違いをその辺で吸収して欲しい。。。

>>201
jikes
joeq

jikesってコンパイラかと思ってたんですがVMだったんですか？

しかもjikesってC++でかかれてたはずなんですけどそのへんどう思われますか？

ttp://www.ibm.com/developerworks/oss/jikesrvm/

> A distinguishing characteristic of Jikes RVM is that it is implemented in the Java

つたない英語で読む限り、Java言語で書いてあってVM on VMじゃないので、>>201が「Javaじゃ作れないだろ」と思ってたものに一致するのではないかと。

MじゃなくてVM。APIじゃなくてVAPIだろ。

>>202
JavaCC でどーやって VM 作るんだろ？

VMの上で動くVMだったら作れるんじゃないの？

>>212
バイトコードをさらに構文解析(?)するのか？
JavaCC 使っても、あんまり VM 作りの役には立たんと思うぞ。

C++ は難しすぎるよね。
C と OOP の最小公倍数をめざすとこんな漢字なのかな。
OOP言語としては、過渡期のものだと思う。
確かに中途半端。

でも、メモリ管理でもなんでも、プログラマの責任において
やらなくてはならない、 C/C++ の学習って、大切だと思う。

>>214
最小公倍数じゃない。