JavaやるとC++は有害に感じる　int 2

C++に対する各界の反応：

私はオブジェクト指向という言葉を発明したが、C++のことなんて全く念頭になかったね。
-- アラン・ケイ

C++の進化の歴史は文字列の抽象化を漏れを塞ごうと試行錯誤するものである。
なぜ彼らが単にネイティブ文字列を追加しないのかわからない。
-- ジョエル・スプロウスキー

C++は見栄えをよくしたCOBOLとして現在使われている唯一の言語だ。
-- バートランド・メイヤー

もしBjarneがCとの互換性にこだわる必要がなかったとしたら、Javaを開発していたろうね。
-- ビル・ジョイ

C++言語のデザイナーたちは、同じ問題を解決するアイディアが二つあると、いつも「よし、両方ともやろう」と言う。
だからこの言語は私の感覚ではかなり奇怪(baroque)なものになっている。
-- ドナルド・クヌース

歴史的に、他人に使ってもらえるようにデザインされた言語は出来が悪い：COBOL, PL/I, Pascal, Ada, C++.
良い言語はクリエイターが自身が使うためにデザインしたものである：C, Perl, Smalltalk, Lsip.
-- ポール・グレアム

C++なぞ問題外. ^^;;;
-- まつもとゆきひろ

重複乙

>>1
乙

前スレ
JavaやったらC++はきもく感じる
http://pc10.2ch.net/test/read.cgi/tech/1168423655/

>>1
＞良い言語はクリエイターが自身が使うためにデザインしたものである：C, Perl, Smalltalk, Lsip.

Lsip ???

C++をJava並の制約で使えば同じでしょ

Jだと生ソケットできないからC系しかないじゃないか＞＜！
そんな俺はエッチな女の子

両方糞

有害かぁ
確かにC++には確実に生産性に悪影響を与える
メモリ管理の問題が未解決だなぁ
前スレに「解決している」って書いていた人がいたけど。
これについて少し書いてみてくれないか？＞詳しい人

>>7
JNI使えよ

フレームワークを使えばメモリ管理は、それにお任せ。

javaやってると、こんなクソスレ立てちゃうんだから
javaが精神にきわめて悪いのは、立証されたな


javaやると、キチガイになるぞと

バベル案内
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
＞C++と比較すれば、Javaは言語として同程度だ。いや、今のなし。ずっといい。文字列があるもの。…

>>10
解決方法がわかってなんだか肩透かし
今の気持ちを譬えるなら恋人と爆弾を同時に手に入れた気分
ありがとう！

そんな問題じゃなかった..

>>6
その制約を守らない奴がいるから、
同じではない。

そしてポインタ演算の扱い。
そしてString型の扱い。
これはどうしようもない。あのC++のstringは駄目仕様だ。

>>9
つまり、Javaの放射性同位体がC++なのだ。

>>12
キチガイほどそういう発言をする

前スレからのコピペだけど。ﾄﾞｿﾞｰ


Comparison of Java and C++
http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B

C++ Java
backwards compatible with C backwards compatibility only with previous versions
trusts the programmer protects the programmer
exposes low-level facilities memory access only through objects
concise expression explicit operation
allows explicitly overriding types type safety
procedural or object-oriented or functional or generic object-oriented
operator overloading meaning of operators immutable
powerful (abstraction) capabilities of language feature-rich, easy to use standard library

マジ文字列型って困りものだよな

と返しておけばそれで成り立つと思ってしまうのが
Java信者の浅はかなところ。

わかりにくいから貼り付けなおそ。

C++
backwards compatible with C
trusts the programmer
exposes low-level facilities
concise expression
allows explicitly overriding types
procedural or object-oriented or functional or generic
operator overloading
powerful (abstraction) capabilities of language

Java
backwards compatibility only with previous versions
protects the programmer
memory access only through objects
explicit operation
type safety
object-oriented
meaning of operators immutable
feature-rich, easy to use standard library

>>22
そういう発言を脊髄反射するおまえみたいなC++厨のほうが浅はかだよ。
まだまだC++の欠点は膨大にある。

俺にとってはstd::stringは標準の文字列とはいえない。
言語でちゃんと標準の文字列が存在しないというか
C言語の文字へのポインタが文字列っていう考えのまま。

だったらあげてみれば？

ありゃ、>>25 に割り込まれた...。

>>26 は、>>24 のレスな。

もう前ｽﾚですでにかたられてることだと思うが

std::stringは既存の古いライブラリで使うとき

std::string x;
x.c_str()

ってしなきゃならない。

JavaのコンパイラStringクラスをサポートしてるってだけで
あんまり変わらん気がするけど

文字コード意識しなくてもいいStringクラスなら
JavaでもC++でもどっちでも歓迎

この世の文字列を使うDLLの
主要なものほとんどがstd::stringをサポートしない限り
JavaのStringと対等とは思えない。

この世の列挙を使うDLLの
主要なものほとんどがstd::listをサポートしない限り
標準じゃないのに標準テンプレート。

>>32
いやstd::stringは糞だろ。

FDiVqcgvuVgDxiOTPHGOXBPvlQQraSm+OHEV1LTPbQQ=

なかなかの盛況っぷりだな

Smalltalkがすばらしいことだけはわかった

もうC++ってアンチも多い人気アイドル的存在だな。
とっつきにくいし難しいし、いつまでも手の届かない存在みたいな。
そんで、できなきゃいつまでもﾄﾞｶﾀｸﾞﾗﾏｰ。
10年前にはC++なんて10年後にはないだろなんてVBプログラマーに言われた
もんだが、VBやってた連中はみな退職していったな。
VBがJavaに食われたように、10年後にJavaはPHP/Rubyに食われて死んでるかも
しれないけどC++はたぶん今と変わらない位置だろうな。大ブームもないけど
重要な位置では使われ続ける。
言語としての弱点はあるけど、結局OSや重要なOSSはみなCだから、Cが直接
使えてオブジェクト指向ができる折衷案のメリットが大きすぎるんだろうね。

ジョエル・スプロウスキー、て。

D言語次第では既存コード保守用言語に成り下がるかもね

>結局OSや重要なOSSはみなCだから
じゃあ、これからもずっとCじゃね。
Cで十分な所に、あえてC++を持ち出す意味は無い。

boost::any使えばjavaと同じようにコード書けるね

boostが標準になって
まともな言語だな

boost無しなら正直Javaの方がマシ

>>42
んなあほな。

javaのUMLからコード自動生成って便利なの？

便利だと思っている人が使えば絶対に便利。

しかし今はもう、C++vsJavaという構図はあまりないだろうに・・
クライアントで敗北したJavaはサーバサイドという土地を開拓したが、
原住民のPerl/PHPの思わぬ抵抗に大苦戦みたいな感じだな。

Java全然知らないのだが、「Java並行処理プログラミング」読んでる。
まだ３章までしか読めてないが、
楽チンな言語かと思いきや、可視性のあたり結構ムズくない？
マルチスレッド始めたらはC++の方がお気楽な気がする。

まあ言語関係なしにスレッドは概念が難しいもんねぇ・・

Javaで促成栽培されたPGもどきが非常に有害な件について

>>49
ピアソンのやつ？その本Java関連の本の中で一番むずかしい。

>>52
ピアソンのは知らないっす。
http://www.amazon.co.jp/o/ASIN/4797337206/

>>53
今調べてみたらピアソンじゃなかったっす。orz
http://www.amazon.co.jp/o/ASIN/4881359185/

>>48
eclipseみたいにクライアントにも侵食してはいるがね。
まあ、SUNのデザイナはセンス０ってことは同意。

>>44
しかしboostがある
むしろboostがjava作ってほしかった

ttp://gedo-style.net/g/?v=350091&d=d.jpg

ttp://gedo-style.net/g/?v=350098&d=d.jpg

C++？　　　チンコプラプラ？ｗ
C#？　　　 チンコシャープ？ｗ

C?　　　　 ちんこ？ｗ



（・∀・）カエレ！　　　　

（・∀・）カエレ！　　　　
（・∀・）カエレ！　　　　
（・∀・）カエレっ！

>>38
> もうC++ってアンチも多い人気アイドル的存在だな。

C++が人気があるって何時の時代だww オッサンよ。
アンチってほどでもなく放置している存在だがな。

> とっつきにくいし難しいし、いつまでも手の届かない存在みたいな。
> そんで、できなきゃいつまでもﾄﾞｶﾀｸﾞﾗﾏｰ。

馬鹿だな。手に届いても、開発効率が悪いから利用者が少ないだけなんだよ。
それにしても、C++の標準ライブラリがあまりにも糞過ぎるのは救いようがねえな。

> 10年前にはC++なんて10年後にはないだろなんてVBプログラマーに言われた
> もんだが、VBやってた連中はみな退職していったな。

C++やってた連中もみな退職していったな。10年後にはC++は無くなることはなくても
今よりも良い条件にはならないだろうな。言語を進化させないと無理だな。

> VBがJavaに食われたように、10年後にJavaはPHP/Rubyに食われて死んでるかも

認識が甘いな。PHPやRubyをろくに触ったことがないことがよくわかる。
片方は最適化コンパイラも無く名前空間がつかえない糞で、双方は型に甘い言語。
これでは将来も糞も無いな。バージョン互換性の限界も超えられないようでは
未来は無い。それなら、D言語を指示した方がマシだ。


> しれないけどC++はたぶん今と変わらない位置だろうな。大ブームもないけど

仕事が減ってる以上、以前よりもかなり立ち位置は下がっている。

> 重要な位置では使われ続ける。

今のところ、ハードウェア絡みで消えないことは消えないが、
D言語やJava Communication APIが台頭したらどうなるかわからんぞ。

> 言語としての弱点はあるけど、結局OSや重要なOSSはみなCだから、Cが直接
> 使えてオブジェクト指向ができる折衷案のメリットが大きすぎるんだろうね。

はっきりいうが、C++のオブジェクト指向は糞。基底クラスが無い時点で負けている。

>>38
> 言語としての弱点はあるけど、結局OSや重要なOSSはみなCだから、Cが直接

これも認識が甘い。すでにJava + アセンブラで作られたOSが存在するわけだが。
実用性はともかくとして。実現可能異性をみれば、C/C++の立場をさらに
追いつめることも可能だ。
組み込みシステムも対応ソフトウェア言語やドライバの規格が統一されれば、
C/C++の立場もどうなるかわかったもんじゃないしな。

それにD言語という存在がある。まだまだ未熟な言語だが、
そういう言語が台頭すると、C/C++のようなネィティブ言語でしか作れなかった
ものがそれらの言語で置き換わる可能性だってあり得るわけだ。

プ

>>42
ガーベッジコレクタの実行を自動化できないからどんなに頑張っても
Javaと同じようにすることは不可能。
例外基底クラスも作れない、finally節も無い、文字列も標準ではろくなものがない、
Objectクラスのような基底クラスも無い、プロセッサが変わるとint型が32ビットになったり
64ビットになったりする糞言語。配列のオーバフローもコンパイラで制御できない糞言語。
DLL地獄に対応できない糞言語。

こんなんでは無理無理、C++はJavaには近づけん。

せいぜい、C/C++はJVM開発の奴隷になってくれていればいいさ。

>>46
便利だが、ツールが高価。100万くらい金払えってレベル

>>48
> しかし今はもう、C++vsJavaという構図はあまりないだろうに・・

ないはずなのだが、>>38や>>22のようなキモイC++信者がいる。
マ板で暴れていた昔のC++厨ほどの気が狂った勢いがないだけましだが。

> クライアントで敗北したJavaはサーバサイドという土地を開拓したが、

敗北というが、また復活している。Swingの高速化はめまぐるしいものがある。
Java Web Startが台頭しているぞ。リッチクライアントだ。
今はAjaxのほうが注目されているが、このJava Web Startも見逃せないものになる。
しかもサーバサイドはクライアントサイドで衰退する前から考えられていた。


> 原住民のPerl/PHPの思わぬ抵抗に大苦戦みたいな感じだな。
PerlはもうPHPに追いやられて衰退している。VBのように馬鹿でも
使える言語だから厨が集まりやすい。WebProg板はまさにそのような状況。
それと、PHPは小規模なウェブサイトの開発が得意なだけであって、
Javaが得意とする金融システム開発は苦手とする。

そこでJavaをPerlやPHPなどのようなおもちゃのようなスクリプト言語と
比較することがあまりにも浅はかというものだ。
畑が違うのだよ畑が。

>>55
NetBeansやJava Studio Creatorは
そうでもなさそうだ。

というか、Sunの宣伝能力が0みたいなモンだ。

良い物作ってるのに注目されないのは宣伝に
力を入れていないからだな。
100%PureJavaでありながらネイティブに
依存するEclipseよりも軽くて高速なIDEを作った
にも関わらず注目されていない。
Swing開発ではEclipseよりも使い勝手が良いのだが。

まあプラグインの充実度ではEclipseには負けるかな。

おめーら必死だなｗ
結局何がいいんだ？
javaでおｋ？

>>56
boostがあってもC++が抱えている欠点を
完全に消すことはできんよ。

>>59
Ｃωはどうした。

でも。おめーらスキル高そうだな。。。
今俺javaやってるよ。

営業なのにスキルがいるのよ。

仕事で話多いのが、VB.NETとjavaでうちのソフトと連帯してのシステム開発だな。

PHPって外向け用でしょ。

>>67
まぁ、小規模サイトで、Servlet,JSP,Strutsなんてのをやらないですむのは助かるよ。
大規模な開発やると、Javaのコーダーは土方だしな。
C++は新規開発はへったけど、やれる奴少ないから、ちょっといじっただけでも
評価があがるのは助かる。
まぁ、普段はCでドライバ書いてますが。これが一番楽。

http://gedo-style.net/g/?v=350137&d=d.jpg

そうか、人気がなくなってきた言語をあえて習得しておくという戦略もありか。
COBOLとかに手を出す気にはなれないけど。さすがに。

団魂世代がいなくなるから、
COBOLできる人が必要になるって、
COBOLやってたやつがいってた。。。

どうなんだ？

Dは演算子オーバーロードあるんだっけ？
あるならゲーム屋的に異存はないですよ。

http://www.kmonos.net/alang/d/operatoroverloading.html

C++は言語に有害な点が多い
Javaは関わっている人間に有害な者が多い

（・∀・）うまい！　だいたいシステムエンジニアって変なやつ多いよなｗ

クライアントでは遅くて使い物にならずC++に負けて(Swing?ﾌﾟ)、
サーバでは開発しづらくてRubyにさえ負けはじめ(やっぱLAMPが楽っす)、
ついにJavaWorldも廃刊だ。おまけに自慢の言語仕様もC#には負けちまう。
もうどこにも居場所はないんだよ。

クライアントで頑張ってるのはCの方です。

>>54==>>49
お前が読んでいる本見たら・・・
出版社: 翔泳社 (2000/08)

随分と時代遅れだな。


>>53のピアソンのほうがJava5から登場した【コンカレント工学】に
対応していて勉強になるぞ。

そんな古い本捨ててさっさとピアソン・エデュケーションの本
に切り替えろ。MUTEXのことろくに載っていない本など価値が無い。

>>69
Javaでオッケー

>>71
> でも。おめーらスキル高そうだな。。。
> 今俺javaやってるよ。
> 営業なのにスキルがいるのよ。
> 仕事で話多いのが、VB.NETとjavaでうちのソフトと連帯してのシステム開発だな。

> PHPって外向け用でしょ。

意味が解らん。
PHPの、何が、何に対して、いつ、どこで、どのように外向けなのだ？

PHPはアクセス数が多いサイトや、セキュリティのことを特に気にする必要も無い
責任も軽い大して金にもならないくだらないサイトを作ることに向いている。
ブログやWikiや2chにPHPやPerlが使われていることはその点にある。

VB.NETはVB6に依存していたVB厨を救済し、どうにかしてJavaに近い文法を持つC#に
移行させるために作ったようなもんだな。

>>72
> >>67
> まぁ、小規模サイトで、Servlet,JSP,Strutsなんてのをやらないですむのは助かるよ。
> 大規模な開発やると、Javaのコーダーは土方だしな。
ドカタと言いきっているようだが、
数々のノウハウを集めた『イディオム』や『デザインパターン』に加えて
『アーキテクチャパターン』『アナリシスパターン』を何一つ理解できない奴が
大規模開発なんかできるはずがない。それを無理矢理やるからドカタが
出てくるだけであって、大規模開発をやる＝Javaアーキテクトがドカタになる
という式は成り立たない。



> C++は新規開発はへったけど、やれる奴少ないから、ちょっといじっただけでも
> 評価があがるのは助かる。

バグが増えても評価が上がるようでは終わってるな。

> まぁ、普段はCでドライバ書いてますが。これが一番楽。

まさに真のドカタだな。組み込み系はデータベース屋と比べると
つらいだろう。Windows DDKに苦しめられたか？　Win32 APIなんて
糞にまだ依存しなければならない状況に追いつめられているか？

某リバースエンジニアリングの本を立ち読みしていたら、著者紹介（複数人）のところで数人曰く
「最近はPHPやってます クラックも良いけどプログラミングもね」
「最近Perl極めた云々」
改めて、「やっぱりクラック好きな人は人間として根本的に狂ってる節があるな」と、Javaしかできない奴や
C++ナルシストに対しての通じるものを感じた。

>>73
君が悔しがってるのは解るが>>57-58に対抗して
「中規模業務系まで」という表現が意味不明だ。
それが許すものは、苦しいがむしろPerlやPHP程度だろう。
PerlやPHPが許されるのは中規模よりもむしろ小規模だが、
業務系よりもむしろ、お遊び系だ。

その画像ジェネレータの生成結果のとおりのことを真実だと
思っているなら、
PerlやPHPでオンラインバンキングやオンライントレーディング
サイトを作ってみろ。

>>74
人気よりも、魅力のある言語を習得した方が良い。
関数型言語とか

>>75
過去の遺産を完全に破棄すれば、結局
COBOLも不要になる。
過去のCOBOL遺産をどうしても再利用したいときだけ
使われるに過ぎない。
だが、仕様書をきっちり書いて残していれば
COBOLがどうこうなんて関係無いがな

>>78
> C++は言語に有害な点が多い
> Javaは関わっている人間に有害な者が多い

Javaプログラマの人口が圧倒的に多いなら
そりゃ絶対数で見れば有害な奴が紛れてくるだろう。

>>80
> クライアントでは遅くて使い物にならずC++に負けて(Swing?ﾌﾟ)、

それも、ハードウェアの高速化に加えて最適化技術が飛躍的に進歩して
C++には余裕で勝てるようになってきているぞ。それにSwingのめまぐるしい
高速化には目をみはるものがある。C/C++を使うことでSwingよりも高速だと
言われていた、IBMによって開発されたあのSWTを使ったあの有名な
オープンソースIDE Eclipseが、Sunが作った100%PureJavaのIDEであるNetBeansに
パフォーマンス面で劣ってしまい、まるでJavaで作ったとは思えないほど、
クライアントサイドではSwingも進化していることは驚くべき事だろう。


まさか、10年前のJavaの世界で思考が止まっているのかな？


この話の真実を確認したければこの例え話に耳を傾けてみてはどうだろう。

　同じ技術力を持った二人のうち、片方にJavaで
　プログラムを書かせ、もう片方にはC++でプログラムを書かせたとしよう。
　すると、なぜかJavaの方が高速になった。

多くの「C++信者はそんなことは『絶対』にあり得ない！」と言い切るかも知れない。

これが自動最適化技術の恐ろしいところなのだよ。

C++で最適化するには手動でデストラクタをどこに配置するかを決めなければならない。
このコストと手間は莫大なものだ。
機械がやるべき事をわざわざ人間がやる必要は無いのだよ。C

++は最適化技術については、原始的な手法に依存している。
そこがC++がJavaに敗れた原因の一つでもある。

> サーバでは開発しづらくてRubyにさえ負けはじめ(やっぱLAMPが楽っす)、

じゃあそのRubyとLAMPで金融システムを開発してみような。

> ついにJavaWorldも廃刊だ。おまけに自慢の言語仕様もC#には負けちまう。

そういえばJavaWorldが廃刊したからもうJavaは終わりだと3年くらい前に
寝言を言っている奴がいたものだ。しかも君と同じようにC#を崇拝していた。
だが結果は、C#の敗北となった。言語仕様であれがC#に負けているというなら、
C++にすら負けているという意味になるが、その解釈は、まるでアルファベットが少ない英語が、
アルファベットが多い中国語に負けていると主張しているようなものだ。

>>86
意味が解らないんだが。
その本の題名を説明して貰わないと。
断片だけで煽るのはやめようや。
PHPやPerlは畑が違うんだからな。

もう「Javaしかできない奴」という煽りも恥ずかしいから
やめておいたほうがいいぞ。
今どき、そんな奴はこのスレには「Java質問スレ」に質問しまくる新人レベルの奴以外
そんなにいないんだからよ。

>>91
C++よりJavaのほうが速いことがあるなんて、
今更得意げになって語るほど目新しくないよ。

そんなんだからJava厨は、なんて言われJavaの魅力が霞む。

JavaのGUIが速いってWindows限定の話じゃネーの

今はビジネスロジックよりコンカレント工学のほうが笑える

ここで話してる人たちとは畑が違うだろうけど
研究や金融系の計算プログラムはほとんどCかC++（もしくはフォートラン）だぞ
Javaで書かれたプログラムなんぞ見たことすらないんだが

> 現在のJavaは、単純なインタープリタ方式に比べ、ネイティブ・プログラムとのパフォーマンスの差は小さくなっています。

> Javaの起動速度については、現在のところでは確かに遅いと言えるでしょう。

> ネイティブ・アプリケーションに比べ、Javaアプリケーションが多くのメモリを必要とするのは確かです。

> GCによるスレッドの停止時間がどのくらいの長さになるかを特定するのは難しいため、いわゆるリアルタイム・システムをJavaによって構築するのは困難な場合があると思われます。

ttp://www.javaworld.jp/technology_and_programming/-/27047-2.html

> ここまでに説明したとおり、現在Javaが主に使われているサーバ側アプリケーションにおいては、性能が理由でJavaが使えないということはほとんどないと言えます。

画像処理をメインでやってるんだけど
javaにすると本当に処理速度あがるの？

>97
金融なら、こいつがJava。(ただし、JR東の中の人が使う画面はCurlで書いてる)
ttp://www.tis.co.jp/product/CreditCube/index.html
SUICAの売上とか残高とか、全部これで管理されてるよ。

>100
Perlで画像処理やってたと言うなら
それはぜひJavaに乗り換えるべきだとおもう。

両方勉強した俺は勝ち組かな。
片方しか出来ない馬鹿乙

そんな低レベルなやつはこのスレにいないよ、きっと。まさか。

http://www.digitalmars.com/d/
Dのトップページのサンプルが微妙にきもいんだけど。CmdLinて。std.stdioとかまるでC++。
writeflnはライト不倫としか読めんし。こういう命名文化の言語ならちょっとヤだぞ。

printlnとかな

printlnやだね。

>>101
C++よりjavaが速度あがるわけじゃないのね

>>107
もちろんC++よりも速くなるよー

>>91
なんかJavaのさえない実績をあおるC++信者に、必死に妄想で対応する
Java信者のいつもの構図だな

画像処理がc++よりもjavaが高速にできるなら
なんでadobeは、いまからc++画像処理ライブラリー作るとか言ってるの？
javaでいいのに

C++にする方が需要が大きい（とAdobeは考えたに違いない）から。

>>110
PerlだろうがPythonだろうがJavaだろうが大抵の言語はC/C++向けの拡張インターフェースを
持っていて、C++で書かれたライブラリを簡単に取り込めるけど。
Javaで書かれたライブラリはまずJavaでしか使われないよね。速度が問題じゃないよ。

リアルタイム画像処理はjavaでは無理
sse使えないし

自分で使ったメモリは、自分で片付けないと、
不安でしょうがない

でもほんとサーバでPHP/Perl/C#に負けるようになったらJavaは
衰退するんだろうな・・。いい言語だとは思うんだけどさ。
俺は実務指向だから、はやらなくなったものはやっぱ使わなくなるかな。

PHP・Perlに負けることはねえだろ。
Rubyが高速化したら負けるけど。

Rubyも見た目がｷﾓｲんですけど？

>>117
先入観無しで一度使ってみるよろし。
Javaでコード書くのダルくなること請け合い、C++は言うに及ばず。

ネットや雑誌でRubyの勢いは感じるんだけど
実際使ってる案件見たことないんだよ

>>119
キモイからじゃね？

キモかったら見ないって理屈が通るなら
俺の会社は誰からも見えないよ

>>119
とりあえず今は、ちょっとしたツール作るときに使ってる。

>>94
> >>91
> C++よりJavaのほうが速いことがあるなんて、
> 今更得意げになって語るほど目新しくないよ。

そんなことにいまだに気づいていないで、今さら得意げに煽る>>80も
同化と思うが。

そんなんだからドトネト・スクリプト厨は、なんて言われ.NETやスクリプト言語の魅力が霞む。

常識的に考えてC++よりキモイのは無いだろ。
だけど、そのキモさが良いんだけど。

>>95
それでもいいよ。デスクトップOSの大部分がWindowsなんだから。
サーバはLinuxやSolarisなどがよく使われていても
結局はJavaを使うケースがあるんだし

EclipseとVisualStudioを比べて前者のほうが速いと感じたことは一度もないよ。

>>97
> 研究や金融系の計算プログラムはほとんどCかC++（もしくはフォートラン）だぞ

それがデマでないなら、金融系のプログラムがほとんどC/C++でかかれているという
根拠を示してくれ。COBOLの間違いじゃないよな？


研究ではCを使っているケースがあることは歴史上しっているが、
最近ではJavaにシフトしているところも現れている。
10年経ってもコンパイルに困らないからという理由で
プログラムを全部Javaで書いている大学教授もいる。

>>100
処理速度が上がることを期待するより、
開発効率、メンテナンス性や拡張性が上がることを期待した方が良い。

>>109
具体的にどこが妄想で対応しているのか、
示せるかな？

それとも、ただの愚痴かな？

>>110
過去の遺産が影響しているからだろう

燃料投下
ttp://local.joelonsoftware.com/mediawiki/index.php/Java%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%AB%E3%81%AE%E5%8D%B1%E9%99%BA

>>111
だから過去の遺産がC++で作られており、
今さらJavaに以降するにはコストがかかるからだろう

>>114
そうこうしているうちに、
Javaの最適化技術が驚くほど進化しているわけだが。

それじゃ
昔、オートマ車がでたとき、事故が頻発したので
30年経っても未だに恐くてオートマ車に買い換えることができずに
20年近く古臭いマニュアル車に乗ってるオッサンと同じだよ。

今じゃオートマどころか、ABSやエアバッグなど数々の安全装置や
カーナビなどがが付いていというのに未だに古いものに拘っている。

ふるいものにも良いものがあるとはいえ、乗り換えた方が効率がよくなるものはある。

>>126
Eclipseの方が便利だけどな

>>115
> でもほんとサーバでPHP/Perl/C#に負けるようになったらJavaは
> 衰退するんだろうな・・。いい言語だとは思うんだけどさ。

まず、PHP、PerlはJavaとは違い型に甘い言語である時点で、衰退
云々など関係がない。いくらPHPが人気があってもJavaには影響がない。
そもそも用途と志向と向き不向きが違うのだから。

というか、Perl6さっさと出せ、そしてPHPに名前空間付けろと言いたいところだね。
ついでにPerl6のParrotのように、言語非依存になるVMをPHPに搭載しないと
完全にJavaの代替言語にすることはできんな。

C#は、C++と同じ道を歩みそうで、Javaのようには流行らないだろうな。
C#の将来は、Windowsを開発しているマイクロソフト次第だな。


それにしても、お前の発想は、

　「XMLが普及すればHTMLやSQLが衰退する！」

と言ってるのと同じレベルだ。

>>118
スクリプト厨とか煽られたことがないか？

あの、型に甘い言語はデバッグがしづらいから
あまりにもキモイのだが。
それにBeginとかEndとかもきもい。

>>119
RoRが面白いだけだ。
Java分野でもおんなじようなもんがあるがな。
Spring FrameworkとかSeasar2とか

>>126
バージョンによるがな。
Eclipseは3.2になってから高速化した。
だが、使い方次第ではえらくのろまになる。

そこえNetBeansだ。PureJavaで書かれているのに速い。

>>131
またJoel on Softwareの関係者か。
あれはM$信者だろ。ただの煽り。
C#が出た頃に、M$の関係者や信者が
「Javaはもう衰退する！　これからの時代はC#だ！　Javaなんて勉強しないでC#を勉強しろ！」
と煽っていたことを思い出す。
だが、あれから6年経ってもJavaはいっこうに衰退せず、C#もろくに普及しなかった。

その程度の煽りだろうね

>>131
こんなスレで低能な言い争いを続けてる連中にそんな長文が
読めるわけだろ。そんなんじゃ燃料にならねぇよ、馬鹿。

>>136
それほどスクリプト言語に思い入れがあるわけじゃないよ。
でも使い捨てのツール書くニーズなんかは誰にでもあるわけで。

C#か、なにもかもなつかしい

覚えなきゃいけないのかと思っているうちにどっかにいったな

>>139
完全にとっては代わることはないだろうが、JavaがどんどんC#に
その役割と立場を喰われているのは事実だろう。

型の甘い言語って、JavaやC++もどっちもそんなに型に厳しいわけじゃないだろ。
どちらも暗黙のキャストするし、コンパイラが賢い型推論もってるわけでもない。
型による自動的なデバッグが好きならHaskellでもなんでも使って、アルゴリズムとかの
本質的なバグを注入してるといいよ。

>>143
全くそんな気がしないんだけど。
なんかソースあるの？

>>145
C#の案件をググれ。それら全てが、JavaがC#に喰われた分だ。

>>143
仮にJavaが全てC#に置き換わったとしても、
Java屋は別に困らんのじゃないだろうか。
それほど移行コストがかかるとは思えん。

>>75
まともに動いてたCOBOLのシステムを捨て去りJavaで書き直すも誤動作連発。
日本終了。

このスレJavaはC++より速い！ってやつが一人で頑張ってるようにしか見えないんだが

ｃ＃はselectやfromを取り入れるそうだよ。
データベースがネイティブに使えるんかな？

>144
スクリプト系は型が甘いっていうか

・変数に型が無い
・パース時に引数の型チェック出来ない

ってことだろ。暗黙のキャストの問題じゃない。

俺は個人的な小規模コードならよくRubyをよく使うが
大きいコードで使う気にはなれない。

Javaは変数も値も型を持つからな。
Java5の仕様変更から流石に個人的な用途でも使い始めたよ。

Javaは全然使ったことが無いが、明示的な型を持たないから糞と聞いていたのに
型はあったのか・・・

>>143
> >>139
> 完全にとっては代わることはないだろうが、JavaがどんどんC#に
> その役割と立場を喰われているのは事実だろう。

C#がまだベータ版だった頃(2001年)からそういう発言をしている某学生派遣会社の営業が
いたことを思い出すよ。
Javaが遅いからという理由で嫌いになりPHPとC#をしきりに勧めていた彼は今頃どうしているかな。

>152
つーかOOPLで型無し言語ってあるのか？
オブジェクトがクラス情報（かそれに近いシステム）持ってなきゃ
ポリモル出来ない気がするんだが。

>>152,>>154
まずはなにをもって型があるとするかだろ。
まぁ、型の強弱はあっても全く型の無い言語なんてそれこそ少数派だろ。

つ JavaScriptなどのプロトタイプベースのOOPL

JDK1.4までは値と型は一応分かれてなかったっけか
内部ではどう扱っていたんだかわからんが

>>151
それは所謂、強い型付けってことでしょう。
Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。
まあ、そもそも型安全でないC/C++よりはマシですどね。

>>158
アップキャストとダウンキャストの区別が�d�j

言語 基本クラスへの型変換失敗 派生クラスへの型変換失敗
スクリプト系 実行時検出 実行時検出
Java コンパイル時検出 実行時検出
C++ コンパイル時検出 プログラマ任せ

俺はＥ言語を開発してるんだけど、だめかなあ。

Javaのアップキャスト検出は状況次第じゃないか

>158
> Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。

全然違うだろ。↓がコンパイル通るなら一緒だがｗ

import javax.swing.*;

public class Test001 {
　　void myMethod(int i) {}
　　public static void main(args) {
　　　　"".getThreadGroup();
　　　　myMethod(new JButton());
　　}
}

ちなみに、変数に型の無い言語なら
int i なんて指定出来ないから何でも入る。
昔のVectorの状態を全ての変数や引数でやるワケだ。

>>161
寝ぼけているのではなく、本気で言ってるのなら、基本から勉強しなおすと良いよ。

>>85
そりゃ、Javaアーキテクトは土方じゃないよ。
コーダーが土方っていってる。
うちは、主要なインターフェースを全部作っておいてあげて、
実装はコーダーさんに任せるってやり方をしてる。
実装にもノウハウは必要だけれど、
こういうやり方をしていると、新人もベテランも、
他の言語ほどあんまり差がつかないんだよね。
まぁ、Javaがよくできた言語だということだと思うけど。

多くのJavaのコーダーさんは、言われた通りにしかやらない人が多い。
言語に罪はないが、自主性のない人間を増やしている気がする。

>>161
>Javaのアップキャスト検出は状況次第じゃないか
アップキャスト検出ではないが、Javaのダウンキャスト検出は状況次第だわ。
ダウンキャスト先が継承関係に無い場合はコンパイル時エラーだな。
俺も基礎からやり直すよorz

>>127
1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
JavaのGCがかなりネックになってしまう。
GCの走るタイミングが読めないし、完了する時間もわからない。
Javaでメモリリークのおこらないシステムにするには、
プログラムの設計だけではだめで、ハードの増強や、
負荷分散の仕組みに金がかかってしまう。
通常の処理をしている分には、Javaは優れているけど、
リアルタイム性がないんだよね。。

今はマルチコアなんだし、GCもコストフリーなんじゃない？

昔、一太郎arkってあったな。今後はどんどんJavaで作られるのかって流れを
感じたが、現実は厳しかったなぁ。

>>167
まあ段々とそう見なせる状況は広がって行くと思う。

>>167
じゃぁ、GC用に一個、コアを予約しておくか。

今時ハードの増強や負荷分散の仕組みくらい安いもんだろ。方法論が確立してるしな。
GCのない言語だとメモリリークを防ぐには、腕の立つプログラマと長い検証期間が必要だ。
そんなの信用ならん。

いくらメモリリークから逃れてもリソースリークしたらそこまでだろう

このスレ，PHPが出てきたりと，Webアプリの話が多いけど，Windows用のクライアントアプリって今でも C++/MFC が全盛じゃないの？

パソコンショップで売ってるWindows用のソフト，例えば画像編集，デジカメ写真整理，年賀状作成，動画編集，シューティングゲーム，etc みたいな
ソフトは C++/MFC で組まれてるんじゃないの？
Windows 用のネイティブアプリをまともに作れる言語ってこれしかないような。
生 Win32 API だけで作るのは大変だし。
.NET Framework は相変わらずもっさりだし。

.hと.cppに同じことを書いてると、俺何やってんだろうと感じる＞＜

TIOBE Programming Community Index
ttp://www.tiobe.com/tiobe_index/index.htm

今後のトレンドを予想してみたい。
ttp://www.tiobe.com/tiobe_index/images/tpci_trends.png

みんな、寝ろよ。
徹夜は効率悪いよ。

>>173
つVB、Delphi、Macromedia Director
あと、MFCとか言い出すと標準C++じゃないから話がややこしくなってくる。
Windows環境はC++コミュニティからも冷めた目で観られてる。

90%位のシェアの市場を冷めた目で見てどうするんだ・・・

>パソコンショップで売ってるWindows用のソフト，例えば画像編集，
>デジカメ写真整理，年賀状作成，動画編集，シューティングゲーム，
>etc みたいなソフトは C++/MFC で組まれてるんじゃないの？
その通りだよ。そんな実態をすべて忘れてJava最高！といい続ける
妄想宗教スレなわけだ。

>>177
> Delphi、Macromedia Director
!? !? !?
なあ、Delphiが生き残ってるって初めて聞いたんだが。

>>179
アプリ系ってもう負け組じゃん。C++は負け組言語と言いたいわけですか。

>アプリ系ってもう負け組じゃん。
ﾌﾟ

（俺C++使いでJava使わないんだが）
（前スレ）JavaやったらC++はきもく感じるとは直接関係ないけど
#include <〜>
なんで拡張子hを消したんだろう。

中途半端なこと変えやがって
そのくせboostみたいに他の言語並みの使いやすさに
近づけてくれるものはなかなか標準にならない。

HTTP通信とかスレッドとか標準ライブラリや言語仕様にして
他のOSでも移植しやすいようにしろよ。
事実上よく使われるとかデファクトとかじゃなくて
標準装備になっていると大違い。

>>143
> >>139
> 完全にとっては代わることはないだろうが、JavaがどんどんC#に
> その役割と立場を喰われているのは事実だろう。

そんなソース無いな。
そもそもライブラリの豊富さですでにJavaに劣っている。

>>144
> 型の甘い言語って、JavaやC++もどっちもそんなに型に厳しいわけじゃないだろ。

お前みたいに大嘘ツク奴は(ry

> どちらも暗黙のキャストするし、コンパイラが賢い型推論もってるわけでもない。

暗黙のキャストといってもPerlやPHPなどのようなスクリプト言語ほど暗黙の
キャストをする言語ではないが。C++の場合はJavaよりもやたらと暗黙のキャストをするが。

それに、型推論持っていれば型に厳しくなるとは限らないのだが。

>>146
そのときそのときに案件でしか判断できないとは痛々しいな。
C#の立場はクライアントサイドのみでしか発揮されないよ。
サーバサイドではどうみてもJavaやPHPには勝てない。

>>150
デーベースと言えば、Javaも Java SE 6(Mustang)
からApache Derbyが標準搭載され、100%PureJavaデータベースが
Java SE 6に取り込まれた。

>>152
JavaとJavaScriptとを勘違いしていないか？
それとも「明示的な型キャスト」をしてもキャストをできないケースがあるという
意味を勘違いしていないか？

Javaの明示的な型キャストは、プリミティブ型やスーパークラスからサブクラスへのキャスト(ナローイング変換)のときだけ。
暗黙の型キャストはその逆でスーパークラスへのアップキャスト(ワイデニング変換)だけ。

Genericsが出てから、余計な明示的ダウンキャストをしなくて良くなった

というものもあるが。

>>154
PHP, Perl, JavaScriptなどなど

>>157
それはオートボクシングのことか。
今でも別れているが。

C#やC++と違い、どんなことがあってもJavaのオブジェクトはすべて参照型。
プリミティブ型もすべて値型。
オートボクシングを使うときは、何かに代入するときに暗黙のうちにボクシングされるだけであって、
C#のように、その値型を持った変数がプリミティブラッパークラスのオブジェクトに変化する「可変」ではない。
そもそもJavaのプリミティブラッパークラスは「不変(イミュータブル)クラス」だ。
「不変」であるという点から、依然として型には厳しい。


値型と参照型両方をもつことができるC#のボクシング&アンボクシング変換とはまったく仕様が違う。

>>158
> >>151

> Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。


なんか、トンデモ発言だな。
まともにJavaプログラミングしたことがあるのかと

>>164
> >>85

> まぁ、Javaがよくできた言語だということだと思うけど。
> 多くのJavaのコーダーさんは、言われた通りにしかやらない人が多い。
> 言語に罪はないが、自主性のない人間を増やしている気がする。

Java質問スレで質問しまくってる厨房どもだろ。
大学でJavaの宿題やってる奴が多いから、そっからお前が見かけるような
厨房が産まれる。

しかしそれは真のJavaアーキテクトじゃないな。
Javaの氷山の一角だけを見ている奴がそうなる。

>>166
> >>127
> 1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
> JavaのGCがかなりネックになってしまう。
> GCの走るタイミングが読めないし、完了する時間もわからない。
> Javaでメモリリークのおこらないシステムにするには、
> プログラムの設計だけではだめで、ハードの増強や、
> 負荷分散の仕組みに金がかかってしまう。

いつの時代の話をしているのだろうと耳(目)を疑う。

少しはjava.lang.ref.SoftReferenceを使って改善しようとは思ったことが
ないのかね？

GCのタイミングを調整するには、java.lang.refパッケージを使って
ネックになりそうなオブジェクトをプロファイラで検出して
そのオブジェクトを見つけたら、そのオブジェクトの到達可能性レベルを
SoftReferenceでカプセル化して変更しろ。

間違っても都市伝説を信じている時代遅れな連中のように意図的にnull代入やSystemgc()なんか使うなよ。

JavaがC++より速いケースは、ファイルI/O処理、メモリ解放確保のタイミングだ。

このことから、Javaの最適化がかなり進んでいるので、GCについてはまず問題ないし、
むしろC++の手動メモリ管理に依存した方が遅くなってしまうぞ。
C++が速度面で勝っているのは今のところは、三角法の計算や数値演算くらいだ。

>>171
まさにその通り、昔は人間がやっていたことを
今では簡単に機械が実行できる時代。

それを認めたくない香具師がたまにいるみたいだが。

>>173 >>177

C#も忘れている。デスクトップではJavaより進んでいるとマイクロソフトの関係者は主張している。
VistaのようなOSを手がける彼らが自信を持って言わなくちゃならない当然の発言だろうけど。


JavaもSwingが強くなってくるから、今後、どうなるか解らないだろうねえ。
Linux方面もFedora Coreのデスクトップが徐々に進化してVistaに対抗して
右食ったと思われる派手な視覚効果も追加されている。
となると、クロスプラットフォームという強みを持つJavaも再び見逃せなくなる。
なにせ、Java Web Startがあるし

>>175
C言語の人気は相変わらずだ。

RubyがRuby on Railsの影響で注目され始めていることがわかるが
結局Javaが圧倒している。

>>179
だから、それは過去の遺産がC++で作られているから
Javaに移行するとスイッチングコストが高く付くから
C++のままで開発しているだけだよ。

JavaがC++よりも速くなるケースが出てきたのは
最近だし。Swingの高速化についてはまだまだ知られていないみたいだね。
JavaはファイルI/Oやメモリ管理速度がC++よりも速くなっているので
そろそろリプレースしてもいいころだろうけど、
Java SwingはGUIコンポーネントがWindowsに付属するものと
比べると劣るものが多いから移行を躊躇う企業が多いのだと思う。

それにVistaも出ているし

>>183
C言語時代の名残だろ。伝統的と揶揄されるがシガラミでしかない

聞きたいんだけど、Javaで数値計算のライブラリってあるの？
あったとしてもほとんどない。
この分野はCおよびC++の独壇場でしょ？
多数人の手で大規模なシステム開発をやるならともかく、
一人または少数人で計算速度重視のプログラムを組む場合、
Javaなんて度外視されてるのが現状じゃない？

>>199
> 聞きたいんだけど、Javaで数値計算のライブラリってあるの？
> あったとしてもほとんどない。
Jakarta Commons Math

> この分野はCおよびC++の独壇場でしょ？
そりゃCは20年くらい先行して現れた言語だからねえ。

> 多数人の手で大規模なシステム開発をやるならともかく、
> 一人または少数人で計算速度重視のプログラムを組む場合、
> Javaなんて度外視されてるのが現状じゃない？

10年前なら真っ先にそうだったね。
だが、もうそんな時代は終わってるよ。
JavaはC++よりもメモリの管理速度やファイル操作が速いので
C++よりも巨大なデータを扱うことに向いている。

勘違いしては困るがCは神言語だろ。C++は神になりそこなったクズってだけ。

もうC++よかメモリ管理もファイル操作も速くなったのか
じゃあ携帯Javaももう天国になったんだな
うらやましいぜ

もうっていうか最初からBrewはクソだろ。

Perl の OO 拡張や V6 で失敗したのが
C -> C++ の失敗に良く似ているね
こういうケースでは新言語作るべきなんだよ

>>200
> JavaはC++よりもメモリの管理速度やファイル操作が速いので
JavaVMはC++で作られたアプリケーションだから、
C++より速いメモリ管理やファイル操作がC++によって実現されていることになる。

>>202
メモリが少なすぎてまだまだ

>>205
だったらさ、C++はなぜそこだけJavaより遅くなるのかな？

>>207
実際に遅いかどうかは別として、こまめにメモリを確保・解放して
メモリの使用量を抑制するか、十分なメモリを確保したままにして
速度を重視するかでトレードオフの関係が成り立つから、
速度を犠牲にしてメモリの使用量を減らすことを優先することもできる。

JavaでもSUNが速度を重視する設計を選択しただけで、逆に速度を犠牲にして
メモリの使用量を抑制する実装もあり得る。

根本的なところだと、C++の速度とかJavaの速度というのは奇妙な表現で、
同じソースからコンパイルしたネイティブコード／クラスファイルでも、
コンパイラやライブラリ等の実装次第で実行速度はいくらでも変わってくる。
コンパイラやライブラリの実装の良し悪しと言語の良し悪しとは、別の問題。

>>207はあらゆる状況でC++のメモリ・ファイル操作はJavaより遅いかのごとく語っているが、
ではどうやってJavaより遅いそのC++でJVMを実装していると考えているのだろうか

つか、>>200 が勝手に
>JavaはC++よりもメモリの管理速度やファイル操作が速いので
とかぬかしてるだけな気がするんだが。

確かに C++ の処理系で実行時最適化できる実装はないし
標準のストリーム I/O は糞以下だが。

std::vectorは cの単純配列より1.2倍ぐらい遅いというのを見たことがある
javaの配列はどんな感じ？
1.1倍？

>>166
>1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
>JavaのGCがかなりネックになってしまう。
>GCの走るタイミングが読めないし、完了する時間もわからない。

某UFJ銀行関連はJava使ってたような・・・。
あと、WebSphereとかの商用APサーバなんかは、そこそこの
チューナーがいればJavaだから遅いなんて思う事はまずないが。

金融系を語る奴に限って金融系の開発をしたことあるのか激しく疑問なんだが。

いつまでもつまらん議論しなさんな。
言語はそれぞれ得意分野があるもんだ。

C/C++はハード側の関心事により最適化できるようになってるし、
Javaはよりユーザ側の関心事に最適化できるようになっている。
ハードの足かせのない世界を指向するJavaを、より「ソフトウェア」と
呼べる分、一プログラマとしてはJavaを支持する。

組み込みソフト業界も良く知ってるけど、やっぱりハード側の仕様に
振り回されるだけの便利屋的な存在になりさがってるしね。

Javaの「WriteOnece,RunAnywhere」の思想とその実現への姿勢は、
最近は余り取り上げられなくなったけど、やはり革命的だと思ってる。

「立てよ国民。我々にとって地球は狭過ぎた！」

実用上、C++の手を借りることが多いのはCOMコンポーネントを作るときかな。
VB用に帳票印刷を手作りしたときには役に立った。

C++は言語としてはいまだに一番好きだけど、これだけでアプリケーションを組む
のは、化学実験室に連れて行かれて試薬でクッキー作れといわれるぐらい嫌。

C++じゃなくてC言語の話だけどさ
ときどきC言語は移植性が高いというのを見つけるけどさ
BASICなどに比べると方言が少ないとかぐらいでしょ。

処理系依存たっぷり
昔から進歩していない標準ライブラリ

そんなC言語と互換を持たせたC++

>>214
>化学実験室に連れて行かれて試薬でクッキー作れといわれるぐらい嫌。

いや、それ面白そうじゃん？　ちょーやりてー

>>215
ANSI C に準拠してるヤツはかなり互換性いいぞ。
てか、C++の互換性の無さにはウンザリ。
あれじゃ、標準規格があって無いようなもんだ。

数値計算というか事務計算をやらせようとするとC++厨もJava厨もろくでもない物しか作れない。
特にJavaの奴は誤差が頻繁に出るからクレーム付けたら「1円くらいどうでもいいだら」なんて言うし。
最低。

>>218
それはお前のまわりだけだろ？
得意としてる言語に関わらず、そんなヤツには合ったことないぞ。

で、まわりにそんなヤツが多いってことは、お前もどうせその同類だろ。

COBOLERでそ

>>220
COBOLが最も得意とする分野なのですが。＞事務計算

>>221
>>218がコボラだつったの。

俺はよく事務計算については知らないんだけど、COBOLは他の言語に対して
事務計算の分野においてどういうアドバンテージがあるのか教えてくれない？

COBOLって言うほど事務計算得意な言語でもないと思う。

事務計算くらいしかできん。と言うならわからんでもないが。

>>215
C の環境依存部分は、ほとんどの場合利用できる関数(とヘッダ)なので
環境依存部分をファイルに分離して Win/Mac/Unix 対応くらいならできる。

これが QB/VB/N88 に対応しろって言われたら頭抱えて途方にくれるよ。
そのくらい違う。

Java はそもそもどこでも動くはず。と言うか動くべき。

>>224
>Java はそもそもどこでも動くはず。と言うか動くべき。

でも、動かない。プッ

>>225
あらゆる環境で完璧に動くよ。

>でも、動かない。プッ
０点。もう少し頭を使いましょう。

>>209
だからC++プログラマの技術力が
ロボットの技術力に追いつかないということだよ。

わかりやすい例に喩えると、

ファクトリーオートメーションを導入している工場と
そうでない工場との違いだよ。

Javaというものは、人間が行えばミスがおかしいものを
ロボットに任せて自動化させたようなもの。
それによって効率が向上しているというものだ。

C++はBoostを使わないときは、人間がやらなくても
いいことをわざわざやろうとするからJavaの最適化技術に勝てず
ある分野ではJavaに最強の座を奪われている。

そこでBoostを導入しようとするけれども、言語仕様に
もとから欠陥がありシガラミがあるため限界がある。
それに、Boostは数十人の優秀な技術者を集めて作った
JavaコンパイラやJVMの技術力には勝てずにいるということも
大きな特徴。

ここでC++が再び、全ての分野でJavaより高速化できるかどうかは、
Boostのようなライブラリの強化にかかっていると思うね。
Javaも Java SE 6になってからソースコードが公開されGPL2.0になったから
今頃、Boost開発者は一生懸命Java SE 6のソースコードを解析して
最適化技術をリバースエンジニアリングしているところじゃないかな？

>>210
> つか、>>200 が勝手に
> >JavaはC++よりもメモリの管理速度やファイル操作が速いので
> とかぬかしてるだけな気がするんだが。


それにはソースがあるよ。
Comparison of Java and C++
http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Performance
* pointers make optimization difficult since they may point to arbitrary data or code
* newly allocated memory is close together because garbage collection compacts memory and allocations are thus sequential in memory; and hence more likely to be 'in the cache'
* run-time compilation can do a better job because it knows what processor it is running on and what code is running - the hot spots

One comprehensive study of microbenchmarks shows quite a large variation in results
but indicates that, in general, Java outperforms C++ in operations such as memory
allocation and file I/O while C++ outperforms Java in arithmetic and trigonometric operations.[3]

For numerical processing, Java has shown significant gains with each new version but
still lags C++ and Fortran, in part due to the requirement for reproducibility of floating-point
results across all platforms.[4]

[3]のソース
# ^ "Microbenchmarking C++, C# and Java" by Thomas Bruckschlegel, Dr. Dobbs, June 17, 2005
http://www.ddj.com/184401976
[4]のソース
# ^ "Java and Numerical Computing" by Ronald F. Boisvert, Jose Moreira, Michael Philippsen and Roldan Pozo, NIST, Dec 2000
http://www.javagrande.org/leapforward/cacm-ron.pdf

>>228
知ったか厨なんてこの程度だな。

>>229
中々面白い。

>>211
Javaは配列自体Javaより遅いからねえ。
今なら、配列の替わりにBufferのサブクラスとChannelクラスを使うことでCの配列のと
同じくらいの高速化を実現できるといえばできるけど。

それと、Java版Vectorは中途半端に同期をとる古い仕様で使われていない。
かわりに、java.util.ArrayListとjava.util.LinkedListが使われている。
それぞれ、読みこみ速度、書込速度に違いがあるのは、アルゴリズムとデータ構造を
大学で教わっているなら変わると思う。


それと、Iteratorに変換すると遅くなるケースもあるようだ。
RandomAccessインタフェースを使って高速化するケースもあるので
配列よりどれだけ遅いか速いかは厳密にはわからない。
http://d.hatena.ne.jp/t_yano/20070128/1170006946

get()を使うかnext()を使うかなどで速度も変わってしまう。

>>212
> >>166
> >1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
> >JavaのGCがかなりネックになってしまう。
> >GCの走るタイミングが読めないし、完了する時間もわからない。
> 某UFJ銀行関連はJava使ってたような・・・。

拡張子がdoになっているので、UFJダイレクトはフロントエンド付近に
Apache Strutsを使っているようだね。

というか銀行の「ダイレクト」系はどこもJavaばっかだね。
三井住友もイーバンクもそうだし。
証券会社もそう。楽天証券、イートレード証券なども。しかもローソク足表示にはJavaAppletを使ってる。
最近じゃ、YahooでもJavaを使っているところがある。
お金が絡むところは何かしらJavaが関与しているみたいだ。

>>215
昔の言語とくらべると「できないことは無い」
というだけで「移植性が高い」と言っているだけだろうね。
Javaの移植性とはまた違う。今なら、Javaのほうが移植性が高く見える
ことは間違いないけど。

>>218
> 数値計算というか事務計算をやらせようとするとC++厨もJava厨もろくでもない物しか作れない。
> 特にJavaの奴は誤差が頻繁に出るからクレーム付けたら「1円くらいどうでもいいだら」なんて言うし。
> 最低。

たまたまそいつがBigDecimalやBigIntegerの使い方知らなかっただけだろ。
はっきりいってそいつのスキルの問題だな。言語の問題じゃないな。

>>222
10進数演算が得意なだけだろう。
日立のCOBOLerがJavaよりも優位な点は、
メソッドを使わず演算子だけでBihIntegerのようなクラスを
使うことができると主張していたな。

たかがそれだけがJavaに対するアドバンテージかよと思った。

過去の遺産が残っているから仕方が無くCOBOLを使ってるだけってのが
殆どだろうがな

>>225
よほど、Sunに知られていないOSや、Java SEやJavaMEが入らない
リソースが小さい古臭いOSじゃない限りそういうことはないだろう。

>>230
知ったか厨？

言っておくが、>>228と>>229は両方とも俺が書いたんだが。

まあ、けっこうGUIライブラリにバグがあったりしたけどね。

>>237
>229 の引用先の内容まで君が書いたわけじゃないんだろう?

>>239
だからWikiで信用できないなら
この大元のソースを見ればいいだろう。

[3]のソース
# ^ "Microbenchmarking C++, C# and Java" by Thomas Bruckschlegel, Dr. Dobbs, June 17, 2005
http://www.ddj.com/184401976
[4]のソース
# ^ "Java and Numerical Computing" by Ronald F. Boisvert, Jose Moreira, Michael Philippsen and Roldan Pozo, NIST, Dec 2000
http://www.javagrande.org/leapforward/cacm-ron.pdf

WikipediaをWikiと略すやつはクズ。これは間違いない。

>>240
いやだから、>239 で引用されている内容は中々面白いとおもうが、
>238 は全然そうではない。それだけの話。

訂正
×>238、 >239
○>228、 >229

>>241
wikipediaが閉鎖の危機になったというニュースを聞きつけて
ニュー速に集まってそういう勘違いをする厨とは違うよ。
Wikipediaに使われているものはWikiだから即座に編集可能だから
ぱっと見ただけでは信用できないという話だけだね。
Wikipediaの仕組みは管理者がコントロールをしているので
だいたいわかってる。管理者にDQNなやつもいるみたいだけどさ。
日本語版Wikipediaは創始者が腐女子みたいな馬鹿女で感情的になりやすく人の話を
ろくに聞かないヤバイ奴だってってことも知ってる。

>>242
そりゃWikipediaにも載っていないことも書いているが。

Javaの歯車製造機械はC++が製造した歯車を動力の一部に動いているが
それがJavaを動かす上で特に問題だと言うことは無い、という意味に喩えればわかるかな？

住んでいる土地が違うだけだよ。

>>244
>日本語版Wikipediaは創始者が腐女子みたいな馬鹿女で感情的になりやすく人の話を
>ろくに聞かないヤバイ奴だってってことも知ってる。
（・∀・）
なるほど、つまりそいつに追い出されたのか。m9（^Д^）ﾌﾟｷﾞｬー

>>245
追い出されてないがw

だが、奴が日本版Wikipediaの印象を悪くしているのは確かだ。

Boostが、いつの間にJITコンパイルやGCのためのライブラリになったのやら

>>232
Strutsとか使ってる部分は、金融系のプログラムっていうのとは違うでしょうが。。

>>193
プロファイラってOptimizeitとかだね。
SoftReferenceを使うのは当然だけれども。
8way CPU とか何台も買ってくれるような顧客はなかなかいないし、
リアルタイム性を確保するのは結構大変だよ。

最近はJavaでもいけるかな、って案件も増えてきたけど。
いい方向に進んでいるとは思う。

>>228は自分が何を問われていたのかわかっていないらしいな
周辺に結論も書いてあるというのに

>>248
> プロファイラってOptimizeitとかだね。
Java標準のでもいけるけど。
Eclipseのでもいけるし。


> SoftReferenceを使うのは当然だけれども。
> 8way CPU とか何台も買ってくれるような顧客はなかなかいないし、

プロファイラやSoftReferenceと8way CPUとは直接関係ないと思うんだけど。

> リアルタイム性を確保するのは結構大変だよ。
組み込みじゃないのにリアルタイムに拘ってどうするのだろう。
マルチスレッドじゃ不満？

マルチスレッドとリアルタイムじゃ話が違うだろ

鯖でリアルタイム？
マニピュレータでも使うのか？

スレッドだけで解決できないのかね？

>今頃、Boost開発者は一生懸命Java SE 6のソースコードを解析して
>最適化技術をリバースエンジニアリングしているところじゃないかな？
ﾜﾗﾀwww
初心者は >>228 の書き込みを鵜呑みにしないようにwww どうみてもネタですからwww

基本的にJavaのほうが優れてる点はGCだから。
メモリのアロケーションはライブラリのレベルである程度は解決できるかもしれないけど
デストラクタの呼び出しタイミングはどうだろね、ライブラリレベルでやるのはしんどいし
いつデストラクタよばれるかわからなくなるとJavaの二の舞になるし、この辺を
ライブラリレベルでできても、多分そのライブラリ使うのめんどくさくなってるでしょ。
あぁ、あれだ16bitWindows時代のGlobalLockとかのような感じならGC実装できるか、
あれはやりたくないね、キャストしまくりだしな。

Javaの二の舞っつーのはfinallyとかな、
finallyっつーのは、本来デストラクタで処理するところJavaだといつデストラクタが
呼ばれるかわからないから仕方なく用意されたんであって、オブジェクト指向的には
ﾌﾟｯfinallyﾀﾞｯﾃﾖ って感じだろ。本来カプセル化の領域にあたる部分だと思うんだけど
Java厨にはこれがわかんないんだよね、だってfinallyばっか使ってんだもんwww

まぁJavaはよくできた言語だし、ただだし、仕事もあるので学生から一般的な
社会人プログラマーまで広範囲にすすめれるな、でもｷﾓｲJava厨にはならないでほしいな。
Javaｻｲｷｮｰとかリアルで話されるとｳｻﾞｲだろーな、格ゲーで○○ｻｲｷｮｰと同レベル。
Java自慢はせいぜい2chだけにしとけよwww おまえ自身の自慢じゃないんだからなwww

Boostは所詮ライブラリだから、最適化はコンパイラ任せでBoostの関与するところではないだろ。
勿論最適化されやすいコードを書くような努力はしているだろうけど。

それとも今度のBoostにはGCがやっているのか。

>>253
> 今頃、Boost開発者は一生懸命Java SE 6のソースコードを解析して
> >最適化技術をリバースエンジニアリングしているところじゃないかな？
> ﾜﾗﾀwww
> 初心者は >>228 の書き込みを鵜呑みにしないようにwww どうみてもネタですからwww

どうみても君の発言のほうがネタですwwww
まさかfinallyを否定するとはねw Object#finalize()とfinallyとの区別が付いていないんじゃないかな。

> メモリのアロケーションはライブラリのレベルである程度は解決できるかもしれないけど
> デストラクタの呼び出しタイミングはどうだろね、ライブラリレベルでやるのはしんどいし
> いつデストラクタよばれるかわからなくなるとJavaの二の舞になるし、この辺を
> ライブラリレベルでできても、多分そのライブラリ使うのめんどくさくなってるでしょ。

そのわりには、BoostはJavaより遅いねえ。ライブラリという考えが実に浅はかだね。
finalize()を実装さえすればいいという考えしかないようだね。C++厨はJavaCやJVMのソース
から何も学ぶこができないのですか？ JVMもJavaCの技術も解読せずに
finalize()を実装するだけで満足しているようじゃそりゃますます遅くなって当たり前でしょ。


> Javaの二の舞っつーのはfinallyとかな、
> finallyっつーのは、本来デストラクタで処理するところJavaだといつデストラクタが
> 呼ばれるかわからないから仕方なく用意されたんであって、オブジェクト指向的には

そうよう恥ずかしい馬鹿丸出し発言はやめようw
C++厨はfinallyとfinalize()との区別が付いていないようだね。
finallyは例外処理に使うものなんだけどねえ。

そういえば、C++の例外処理にはfinally節や例外基底クラスが
ないことが致命的な欠陥となっていることが実に香ばしいねえ。

>>253は

for(int i = 0; i < 10000; i++){
　try{
　　//何か
　} catch (Exception e){
　　//何か
　}
}
よりも

try{
　for(int i = 0; i < 10000; i++){
　　//何か
　}
} catch (Exception e){
　//何か
}

の方が速いから書き直せとファビョるタイプなんだろうなあ。

今じゃ最適化が進んでどちらのコードでも速度はさほど変わらないのにねえ。

　　　l　　　　　　　＼　　　　ヽ
　　　l|,　､　 ､ |iヽ, ヽ ＼.　　　ヽ
　l　　i ! | i　 | |l'､ﾄ　ヽ iヽ　ヽ　 ',
　|　 / | |. i　 |.|| i.|ヽ |､ | ', 　 i　 i
　!　/　|_|　|　|i 　,;ﾄi‐トi､! l　 .i|　 i
,.|!,.+''"^| |` | |i}　　' ｭﾉｪ|i,`i　　l.|　i
l |/;:=ニ|i　 l |　　 /rj:ヽ＼ i　　l i　l
' '/ iﾆ)ヽ,ヽ |!. 　　' {::::::;､! 〉iー | |　| 　
;〈　!:::::::c!　　　　　 `'ｰ''　' }i |　i.|　|　　　　
　`　`''"　　　　､　　//// /;:i |　| !. |　　　　きもちよかった？
､////　　　　　 '　　　　　/,ノi,　　 i. |
､,ゝ、　　　　--−' 　　　/　　 i |　 |. i
　| lヽ、　　　　　　　　／　　　 | i　 |　!
i |l l|　|`''‐ ､　　　, イ　| |　　　 | i　 |. !
| ||i,|　|　　　 ` ''"　 | /l| l　 |i　 |l l　 ! i
| l|!,>‐! 　 　 　 　 　|〃i:|'i　i |　|.i |i　| |i
i l iヽ.,!　　　　　　　 |メ,/ | /ﾉi　i. ! il　i |i
/' |.:.:.:.｀`''ｰ-､ 　 　 !　 〉,|/　|/i'　l |i　l |ヽ
; r'.:.:.:.:.:.:.:.:.:.:.:.｀`''ｰ-'､ノ:|､_　ﾉ '　 i,| l　i|. l
/､､__.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:i.:.:ヽ　　　|　|.i |. |
.:.:.:＼`'ｰ-､＿＿＿:.:.:ー'";／|:＼　 '　ﾄ;|　|
:.:.:.:.:.:＼:.:.:.:.::..:.:.:.:.:.:.:.:￣.:.:.:.:.:|.:.:.:.`ヽ、|.i

>>253は
int c = 0;
long first = System.nanoTime();
for (int i = 0; i < 10000; i++) {
c = (A <= B) ? A : B;
}
long last = System.nanoTime() - first;

System.out.println("c = (A <= B) ? A : B の所要時間 " + last);

このプログラムはあるマシンでは
c = (A <= B) ? A : B の所要時間 246680
を返す(単位はナノ秒)のだが、
このループで10000を1000000に変えるとC++厨は単純に所要時間はこの結果を100倍
しただけの24000000ナノ秒になると勘違いするのだろうな。

このforループを二重にして何回も同じ計算をJavaにやらせると
面白い結果も現れるんだけどねえ。

>>257がキモオタくさくてキモち悪かった

>>257
ショウサイ・キボンティーヌ

ここのJava最速君はどうしようもないな
同じJava信奉者でもマ板のおじゃばさまに遙かに劣る

>>258
いやいやそんなことはない。
そもそもC++で書けば桁が違う、論外だと思っているのがC++厨

>>248
だから藻前は金融系の仕事をしたことあるのか？と小一時間。

漏れは一応あるんだが、藻前の言う病的なリアルタイム性なんか
逆に要求されないんだが。
やたら無駄にクラスタはしてる印象ある。まあ万が一を怖がるから当然だが。

藻前の知っている金融機関はどこかの農協なんだろうけど、
都銀くらいで仕事してから語ってくれ。

藻前こそJavaとC++を適材適所で使うことを覚えた方がいい。

金融系よりも株式系(?)とかのあっちの方が
走るトランザクション数多いけど、Javaや言語がどーこーよりも
RDBの性能の方が影響でかいから、「Javaだと不安」ってのは
仕事したことあるのか？と疑われても当然だ罠

設計をしたことない底辺プログラマーにありがちな妄想と言われるのがオチ。

とりあえずC++0xがどうなるか見て見ないことには
なんか最近のC++は関数型に近くなってるよね

オブジェクト指向が間違いだったことに皆が気付く日も近いのか

一人だけ無駄に必死なやつがいるな

積極的に最適化してくれというメソッドをアノテーションで指摘してやったら
多少は早くならんか

ちなみに歴史的経緯は、GCが遅いことの反省からC++ではスタックとヒープを
プログラマが選べるようにして、コンピュータが速くなってきたからJavaでは
GCを再び採用したみたいな感じなんだけどね・・

今後、コンピュータが速くなっても速度差の比は変わらないわけだけど、
でも、"C++>Java>要求仕様A"に該当するならどちらでも好きな方を
(開発しやすい方ならJavaでしょうかね・・)使えばいいし、
"C++>要求仕様B>Java"ならC/C++を使うしかないことになるんだよね。

たぶんJavaﾏﾝｾｰの人は"要求仕様B"が存在しないと思ってるんだろうけど、
やっぱあるんだよねえ、残念ながら・・
俺ゲームやってるけど、やっぱ無理としか言えない。Java3Dでできれば
楽でいいなあとか思うけどやっぱ無理かな。10年後は知らないけど。
やっとアセンブラ/CからC++に移行してるような感じだからね。
でも確実に差は埋まってるし、コンピュータの速度が上がってきてるから、
"要求仕様A"の数は増えてきるんじゃない?Webアプリなんかそうだろうし。

ただ、ゲームに限らないけど、何かを作るときには、最初に言語を決めなきゃ
いけないわけで、その時に最終的にできるものはなるべく速くて省メモリがいい
という要求はよくある話で、つまり無限に速ければ速いほどいいという要求の
場合はやっぱり要求仕様Bってことになっちゃうんだよなあ。

本当に速いものが欲しければアセンブリ言語。
今でも映像・音声の圧縮はアセンブリ言語が当たり前（少なくとも俺が使う範囲では）。

ただし、それに対するフロントエンドはリンカでくっつけられるので自然とC/C++になるけど。

つまるところ、ことたりるところはより高級な言語で、
速度を要するところでは低級言語で、という教科書に書いてる
ような結論になるわけだ。さすが教科書。

>本当に速いものが欲しければアセンブリ言語。
さらに望むなら専用チップに焼き込みだ!でしょうか・・?

プログラムの焼きこみとHDL(or専用回路)は本質的に違う訳だが

無限に早ければいいと言う要求があるのは事実だろうけど、
C++をキモく感じる感情自体も事実だろ。

このスレはどっちが優れているか？ではなくて、
キモく感じるかどうか？が趣旨だしな

Javaでキモいのはmainだな

>>269
そういう話はC++煽り厨から耳にタコができるくらい聞いたから飽きた
もういい。数値演算だけは速いんだからC++でゲームでも作っていればいい。

純粋仮想関数の =0; はキモすぎ。

キモく感じるか、ならC++使いでもキモく感じているだろうよ
有害かどうか、って言うのはどうやって決めるよ？

>>272
今なら、HDLもJavaで書く時代だw

BYU JHDL, Open Source FPGA CAD Tools
http://www.jhdl.org/

Java-HDLだからな。
SystemCもVerilogもいらんw

>>273
感情よりも実用性、効率性を考えるとC++の用途は
限られてくる。

>ここのスレはどっちが優れているか？ではなくて、
>キモく感じるかどうか？が趣旨だしな
おぉそうだったな、そりゃ森三中とモリマンどっちが優れてる？と
変わらないくらいばかばかしい比較だからな。
俺はC++はキモかわいくて、Javaはパンチが足りない美形みたいなイメージだな。
もしくは萌え熟女と白肌美少女かな。

確かにキモさを語るべきだな
C++不要論は別スレ立ててやればいんじゃね

白肌美少女=Whitespace

>>276
C++作ったBjarneがとにかく早く導入したかったから=0にしたとD&Eに書いている。

構造体のコンストラクタとかどうよ？

>>278
それってJavaでHDLを書けるっていうだけで
JavaそのものがHDLになる訳じゃないじゃん？

http://124.38.226.66/bbs/156147/img/0053778307.JPG

かわいい

>>286 は Java と C++ どちらですか？

>>280
C++厨は腐女子かw

>>285
だがそれも重大な進歩である。

ここから家電Javaへの道が拓かれる

低レベル処理がやりたかったらasmやcに行くし
高レベル処理ならスクリプトやJavaになるなぁ。
C++って選択肢は選びたいと思わない。

両方をふらふら行き来しなければならないときには、選択肢の1つになると思う。

桑島法子「C++厨は脳の手術をするべきだと思います」

C++厨の脳にはガーベッジコレクタを搭載すべきだ。

いや、Javaチップを埋め込んでやればいい。

ついでに人格補正チップも埋め込むと良い。

GCを搭載した結果出るのがそんな発言ならまだGCは不要だろうな

Java脳で全てを解釈しようとするからそうなる。

Javaチップなんて・・・
なんのためのVMなんだよ・・・

ttp://gedo-style.net/g/?v=351494&d=d.jpg

Bjarne Stroustrup Interview about C++
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

ゲーム屋って、組み込み系だと思うな。

>301
前スレで既出

>>255
>Object#finalize()とfinallyとの区別が付いていないんじゃないかな。
ちょwww 意味わかってないんなら適当にレスすんなよwwwwwwwwwwww

>C++厨はfinallyとfinalize()との区別が付いていないようだね。
>finallyは例外処理に使うものなんだけどねえ。
finallyは例外の話だよ

>finallyとかな、
>Javaだといつデストラクタが呼ばれるかわからないから
ここではデストラクタの呼び出しがコントロールできないjavaの欠点について
書いたつもりだったんだけど、典型的なｷﾓｲJava厨だったから理解できなかったんだねwww
まぁ、言葉足らずだったのは認めるよ、おかげでｷﾓJava厨釣り上げちゃったwww

>C++の例外処理にはfinally節や例外基底クラスがないことが致命的な欠陥
例外が発生した場合はデストラクタでリソースの開放などの処理をするから
finallyいらないっていってんだよwww これいってもｷﾓJava厨にはわかんないんだよねwww
だって
>本来カプセル化の領域にあたる部分だと思うんだけど
>Java厨にはこれがわかんないんだよね、だってfinallyばっか使ってんだもんwww
このまんまwwwwwwwwwwwwwwwww

>そのわりには、BoostはJavaより遅いねえ。ライブラリという考えが実に浅はかだね。
Boostには自動でリソース開放してくれるような仕組みは提供してるけど
今風のGCはないからね、>>253ではあくまでライブラリでGC実装するならっつー話。
Boostしらないんならﾃｷﾄｰなこと書くなよ、つーか、JavaのGCがどんな処理してるのか
しらねーんじゃねーのか、このｷﾓJava厨wwwwww

>finalize()を実装するだけで満足しているようじゃそりゃますます遅くなって当たり前でしょ。
ちょwww 意味不www いみふって変換できるのかよwwwwwwwwwwwww

>>256
ちょwww おまっwwwwwwww まじかっwwwwwwwwwwwwwwwwwwwwwwwwwww
それ、途中で例外でたら処理の流れ違うからwwwwwwwwwwwwwwwwwwwwww
ネタ? ネタなんだろ? ｷﾓJava厨的にはこんなん当たり前?

>ファビョるタイプなんだろうなあ。
抱腹絶倒wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
アルバイトに一通りソースチェックしてもらっちゃうよwwwwwwwwwwwwww

このスレ伸びすぎ

デストラクタの話が出たときに、dispose()に思い当たらない
Java使いはもぐりだろ。

>>306
ほとんど自演だから

4人くらいで回してる感じだよな

>>297
俺たちにはニューラルネットワークがあるかｒGCはいらない。
だがC++脳にはGCが必要だ。

個人的にはデストラクタが好き。

{
    Data x;
} <- 確実にデストラクタが呼ばれるから。

disposeについてよく知らんが
あることを楽にするため別の厄介なことが生まれたように感じる。

>>305
> >>256
> ちょwww おまっwwwwwwww まじかっwwwwwwwwwwwwwwwwwwwwwwwwwww
> それ、途中で例外でたら処理の流れ違うからwwwwwwwwwwwwwwwwwwwwww
> ネタ? ネタなんだろ? ｷﾓJava厨的にはこんなん当たり前?
> >ファビョるタイプなんだろうなあ。
> 抱腹絶倒wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
> アルバイトに一通りソースチェックしてもらっちゃうよwwwwwwwwwwwwww


「ちょwwwおまっっwwww」とはこっちが言いたいんだが。

今のJavaCの最適化能力を甘く見ているだろう。
二者のコードのパフォーマンスには当然ながら若干差はあるが、
Java SE5, Java 6から劇的な変化が起きているぞ。
どちらのコードもほぼ変わらない。

現在のJavaコンパイラはその程度、自動的に最適化してくれるように
なっていることを知らないとはC++厨は実に香ばしいな。

試しに古いJavaコンパイラ + JVMと新しいJavaコンパイラ + JVMを使って
パフォーマンスの変化を比較してみると良い。

俺も初めて知ったときは驚いたが、ループ内にtry-catch構文を入れても
その逆の配置にしてもパフォーマンスは大して変わらない事がわかった。

それがJavaの恐ろしさというやつよ。

コンストラクタ（C++ね）は嫌い。

クラス名と同じって言うのは変な感じがする。
デストラクタが~をつけたっていうのはもっと変な感じがする。
テキストエディタのダブルクリックじゃ~は選択されないby VisualStudio。

xxx::xxx()とxxx::xxx(int)で共通の初期化したいとき困るじゃん。
初期化メソッド用意して呼び出せっていうことになるけどめんどくさ。

class xxx : public base
{
const int b;
以下略
};

xxx::xxx(int a)
: base(a), b(0) ← なんだかねー
{
}

xxx::xxx()
: b(1) ← どっちのコンストラクタなのかによりconstの値が違うなんてキンモー
{
}

class xxx : public base
{
const int b = 5; ← コンパイルエラー
以下略
};

後から
class xxx : public base 
{ 
static const int b = 5;
以下略 
}; 
というのができるようになったらしいが
常に最新のC++が使えるわけじゃない。

>>256の上下でコードの意味が違うのだがJavaはそんなところまで最適化してくれるようになったの？
確かに恐ろしい最適化能力だな。人間を超えている。

>>312
横からC#厨が失礼だけど、>>305の言いたいのはパフォーマンスの話じゃないと思うんだ。
>>256の上の例は例外が発生したとき、forループを抜けずにcatchブロックで処理をしてインクリメント。
しかし、下の例は例外が発生した瞬間にforループを抜け、catchブロックで処理をする。
この処理自体の違いに突っ込んでるんじゃないかと。

Javaマスター曰く金融の世界では上下で同じ意味らしいよ

>>316
例外処理も最適化（自分の思った形にロジック変更）されるらしいと
思い込んでるんで勘弁してやってください

つか、いつまで粘着してんの。くだらねえ。

>>304
> >>255
> >Object#finalize()とfinallyとの区別が付いていないんじゃないかな。
> ちょwww 意味わかってないんなら適当にレスすんなよwwwwwwwwwwww
> >C++厨はfinallyとfinalize()との区別が付いていないようだね。
> >finallyは例外処理に使うものなんだけどねえ。
> finallyは例外の話だよ

そのくせデストラクタの話をするとはね。
C++言語の欠陥はむしろ、finally節が無いことなのだが。

> >finallyとかな、
> >Javaだといつデストラクタが呼ばれるかわからないから
> ここではデストラクタの呼び出しがコントロールできないjavaの欠点について

お前はjava.lang.SoftReferenceについて勉強してから発言した方がいいな。
無知にもほどがある。

> >C++の例外処理にはfinally節や例外基底クラスがないことが致命的な欠陥
> 例外が発生した場合はデストラクタでリソースの開放などの処理をするから
> finallyいらないっていってんだよwww これいってもｷﾓJava厨にはわかんないんだよねwww

ほうほう、その論理ではC++にはデストラクタは要らないと言ってるようなものだな。いかにもC++厨らしい考え方だ。
そのようなヌカ喜びをするまえに例外処理について勉強しておくんだな。
C++厨は複数のcatch節にいちいちデストラクタを呼ぶ構文でも書くのか。
finallyの特徴は例外が発生しようがしまいが、(return文を除き)必ず実行してから終了するというものなのだが。
C++にはそういうものがないから欠陥だと言っているんだが。
お前こそJavaのことも知らないで知ったかぶりをしているだろう。
いずれにしても次世代Javaではクロージャの導入が検討されている。お前がウザイと思っている些細な問題も
解決するかもしれんがな。

それにしても、愚かなC++厨はObject#finalize()を間違った方法でオーバーライドしてパフォーマンスを劣化させるだろう事が想像つく。

>>307
close()の間違いじゃなかろうな

>>311
こいつが言ってるdispose()はclose()のことだろう。
ファイルI/OやDBなどのセッションクローズのことを
言いたいだけだろう。
デストラクタとfinallyどっちがマシだ、といったらfinallyのほうが
ましな構造をしているのだが、C++厨は認めたくないらしい。

こんなの見つけた
http://mag.autumn.org/Content.modf?id=20050506145337

>>316
> >>312
> 横からC#厨が失礼だけど、>>305の言いたいのはパフォーマンスの話じゃないと思うんだ。
> >>256の上の例は例外が発生したとき、forループを抜けずにcatchブロックで処理をしてインクリメント。
> しかし、下の例は例外が発生した瞬間にforループを抜け、catchブロックで処理をする。
> この処理自体の違いに突っ込んでるんじゃないかと。

それも最適化されるんだよ。やってみ。C#ではどうなるのか知らんが。Javaでは
速度差は大して変わらなくなる。

>>318
ああ思い込んでいるとも。実際その通りになるんだからな。

>>256が実際どんな処理かは知らんが、例外が発生したらcatchで処理して
インクリメントしてくれなくても構わん場合がほとんどな気がするが。

仮にファイルのIOで一回目で例外発生したなら残り9999回も例外でるだろうし。

古いサイトではこんな都市伝説があるが、これもJ2SE1.4までの話。
Javaの最適化技術を甘く見ていると恥をかくので注意すること。

http://www.sgnet.co.jp/java/chapter0503.html

自動変数のデストラクタの特徴は例外が発生しようがしまいが、(スコープを抜けるときに)必ず実行してから終了するというものなのだが。 

>>323
ビーデーのメガネデブ川俣 晶かよw
その日記に自らJavaが嫌いになったJavaコミュニティが嫌いになったと
書いてる奴だろw ユニシスの某馬鹿社員と気が合いそうな奴で笑える。

>>326
ソースきぼ

256が最適化されようがされなかろうが、
こんなソース書いてる奴は作法がなっとらんわ。

dispose()、close()、flush()、ほかにもあるかもしれない。
ヒープの解放の自動化は自慢するのに、
それ以外の資源については手作業でごりごり書くしかない。
それが「まし」だと思い込まされてることに気づかない。

>>322
あいにくだがfinallyを引き合いにした話じゃないし
前レスのtryの話の続きじゃない

>>329-330

>>256のパフォーマンスがさして変わらない理由は、
Java One Tokyo 2005のセッション
「Java Performance Myths Exposed」を聞いた者だけがわかる。

いま資料が無いかググっているところ

ちゃんと残りの9999回例外吐いてくれたよ@JDK6

>>333
それが一般化してるならまだしも、
知ってる奴が限定されてんなら
思いっきり性能改善対象になるだろ。
知らない奴が多数なんだから。
つか、資料よろ

Javaのfinallyが駄目って話じゃなくて
finallyはfinallyでC++にあっても便利だと思うし、
C++のデストラクタのような即効性があって
Close書き忘れを実行時に発見できるもの便利だと思う。

{ 
    Data * x; ポインタだと自動じゃ呼ばれないけどね。
} 

>>333
何か知らんが例外の負荷が低いって良い話じゃない。

>>335

見つけた。
http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-3268.pdf
若干コードが異なるが、
新しいOSとJVMではfor文無いでtry-catchをつけようがつけまいが、
さしてパフォーマンスは変わらないことがよくわかる。
古いOSだと恐ろしいほど差が出ている。


>>334
所要時間は？

>>338のPDFファイルの9枚目には
for文無いでtry-catchを書いてぬるぽを発生させた場合での
パフォーマンスもあるので、>>256の言ってることは正しい可能性が高い。

>>313
C++0xではコンストラクタからメンバ初期化子構文で別のコンストラクタを呼べるようになるという噂。

>>314
そこでenumハック

ところで313-314も256と同じくらいアレだと思うんだ。

>>338の元のページはこれ

会員登録していればHTMLでも見ることができるらしい。

http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-3268.html

ループの中で例外処理を行うのと、例外処理機構の内部でループするのでは
意味合い(というかムード)がぜんぜん違うと思うんだが。
前者は逐次処理毎に例外を扱い、後者は一連のひとまとめの中で例外を扱う、みたいな。
ひとくくりにされて同じだと言われると、算法的になんとも気持ちの悪い感じを受けてしまう。

とりあえずJavaのfinallyもC++の（ローカル変数に対する）デストラクタも、
（どっちの構文が優れているかはともかくとして）
例外の発生するしないに関わらず実行されることには違いないだろ。

>>340
C++0xが早くできねーかな。
Javaにいいところ取られっぱなしだよ。

そうそうenumだよね。実はよく使っている。
Javaとは違い細かいことうるさくないのが逆にC/C++のいいところでもあるけど
なんだかなー

Javaのfinallyはtry { } finally { x.close(); } を毎回書くが
デストラクタは X::~X() { close(); } を一度書くだけ。

ただの finally よりも、例外が発生した時だけ実行される finally がほしい。

何かJavaよくしらんけど
 X::~X() { if(!isClosed) throw "おまえcloseし忘れてないか"; } 
みたいな機能Javaにあるの？

9999回リトライしない場合は上下のコードに大した速度差はないな

>>346
それcatchの中でやればよくね？

なんでもいいけど、
for文の中に例外処理が入ってるってのを
感覚的に気持ち悪いって思える方が信頼できる。
「最適化できますから」と力説されても気持ち悪いもんは気持ち悪い。

>>346
C/C++だと何かメンドクセーgoto使っちゃえの世界だな。
goto減らす代わりにフラグとifが増やすのってめくそはなくそに思うんよ。
めくその方がちょっとましかもしれないけどさ。

そういえば、Javaってクラスの中のクラスから
外のクラスのメンバにアクセスできるのと出来ないのがあるんだってね。
面白そうだね。
C++はできないタイプのほうしかない。

>>352
これの、そういえばって、

>>346
関数の中に関数を書けたら
そういうニーズに対応できるね

ってレスしようとしてやめた。

>>349
複数の catch に同じ開放コードを書くのはうんざり

>>354
具体的に、どんな構文だったらマシになるかな？

D言語のscope(failure)とか
http://www.kmonos.net/alang/d/exception-safe.html

へー。VBのon errorにちょっと似てる？

>>354
俺C++しかしらないけど、一応こういう書き方ができる（誰もやらないが）。
Javaでも似たような書き方ができないか？
try {
try {
//...
} catch (...) { //全ての例外を捕捉
//... 共通の後処理
throw;
}
} catch(const MyException& e) {
//...
} catch(const std::exception& e) {
//...
}

>>355
try {
} catch {
} catch {
　　　・
　　　・
　　　・
} commoncatch {
} finally {
}

commoncatch はどれかの catch を通ったらcatch処理後、finally実行前に実行される。
catch されないときは実行されない。素人考えかな？

>>359
それだったら、switchみたいにcatchをbreakで抜けるようにすればよくね？

>>358
まんま同じように書けるよ。

>>345
それなら、Apache Jakarta Commons DBUtilsや
Apache Jakarta Commons IOを
使えばJavaでもfinallyを書かなくて済むようになると言えてしまうぞ。

ついでにDBの場合、Hibernateを使えば
さらに開発が楽になりfinallyだろうがデストラクタだろうが
煩わしいものが無くなる。

>>346
catch節抜きで

try {
　//例外が発生する可能性があるコード。
} finally {
　//try節にreturn文やbreak,continueが無ければ必ず実行される。
}

こうやればあなたの夢は叶います。

>>345
そもそもclose()する必要がないオブジェクトに対しては
そんなものがいらないのでデストラクタなんぞ不要。

>>347
Connection#isClosed()ならある。

Conneciton con = DataSource・・・・・
PreparedStatement ps = null;
Result rs = null;
try {
//SQL実行
} catch (SQLExceiton e) {
　・
　・
} finally {
　try {
　　if(con != null &&!con.isClosed()){
　　　con.close();
　　} else {
　　　throw new SQLException("おまえcloseし忘れてないか?");
　　}
　　ifps != null){
　　　ps.close();
　　}
　　ifrs != null){
　　　rs.close();
　　}
　} catch (SQLException e){
　・
　・
　}
　・
　・
}

>>350
それもそうだ。外側に置いた方が、古いOSやJVMでも
パフォーマンスを改善できるのだからな。

>>351
そこでJakartaなどのプロジェクト が様々な解決方法を提供しているわけだが。
Java5から登場したアノテーションを使うという手もあるだろう。

次世代Javaから登場する予定のクロージャに期待せよ。

>>358
Javaなら、そういうこと>>365のようにfinallyでやる。


>>355-356
面倒くさければまとめて
catch(Exception e)
だけで補足するという手がある。
ただしこれだと、開発やデバッグに支障を来すぞ。


こういう問題は、EclipseなどのIDEで自動化すれば済むこと。
Eclipseでは、try-catchで過去みたいあるコード領域をマウスでドラッグして
「try-catchで囲む」を実行すると、どの例外をthrowsするのか
メソッドから、調べて、catchすべき例外をリストアップしてくれるぞ。
さらにコードテンプレートでcatch節に書く内容も定めることができる。


>>359
throwsで外部に任せるという手もある。だがそれは例外機構の原理と設計を理解してから。

なんだかんだ言って、JavaもJakartaみたいに外部ライブラリを使わないといかんのかな・・
C++とBoostの関係と似たような物なのだろうか。

俺は初期のJavaの解説をちょっと見た程度の知識しかないが
Java+Eclipse+Jakarta=ｽｹﾞｰ
ってことなんだな。

もうエディタにコンパイラが内蔵してあるようなものでしょ。

俺がメインに使うC+++VisualStudio2005は
徐々に機能アップしているけど
C++のコード生成自動化はJavaやC#に比べると限界が近いな。

CとかC++って検索しにくかったな。
最近のgoogleはC++で検索できるようになってるみたいだけど。

アルファベット1文字と+記号

>>364
何が言いたいの？

>>369
BoostとJakartaはあまりにも違うだろ。
Javaでは言語仕様にBoostのようなライブラリが含まれている。

JakartaのAPIとJava標準APIとの違いは
Java標準APIが低レベルＡＰＩを提供しており
標準APIに不足しているJakartaが高レベルAPIを提供しているということ。

この違いが、Javaのアップグレードに混乱を起こしにくくして
ゆっくりと確実な進化を遂げており、Win32 APIやMFCのような
トンデモAPIのようなAPIに悩まされずに済むということだね。

M$はWin32APIのようなやたらと高レベルAPIを.NET frameworkやWInFXでも
提供してバカでも簡単にstaticメソッドでファイルI/Oが使えますよ、と宣伝
しているけど、それが大きな仇になってる。
Javaはそういうところはstaticにせずデザインパターンを巧みに使用して
汎用性と拡張性を高めている。

>>373
なんでWindows叩きをしてるの？

C++がもっともつかわれているプラットフォームは
主にWindowsだからじゃね？

Jakarta　Commonsは低レベルだけど、スルーしないでほしい。

>BoostのAPIとC++標準APIとの違いは 
>C++標準APIが低レベルＡＰＩを提供しており 
>標準APIに不足している高レベルな部分をBoostが提供しているということ。 

こう置き換えても余り変わらない希ガス。
確かに、Java標準ライブラリはスレッドからGUIまで、C++標準に無い部分まで手広く抑えてるけど。

つうか、BoostはC++に標準で組み込まれてもいいはずの
低レベルAPIのはずなのに分離している。

次期標準のC++0xでBoostの一部が取り込まれますから。

ちょっwww
>>312 >>324 こいつwww ヤバイwwwwwwwwwwwwwwwwwwww
こんなに面白そうなｵﾓﾁｬ釣り上げたのに意外とレスつかないね。
やっぱム板は冷静な人多いね。
むしろ自分が初心者いじめてるイジメッコにしか見えんw

まじで初心者ならごめんなさいね、あなたのためにちゃんとレスしてる人もいるので
その人たちの善意を無駄にしないようにねw

追伸
十年ロムってろw

とりあえずVIPPERを装いたいんならｗを大文字にしろ

>>320 やっぱ、こいつも初心者? それともC++知らないだけ?

>>381 ワリーw VIPPERごっこあきたからもうやめるわ、初心者しかつれねーしw

C++にはfinallyいらねって書いてるけど、めんどくせーからfinally使わせろよって
思うときは結構あるんだよね。
C++はあれだけゴチャマゼとか言われてるのにfinallyがないのが結構不思議なんだよな。

例外は直接関係ないけどC#にはDisposeとusingでC++風デストラクタの呼び出しできて
(Disposeだけどな)結構便利かな、いちいちusing書かせんなよって思うけど。
この辺はJavaよりあとに出ただけあって微妙にいいよな。

>いずれにしても次世代Javaではクロージャの導入が検討されている。
最近はjavaから離れてるし実際に業務で使用できないのはいちいちチェックしないから
よく知らないけど、これなに?ってここで聞いていい?
引用は>>320からだけど>>320以外に答えてほしいw

追伸
>>320 十年ロムってろw

>>382 Pythonの例だけど、closure
http://www-06.ibm.com/jp/developerworks/linux/010706/j_l-prog2.html

だけど、>>320が分からん。
関数が環境付きで持ち運びできることと、例外発生時に後処理が確実に呼ばれるようにすることの関連が良く分からん。
だれか教えて。

クロージャも知らないプログラマが存在するのにはびっくり。

>>832はJava頭のままC++を使わされて、どつぼに嵌ったかわいそうな人。

>>832
おお、なんとかわいそうなお人。

頑張れよ >>832
俺は期待してるぞ。

いらん恥かいちゃったねw 言い訳しませんw

>>383
わざわざありがとー

デストラクタ・例外のあたりはもういいかな、
以下はクロージャと >>832 へのネタ振りよろしくーw

>>382
C++の言語仕様って、それを外すとろくな代替がないことが多いんだ。
そういう意味では無駄がないと言えなくもない。
finallyはデストラクタがあるから要らないと考えれば納得できないか？

>>380
> ちょっwww
> >>312 >>324 こいつwww ヤバイwwwwwwwwwwwwwwwwwwww
> こんなに面白そうなｵﾓﾁｬ釣り上げたのに意外とレスつかないね。
> やっぱム板は冷静な人多いね。

お前が冷静じゃないだけだろ。
C++厨は相変わらず絶対に自分の間違いを認めないんだなw
何もかも全て自分の都合の良いようにしか考えることができない惨めなC++厨。

あとのお前のレスはすべて言い訳だな。
それに便乗する>>382も時代の流れを認めずC++に固執している姿が伺える。

こいつらを見ていると、
C plus plus のの略CPPは本当はCCPlus(CCP)、いや、
C++厨は嘘と脅しと虐殺で大陸を統治するCinese Communist Partyの連中なのでは
ないかと思えてくる。

>>388
> いらん恥かいちゃったねw 言い訳しませんw

すでにしてるだろうw

ところでお前は>>256の主張をまだ認めることができないんだなｗ

以下はMLからの引用だが。Java SE 7(Dolphin)から導入予定の
クロージャによってfinallyを書く手間を省けるコードの例

http://www.javareading.com/bof/logs/2006/msg00520.html

Neal Gafter氏のブログに、JDK 7で導入検討中のクロージャのコード例が
記載されています。
http://gafter.blogspot.com/2006/08/use-cases-for-closures.html

() { 文... }
という記述になるみたいですね。ちょっと違和感ありますが、
匿名クラスを書くよりシンプルです。クロージャはコンパイル時に
匿名クラスに書き換えられるようなので、糖衣構文な機能です。
void sayHelloInAnotherThread(Executor ex) {
ex.execute(() {
System.out.println("Hello");
});
}
これは、コンパイル後
void sayHelloInAnotherThread(Executor ex) {
ex.execute(new Runnable() {
public void run() {
System.out.println("Hello");
}
});
}

また、上記ブログでは、さらに同期に関して興味深い使用例が取り上げ
られています。C++のRAIIに匹敵する機能です。
withLock(lock) {
...
}

java.util.concurrentのLockをsynchronzied文同様に囲ってしまう
　機能です。これは、コンパイル後、
　try {
...
} finally {
lock.unlock();
}
に書き換えられるようです。

＃ざっと流し読みしただけなので間違いあるかもしれません。

これでtry finallyマンセーやろうが減ればいいんだけど。

>>374
もちろん、>>373が馬鹿だからw

>>395
お前、顔真っ赤だぞ

酔ってないよ!!

語尾にwを沢山つけていた
>>395の顔はしわくちゃになってます。

つるつるすべすべだよ!!

>>392
よりによって去年の8月の構文だしてくるかよ……

finally好きでごめんな

>>256
>>305
>>312
>>315
>>316
>>318
>>324
>>333
>>391
良スレあげ

>>402
お前、256(もしくは320)？
391を含ませている辺り悪意を感じるな。
382が恥をかいたといっているのはクロージャ知らない
事に対してではないの？

あと、256の例の前後で処理の流れがぜんぜん違うのは問題
無しなの？

ttp://d.hatena.ne.jp/uskz/20070206/
クロージャといえばこんなんあった

>>403
細かい探りを入れると惨めになってくよ。
ここは有益な情報が入ったから、よいとしようジャマイカ

>>404
何このコードw

namespace lunatic { namespace lambda {

template <typename T>
struct close_type
: boost::mpl::identity<
boost::lambda::lambda_functor<
boost::lambda::lambda_functor_base<
boost::lambda::other_action<
boost::lambda::contentsof_action
>,
boost::lambda::tuple<
boost::lambda::lambda_functor<
boost::lambda::identity<
boost::shared_ptr<T>
>
>
>
>
>
>
{ };

つかクロージャ知らないなんてマとして認められんだろ。

(let (（恥の上塗りcnt 0))
　　(defun >>391 ()
　　　　(princ "ところでお前は>>256の主張をまだ認めることができないんだなｗ")
　　　　(incf 恥の上塗りcnt)))

>>408
関数名に >> まで使えるのか。lisp 恐るべし。

ﾜﾛ

クロージャ使うのはひと苦労じゃ

そんな寒いオヤヂギャグ

>>408
>>338のPDFを見て実際に実験してみれば
C++厨のほうが恥の上塗りになるだろうさ

駅で切符を買ってから改札を通るか、改札を通ってから切符を買うかを
電車に間に合うかどうかで決めることの愚かしさ。

>>406
C++の人は変態と言ってあげると喜びます

じゃあ、C++厨に向かって「きんもー☆」っと女の子に言わせるように指示しておくよ

韮沢さんと大槻教授の噛み合わない論戦を見ているようだ。

大昔のBASICとマシン語のやりとりとかわらんっつか、
俺はCOBOLer全盛時にASM屋だったケド同じだな。
やる場所がちがうだけだろ。

電車に間に合わないときは乗ってから買うんだよ
今は通用しないのかな？

>>419
Just in Timeコンパイラのことか？

今なら、電車に間に合わないときは乗ってから
携帯電話でSuicaチャージするんだよ。

っていうネタを想像した。

>>419
最低でも一駅分の切符がないとｗ

>>419
今でも田舎では通用するよ

>>421
最低でも一駅分のお金がないと買えないw

VIEW Suicaや登録したPASMOではタッチしたときに残額が足りなければ、
クレジットカードからチャージするオートチャージという機能がある。

人が立ってる側の改札なら突破できるぞ？

自動改札も簡単に突破できるが？

ム板で鉄道の話して勢い最大とかありえない

基本的にこの板は活発でないもん。
半年以上書き込みがなくてもレス数があれば落ちないし。

鉄道のシステムはJavaですかC++ですか？

>>429
COBOLです

TGVも？

>>421
んなこたあない。改札がない駅はまだ幾らでもある。

JR情報システムの社長はWindowsとドトネトに激しく拘っていたからな。
彼は「Windowsがないシステムはありえない」と強調しているからな。
COBOLが使われていたことが影響してMSの宣伝文句でCOBOL.NETに
乗せられてるんだろ。

それに、緑の窓口のプラズマディスプレイにはよく赤い×印のポップアップが出る。

無人駅がかなりある。

>>432
ちょ、それ改札通ってないｗ

なるほど、つまり

　ちょ､それ例外起こってない

っていうことか

>413 名前：デフォルトの名無しさん[sage] 投稿日：2007/02/17(土) 19:39:29
>>>408
>>>338のPDFを見て実際に実験してみれば
>C++厨のほうが恥の上塗りになるだろうさ

>>256 のネタいじったら毎回反論君プログラムが実行されるの?

　 　　　 　　 　＿＿＿_　　　
　　　　　　 ／ ＼　　／＼　ｷﾘｯ
.　　　　　／　（ー） 　（ー）＼　　　　　　
　　　　／　　 ⌒（__人__）⌒ ＼　　　　＜Javaの最適化を甘く見ているだろう
　　　　|　　 　　　|r┬-|　　　　| 　　
　　　　 ＼　　　　 `ー'´　　 ／
　　　　ノ　　　　　　　　　　 　＼
　 ／´　　　　　　　　　　　　 　　ヽ 　 　 　 　 　 　 　
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､. 　 　
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

　 　　　　 　　　＿＿＿_
　　　　　　　 ／_ノ 　ヽ､_＼
　ﾐ　ﾐ　ﾐ　　oﾟ(（●）) (（●）)ﾟo　　　　　　ﾐ　ﾐ　ﾐ
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼　　　/⌒)⌒)⌒)
|　/　/　/　　　　　|r┬-|　　　　|　(⌒)/　/ / /／　　＜ だっておwwwwwwwwwwwwww
|　:::::::::::(⌒)　　　　|　|　 |　　 ／ 　ゝ　　:::::::::::/
|　　　　　ノ　　 　　|　|　 |　 　＼　　/　　）　　/
ヽ　　　　/　　　　　`ー'´ 　 　 　ヽ /　　　　／　　　　　バ
　|　　　　|　　 l||l　从人 l||l 　　　　 l||l 从人 l||l　　バ　　　ン
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､　　　　ン
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

社内にいる車掌が改札だからな

>>437
くだらない。何かちょっといっただけで毎日>>437のAAがレスされるの？
じつにくだらない

最適化されるってレスしてるやつは、本気でそう思ってるのかネタでレスしてるのか
どっちなのか知りたいね。

>>439
俺は>>437じゃないがお前の書き込み見てると>>437のAAでレスしたくなったぞw

本人登場。まぁ言い返せないんだろうね。

このスレ、今日はじめて見たんだが……（といっても全部じゃない）
cppとjavaの優劣をつけたいもんなのか？
俺、どっちも使うけど別に違いなんてその言語の味みたいなもんだろ。
必死になる気持ちがわからねぇよ

自分の使ってる言語が偉いことになれば、自動的に自分が偉いことになるじゃん。
「やったァ、俺の勝ちぃぃぃぃぃぃ！　お前は俺より格下な！　下、下ﾌﾟｹﾞﾗ」
っていう最高の気分になれるじゃん。
ここのスレの人間はみんなそれを目指して頑張ってるんだよ。

>>444
両方使えばﾖｸﾈ？新しいの覚えると、先のは頭から削除されるのか？

>>439
AA略　＜くだらない。何かちょっといっただけで毎日>>437のAAがレスされるの？
　　　　 ＜じつにくだらない
AA略　＜ だっておwwwwwwwwwwwwww

>>443
釣りに引っ掛かる変なやつをいじって遊ぶところだろ >>256 とかの
>>256
>>305
>>312
>>315
>>316
>>318
>>324
>>333
この辺の流れか、いかにもアホそうなやつが沸いてるのは

とりあえずage進行で発言してるやつはアフォなヤツが多いのは解る

>>447
なぜおまえはそんなに必死なのだ。

Javaやっているからって偉そうにすんなよ
どうせWindowsユーザでJavaで作られたソフトを使う人なんて多くないだろ

いるだろ。
オンラインバンキングをなめんなよw

> 多くないだろ
いるいないじゃなくて多いか少ないかの問題なんだが？
よく勘違いする奴って、何かと相手の意見を勘違いして
自分の脳内だけで意見のゴリ押しするから嫌われるんだよ

>>451
あぁ〜〜そぉ、お前ってネットバンキングのプログラム作ってんの
あぁそうか、そりゃすごいね。それはそれですごいよ。だから何？

あるぇ？この間それ関連でVistaだとサポートされてなくてしばらく対処されるまで
待つようにと告知されてなかったっけ？まぁ、Javaでそれが出来ればOSに依存せずに済む罠。

>>452
>多いか少ないかの問題なんだが？
何が問題なんだか。

>Javaで作られたソフトを使う人
が少ないと、
>Javaやっているからって偉そうに
しちゃいけないのか？

何その園児のケンカ。

>>450
いるだろ、オンライントレーディングをなめんなよw

将棋倶楽部24ではお世話になったなぁ
最近全然行ってねーや

>>450は何時の時代の人なんだろう。
10年前の世界で思考停止している人ですかな

誰でもいいからﾎﾟｲﾎﾟｲ釣れるネタ書き込めよ、燃料無いとこのスレつまらんから。

>どうせWindowsユーザでJavaで作られたソフトを使う人なんて多くないだろ
そーいえばWindowsでよく使うJavaで作られたソフトって何使ってる?
俺、Eclipseぐらいしか使ってないかな、
サーバサイドは無しでどんなのあるの?

458 名前：デフォルトの名無しさん 投稿日：2007/02/19(月) 17:06:17
>>450は何時の時代の人なんだろう。
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな

さて、それではユーザはともかくJavaでプログラミングしている人と
Windowsアプリケーションを作っている人の割合を示すソースの提示を要求しよう。
これでJavaの方が上ってならそれはそれでどうでも良いことだがｗ

Javaって、ゆとり教育にぴったり。
C++からｺﾑｽﾞｶｼｰ機能は取り除きました! みたいな感じ。
んで、java厨は「こんなｺﾑｽﾞｶｼｰ機能は有害なんです。」ってわめーてるのw
おめーがつかえねーだけだろw

>>462
そうだよ、それが何か？

有害に感じてくれていいと思うよ
こっちこられても困るし
仮にC++が滅亡しても1ヶ月もあれば余裕でJava厨になれるし
ゆとり教育にぴったりってのも素晴らしいメリットだよね

　 　　　 　　 　＿＿＿_　　　
　　　　　　 ／ ＼　　／＼　ｷﾘｯ
.　　　　　／　（ー） 　（ー）＼　　　　　　
　　　　／　　 ⌒（__人__）⌒ ＼　　　　＜そうだよ、それが何か？
　　　　|　　 　　　|r┬-|　　　　| 　　
　　　　 ＼　　　　 `ー'´　　 ／
　　　　ノ　　　　　　　　　　 　＼
　 ／´　　　　　　　　　　　　 　　ヽ 　 　 　 　 　 　 　
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､. 　 　
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

　 　　　　 　　　＿＿＿_
　　　　　　　 ／_ノ 　ヽ､_＼
　ﾐ　ﾐ　ﾐ　　oﾟ(（●）) (（●）)ﾟo　　　　　　ﾐ　ﾐ　ﾐ
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼　　　/⌒)⌒)⌒)
|　/　/　/　　　　　|r┬-|　　　　|　(⌒)/　/ / /／　　＜ だっておwwwwwwwwwwwwww
|　:::::::::::(⌒)　　　　|　|　 |　　 ／ 　ゝ　　:::::::::::/
|　　　　　ノ　　 　　|　|　 |　 　＼　　/　　）　　/
ヽ　　　　/　　　　　`ー'´ 　 　 　ヽ /　　　　／　　　　　バ
　|　　　　|　　 l||l　从人 l||l 　　　　 l||l 从人 l||l　　バ　　　ン
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､　　　　ン
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

>>462
複雑なものをできるだけ単純に見せかける。
Javaの良し悪しは別として、言語の進歩ってそういうものだよ。
人間の頭は簡単には進化しないのだから。

>>460-462
吹いたw
お前粘着かw

C言語厨は>>458の一言にかなり傷ついたらいしな

>>460
どうしたら>>458をそう曲解できるのだろう。
>>458は>>450の二行目のことを言っているだけだと思うのだがw

>>461
作っている人の数で判断してどうするんだw
>>450の花井から、使っている人の数を確認したかっただけじゃないのか？

>>462
そうおもうなら、おまえはアセンブラでシコシコ書いていればいいよ

>>464
> 有害に感じてくれていいと思うよ
> こっちこられても困るし
> 仮にC++が滅亡しても1ヶ月もあれば余裕でJava厨になれるし

無理。甘く見すぎや。

>>472
うちの会社そんくらいの期間でJava未経験から粗製乱造して出荷してますから
営業が強いって、いいよね

不要な機能を取り去る、というのはいいことだと思う。
取り去ってみたけど、後で必要が生じて付け足すのはバカバカしい。

たとえば演算子オーバーロードのことですかね。

>>474
テンプレート(C++) -> なし(昔のJava) -> ジェネリック
ちゃんとJava厨にも使えるように難しい使い方はできないようにしてあるけどね
バカバカしいでしょw

それとも、可変長引数？

RAIIとか

Genericとかいらんだろ。Java1の頃が速度以外は一番良かった。

懐古だが、あの頃はまだ夢があったな

夢のある言語に乗り換えないの？

>>459
>誰でもいいからﾎﾟｲﾎﾟｲ釣れるネタ書き込めよ、燃料無いとこのスレつまらんから。
そういう下らない事はマ板でどうぞ。

Java?
C++?
お前ら何言ってんの
これからの時代はC#だろ

>>482
ム板のほうがたまにいいレスつく確率が高そうなきがすんだよね
>>466 とか具体例だしてほしいんだけど、C++とJavaの違う部分でGC以外

C#最強を信じる俺でもC#が盛り上がるとは思えん…

そうか。ｽﾏｿ

>>476
そんな煽りをするなら、












アセンブラ　-> C/C++

ちゃんとC++厨にも使えるように難しい使い方はできないようにしてあるけどね
バカバカしいでしょw

>>479
意味ねえ。リフレクションも使えねえし

C#はｳﾝｺ。いいものをパクって我が物顔のいつものＭＳ商法。
Monoならまあ、考えなくもないが結局それならPython使うよ。

LISP最強

>>481
Rubyに乗り換えたいけど、使い物になるにはまだまだ時間かかりそうだな。

> 仮にC++が滅亡しても1ヶ月もあれば余裕でJava厨になれるし
なれるかボケ

Javaをなめてかかって甘く見ている証拠だな。


多くのC++厨がJavaのライブラリを覚え直すのが面倒くさいと主張している。

それが証拠だな。

今からデータベースやネットワーク、セキュリティの勉強やらパーシステンスAPIの
勉強やらをたった一ヶ月ですべて済ませられるかな。

>アセンブラ　-> C/C++
>ちゃんとC++厨にも使えるように難しい使い方はできないようにしてあるけどね
アセンブラのなにが難しいんだ? アセンブラ自体はシンプルだろ。

> 多くのC++厨がJavaのライブラリを覚え直すのが面倒くさいと主張している
そうか？俺はあまり聞かない気がする。
Wikipedia的にソース希望。

どうか知らんが実際めんどいぞ。

>多くのC++厨がJavaのライブラリを覚え直すのが面倒くさいと主張している
わざわざ覚えなおす理由がわからん、一度本でも読めば十中八九理解できるし
細かいとこは必要なときに調べればいいだろ。
はなからデータベースしらんとかネットワークしらんとか前提でいってるならしらん。

JavaやるとSTLがきもくてたまらん。OOPLの考え方に反してる。

>>495
お前、チョンなどの三国人みたいにWikipedia改竄するなよ。

>>497
たかくくりすぎだな。
お前にEJB使いこなせるか？

一ヶ月でJavaを覚えられると言っている奴は
C++では想像もつかなかったコンパイルエラーに悩まされるだろう

>>500
EJBを使いこなす必要のある仕事がどれぐらいあるんだ?

>>497
やりゃわかるべ。
ひとつひとつは別に難しくないけど、覚えること多すぎ。

>>498
STL使えるとJavaのコレクションはｵｺﾁｬﾏ用にしかみえない。
効率悪くてやるきなくす。コード書かせすぎ。

C++でATL組めるぐらいまでやれれば、Javaでとりあえず組むぐらいはできるよ。
Strutsのプロジェクトに参加するぐらいならネットで調べながらでもできるから、
できると思ってる人の気持ちはわかる。

何度言っても配列Overでプログラムを変な落ちかたさせる同僚を見てると
Javaの方が数段優れてるように思えてくる。

C++いいじゃん。
速いし、やれる事が沢山ある。
趣味プログラマーだからそう感じるんだろうけど（・・；）
仕事だったら生産性悪い気がする。

JavaとC++、どっちが優れているかは別にして、
JavaプログラマーとC++プログラマーはどっちが技術のレベルが高いの？

>>508
C++とJavaの知識領域は、実はあまりかぶるところが無いと思う。
両方（というか他の言語も）やる奴以外、技術レベルはあまり高くないと言えるかも。

できるやつはC++もJavaも両方つかえるんじゃねーか?

でもまぁ、JavaがC++よりよいと思われることの大部分は、VMによって享受されて
いるわけで。

とはいえ、厳密に言語として比較するのは難しいので、同じ仮想マシン上で動くプログラムを作成するという条件で比較するといいと思う。

つまり、C++/CLIとJ#だ。

おれはC++の勝ちだと思う。

C++/CLIとC++はまったくの別物だし、J#とJavaはまったくの別物。
これでは、比較にならないぞ。

ってか、偽言語を広めるな > MS

JavaもC++もまだまだ改良の余地ありすぎだろ。
早く改良しやがれ！

つC++0x

>>512
もちろん冗談だが。

JAVAはVM込みで進化するので、C＋＋と比較すること自体おかしい。

VMバージョン地獄はもういやお

>>516
ﾊﾞｰｼﾞｮﾝｱｯﾌﾟしない言語に乗り換えないの？

Javaの案件やってて鬱になるのは、フレームワークが多すぎて
どれ使っていいかの判断が辛いことだな。
それなりに本やWEBで追っているつもりだが、大変だ。
あと、おっさんが日経なんとかで見つけた技術を使いたがって鬱陶しい。

Cとか、C++の案件はやり方について上がうるさくないのはいいね。
でも、そろそろboostくらいは覚えるかな。

>>494
インテル系の石は直交性低いせいで無駄に難しくなってるよ。

>>504
STLのほうがどうみても効率悪いだろ。
Objectクラスが無い時点でもうすでにオコチャマだな。


不満があるなら、Jakarta Commons Collectionsを使え。

>>511
機能が多いだけならそりゃ勝てる。
だが、実用性という観点を考える、C++は負ける。

>>518
それもおまいの修行が足りないんだよ。

ＳＴＬの作者のＯＯＰＬ嫌いは有名

>>501
C++の変態的動作に比べればぬるいぬるい

>>520 Objectクラスがなくてもtemplateがあればいいじゃない

>>525
だめだ。
equals()もhashcode()もwait()もnotify()も実装できない言語なんぞたかが知れてる

>STLのほうがどうみても効率悪いだろ。
>不満があるなら、Jakarta Commons Collectionsを使え。
Jakarta Commons Collectionsっていうのをちょっとだけ調べてみたけど
たんにSTLをJavaで無理なく実装してみた感じのものなのか?
まぁ、Java使うときはこれ使っとくよ。

>Objectクラスが無い時点でもうすでにオコチャマだな。
これが、理解できん。
Jakarta Commons Collectionsでも基本的に全部Objectで扱うように
なってるんだよな、おかげでJakarta Commons Collections使っても
キャストしまくりじゃねーか。
>JavaやるとSTLがきもくてたまらん。OOPLの考え方に反してる。
JavaてきにはキャストしまくりがOOなのか?

STLならコンパイル時に型違いのエラー検出できるぞ。STLがOOとはいわんが。

>C++では想像もつかなかったコンパイルエラーに悩まされるだろう
C++では想像もつかなかった実行時エラーのほうが多そうだな。キャストのせいでな。

>>527
> Jakarta Commons Collectionsでも基本的に全部Objectで扱うように
> なってるんだよな、おかげでJakarta Commons Collections使っても
> キャストしまくりじゃねーか。

つGenerics対応版

>>527
> >Objectクラスが無い時点でもうすでにオコチャマだな。
> これが、理解できん。

equals(), hashCode()をオーバーライドできないから糞ってこと。
コレクションに格納できるオブジェクトは、とくにMapはequals(), hashCode()の
実装に大きくかかっている。


> Jakarta Commons Collectionsでも基本的に全部Objectで扱うように
> なってるんだよな、おかげでJakarta Commons Collections使っても
> キャストしまくりじゃねーか。


新しいCollectionsはGenericsに対応してその問題は解決している。
もっとちゃんとググれ。

>新しいCollectionsはGenericsに対応してその問題は解決している。
url書けよ、余計なものばっかり引っ掛かるぞ。リファレンスのurlな

>equals()もhashcode()もwait()もnotify()も実装できない言語なんぞたかが知れてる
自分で実装しろよ、equals()ってわらかしてんのか?

>>529 

template関数で出来ると思いますが。共通の基底型が無くたって、

template<typename T>
int hashcode(const T& t) { return t.hashcode(); }

とやれば、hashcode()関数を持つクラスなら hasecode(Hoge)で全部呼んでくれます。

共通の基底型の関数をオーバーライドして、仮想関数呼び出し相当のコストを払うのはもったいない。
「JITコンパイルでインライン化されるから、早さは変わらない」と言われるんだろうけど。


あと、Genericsも5.0時代の実装ではキャストが消えてないみたいですが。
http://www.javainthebox.net/laboratory/J2SE1.5/LangSpec/Generics/Generics.html
「最近のVMの進歩で、コストは償却されます」と言われるんだろうけど。

>equals(), hashCode()をオーバーライドできないから糞ってこと。
>コレクションに格納できるオブジェクトは、とくにMapはequals(), hashCode()の
>実装に大きくかかっている。
STL知らんのまるだしかよ。

>>530
ほれ
http://sourceforge.net/projects/collections

>>531
それで、intが64bitに変わったときはどうするんだ？

>>531
> あと、Genericsも5.0時代の実装ではキャストが消えてないみたいですが。

Genericsはパフォーマンス目的ではなく type safeが目的だからな。

>>534
戻り値もtemplateにしますかね。

>>535
C++並になれてよかったね。

>>533
リファレンスのurlっていってるだろーが

>>531
それだと、実装しない馬鹿対策には弱い。
Mapに実装しないと意味がない。

いまどき非finalメソッドが遅くなるなんていっていってるのは都市伝説信者だな。

Javaの理論と実践: パフォーマンスの都市伝説
http://www-06.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html
都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる
都市伝説その3: 不変オブジェクトはパフォーマンスを悪化させる

>>536
> >>534
> 戻り値もtemplateにしますかね。
そのクラスのオブジェクトのパターンが2の32乗通り以上あった場合どうするんだ？
しかも、馬鹿が書いたクラスのオブジェクトのフィールドの一つ一つがすでに
2の32乗の範囲を超えている。

> >>535
> C++並になれてよかったね。
むしろ、C++のほうがtype safe性に弱いのでJava並みになれていないことがC++の落ち度だが。

>>537
甘えるな。
あとはそれでなんとかなるだろ

>>530
STLのequals()はhashCode()との『契約』をちゃんと満たしているか？

"Design by Contract" をちゃんと満たしているか？

まず、Jakarta Commons Collections のGenerics対応版のリファレンスのURL書けよ

>いまどき非finalメソッドが遅くなるなんていっていってるのは都市伝説信者だな。
>Javaの理論と実践: パフォーマンスの都市伝説
>http://www-06.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html
>都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる
>都市伝説その3: 不変オブジェクトはパフォーマンスを悪化させる
だれもそんな話してないから。

あと、STL知らんのならわざわざSTLについてかかなくていいよ。

なんか、この前のJava最適化君がわいてるようなｵｶﾝ。

STLのequals()は以下をちゃんと満たしているか？

HashMapのキーに使用できるオブジェクトの
equals()メソッドの実装は以下の条件を満たさなければMapの
実装を破壊するわけだが。

null以外においてa == aは常にtrueを返さなければならない。
a == b がtrueを返すならば b == aもtrueを返さなければならない。
a == b, b == cがどちらもtrueを返すならば a == cもtrueを変え餌無ければならない。
a == b がtrueならば、a == b は何回呼び出されようと終始一貫して trueを返さなければならない。
a == b ならば a.hashCode()とb.hashCode()は必ず同じ値にならなければならない。
a(またはb)が不変または一切変更されないときは、首尾一貫してつねに同じ数値を返さなければならない。


==はequals()に置き換えて考えてくれ

>>543
> いまどき非finalメソッドが遅くなるなんていっていってるのは都市伝説信者だな。
> >Javaの理論と実践: パフォーマンスの都市伝説
> >http://www-06.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html
> >都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる
> >都市伝説その3: 不変オブジェクトはパフォーマンスを悪化させる
> だれもそんな話してないから。

> 共通の基底型の関数をオーバーライドして、仮想関数呼び出し相当のコストを払うのはもったいない。

ほら、してるよ。

>>542
>>540

>>538
>実装しない馬鹿対策には弱い。 
ってどういうこと？C++でtemplateを使う場合は、むしろ関数宣言が無ければコンパイルエラーで落ちてくれますが。
「基底型の関数をオーバーライドせずに使うのは問題」というのなら確かにそう。
でもJavaも変わらない気が。Object#hashcode()があるからある意味安全だと思うけど。


無駄なfinal宣言を避けろって、これは「些細なパフォーマンスの期待で、インターフェースを汚すことは無い」と言う話だよね。
パフォーマンスのJIT最適化も、これなんでしょう？
>「JITコンパイルでインライン化されるから、早さは変わらない」と言われるんだろうけど。 


>>539
その肥大したクラス階層を総称的にtemplateで扱えますよ。
むしろ、その泥沼状態はJavaでも変わらない気が。


安全じゃないキャストが出来てしまう、のは確かにC++の泥沼感を示している。
全部dynamic_castに制限すれば、Java並になれるけどね。そこはJavaでの洗練が感じられる。


>>540
その手の"契約"は、静的にはtemplate解決失敗時の(意味不明な)エラーと assert()で行うのがC++では普通かな。

あと、STLの連想コンテナは'<'演算子に基づくもので、Javaのようにハッシュとequals()に基づくものじゃないよ。
だからそんな契約も必要ない。ていうか共通の基底型が無くて出来ない。

>> 共通の基底型の関数をオーバーライドして、仮想関数呼び出し相当のコストを払うのはもったいない。

>ほら、してるよ。
C++の話だ

>>547はチーム開発経験が浅いのかね

安価間違えたorz >540→>>541

あと、"動的には"assert()で契約を行う・・だった。でもこのへんはJavaも一緒か

>>549 うん orz

>>547
> >>538
> 無駄なfinal宣言を避けろって、これは「些細なパフォーマンスの期待で、インターフェースを汚すことは無い」と言う話だよね。

「virtualを付けると遅くなるから、virtualがデフォルトであるJavaのメソッドにはfinalをつけなければならない」
こう主張しているジジイがたまにいるんだよね。

> 共通の基底型の関数をオーバーライドして、仮想関数呼び出し相当のコストを払うのはもったいない。

あんたもこんな発言をしたからそのジジイとかわらないんじゃないかな。


> >>539
> その肥大したクラス階層を総称的にtemplateで扱えますよ。

意味わかって言ってるのかね。JavaのintはどんなOSであっても32bitsと決まっている。
だがC++のintはプラットフォームによってころころ変わる。そんな環境下で、intが64bits前提で
hashCode()を実装した奴とintが32bits前提で実装した奴のそれぞれのhashCode()を持ったクラスを
集約したクラスをつくるときに面倒なことが起きる、ということを想像できないのかね。
しかもそいつらが作ったクラスがブラックボックスだったら、ますます厄介なことになるぞ。

> >>541
> その手の"契約"は、静的にはtemplate解決失敗時の(意味不明な)エラーと assert()で行うのがC++では普通かな。
> あと、STLの連想コンテナは'<'演算子に基づくもので、Javaのようにハッシュとequals()に基づくものじゃないよ。
> だからそんな契約も必要ない。

まるでComparable<T>#CompareTo(T)みたいだな。

しかし、hashCode()なしではHashMapやhashSetの
パフォーマンスに弊害がでるものではないかな。

ついでにこれらのクラスにもそのComparableインタフェースが実装されている。
　

>>548
だが、それをJavaに置き換えて「Javaは遅いニダ！」とファビョる馬鹿もいるんだよね

>>544の要求を満たすequals()相当のメソッドがないSTLはかなりやばいね

STLはしらねーし、リファレンスはないし話にならねーな

>>551
Javaなら
>「JITコンパイルでインライン化されるから、早さは変わらない」
って最初に書いたのに・・orz
だから俺も、Javaで組むときには無駄にはfinalつけるようなことはしない。
C++のときは、非仮想に出来るだけ持っていく


>>539ではクラスの数の話、>>534ではint型の大きさの話をするから混ざって訳分からなかったけど、環境依存の話？
確かにそれはカオス。VMで型の大きさが決まっていることは素晴らしく楽だね。


>>552
まあ、標準にハッシュ表がないからねえ。


>>554
C++は、< 演算子を用いた ∀i ，!(*(i+1) < *i)　による"等価"を用いて、そのequals()契約と同等のことをしてます。
式が適当でスマソ

Javaのハッシュによる辞書とC++のツリーによる辞書を比べてどうするんだ
意味がわからん

Javaが遅いとか言われているしスパコン並みの超高速CPUでも買うか。
メモリも512テラぐらいつむか

>>558
何言いたいのか解らないが
メモリ512テラ載せれるマシンってあんのかよ

Win x64 でも 16TiB までしかサポートしてませんね。
Itanium はプロセッサ自体は 1PiB まででしたっけ？

>>555
そうか、おまいがしらなかったのか。ファッキン！ファッキン！

>>498
散々言われているようにSTLはOOP的でないので、
Javaやってからだときもく感じるのは別に不思議ではない。

で、お前がきもいと感じるかどうかと有害かどうかは別問題なんだ。

>>558
通常はそこまでいらんわ。
EclipseやNetBeansでは1GBくらいが妥当。

すくなくともCのポインタはPerlのポインタより
糞だということだけはわかる。

Perlにポインタなんてあったっけ。

ある

　　　 　∧＿∧
ﾋﾟｭ.ｰ　(　　＾３＾） ＜エェー　これからも僕を応援して下さいね（＾３＾）。
　　＝〔~∪java~〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　java＆サン

ちなみに、TreeSet, TreeMapクラスに
使用するキーとなるオブジェクトは必ずComparableインタフェースを
実装しなければならないという決まりがあるよ。

>>567
Javaすれにわざわざコピペご苦労

>>568
このスレにきてる人の大部分は、
すでに知ってるか、知らなくてもすぐに調べられる人だと思うよ

C++しか知らない奴の多くが知らないことだと思うよ

>>571
脊髄反射乙。たった2行なんだから、全部読んでからレスしてね。

煽り厨乙

厨厨乙

じゃあ逆にC++を書けば釣り合う。

std::set, std::mapクラステンプレートには
使用するキーとなるオブジェクトを比較するファンクタのクラスを
指定しないといけないよ。

ただしデフォルトではoperator <で比較するファンクタが指定されるから
キーとなるオブジェクトの型がoperator <を持っていればそれを使えるよ。

Javaしか知らない奴はVB厨と同レベル

C++しか知らない奴も然り。

C++を知っててCを知らないことはあり得ないから
C++しか知らない奴は存在しえない。

>>578
ｱﾌｫでつか・・・

VB、Java、C++をそつなくこなす俺が最強

>>578
> C++を知っててCを知らないことはあり得ないから

ありえるよ。いきなりC++からやった奴なんてCのポインタの
使い方間違えるし。

> C++しか知らない奴は存在しえない。

現実をみよう

Visual C++にいきなり手を出した奴なんて
ろくなやつがいない。まさにVB厨と変わらないレベル

までエディタ + シェル + Ant でJavaを始めた奴のほうがまとも

Javaも所詮は環境依存なのにそのままどこに持っていっても動くとか勘違いする馬鹿を量産するだけ。
低レベルな視点を全く身につけられないJavaは害悪以外の何者でもない。

>>580
全部事務用言語じゃねーか。そんなの「こなす」とか言ってるレベルで駄目。

すくなくともLisp、Ruby|Python, javascriptぐらいはやってからこのレベルの高いスレに
参加してほしい。

>>583
何時の時代の話をしているんだこのハゲはw

>>584
似たようなスクリプト言語ばっかだな
RubyとLisp程度でいいだろw

>>586
結論には同意するが、似てるのは「スクリプト」と言う点だけだろと突っ込み入れておく。
特に lisp はその中でも異色。

スクリプトは処理遅いって思ってる俺は時代遅れ？

Lispもpythonもコンパイルできるぞ

>>581
それで「C++できる」にカウントするのか？

コンパイルできる＝高速って考えもあれだが

スクリプトが型に甘いのでイマイチ

型推論とも違うし

>>583
ファイルパスの扱いとか、環境非依存にしようがない所ぐらいしか
環境依存部分はないと思うのだが。

環境非依存にすることが出来るのにも関わらず、
環境依存になってしまっている例を挙げれるものなら挙げてみ

勝手にキャストするほうがおかしいだろ

何の話をしてるんだ？

>>595
キャストの話をしてるんだ

Javaの最大の環境依存性　：　JVMの有無

ISO C++0x に入るもの
- Garbage collection
- Memory model for concurrency
- Concurrency libraries

GCがあり、並行プログラミングに強いJavaではもうおなじみのものだな。

>>597
それ、あるね。
Windows使っている人に、Java入れてよってなかなかね。
JREのダウンロードサイトもなんかわかりにくいし。

>>598みたいなしくみ必要ないんじゃない？
C++よりパフォーマンス悪くして何を目指してるんだろう。

一番アフォくさいのはGCや生配列扱うときのの添え字チェックだよ
テストでまかなえるのにわざわざパフォーマンス下げるなよ・・・
なんで有限回数しか回らないんだからコアダンプ吐くまでテストすりゃ十分じゃん。
メモリの生きてる範囲小さくしていけばメモリリークも十分テストで網羅できるし、
パフォーマンス意識してキャッシュライン考えるとGC悪じゃん。
数百万出せば逆アセからメモリリーク出そうな場所特定してくれるツールもあるんだしさー

c++は今のままで十分、改造するなら別の言語として作って欲しいわ

何が勝手にキャストするのか

>>599
勝手にはいるから問題ない

何でもあり言語C++はとどまることを知らず

>>599
つJETコンパイラ

>>600
> >>598みたいなしくみ必要ないんじゃない？
> C++よりパフォーマンス悪くして何を目指してるんだろう。
> 一番アフォくさいのはGCや生配列扱うときのの添え字チェックだよ

そう思うなら、超巨大な配列を作ればいい。

Javaなら、Bufferクラスを使って


> テストでまかなえるのにわざわざパフォーマンス下げるなよ・・・
> なんで有限回数しか回らないんだからコアダンプ吐くまでテストすりゃ十分じゃん。

『アジャイルソフトウェア開発の奥義』ではそんな言い訳は許されない。

http://en.wikipedia.org/wiki/C++0x
にはそれ以外も挙げられてるが、>>586のJava使いは
それらの重要性は理解できずに割愛したんだろう。

>>606
まて、お前英語読めるか？

The factual accuracy of part of this article is disputed.
The dispute is about the current status of C++0x work (the description below is now outdated).
Please see the relevant discussion on the talk page.

その記事を見ただけでは信用するに値するかどうかもわからん

>>607
ありがと。でも、これよりまとまったページ知ってる？

Implicit function call

To call a function always required an explicit use of parenthesis. If a function takes no parameters this formality can be out-of-date declaring the function as implicit.

Obviously an Implicit callable function cannot receive parameters (probably it will not be even permitted to write void as the parameter list), and it must not to be confused with a pointer to function. For example:

long double greekpi() implicit { return 3.14159265358979323846264338327950288L ; }
area = greekpi * 144 ;


↑こういう紛らわしいことは辞めて欲しいんだけどな。
ソースが読みにくくなる。

暗黙の型キャストもキモイ

The idea is to introduce a special constructor taking a sequence of objects:

vector( initializer_list<int> seq ) ; // Constructor from a sequence of int.

The sequence initializer (initializer_list) is a template class defined as it follows:

template<class E> class initializer_list
{
public:
initializer_list( const E* first, const E* last ) ;
initializer_list( const E* first, int length ) ;

int size () const ; // Number of elements.
const E* begin() const ; // The first element’s address.
const E* end () const ; // The following address to the last element.
} ;


というか、C++には今までイニシャライザがなかったのか。
Javaより後発で導入するとは

C++はC++0xになってもコードが美しくないな

なんでもいいからさっさと標準的なString型を導入しろよ

String foo = "hogehoge" + "fugafuga";

って書けるだけいいからさあ。

>>602
最近はかってに入るのか。。
>>604
JITコンパイラの利点は無くなっちゃうのかな。

>>611
Javaだって汎用のヤツはなかったんじゃないか？
いつの間にか
ArrayList<int> a = new ArrayList<int>() { 1, 2, 3 };
と書けたりするようになったのか？

ObjCが
http://developer.apple.com/jp/briefing/cocoa.html

>>613
いまはこれで我慢しとけ。

std::string foo = "hogehoge" "fugafuga";

それ違うｗ

相互排他ロック期間が短いなら、JVMはそれを認識して
待ちのスレッドをスピンロックに変えるらしい

C++でのプロファイル後オプチマイズもJITはやってくれるだろうし
複雑なプログラムではJAVAが速いのは自明な気がする

まだ，この糞スレやってるの？

プロなら好みで言語は選べないし，
趣味でやるなら好きな方でやればいいじやない

>>614
> >>602
> 最近はかってに入るのか。。
> >>604
> JITコンパイラの利点は無くなっちゃうのかな。

ならねえところ無くならねえ。
分散ではいちいち手動再婚パイルなんてかったるいから。

>>615
Javaにはそんなイニシャライザはない。
「Java スタティックイニシャライザ」
「Java インスタンスイニシャライザ」でググってみ

>>622
だよね。ありがと。
>>611のやつは、組み込みの配列型だけではなくて一般のクラスでも、
std::vector<int> v = { 1, 2, 3 };
と書けるようにすることが目的だったはず。

>>605
『アジャイルソフトウェア開発』はただの迷信だよ
http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm
http://www.aoky.net/articles/steve_yegge/egomania_itself.htm

>>624
お前迷信というまえにこの本をちゃんと読んだのか？
>>605が言ってるのはこの書籍のことだぞ
アジャイルソフトウェア開発の奥義 (単行本)
ロバート・C・マーチン (著), 瀬谷 啓介 (翻訳)
http://www.amazon.co.jp/
%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD
%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7
%99%BA%E3%81%AE%E5%A5%A5%E7%BE%A9-%E3%83%AD%E3%83%90%E3
%83%BC%E3%83%88%E3%83%BBC%E3%83%BB%E3%83%9E%E3%83%BC%E3
%83%81%E3%83%B3/dp/4797323361

>>608
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2142.html

>>625
示したURLの記事をちゃんと読めば、迷信をどういう意味で使っているか
分かるはずだし、この意味での迷信であれば、本を取り上げることは全くの
反論になってないことも分かるはず。

スレ伸びてるけど今日はあんまり病的な人はいませんねー

628 名前：デフォルトの名無しさん 投稿日：2007/02/21(水) 13:42:59
スレ伸びてるけど今日はあんまり病的な人はいませんねー

warota

このスレって結局自分が一番使える言語マンセーのカスしかいないなぁ。
しょんぼりだわ。

ほんと、スレタイの勢いはどこへ行ったのやら。

>>631
だよなー、たまに沸いてくるへんなやつが、知りもしないのにたたいてるのみると
なんか得体の知れないものを必死にたたく○○厨みたいで笑えるけど。

>>>600
>> >>598みたいなしくみ必要ないんじゃない？
>> C++よりパフォーマンス悪くして何を目指してるんだろう。
>> 一番アフォくさいのはGCや生配列扱うときのの添え字チェックだよ
>そう思うなら、超巨大な配列を作ればいい。
パンが無いならケーキみたいで笑えるw

なぁ、今更なんだが…
> type Test0003.java
import java.io.PrintStream;
public class Test0003 {
private static PrintStream out = System.out;
public static void main(String[] args) {
test01();
test02();
}
private static void test01() {
for(int i = 0; i < 10; i++){
try{
out.print("test01 ");
out.println(i);
if(i == 5) throw new Exception();
} catch (Exception e){
out.println("test01 exception");
}
}
}
private static void test02() {
try {
for(int i = 0; i < 10; i++){
out.print("test02 ");
out.println(i);
if(i == 5) throw new Exception();
}
} catch (Exception e){
out.println("test02 exception");
}
}
}

> javac Test0003.java

> java Test0003
test01 0
test01 1
test01 2
test01 3
test01 4
test01 5
test01 exception
test01 6
test01 7
test01 8
test01 9
test02 0
test02 1
test02 2
test02 3
test02 4
test02 5
test02 exception

ちなみに
> javac -version
javac 1.6.0

> java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

でやってるワケだが、あの２つのどこが同じなんだ…？

最適化君の降臨にwktk

JavaだけやるとC++は有害に感じる　

>>637
あの2つってどの2つ？

>>634
意味がわからないので解説よろ

>>635-637
何が言いたいのかわからんのだねど。
速度の話をするなら、ちゃんと時間を計算しようね。

違う処理で時間を比較することに意味があるのだろうか。

>>640
>>256のことだと思われ

>>642
俺は635じゃないけど、当然 test02 のほうが速いだろ。

>>644
なるほど。これは香ばしいな。

>>645
速いとか、遅いとかじゃなくて、test01とtest02は、異なる処理なので、
mpegエンコードは、レイトレーシングより速いってぐらい意味のない比較だと思う。

>>646
そうなんだけど、>>256 以降のやりとりをみればわかるが、
それが理解できないやつがいるので、そいつを釣り上げてみるかなって思っただけ。
test02 のほうが速いと書けば食いつきそうなので。

オートマ車でいえば
オーバードライブオフ、スポーツモードみたいなモンジャマイカ？

>>646
> >>644
> なるほど。これは香ばしいな。

香ばしいと思う前に、>>338のPDFをよく読んでみろ。
速度に若干は差がでるもの、ほぼ変わらないと言う意味だ。

　　前者±ε = 後者
　　|前者 - 後者| << ε
　　（ε >> 0 (限りなく0に近いという意味)）

こういうことだ。

338 名前：デフォルトの名無しさん[sage] 投稿日：2007/02/16(金) 01:12:41
>>335

見つけた。
http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-3268.pdf
若干コードが異なるが、
新しいOSとJVMではfor文無いでtry-catchをつけようがつけまいが、
さしてパフォーマンスは変わらないことがよくわかる。
古いOSだと恐ろしいほど差が出ている。

>>647
>>649を読め

　 　　　 　　 　＿＿＿_　　　
　　　　　　 ／ ＼　　／＼　ｷﾘｯ
.　　　　　／　（ー） 　（ー）＼　　　　　　
　　　　／　　 ⌒（__人__）⌒ ＼　　　　＜速度に若干は差がでるもの、
　　　　|　　 　　　|r┬-|　　　　| 　　　　　　ほぼ変わらないと言う意味だ。
　　　　 ＼　　　　 `ー'´　　 ／
　　　　ノ　　　　　　　　　　 　＼
　 ／´　　　　　　　　　　　　 　　ヽ 　 　 　 　 　 　 　
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､. 　 　
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

　 　　　　 　　　＿＿＿_
　　　　　　　 ／_ノ 　ヽ､_＼
　ﾐ　ﾐ　ﾐ　　oﾟ(（●）) (（●）)ﾟo　　　　　　ﾐ　ﾐ　ﾐ
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼　　　/⌒)⌒)⌒)
|　/　/　/　　　　　|r┬-|　　　　|　(⌒)/　/ / /／　　＜ だっておwwwwwwwwwwwwww
|　:::::::::::(⌒)　　　　|　|　 |　　 ／ 　ゝ　　:::::::::::/
|　　　　　ノ　　 　　|　|　 |　 　＼　　/　　）　　/
ヽ　　　　/　　　　　`ー'´ 　 　 　ヽ /　　　　／　　　　　バ
　|　　　　|　　 l||l　从人 l||l 　　　　 l||l 从人 l||l　　バ　　　ン
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､　　　　ン
　　ヽ ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

よく知らないんだけど、Javaの最適化ってのは
ループの構造まで（人間が望むように）変えてくれるものなんすか？
コンパイラの中の人も大変だ。

デストラクタあるからfinallyｲﾗﾈ

クラスの設計がクソ

>>649 は梅宮タツオ級の釣り師と見た。だが、仕掛けが露骨過ぎる。

>>653
釣りですか？
それとも馬鹿ですか？　

>>651は真性の馬鹿

>>651も、>>649のアフォさ加減の前には霞んで見える。
コードは間違ってた、元のPDFだけ読んでください、と言えるヤツなら、
まだ救いがあるんだが。

日本語読めないC++厨は
なぜここまで自演してまで必死になるのだろうか。

バイトコードについて何も知らないJava厨よりまし。

> Bjarne Stroustrup:
> 言語には次の２種類しか存在しないということです
> ――皆が不満を顕にするものか，あるいは，誰も使いもしないものか，です。
ttp://www.radiumsoftware.com/0702.html#070221

　　　　/::::i::::､:::ヽ､:::::＼:ヽ:＼::::::ヽ:::､::ヽ::､:',
　 　　/::i|::l::ﾄ､ヽ::､:::ヽ:､::::::＼::ヽ::::l::::ヽ::i:::i:::!
　　　/:/:!:::!:|::ヽ:＼ヽ::::､:＼::::ヽ:::ヽ!::::::i::|:::!::!
　　　!ﾊ::|::::i::l:|心､:ヽ::＼:ヽ_＼､＼:::ヽ:::|!::|:|i
　　　　i､:!:|:､N{､ﾋjヽゝ＼ヾｲ ﾋｊ　>､ヽi:､|!:|:l
　　　　　ヽ:!::ﾄヽ￣　l! `　　｀￣´　|::l::|:|j:,!:!　　駄目だこいつ……早くなんとかしないと……
　　　　　　ﾄ､::! u　　　　　　　　　ｊ |::/lj:::!ﾘ
　　　　　　　 ヾ、　 丶 -　　　　u　ﾘｲ:|ﾘ　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　ﾘヽ　‐､ｰ- ､_　　 ／ｲ:::i
　　　　　　 rｰ'"ﾄ:lﾞ､ 　￣ 　 .／　 , |::!
　　　　　　/ ﾍ　ヾ　ヽ､ _,.　'　　 /　|:'

ではJavaは誰も不満を抱かない言語なのか

>>662の脳内では『皆が不満を顕にするもの』の反対語は『誰も不満を抱かないもの』らしい

>>659
わかりやすい日本語で >>256 をJavaで最適化するとどうなるか教えてください ><

Javaは悪くないけどさ、別にC++でも良いじゃん？
これじゃなきゃダメ！なんて限定する必要もなし。
使えるものをどんどん吸収すべし！

>>664
双方のコードの速度差がゼロに近似する

>>661
> Technology Review 誌による Stroustrup へのインタビュー記事。
> 現代のソフトウェアが抱える諸問題についての話題を軸としながら，
> 氏のプログラミングに対する科学的あるいは工学的な視点をうかがう。
> C++ の設計に関して悔やむところなど何も無いと述べる氏の語り口は非常に明朗としていていっそ清々しい。

↑まさにC++信者を庇うためにわざとストラウストラップが言った言葉。
それに「非常に明朗としていていっそ清々しい。」とまでいうのはC++信者。

>>660
C++厨もバイトコード知らないよ

例外さえ起こらなければチェック回数は同じだし
起こってしまえば処理の流れが違うんだから比べる意味がわからない。

バイトコードと聞くとQuickBASICしか思い浮かばんなぁ。
Javaはあれと同じレベルなのか。

ttp://ja.wikipedia.org/wiki/%E3%83%90%E3%82%A4%E3%83%88%E3%82%B3%E3%83%BC%E3%83%89
ttp://d.hatena.ne.jp/keyword/%A5%D0%A5%A4%A5%C8%A5%B3%A1%BC%A5%C9

>>670
Emacs-Lisp もある。

>>668
何で知る必要があるの？
C++の処理系でバイトコードをはくやつなんてあった？

>>666
変な日本語

「近似する」って他動詞だよなぁ

>>673
Visual C++のManeged C++とC++/CLIは.NETのCILを吐くぞ。

Javaはいい加減typedefとgotoを導入汁

>>675
漸近するの間違いじゃね？

>>676
Managed C++とかC++/CLIって、
正直なところ、C++に入れてもらえてないんじゃない？
しかも、C++/CLIでは、C++のテンプレート用の実行時コード生成もあるから、
Javaのバイトコードと比較するのもアレな感じだし。

>>677
ラベル付きbreakが進化したgotoだろ
typedefは・・・・・・えーと、現代的なIDEを使って自動入力してください。

>>677
try-catchがgoto替わり

>>675
日本語では他動詞と自動詞の区別なんて曖昧だけど

>>669
だからVMの種類やバージョンを変えてみそ
って話。
古いJVMであのプログラムを動かすとtryの中にforのほうが
明らかに早いことがわかる。
しかし新しいJVMだとforに中にtryを置こうと大差なくなってきている。

とくに-serverオプションを付けるとその様子が顕著に表れてくる。

>>677
クラスやインタフェースがtypedef替わりになる。

>>684
それは、
http://www-06.ibm.com/jp/developerworks/java/060310/j_j-jtp02216.shtml
に書かれているアンチパターンのこと？

>>677の不満
　class とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名
これをtypedefで
　typedef ShortClass とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名;
のようににJavaではtypedefを使うことができない。

そこでこういうとんでもないネーミングをしている奴のコードを
弄る羽目になったときのJavaでの解決方法:

■解決方法その１ - 継承
class ShortClass extends とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名 { }
■解決方法その２ - 委譲(static)
final class ShortClass {
　private ShortClass{}
　private static とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名 a(){
　　return とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名
　}
}
■解決方法その３ - 委譲(インスタンス)
final class ShortClass {
　private とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名 a:
　public ShortClass(とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名 a){
　　this.a = a;
　}
　 public 型 a(){
　　this.とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名.その長いクラスのメソッド名()
}
}
■解決方法その４ - static import
import static パッケージ名.とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名.staticメソッドorフィールド名

これで>>677の不満も解消されるであろう。

>>685
>>677がそれで自業自得に陥るならそれでも構わんだろう

>>686
1: >>685 に書いてある通り、使えない。
2: そもそもコード間違ってない？
3: メソッドを全部記述するなんて面倒なこといちいちできるわけがない。
　 あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
4: staticのみ？ 論外。

そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。

>>683
君は現実の世界でもそういうかみ合わない会話をしているのかね?

>>688
> 2: そもそもコード間違ってない？
メソッドをpubilcに
する

> 3: メソッドを全部記述するなんて面倒なこといちいちできるわけがない。

だいたクラスなんて大した数のメソッド持ってないだろ。
そんなことで面倒くさがるなら、自動化ツールで自動生成すればいい。
Jakarta Velocityでテンプレート作れ。

そもそも、一つのクラスにメソッド100近く作る奴はDQN。
Javaでは一つのクラスに付きメソッド255個までしかつくることができないようになっているが。
クラスが1000行超えたら分割しないといけない。
ついでにメソッドも40行超えたら分割しろ。


> 　 あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。

『鉄則：分割し、統治せよ。』


さらについかしてみよう。
■その５
同じプロジェクト内ならリファクタリング(名前変更)で解決。

■その６
クラス名の一部をパッケージ名に変更してクラス名を短縮。
■その７

>>688
> >>686
> 4: staticのみ？ 論外。
> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。


仮に、こんな長ったらしい型があったとしよう。

Map<List<List<Set<Map<List>>>>>


ここで、頻繁に変更するヶ所が一番最深部のListだけであるなら、
ラッパーでまとめるという手も考えるべきだ。

こんなクラスにまとめてしまえ
Wrapper<List>

>>690
>だいたクラスなんて大した数のメソッド持ってないだろ。
>そんなことで面倒くさがるなら、自動化ツールで自動生成すればいい。

Javaはtypedef一つするにしてもそんな面倒なことやらなきゃいけないんですね。

>> 　 あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
>> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。
>『鉄則：分割し、統治せよ。』

受け答えが成立していません。誤魔化さずに真面目に答えてください。

>690
>■その５
>同じプロジェクト内ならリファクタリング(名前変更)で解決。
>
>■その６
>クラス名の一部をパッケージ名に変更してクラス名を短縮。

Genericsで型名が長くなる場合にはどうしようもないよね

っていうか、クラスって Class 型の変数に代入出来ないの？
もしくはそれに近い方法で使えない？
そしたら短い名前で参照できるのでわ

すべてのクラスはObjectクラスを継承してるからObject型には入るけど
名前のためだけにそういうことをするのはかなりキモい

>>679
C++/CLIはISOに蹴られますた
ttp://blogs.wankuma.com/episteme/archive/2006/09/12/38394.aspx

さしずめそれが妥当だろう

>>692
> >>690
> >だいたクラスなんて大した数のメソッド持ってないだろ。
> >そんなことで面倒くさがるなら、自動化ツールで自動生成すればいい。
> Javaはtypedef一つするにしてもそんな面倒なことやらなきゃいけないんですね。

そもそも、typedefに拘ること自体、くだらない。
実装多重継承ができないくらいでいらいらするなんぞ恥ずかしいこと。

君が、無駄にメソッドを大量生成するというeXtreme Programmingの鉄則に
反する愚かな行いをしていることはよくわかった。

> >> 　 あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
> >> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。
> >『鉄則：分割し、統治せよ。』
> 受け答えが成立していません。誤魔化さずに真面目に答えてください。

やはり、お前は人の話を聞かず、
オブジェクト指向を否定し、「アジャイルソフトウェア開発」までをも否定するというのか。

君は本当にそんなにGenericsのGenericsになってる「長い型」が本当に必要なのか
今一度、考え直すべきだ。

君の性格のことだから、配列でも同じようなことをやっているのだろう。
君はおそらく、多次元配列を作って混乱しているのだろう。
それに有用性があるというならわかる。
そうでもないにもかかわらず多次元配列に拘っているようだったら、考え直せ。

だからこそ、分割し、統治せよ、と説いているのだ。君は「解放・閉鎖原則」についてもっとよく勉強すべきだ。
君は、KISSについても勉強すべきだろう。

君は、この原則を守れるか？

5つのクラス設計原則(There are five principles of class design)
The SingleResponsibilityPrinciple(SRP)
責務単一原則
The OpenClosedPrinciple(OCP)
開放閉鎖原則

A module should be open for extension but closed for modification.

モジュールは拡張に対して開いており、変更に対しては閉じている必要がある。
The LiskovSubstitutionPrinciple(LSP)
Liskovの置換原則

Subclasses should be substitutable for their base classes.

サブクラスは基本クラスと置換可能でなければならない。
The DependencyInversionPrinciple(DIP)
依存性逆転原則

Depend upon Abstractions. Do not depend upon concretions.

依存は抽象的にする。実装に対して依存させてはならない。
The InterfaceSegregationPrinciple(ISP)
インタフェース分離原則

Many client specific interfaces are better than one general purpose interface

汎用的なひとつのインタフェースよりも、多くの特化したインタフェースを利用する。

3つのパッケージ凝集原則(There are three principles of package cohesion)
The ReuseReleaseEquivalencePrinciple(REP)
再利用開放等価原則

The granule of reuse is the granule of release.

再利用できる最小単位はリリースできる最小単位。
The CommonClosurePrinciple(CCP)
共通閉鎖原則

Classes that change together, belong together.

あるクラスの変更により、同時に変更されるクラス。
The CommonReusePrinciple(CRP)
共通再利用原則

Classes that aren't reused together should not be grouped together.

再利用できるのはクラスではなく一連のグループ。

3つのパッケージ結合原則(There are three principles of package coupling)
The AcyclicDependenciesPrinciple(ADP)
非環式依存原則

The dependencies between packages must not form cycles.

The StableDependenciesPrinciple(SDP)
安定依存原則

Depend in the direction of stability.

The StableAbstractionsPrinciple(SAP)
安定抽象概念原則

Stable packages should be abstract packages.

この原則を守ることができなければ
C++ができるとは言わせないぞ！

この原則に則していない言語はオブジェクト指向言語ではない。

ゆえに、JavaScriptは厳密にはオブジェクト指向言語ではない。
ゆえに、Perlは厳密にはオブジェクト指向言語ではない。
ゆえに、PHPは厳密にはオブジェクト指向言語ではない。
ゆえに、VBは厳密にはオブジェクト指向言語ではない。
ゆえに、Perlは厳密にはオブジェクト指向言語ではない。

ゆえに、Rubyは厳密にはオブジェクト指向言語ではない。

Javaを批判するC++厨にはこの悪臭のニオイがプンプンとする






　以下にロバート・C・マーチンによる書籍『アジャイルソフトウェア開発の奥義』に記載されている
7つの「設計の悪臭」を紹介する。これらのうち、どれか1つでもその傾向が感じられたなら、すで
にわなに陥っていると考えてもよいだろう。

兆候 説明
1. 硬さ 変更しにくいシステム。1つの変更によってシステムのほかの部分に影響が及び、
　　　　　　　　　　　　　　　多くの変更を余儀なくさせるようなソフトウェア

2. もろさ 1つの変更によって、その変更とは概念的に関連のない個所まで壊れてしまうようなソフトウェア

3. 移植性のなさ ほかのシステムでも再利用できる部分をモジュールとして切り離すことが困難なソフトウェア

4. 扱いにくさ 正しいことをするよりも、誤ったことをする方が安易なソフトウェア

5. 不必要な複雑さ 本質的な意味を持たない構造を内包しているようなソフトウェア

6. 不必要な繰り返し 同じような構造を繰り返し含み、抽象化してまとめられる部分がまとまっていないソフトウェア

7. 不透明さ 読みにくく、分かりにくい。その意図がうまく伝わってこないソフトウェア
　ロバート・C・マーチンによる7つの設計の悪臭

Javaを批判するC++厨にはこの悪臭のニオイがプンプンとする






　以下にロバート・C・マーチンによる書籍『アジャイルソフトウェア開発の奥義』に記載されている
7つの「設計の悪臭」を紹介する。これらのうち、どれか1つでもその傾向が感じられたなら、すで
にわなに陥っていると考えてもよいだろう。

兆候 説明
1. 硬さ 変更しにくいシステム。1つの変更によってシステムのほかの部分に影響が及び、
　　　　　　　　　　　　　　　多くの変更を余儀なくさせるようなソフトウェア

2. もろさ 1つの変更によって、その変更とは概念的に関連のない個所まで壊れてしまうようなソフトウェア

3. 移植性のなさ ほかのシステムでも再利用できる部分をモジュールとして切り離すことが困難なソフトウェア

4. 扱いにくさ 正しいことをするよりも、誤ったことをする方が安易なソフトウェア

5. 不必要な複雑さ 本質的な意味を持たない構造を内包しているようなソフトウェア

6. 不必要な繰り返し 同じような構造を繰り返し含み、抽象化してまとめられる部分がまとまっていないソフトウェア

7. 不透明さ 読みにくく、分かりにくい。その意図がうまく伝わってこないソフトウェア
　ロバート・C・マーチンによる7つの設計の悪臭

　以下に、『アジャイルソフトウェア開発の奥義』に記載されている、クラスに関する5つの設計原則を紹介する。

原則名 説明
1. 単一責任の原則（SRP：Single Responsibility Principle）
クラスを変更する理由は1つ以上存在してはならない

2. オープン・クローズドの原則（OCP：Open-Closed Principle）
ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いていなけれ
ばならず（オープン：Open）、修正に対しては閉じていなければならない（クローズド：Closed）

3. リスコフの置換原則（LSP：Liskov Substituion Principle）
派生型はその基本型と置換可能でなければならない

4. 依存関係逆転の原則（DIP：Dependency Inversion Principle）
a. 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュー
ルも「抽象」に依存すべきである
b. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである

5. インターフェイス分離の原則（ISP：Interface Segregation Principle）
クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない

1. 単一責任の原則（SRP：Single Responsibility Principle）

　クラスの「役割（責任）」＝「変更理由」は1つに絞るべきである。
クラスが複数の役割を持っていれば、クラスを変更する理由も複数になってしまう。
また複数の役割を持ったクラスの役割は互いに結合してしまい、片方を変更すれ
ばその変更の影響が他方にも影響してしまう。つまり、複数の理由から1つのクラ
スを変更することがないようにすべきである。


2. オープン・クローズドの原則（OCP：Open-Closed Principle）

　モジュールの振る舞いが拡張可能であれば、「拡張に対して開かれている」といえる。
また、モジュールの振る舞いを変更しても、既存のソース・コードやバイナリ・コードが影
響を受けることがなければ、「修正に対して閉じている」といえる。矛盾しているように思え
るこの2つの属性は「抽象」と「ポリモーフィズム」で実現できる。抽象クラスやインターフ
ェイスを定義して、その派生クラスを新たに追加すれば、既存のコードを修正することな
くモジュールの振る舞いを拡張できる。

3. リスコフの置換原則（LSP：Liskov Substituion Principle）

　クライアントが使用している基本クラス型を派生クラス型に置き換えても正常に動作しなくては
ならない。そのためには派生クラスは基本クラスの振る舞いの妥当性を維持する必要がある。
基本クラス以下の機能しか持たない派生クラスは、基本クラスと置き換えることはできない。

　バートランド・メイヤーによって提唱された「契約による設計（DBC：Design By Contract）」を使用
すれば、この原則を適用できるようになる。「契約による設計」では、クラスの振る舞いを、クラスが
持つ各メソッドの事前条件と事後条件、クラスの不変条件によって明文化する。

　.NETにおいて契約による設計を行うには、Debugクラス（System.Diagnostics名前空間）のAssert
メソッドを使用してアサーションを行い、契約に対する違反を検出する方法がある。またもう1つの
方法としてユニットテストがある。ユニットテストはクラスの振る舞いに関する契約を記述し、チェッ
クするための有効な手段である。

4. 依存関係逆転の原則（DIP：Dependency Inversion Principle）


　従来の手続き型プログラミングでは、上位レベルの方針が下位レベルの実装に依存してしまう。
これでは、実装の詳細を担当する下位モジュールの変更が上位モジュールにまで及び、その変
更を余儀なくされてしまう。オブジェクト指向プログラミングでは、「抽象」を導入することでその依
存性を逆転させる。つまり上位レベルで「抽象インターフェイス」を定義し、下位レベルでこの「抽象
インターフェイス」を実装する。このようにして方針と実装の詳細をともに「抽象インターフェイス」に
依存させるのだ。

　上位レベルのモジュールをクライアントとして考えた場合に、従来の方法では、下位レベルのモジュ
ールのインターフェイスにクライアントが依存していた。つまり、本来クライアントが受けるべきサービ
スのインターフェイスの所有者は、下位レベルのモジュールであると考えられる。しかし、この原則に
従えばクライアント側でサービスのインターフェイスを宣言することになり、「インターフェイスはクライ
アントに属する」ことになる。オブジェクト指向設計では、このようにインターフェイスの所有権を逆転
させることがとても重要になってくる。





5. インターフェイス分離の原則（ISP：Interface Segregation Principle）


　クラスを利用するクライアントが複数存在するような場合に、各クライアントに共通の大きなインタ
ーフェイスを利用させてしまうと、各クライアントは利用しないメソッドにまで依存してしまう。つまり、
各クライアントが利用していないメソッドに対する変更の影響まで受けてしまう可能性があるというこ
とだ。そこで各クライアントが呼び出す必要のあるサービスの単位でクライアントをグループ分けし、
そのグループに特化したインターフェイスを準備することで、異なるサービス間での関連性を分断す
ることが可能となる。

連投しすぎ……

typedef で追いつめられたから必死で流そうとしてるのか

>>698
>そもそも、typedefに拘ること自体、くだらない。

これは敗北宣言（= Javaではtypedefは実現できない）とみなしてよろしいですね？
あなたが挙げた方法のいずれもtypedefの簡便さに比べると相当劣っているどころか
いちいち面倒な作業を要求されるように見えます。
KISSについてご存じなようですが、あなたのやり方はシンプルからはほど遠いものだと思います。

>君が、無駄にメソッドを大量生成するというeXtreme Programmingの鉄則に
>反する愚かな行いをしていることはよくわかった。

いわれのないレッテル貼りはやめてください。typedefと関係ありません。

>君は本当にそんなにGenericsのGenericsになってる「長い型」が本当に必要なのか
>今一度、考え直すべきだ。

Genericsという仕組みがある以上型名が長くなるのは仕方ないと思いますが
そのような型を使ってはいけないと言うのですか？
それはGenericsの柔軟性を大きく損なう行為ではないでしょうか。

>>711
なぜ追いつめられたことにするのかな？
現実逃避か？

>>712
> >>698
> >そもそも、typedefに拘ること自体、くだらない。
> これは敗北宣言（= Javaではtypedefは実現できない）とみなしてよろしいですね？

なにその悔しまみれな発言w

いくら書いても、
C++はグローバル変数や関数使えるんだろ？
マクロで糞仕様にもできるんだろ？

c++でOOPじゃない糞コードは山ほどあるだろ。

多次元配列ばかり作ってることには肯定してしまったのか。

それに、C++厨はオブジェクト指向設計の原則も守れないことを
認めてしまったか

日本で銃を持つ方法を聞いて「持つ必要あるのか」と聞かれたら「ププー銃持てないんだってー」というアメリカンみたいだ

ところでC++のテンプレートだと何重ものネストだって使っている気がするけど、
Javaのジェネリクスだとそう何重にもネストして使うことは少ない気がする。

最近のC++はOOPよりもジェネリックプログラミングや
テンプレートメタプログラミングに傾斜していて、
JavaはOOP一筋を貫いているという違いからだろうけど。

それとは関係ないが、>>686を見てみると、
「とんでもないネーミングをした奴のコード」と書いてあって、ジェネリクスには一言も触れていない。
つまりそう頻繁にはやらないということを前提で書いているように俺は思う。
それに対して、ジェネリクスであっという間に長い型名が出来てしまうが、その度に
そんな面倒なことはやりたくないと言ったら、話が噛み合わなくなるのは当然かなという気がする。

>>716
どこに書いてあるの

うーん……そういう新しいプログラミング手法を使ってるのにtypedefという
古臭い仕組みを使って表現しないといけないというのはなんとなく腑に落ちない
別の表現形式を考えたほうがいいのかもな……
そのうちジェネリックスに特化した構文が出てくると思う。

そもそも、長ったらしいGenericsをそんなに使うことがあるのかっつー話をまずしなければ。

金庫には本来金しか入れないわけだが、このC++厨は金以外のものでも
くだらないものでも何でも入れたがる。
だから、どんな型のブツが入るかわからないから、パラメタライズしておきたい
って話だろう。

普通の人間なら、金しか入れないので、そこに入れるものは金だけだと
わかっているのでそのクラスをいちいちパラメタライズしない。

class Coffer {
　private Money money;
　//その他の情報
}

ところがこのC++厨は・・・・

class Coffer<List<List<T>>, List<List<貴重品>,List<List<骨董品>>> ........ > { }
などなどとなんでもかんでも詰め込みすぎる。


こういう価値観の違いがあるのではないだろうか？

こんなことを擦るんだったら、
普通は、クラスを分割するものなんだけどねえ

enum { 金庫, 貴重品, 骨董品}
みたなもの作ってメソッド引数に入れるってことも普通は考えるのだが。

C++厨はどこまでも拘る。

連投しすぎ……

よっぽどtypedefが効いたんだな

>>721
そういう例なら人間が詰め込もうと思ったからテンプレート引数が長くなっている。
JavaでだってC++でだってまともな人間はそんなコードは書かない。

C++では何気なくBoostなどのテンプレートを多用するライブラリを使うと、
使っている人間は意識していないのに、気が付けば巨大なテンプレート引数の並びが生まれる。
それが関わったコンパイルエラーに遭遇して初めてその巨大さを知らされる羽目となる。
今のC++はそこが嫌だね。0xでどうなるか見物だけど。

>>724
全然反論になってないよ。
人の話を聞けないからそういうレスしかできないんだね

>>725
> >>721
> そういう例なら人間が詰め込もうと思ったからテンプレート引数が長くなっている。
> JavaでだってC++でだってまともな人間はそんなコードは書かない。

このスレにいるtypedef馬鹿をいると、とてもそうとは思えないんだよな。
やけにやたらとtypedefに拘るということは、
彼はまともな人間ではないC++厨ということか。


> C++では何気なくBoostなどのテンプレートを多用するライブラリを使うと、
> 使っている人間は意識していないのに、気が付けば巨大なテンプレート引数の並びが生まれる。


それがおかしい。オブジェクト指向設計原則を守っていない証拠

コピペ止めろ。自分の言葉で語れ。

>>726
君が連投してないということを示すために
書き込んだレス番号のリストを教えて欲しい。

>>716
>それに、C++厨はオブジェクト指向設計の原則も守れないことを
>認めてしまったか

このへんはまさにいろんな制限に縛られるのが大好きなマゾっ子Java厨の発想だな。
その時々でさまざま選択ができる自由とそれらに伴うメリットとリスクを抱えて歩むのがC++厨だ。

テンプレートとオブジェクト指向をごっちゃにしてるアフォに
馬鹿だとか厨とか言われてもなあ。

>>728
どこが？

>>726 がんばって書いてみたよ
>>708-710 について、C++厨の俺が思うに

>1 
あの忌まわしき「多重継承」によって、C++はJavaのinterfaceの行っている
「実装とインターフェースの分離」以上の機能の分割も可能にしている。
テンプレート・メタプログラミングでよく使われる「ポリシー･クラス」がその例だ。

>2
もちろん、C++にもJavaと同じ「データ抽象」と「ポリモルフィズム」がある。
C++にはそれに加え、型自体を抽象化できる仕組みがある。
例えば、STLはコンテナ・イテレータ・アルゴリズムに抽象化した。
そして、ユーザ定義のコンテナ・イテレータ・アルゴリズムを、既存のコードの変更無く投入できるコンパイル時ポリモルフィズムがある。

>3
C++では、public継承して作成されたクラスは、その親クラスとしての振る舞いも求められる。
C++で契約による設計を行いたければ、コンストラクタでのチェックに加え、NVIパターンを使えばよい。
公開するインターフェースとカスタマイズ可能な振る舞いを分割することは、
基本クラスでの事前条件・事後条件のチェックの機会を与える。

>4
もちろん、C++の持つ「データ抽象＋仮想関数による振る舞いの変更」は、Javaと同等。
さらに、上記3でも指摘したように、NVIパターンを使えば基本クラスから派生クラスへと
カスタマイズできる振る舞いの範囲に制約を課し、より上位レベルからの扱いが安全に行える。

>5
あの『オブジェクト指向における再利用のためのデザインパターン』がC++書かれているように、
その分離は自然に行える。

>>730
おかしな奴だ。
それでマゾ？

なら、お前は道路に放り出されて
車に轢かれてもかまわないというのだな？

お前みたいに、馬鹿みたいにわざわざ、車の通りが激しい
渋滞もしていない高速道路を徒歩で横断するのがC++厨なのかw

>>733
で、それらの鉄則をすべて守ることはできるのかな？

日頃から、ドライバ開発や組み込み系しかやってない
馬鹿には守ることができなさそうなことだが

>>735
下を見ればどうしようもない奴がいることは十分承知。

#中身への言及じゃないことに萎えた
#そんなこと言い出したらJavaでも、なんでもかんでもpublicとかstaticにしていくバカがいるからダメだ
#・・といえてしまう orz

>>734
なんか過剰反応してんなぁ。マゾっ子とは表現したけど、別にそれ自体は俺も悪いこと
だとは思わんし、C++はよくも悪くもアウトローの言語だ。

>なら、お前は道路に放り出されて

放り出されるんじゃない。自ら飛び出ることができるんだ。

>お前みたいに、馬鹿みたいにわざわざ、車の通りが激しい
>渋滞もしていない高速道路を徒歩で横断するのがC++厨なのかw

ごめん、なに言ってんのかわかんない。日本語でおk

>>734-735
ねえ、どのレスを書いたか教えてよ

>>727
C++だとtypedefなしにテンプレートはまともに使えない。
だからtypedefがないJavaでジェネリクスが使えると信じられない奴が出てくるのは全然不思議ではない。
そういう奴はC++のテンプレートとJavaのジェネリクスは同じようなものだと思っているからたちが悪い。
class Hoge;
typedef Foo<Hoge> FooX;
typedef Bar<FooX> BazType;
BazTypeの実態はBar<Foo<Hoge> >、これはわざとらしいけど、
実際これに近い感じでテンプレート引数は膨れていく。

> オブジェクト指向設計原則を守っていない証拠
ある意味当然だ。Boostなどはもはやオブジェクト指向プログラミングとは別次元の世界と化している。
勿論そっちにはそっちの流儀の設計原則があって
それを守っているはずだ（すまん、そこまで俺は知らない）。

>>737
> 放り出されるんじゃない。自ら飛び出ることができるんだ。
みんなそういうけど、そのつもりがなくても慣れないと
気が付いたら飛び出てしまっていることがあるのもまた事実。

折角の防御機構だって入門書レベルで扱われることはまず無い。
放り出されると言われても現状では仕方が無い。

>>737
>>アウトローの言語

言い得て妙の表現ですな。ほんとにその通りｗ
C++というのは、お行儀の良いコードを書くこともできるし、コンパイラを軽くだまくらかすこともできるし、無茶苦茶もできる。
コンパイラもそれを拒絶しない言語だもんね。
言語設計に信念のあるJavaとは本質的に違うし競合もしないのに、何で皆ムキになるのかね。
ピザとピザパンはどっちが美味いかと喧嘩してるようなもんだ。

>>741
>ピザとピザパンはどっちが美味いかと喧嘩してるようなもんだ。

そりゃ絶対に譲れんな、ピザ(C++)のほうが美味しいに決まってる！

>>736
だから「オブジェクト指向設計原則」を守るべきだと

>>737
> >>734
> なんか過剰反応してんなぁ。マゾっ子とは表現したけど、別にそれ自体は俺も悪いこと
> だとは思わんし、C++はよくも悪くもアウトローの言語だ。
> >なら、お前は道路に放り出されて
> 放り出されるんじゃない。自ら飛び出ることができるんだ。

やってることが、北朝鮮の瀬戸際外交だな。


> >お前みたいに、馬鹿みたいにわざわざ、車の通りが激しい
> >渋滞もしていない高速道路を徒歩で横断するのがC++厨なのかw

よめねえのか。

廃墟のように車の通りが一切無いかまたは
渋滞していれば高速道路を横断しても車に轢き殺されずに済むって事だろ。


通常通りなら、時速100kmの車に轢き殺されてあの世に逝く確率の方が非常に高い。
そういうこと。

Javaって、const が無いのが納得がいかない。

書き換え禁止で参照返せないじゃん。

>>740
まぁ、それが怖いヤツは決められたレールの上だけ歩いてなさいってこった。
それは確かに安全なことだし悪いことじゃない。が、安全なハズのレールの
上だって事故が起きないわけじゃないってことをお忘れなく。

>>742
ピザでも食ってろデブ

>>745
final

>>742
マルチパラダイムなC++はピザパンのほうだな。

>>745
あれは本当いただけないな。Javaの安全志向の設計から外れてる。
ところでこの件に関してゴスリンは設計ミスだったと今は思ってんの？
それともそんなんJavaには要らねぇよって今も主張してんの？

>>748
ちがうでしょ。
immutable

>>751
それもfinalで実現できる。不変クラスでググレ

Java厨は連投ばかりしていることを認めてしまったか

>>753
よく聞こえませんよ？
日本語でおｋ

そう言えばゴスリンには、ハゲみたいな愛称ってないんだっけ？

ゴスりん自体が愛称じゃねえの

もう一人の禿ストラウストラップなんか名前からして
ジョークみたいだけどな

びぃよよょ〜ん・すとらう・struts

ロシアのプチハゲと比べたらましよ

>>752
だから〜、不変クラスの意味でimmutableって言ったんだけど。
finalキーワードだけでは実現できないでしょーが。

>>739
どうりでC++Templateばかりやってると頭禿げるわけだ

ねえ、ものすごく必死に連投してる人がいるみたいだけど、
Java好きな人ってこんなキモい人ばっかなの？
付き合いたくない……

>>760
おおむね、finalキーワードを中心にできているようなもんだあれは。

クラスとメソッド引数をすべてfinalにして、フィールドはprivate finalにして
setterメソッドを作らず、コンストラクタとgetterメソッドを使うときは
すべてclone()でコピーしてから代入する。

配列やコレクションだと、それらの要素にまで影響が及ばないように
ちょっと面倒くさいことをするが、Collectionsクラスを使えばどうってことでもない。

>>762
またそんな煽り
C++好きな人ってこういう言い訳しかできないの？
付き合いたくない・・・・

>>759
プーチン大統領のことだったんだ

>>755
何がいいたいの？

イミュータブル
http://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%9F%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%96%E3%83%AB

ここにJavaのサンプル発見

特に >>699- のあたりがキモい
全然関係ない話を延々コピペしてるし

>>768
設計原則を守れないとは、さすがアウトローＣ＋＋厨w

オブジェクト指向設計原則を守れないC++厨は
人工衛星破壊実験でスペースでブリをばらまいて
宇宙環境を破壊して国際社会に迷惑をかける中国共産党みたいだw

さしずめ、Chinese++といったところかwwwww

>>763
それを>>742みたいに一言「final」なんていった日にゃ、
C++のconstのつもりでfinalを使ってはまる人続出だぞ。
誰向けの回答だよ。

そういう意味ではリトビネンコを放射性物質で殺したプチハゲにも似てる。

かれはサングラスをかけるとエージェントスミスになるクラッカーだからw

C++のほうがウィルスやスパイウェアを作りやすいから、いかにも
プチハゲ(エージェントスミス)って漢字だw

>>771
多くのJavaプログラマはconstもfinalもただの定数程度にしか思ってないだろう。
ちょっと慣れてくると、finalは一回しか代入できない定数や継承を禁ずるために
あると考えるようになる。確かに、不変クラスのことを知らない奴はﾏﾀﾞ多いな。
配列をfinalにしても配列の要素まではfinalにならない、clone()しなければ不変にならない
ってことを知らない奴もまだいるねえ。JavaのオブジェクトがC++のポインタと同じように
作用することもしらず、「浅いクローニング」「深いクローニング」の意味を知らない奴はまだまだいるねえ

不変クラスも知らないようなのがプログラマやってんのか。
世も末だな。

そりゃ、最近、学生が多いから

>>767
final class ImmutableCart<T> {
　private final List<T> items;
　
　public ImmutableCart(final List<T> items) {
　　//防御的コピーを行った後、リストの要素の実行時タイプチェックを行い、
　　//リストの要素をfinalにする。
　　this.items = Collections.unmodifiableList(
　　　　　　　　　 Collections.checkedList(
　　　　　　　　　　 (List<T>) items.clone(), T.class
　　　　　　　　　 )
　　　　　　　　 );
　}
　
　public List<T> getItems() {
　　return (List<T>) items.clone(); //内部フィールドの防御的コピー
　}
　public int total() { /* return sum of the prices */ }
}

配列を使うと確かに複雑だ。

オブジェクト指向もわからないC言語厨/Ｃ＋＋厨には

Javaの static importは使わせたくないな。

やつら、やたらとstaticが好きで過剰に使いすぎるから

そんなにオブジェクト指向設計って偉かったのか・・
それしか言えなくなって、だんだん>>770 >>772 >>777みたいになっていくのが哀れ。

イミュータブル・クラスの意味はわかったが、C++のconst type &とは根本的に違うよな。
クラスがイミュータブル・クラスでなければ、書き換え禁止で参照渡しすることはできないんだよね。

どんなクラスでも、イミュータブルにできるわけじゃないし。解決にはならない。
結局、安全面を妥協して書き換え可能な形で参照返すか、実行効率を犠牲にしてコピーを作成するしか無いんだよね。

俺は、普段はC++を使っていて、Javaを毛嫌いしているわけじゃないが、この仕様だけには納得がいかなかった。

C/C++は本当にstaticが無いとやっていけないから困る

>>773
その辺がわかってる人だと、何でJavaのStringは不変クラスで、
C++のstd::stringはそうじゃないのか、みたいなことも、
難なく納得してもらえるんだけどなあ。
そうじゃない人は、言語にかかわらずアレだけど。
（ついでに。ごめん、>>771の2行目の「>>742」は「>>748」の間違い。）

>>769-770
お前らは走行中のトラックの前に飛び出すことができるなら
引かれて死ぬと解ってても思わず飛び出しちゃうのか？　
なるほど、Java厨の為にはガチガチの制限が必要なわけだ。