JavaやるとC++は有害に感じる int 2
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
2007/02/11(日) 14:53:43私はオブジェクト指向という言葉を発明したが、C++のことなんて全く念頭になかったね。
-- アラン・ケイ
C++の進化の歴史は文字列の抽象化を漏れを塞ごうと試行錯誤するものである。
なぜ彼らが単にネイティブ文字列を追加しないのかわからない。
-- ジョエル・スプロウスキー
C++は見栄えをよくしたCOBOLとして現在使われている唯一の言語だ。
-- バートランド・メイヤー
もしBjarneがCとの互換性にこだわる必要がなかったとしたら、Javaを開発していたろうね。
-- ビル・ジョイ
C++言語のデザイナーたちは、同じ問題を解決するアイディアが二つあると、いつも「よし、両方ともやろう」と言う。
だからこの言語は私の感覚ではかなり奇怪(baroque)なものになっている。
-- ドナルド・クヌース
歴史的に、他人に使ってもらえるようにデザインされた言語は出来が悪い：COBOL, PL/I, Pascal, Ada, C++.
良い言語はクリエイターが自身が使うためにデザインしたものである：C, Perl, Smalltalk, Lsip.
-- ポール・グレアム
C++なぞ問題外. ^^;;;
-- まつもとゆきひろ
0002デフォルトの名無しさん
2007/02/11(日) 14:54:230003デフォルトの名無しさん
2007/02/11(日) 14:56:24乙
0004デフォルトの名無しさん
2007/02/11(日) 14:59:32JavaやったらC++はきもく感じる
http://pc10.2ch.net/test/read.cgi/tech/1168423655/
0005デフォルトの名無しさん
2007/02/11(日) 15:01:57＞良い言語はクリエイターが自身が使うためにデザインしたものである：C, Perl, Smalltalk, Lsip.
Lsip ???
0006デフォルトの名無しさん
2007/02/11(日) 16:01:070007デフォルトの名無しさん
2007/02/11(日) 16:17:16そんな俺はエッチな女の子
0008デフォルトの名無しさん
2007/02/11(日) 16:17:410009デフォルトの名無しさん
2007/02/11(日) 16:21:48確かにC++には確実に生産性に悪影響を与える
メモリ管理の問題が未解決だなぁ
前スレに「解決している」って書いていた人がいたけど。
これについて少し書いてみてくれないか？＞詳しい人
0010デフォルトの名無しさん
2007/02/11(日) 16:23:34JNI使えよ
0011デフォルトの名無しさん
2007/02/11(日) 16:23:380012デフォルトの名無しさん
2007/02/11(日) 16:25:05javaが精神にきわめて悪いのは、立証されたな
javaやると、キチガイになるぞと
0013デフォルトの名無しさん
2007/02/11(日) 16:25:26http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
＞C++と比較すれば、Javaは言語として同程度だ。いや、今のなし。ずっといい。文字列があるもの。…
0014デフォルトの名無しさん
2007/02/11(日) 16:33:01解決方法がわかってなんだか肩透かし
今の気持ちを譬えるなら恋人と爆弾を同時に手に入れた気分
ありがとう！
001514
2007/02/11(日) 16:37:590016デフォルトの名無しさん
2007/02/11(日) 16:41:56その制約を守らない奴がいるから、
同じではない。
そしてポインタ演算の扱い。
そしてString型の扱い。
これはどうしようもない。あのC++のstringは駄目仕様だ。
0017デフォルトの名無しさん
2007/02/11(日) 16:42:22つまり、Javaの放射性同位体がC++なのだ。
0018デフォルトの名無しさん
2007/02/11(日) 16:42:45キチガイほどそういう発言をする
0019デフォルトの名無しさん
2007/02/11(日) 16:43:49Comparison of Java and C++
http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B
0020デフォルトの名無しさん
2007/02/11(日) 16:44:11backwards 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
0021デフォルトの名無しさん
2007/02/11(日) 16:44:300022デフォルトの名無しさん
2007/02/11(日) 16:45:38Java信者の浅はかなところ。
0023デフォルトの名無しさん
2007/02/11(日) 16:45:50C++
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
0024デフォルトの名無しさん
2007/02/11(日) 16:46:24そういう発言を脊髄反射するおまえみたいなC++厨のほうが浅はかだよ。
まだまだC++の欠点は膨大にある。
0025デフォルトの名無しさん
2007/02/11(日) 16:50:25言語でちゃんと標準の文字列が存在しないというか
C言語の文字へのポインタが文字列っていう考えのまま。
0026デフォルトの名無しさん
2007/02/11(日) 16:51:130027デフォルトの名無しさん
2007/02/11(日) 16:52:31>>26 は、>>24 のレスな。
0028デフォルトの名無しさん
2007/02/11(日) 16:56:260029デフォルトの名無しさん
2007/02/11(日) 16:56:44std::string x;
x.c_str()
ってしなきゃならない。
0030デフォルトの名無しさん
2007/02/11(日) 17:01:05あんまり変わらん気がするけど
0031デフォルトの名無しさん
2007/02/11(日) 17:05:00JavaでもC++でもどっちでも歓迎
0032デフォルトの名無しさん
2007/02/11(日) 17:09:53主要なものほとんどがstd::stringをサポートしない限り
JavaのStringと対等とは思えない。
0033デフォルトの名無しさん
2007/02/11(日) 17:11:25主要なものほとんどがstd::listをサポートしない限り
標準じゃないのに標準テンプレート。
0034デフォルトの名無しさん
2007/02/11(日) 17:11:59いやstd::stringは糞だろ。
0035デフォルトの名無しさん
2007/02/11(日) 17:16:190036デフォルトの名無しさん
2007/02/11(日) 17:23:210037デフォルトの名無しさん
2007/02/11(日) 17:25:050038デフォルトの名無しさん
2007/02/11(日) 17:54:39とっつきにくいし難しいし、いつまでも手の届かない存在みたいな。
そんで、できなきゃいつまでもﾄﾞｶﾀｸﾞﾗﾏｰ。
10年前にはC++なんて10年後にはないだろなんてVBプログラマーに言われた
もんだが、VBやってた連中はみな退職していったな。
VBがJavaに食われたように、10年後にJavaはPHP/Rubyに食われて死んでるかも
しれないけどC++はたぶん今と変わらない位置だろうな。大ブームもないけど
重要な位置では使われ続ける。
言語としての弱点はあるけど、結局OSや重要なOSSはみなCだから、Cが直接
使えてオブジェクト指向ができる折衷案のメリットが大きすぎるんだろうね。
0039デフォルトの名無しさん
2007/02/11(日) 17:58:410040デフォルトの名無しさん
2007/02/11(日) 20:05:420041デフォルトの名無しさん
2007/02/11(日) 20:14:20じゃあ、これからもずっとCじゃね。
Cで十分な所に、あえてC++を持ち出す意味は無い。
0042デフォルトの名無しさん
2007/02/11(日) 20:30:310043デフォルトの名無しさん
2007/02/11(日) 21:07:45まともな言語だな
0044デフォルトの名無しさん
2007/02/11(日) 21:11:030045デフォルトの名無しさん
2007/02/11(日) 21:52:13んなあほな。
0046デフォルトの名無しさん
2007/02/11(日) 22:34:230047デフォルトの名無しさん
2007/02/11(日) 22:41:060048デフォルトの名無しさん
2007/02/11(日) 23:01:04クライアントで敗北したJavaはサーバサイドという土地を開拓したが、
原住民のPerl/PHPの思わぬ抵抗に大苦戦みたいな感じだな。
0049デフォルトの名無しさん
2007/02/11(日) 23:31:01まだ３章までしか読めてないが、
楽チンな言語かと思いきや、可視性のあたり結構ムズくない？
マルチスレッド始めたらはC++の方がお気楽な気がする。
0050デフォルトの名無しさん
2007/02/11(日) 23:35:240051デフォルトの名無しさん
2007/02/11(日) 23:40:540052デフォルトの名無しさん
2007/02/11(日) 23:46:07ピアソンのやつ？その本Java関連の本の中で一番むずかしい。
0053デフォルトの名無しさん
2007/02/11(日) 23:58:37ピアソンのは知らないっす。
http://www.amazon.co.jp/o/ASIN/4797337206/
0054デフォルトの名無しさん
2007/02/12(月) 00:12:50今調べてみたらピアソンじゃなかったっす。orz
http://www.amazon.co.jp/o/ASIN/4881359185/
0055デフォルトの名無しさん
2007/02/12(月) 00:34:55eclipseみたいにクライアントにも侵食してはいるがね。
まあ、SUNのデザイナはセンス０ってことは同意。
0056デフォルトの名無しさん
2007/02/12(月) 01:52:24しかしboostがある
むしろboostがjava作ってほしかった
0057デフォルトの名無しさん
2007/02/12(月) 02:04:170058デフォルトの名無しさん
2007/02/12(月) 02:56:020059デフォルトの名無しさん
2007/02/12(月) 03:31:33C#？ チンコシャープ？ｗ
C? ちんこ？ｗ
（・∀・）カエレ！
0060デフォルトの名無しさん
2007/02/12(月) 03:41:05（・∀・）カエレ！
（・∀・）カエレっ！
0061デフォルトの名無しさん
2007/02/12(月) 03:44:12> もうC++ってアンチも多い人気アイドル的存在だな。
C++が人気があるって何時の時代だww オッサンよ。
アンチってほどでもなく放置している存在だがな。
> とっつきにくいし難しいし、いつまでも手の届かない存在みたいな。
> そんで、できなきゃいつまでもﾄﾞｶﾀｸﾞﾗﾏｰ。
馬鹿だな。手に届いても、開発効率が悪いから利用者が少ないだけなんだよ。
それにしても、C++の標準ライブラリがあまりにも糞過ぎるのは救いようがねえな。
> 10年前にはC++なんて10年後にはないだろなんてVBプログラマーに言われた
> もんだが、VBやってた連中はみな退職していったな。
C++やってた連中もみな退職していったな。10年後にはC++は無くなることはなくても
今よりも良い条件にはならないだろうな。言語を進化させないと無理だな。
0062デフォルトの名無しさん
2007/02/12(月) 03:44:15認識が甘いな。PHPやRubyをろくに触ったことがないことがよくわかる。
片方は最適化コンパイラも無く名前空間がつかえない糞で、双方は型に甘い言語。
これでは将来も糞も無いな。バージョン互換性の限界も超えられないようでは
未来は無い。それなら、D言語を指示した方がマシだ。
> しれないけどC++はたぶん今と変わらない位置だろうな。大ブームもないけど
仕事が減ってる以上、以前よりもかなり立ち位置は下がっている。
> 重要な位置では使われ続ける。
今のところ、ハードウェア絡みで消えないことは消えないが、
D言語やJava Communication APIが台頭したらどうなるかわからんぞ。
> 言語としての弱点はあるけど、結局OSや重要なOSSはみなCだから、Cが直接
> 使えてオブジェクト指向ができる折衷案のメリットが大きすぎるんだろうね。
はっきりいうが、C++のオブジェクト指向は糞。基底クラスが無い時点で負けている。
0063デフォルトの名無しさん
2007/02/12(月) 03:47:12> 言語としての弱点はあるけど、結局OSや重要なOSSはみなCだから、Cが直接
これも認識が甘い。すでにJava + アセンブラで作られたOSが存在するわけだが。
実用性はともかくとして。実現可能異性をみれば、C/C++の立場をさらに
追いつめることも可能だ。
組み込みシステムも対応ソフトウェア言語やドライバの規格が統一されれば、
C/C++の立場もどうなるかわかったもんじゃないしな。
それにD言語という存在がある。まだまだ未熟な言語だが、
そういう言語が台頭すると、C/C++のようなネィティブ言語でしか作れなかった
ものがそれらの言語で置き換わる可能性だってあり得るわけだ。
0064デフォルトの名無しさん
2007/02/12(月) 03:51:040065デフォルトの名無しさん
2007/02/12(月) 03:51:14ガーベッジコレクタの実行を自動化できないからどんなに頑張っても
Javaと同じようにすることは不可能。
例外基底クラスも作れない、finally節も無い、文字列も標準ではろくなものがない、
Objectクラスのような基底クラスも無い、プロセッサが変わるとint型が32ビットになったり
64ビットになったりする糞言語。配列のオーバフローもコンパイラで制御できない糞言語。
DLL地獄に対応できない糞言語。
こんなんでは無理無理、C++はJavaには近づけん。
せいぜい、C/C++はJVM開発の奴隷になってくれていればいいさ。
0066デフォルトの名無しさん
2007/02/12(月) 03:51:38便利だが、ツールが高価。100万くらい金払えってレベル
0067デフォルトの名無しさん
2007/02/12(月) 03:58:09> しかし今はもう、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などのようなおもちゃのようなスクリプト言語と
比較することがあまりにも浅はかというものだ。
畑が違うのだよ畑が。
0068デフォルトの名無しさん
2007/02/12(月) 04:03:25NetBeansやJava Studio Creatorは
そうでもなさそうだ。
というか、Sunの宣伝能力が0みたいなモンだ。
良い物作ってるのに注目されないのは宣伝に
力を入れていないからだな。
100%PureJavaでありながらネイティブに
依存するEclipseよりも軽くて高速なIDEを作った
にも関わらず注目されていない。
Swing開発ではEclipseよりも使い勝手が良いのだが。
まあプラグインの充実度ではEclipseには負けるかな。
0069デフォルトの名無しさん
2007/02/12(月) 04:06:48結局何がいいんだ？
javaでおｋ？
0070デフォルトの名無しさん
2007/02/12(月) 04:07:45boostがあってもC++が抱えている欠点を
完全に消すことはできんよ。
>>59
Ｃωはどうした。
0071デフォルトの名無しさん
2007/02/12(月) 04:11:05今俺javaやってるよ。
営業なのにスキルがいるのよ。
仕事で話多いのが、VB.NETとjavaでうちのソフトと連帯してのシステム開発だな。
PHPって外向け用でしょ。
0072デフォルトの名無しさん
2007/02/12(月) 04:54:15まぁ、小規模サイトで、Servlet,JSP,Strutsなんてのをやらないですむのは助かるよ。
大規模な開発やると、Javaのコーダーは土方だしな。
C++は新規開発はへったけど、やれる奴少ないから、ちょっといじっただけでも
評価があがるのは助かる。
まぁ、普段はCでドライバ書いてますが。これが一番楽。
0073デフォルトの名無しさん
2007/02/12(月) 05:29:390074デフォルトの名無しさん
2007/02/12(月) 05:58:53COBOLとかに手を出す気にはなれないけど。さすがに。
0075デフォルトの名無しさん
2007/02/12(月) 06:07:04COBOLできる人が必要になるって、
COBOLやってたやつがいってた。。。
どうなんだ？
0076デフォルトの名無しさん
2007/02/12(月) 06:22:36あるならゲーム屋的に異存はないですよ。
0077デフォルトの名無しさん
2007/02/12(月) 06:38:200078デフォルトの名無しさん
2007/02/12(月) 07:05:29Javaは関わっている人間に有害な者が多い
0079デフォルトの名無しさん
2007/02/12(月) 07:12:200080デフォルトの名無しさん
2007/02/12(月) 09:39:53サーバでは開発しづらくてRubyにさえ負けはじめ(やっぱLAMPが楽っす)、
ついにJavaWorldも廃刊だ。おまけに自慢の言語仕様もC#には負けちまう。
もうどこにも居場所はないんだよ。
0081デフォルトの名無しさん
2007/02/12(月) 13:36:070082デフォルトの名無しさん
2007/02/12(月) 13:37:18お前が読んでいる本見たら・・・
出版社: 翔泳社 (2000/08)
随分と時代遅れだな。
>>53のピアソンのほうがJava5から登場した【コンカレント工学】に
対応していて勉強になるぞ。
そんな古い本捨ててさっさとピアソン・エデュケーションの本
に切り替えろ。MUTEXのことろくに載っていない本など価値が無い。
0083デフォルトの名無しさん
2007/02/12(月) 13:37:51Javaでオッケー
0084デフォルトの名無しさん
2007/02/12(月) 13:43:01> でも。おめーらスキル高そうだな。。。
> 今俺javaやってるよ。
> 営業なのにスキルがいるのよ。
> 仕事で話多いのが、VB.NETとjavaでうちのソフトと連帯してのシステム開発だな。
> PHPって外向け用でしょ。
意味が解らん。
PHPの、何が、何に対して、いつ、どこで、どのように外向けなのだ？
PHPはアクセス数が多いサイトや、セキュリティのことを特に気にする必要も無い
責任も軽い大して金にもならないくだらないサイトを作ることに向いている。
ブログやWikiや2chにPHPやPerlが使われていることはその点にある。
VB.NETはVB6に依存していたVB厨を救済し、どうにかしてJavaに近い文法を持つC#に
移行させるために作ったようなもんだな。
0085デフォルトの名無しさん
2007/02/12(月) 13:47:01> >>67
> まぁ、小規模サイトで、Servlet,JSP,Strutsなんてのをやらないですむのは助かるよ。
> 大規模な開発やると、Javaのコーダーは土方だしな。
ドカタと言いきっているようだが、
数々のノウハウを集めた『イディオム』や『デザインパターン』に加えて
『アーキテクチャパターン』『アナリシスパターン』を何一つ理解できない奴が
大規模開発なんかできるはずがない。それを無理矢理やるからドカタが
出てくるだけであって、大規模開発をやる＝Javaアーキテクトがドカタになる
という式は成り立たない。
> C++は新規開発はへったけど、やれる奴少ないから、ちょっといじっただけでも
> 評価があがるのは助かる。
バグが増えても評価が上がるようでは終わってるな。
> まぁ、普段はCでドライバ書いてますが。これが一番楽。
まさに真のドカタだな。組み込み系はデータベース屋と比べると
つらいだろう。Windows DDKに苦しめられたか？ Win32 APIなんて
糞にまだ依存しなければならない状況に追いつめられているか？
0086デフォルトの名無しさん
2007/02/12(月) 13:47:54「最近はPHPやってます クラックも良いけどプログラミングもね」
「最近Perl極めた云々」
改めて、「やっぱりクラック好きな人は人間として根本的に狂ってる節があるな」と、Javaしかできない奴や
C++ナルシストに対しての通じるものを感じた。
0087デフォルトの名無しさん
2007/02/12(月) 13:51:33君が悔しがってるのは解るが>>57-58に対抗して
「中規模業務系まで」という表現が意味不明だ。
それが許すものは、苦しいがむしろPerlやPHP程度だろう。
PerlやPHPが許されるのは中規模よりもむしろ小規模だが、
業務系よりもむしろ、お遊び系だ。
その画像ジェネレータの生成結果のとおりのことを真実だと
思っているなら、
PerlやPHPでオンラインバンキングやオンライントレーディング
サイトを作ってみろ。
0088デフォルトの名無しさん
2007/02/12(月) 13:51:57人気よりも、魅力のある言語を習得した方が良い。
関数型言語とか
0089デフォルトの名無しさん
2007/02/12(月) 13:52:49過去の遺産を完全に破棄すれば、結局
COBOLも不要になる。
過去のCOBOL遺産をどうしても再利用したいときだけ
使われるに過ぎない。
だが、仕様書をきっちり書いて残していれば
COBOLがどうこうなんて関係無いがな
0090デフォルトの名無しさん
2007/02/12(月) 13:53:55> C++は言語に有害な点が多い
> Javaは関わっている人間に有害な者が多い
Javaプログラマの人口が圧倒的に多いなら
そりゃ絶対数で見れば有害な奴が紛れてくるだろう。
0091デフォルトの名無しさん
2007/02/12(月) 14:11:33> クライアントでは遅くて使い物にならず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に敗れた原因の一つでもある。
0092デフォルトの名無しさん
2007/02/12(月) 14:11:40じゃあそのRubyとLAMPで金融システムを開発してみような。
> ついにJavaWorldも廃刊だ。おまけに自慢の言語仕様もC#には負けちまう。
そういえばJavaWorldが廃刊したからもうJavaは終わりだと3年くらい前に
寝言を言っている奴がいたものだ。しかも君と同じようにC#を崇拝していた。
だが結果は、C#の敗北となった。言語仕様であれがC#に負けているというなら、
C++にすら負けているという意味になるが、その解釈は、まるでアルファベットが少ない英語が、
アルファベットが多い中国語に負けていると主張しているようなものだ。
0093デフォルトの名無しさん
2007/02/12(月) 14:14:15意味が解らないんだが。
その本の題名を説明して貰わないと。
断片だけで煽るのはやめようや。
PHPやPerlは畑が違うんだからな。
もう「Javaしかできない奴」という煽りも恥ずかしいから
やめておいたほうがいいぞ。
今どき、そんな奴はこのスレには「Java質問スレ」に質問しまくる新人レベルの奴以外
そんなにいないんだからよ。
0094デフォルトの名無しさん
2007/02/12(月) 14:22:14C++よりJavaのほうが速いことがあるなんて、
今更得意げになって語るほど目新しくないよ。
そんなんだからJava厨は、なんて言われJavaの魅力が霞む。
0095デフォルトの名無しさん
2007/02/12(月) 14:44:510096デフォルトの名無しさん
2007/02/12(月) 14:45:160097デフォルトの名無しさん
2007/02/12(月) 15:01:22研究や金融系の計算プログラムはほとんどCかC++（もしくはフォートラン）だぞ
Javaで書かれたプログラムなんぞ見たことすらないんだが
0098デフォルトの名無しさん
2007/02/12(月) 15:24:49> Javaの起動速度については、現在のところでは確かに遅いと言えるでしょう。
> ネイティブ・アプリケーションに比べ、Javaアプリケーションが多くのメモリを必要とするのは確かです。
> GCによるスレッドの停止時間がどのくらいの長さになるかを特定するのは難しいため、いわゆるリアルタイム・システムをJavaによって構築するのは困難な場合があると思われます。
ttp://www.javaworld.jp/technology_and_programming/-/27047-2.html
0099デフォルトの名無しさん
2007/02/12(月) 16:42:450100デフォルトの名無しさん
2007/02/12(月) 18:02:21javaにすると本当に処理速度あがるの？
0101デフォルトの名無しさん
2007/02/12(月) 18:23:13金融なら、こいつがJava。(ただし、JR東の中の人が使う画面はCurlで書いてる)
ttp://www.tis.co.jp/product/CreditCube/index.html
SUICAの売上とか残高とか、全部これで管理されてるよ。
>100
Perlで画像処理やってたと言うなら
それはぜひJavaに乗り換えるべきだとおもう。
0102デフォルトの名無しさん
2007/02/12(月) 18:35:33片方しか出来ない馬鹿乙
0103デフォルトの名無しさん
2007/02/12(月) 18:40:250104デフォルトの名無しさん
2007/02/12(月) 18:43:55Dのトップページのサンプルが微妙にきもいんだけど。CmdLinて。std.stdioとかまるでC++。
writeflnはライト不倫としか読めんし。こういう命名文化の言語ならちょっとヤだぞ。
0105デフォルトの名無しさん
2007/02/12(月) 18:45:210106デフォルトの名無しさん
2007/02/12(月) 18:54:550107デフォルトの名無しさん
2007/02/12(月) 19:36:24C++よりjavaが速度あがるわけじゃないのね
0108デフォルトの名無しさん
2007/02/12(月) 19:40:03もちろんC++よりも速くなるよー
0109デフォルトの名無しさん
2007/02/12(月) 19:40:31なんかJavaのさえない実績をあおるC++信者に、必死に妄想で対応する
Java信者のいつもの構図だな
0110デフォルトの名無しさん
2007/02/12(月) 20:03:25なんでadobeは、いまからc++画像処理ライブラリー作るとか言ってるの？
javaでいいのに
0111デフォルトの名無しさん
2007/02/12(月) 20:06:050112デフォルトの名無しさん
2007/02/12(月) 20:24:46PerlだろうがPythonだろうがJavaだろうが大抵の言語はC/C++向けの拡張インターフェースを
持っていて、C++で書かれたライブラリを簡単に取り込めるけど。
Javaで書かれたライブラリはまずJavaでしか使われないよね。速度が問題じゃないよ。
0113デフォルトの名無しさん
2007/02/12(月) 20:34:45sse使えないし
0114デフォルトの名無しさん
2007/02/12(月) 20:52:44不安でしょうがない
0115デフォルトの名無しさん
2007/02/12(月) 20:57:23衰退するんだろうな・・。いい言語だとは思うんだけどさ。
俺は実務指向だから、はやらなくなったものはやっぱ使わなくなるかな。
0116デフォルトの名無しさん
2007/02/12(月) 22:03:47Rubyが高速化したら負けるけど。
0117デフォルトの名無しさん
2007/02/12(月) 22:05:470118デフォルトの名無しさん
2007/02/12(月) 22:12:10先入観無しで一度使ってみるよろし。
Javaでコード書くのダルくなること請け合い、C++は言うに及ばず。
0119デフォルトの名無しさん
2007/02/12(月) 22:15:30実際使ってる案件見たことないんだよ
0120デフォルトの名無しさん
2007/02/12(月) 22:18:00キモイからじゃね？
0121デフォルトの名無しさん
2007/02/12(月) 22:19:42俺の会社は誰からも見えないよ
0122デフォルトの名無しさん
2007/02/12(月) 22:20:08とりあえず今は、ちょっとしたツール作るときに使ってる。
0123デフォルトの名無しさん
2007/02/12(月) 22:21:10> >>91
> C++よりJavaのほうが速いことがあるなんて、
> 今更得意げになって語るほど目新しくないよ。
そんなことにいまだに気づいていないで、今さら得意げに煽る>>80も
同化と思うが。
そんなんだからドトネト・スクリプト厨は、なんて言われ.NETやスクリプト言語の魅力が霞む。
0124デフォルトの名無しさん
2007/02/12(月) 22:21:49だけど、そのキモさが良いんだけど。
0125デフォルトの名無しさん
2007/02/12(月) 22:21:57それでもいいよ。デスクトップOSの大部分がWindowsなんだから。
サーバはLinuxやSolarisなどがよく使われていても
結局はJavaを使うケースがあるんだし
0126デフォルトの名無しさん
2007/02/12(月) 22:25:100127デフォルトの名無しさん
2007/02/12(月) 22:26:28> 研究や金融系の計算プログラムはほとんどCかC++（もしくはフォートラン）だぞ
それがデマでないなら、金融系のプログラムがほとんどC/C++でかかれているという
根拠を示してくれ。COBOLの間違いじゃないよな？
研究ではCを使っているケースがあることは歴史上しっているが、
最近ではJavaにシフトしているところも現れている。
10年経ってもコンパイルに困らないからという理由で
プログラムを全部Javaで書いている大学教授もいる。
0128デフォルトの名無しさん
2007/02/12(月) 22:27:23処理速度が上がることを期待するより、
開発効率、メンテナンス性や拡張性が上がることを期待した方が良い。
0129デフォルトの名無しさん
2007/02/12(月) 22:28:44具体的にどこが妄想で対応しているのか、
示せるかな？
それとも、ただの愚痴かな？
0130デフォルトの名無しさん
2007/02/12(月) 22:29:02過去の遺産が影響しているからだろう
0131デフォルトの名無しさん
2007/02/12(月) 22:29:19ttp://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
0132デフォルトの名無しさん
2007/02/12(月) 22:29:25だから過去の遺産がC++で作られており、
今さらJavaに以降するにはコストがかかるからだろう
0133デフォルトの名無しさん
2007/02/12(月) 22:32:07そうこうしているうちに、
Javaの最適化技術が驚くほど進化しているわけだが。
それじゃ
昔、オートマ車がでたとき、事故が頻発したので
30年経っても未だに恐くてオートマ車に買い換えることができずに
20年近く古臭いマニュアル車に乗ってるオッサンと同じだよ。
今じゃオートマどころか、ABSやエアバッグなど数々の安全装置や
カーナビなどがが付いていというのに未だに古いものに拘っている。
ふるいものにも良いものがあるとはいえ、乗り換えた方が効率がよくなるものはある。
0134デフォルトの名無しさん
2007/02/12(月) 22:32:52Eclipseの方が便利だけどな
0135デフォルトの名無しさん
2007/02/12(月) 22:36:34> でもほんとサーバでPHP/Perl/C#に負けるようになったらJavaは
> 衰退するんだろうな・・。いい言語だとは思うんだけどさ。
まず、PHP、PerlはJavaとは違い型に甘い言語である時点で、衰退
云々など関係がない。いくらPHPが人気があってもJavaには影響がない。
そもそも用途と志向と向き不向きが違うのだから。
というか、Perl6さっさと出せ、そしてPHPに名前空間付けろと言いたいところだね。
ついでにPerl6のParrotのように、言語非依存になるVMをPHPに搭載しないと
完全にJavaの代替言語にすることはできんな。
C#は、C++と同じ道を歩みそうで、Javaのようには流行らないだろうな。
C#の将来は、Windowsを開発しているマイクロソフト次第だな。
それにしても、お前の発想は、
「XMLが普及すればHTMLやSQLが衰退する！」
と言ってるのと同じレベルだ。
0136デフォルトの名無しさん
2007/02/12(月) 22:37:23スクリプト厨とか煽られたことがないか？
あの、型に甘い言語はデバッグがしづらいから
あまりにもキモイのだが。
それにBeginとかEndとかもきもい。
0137デフォルトの名無しさん
2007/02/12(月) 22:38:08RoRが面白いだけだ。
Java分野でもおんなじようなもんがあるがな。
Spring FrameworkとかSeasar2とか
0138デフォルトの名無しさん
2007/02/12(月) 22:39:08バージョンによるがな。
Eclipseは3.2になってから高速化した。
だが、使い方次第ではえらくのろまになる。
そこえNetBeansだ。PureJavaで書かれているのに速い。
0139デフォルトの名無しさん
2007/02/12(月) 22:41:30またJoel on Softwareの関係者か。
あれはM$信者だろ。ただの煽り。
C#が出た頃に、M$の関係者や信者が
「Javaはもう衰退する！ これからの時代はC#だ！ Javaなんて勉強しないでC#を勉強しろ！」
と煽っていたことを思い出す。
だが、あれから6年経ってもJavaはいっこうに衰退せず、C#もろくに普及しなかった。
その程度の煽りだろうね
0140デフォルトの名無しさん
2007/02/12(月) 22:42:26こんなスレで低能な言い争いを続けてる連中にそんな長文が
読めるわけだろ。そんなんじゃ燃料にならねぇよ、馬鹿。
0141デフォルトの名無しさん
2007/02/12(月) 22:43:19それほどスクリプト言語に思い入れがあるわけじゃないよ。
でも使い捨てのツール書くニーズなんかは誰にでもあるわけで。
0142デフォルトの名無しさん
2007/02/12(月) 22:43:46覚えなきゃいけないのかと思っているうちにどっかにいったな
0143デフォルトの名無しさん
2007/02/12(月) 22:45:05完全にとっては代わることはないだろうが、JavaがどんどんC#に
その役割と立場を喰われているのは事実だろう。
0144デフォルトの名無しさん
2007/02/12(月) 22:49:19どちらも暗黙のキャストするし、コンパイラが賢い型推論もってるわけでもない。
型による自動的なデバッグが好きならHaskellでもなんでも使って、アルゴリズムとかの
本質的なバグを注入してるといいよ。
0145デフォルトの名無しさん
2007/02/12(月) 22:49:38全くそんな気がしないんだけど。
なんかソースあるの？
0146デフォルトの名無しさん
2007/02/12(月) 22:54:43C#の案件をググれ。それら全てが、JavaがC#に喰われた分だ。
0147デフォルトの名無しさん
2007/02/12(月) 22:55:51仮にJavaが全てC#に置き換わったとしても、
Java屋は別に困らんのじゃないだろうか。
それほど移行コストがかかるとは思えん。
0148デフォルトの名無しさん
2007/02/12(月) 23:49:25まともに動いてたCOBOLのシステムを捨て去りJavaで書き直すも誤動作連発。
日本終了。
0149デフォルトの名無しさん
2007/02/13(火) 00:12:330150デフォルトの名無しさん
2007/02/13(火) 00:15:21データベースがネイティブに使えるんかな？
0151デフォルトの名無しさん
2007/02/13(火) 00:32:57スクリプト系は型が甘いっていうか
・変数に型が無い
・パース時に引数の型チェック出来ない
ってことだろ。暗黙のキャストの問題じゃない。
俺は個人的な小規模コードならよくRubyをよく使うが
大きいコードで使う気にはなれない。
Javaは変数も値も型を持つからな。
Java5の仕様変更から流石に個人的な用途でも使い始めたよ。
0152デフォルトの名無しさん
2007/02/13(火) 00:38:35型はあったのか・・・
0153デフォルトの名無しさん
2007/02/13(火) 00:40:09> >>139
> 完全にとっては代わることはないだろうが、JavaがどんどんC#に
> その役割と立場を喰われているのは事実だろう。
C#がまだベータ版だった頃(2001年)からそういう発言をしている某学生派遣会社の営業が
いたことを思い出すよ。
Javaが遅いからという理由で嫌いになりPHPとC#をしきりに勧めていた彼は今頃どうしているかな。
0154デフォルトの名無しさん
2007/02/13(火) 00:41:50つーかOOPLで型無し言語ってあるのか？
オブジェクトがクラス情報（かそれに近いシステム）持ってなきゃ
ポリモル出来ない気がするんだが。
0155デフォルトの名無しさん
2007/02/13(火) 00:47:54まずはなにをもって型があるとするかだろ。
まぁ、型の強弱はあっても全く型の無い言語なんてそれこそ少数派だろ。
0156デフォルトの名無しさん
2007/02/13(火) 01:02:520157デフォルトの名無しさん
2007/02/13(火) 01:11:58内部ではどう扱っていたんだかわからんが
0158デフォルトの名無しさん
2007/02/13(火) 01:22:16それは所謂、強い型付けってことでしょう。
Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。
まあ、そもそも型安全でないC/C++よりはマシですどね。
0159デフォルトの名無しさん
2007/02/13(火) 01:37:53アップキャストとダウンキャストの区別が㌧㌦
言語 基本クラスへの型変換失敗 派生クラスへの型変換失敗
スクリプト系 実行時検出 実行時検出
Java コンパイル時検出 実行時検出
C++ コンパイル時検出 プログラマ任せ
0160はっさく
2007/02/13(火) 01:57:290161デフォルトの名無しさん
2007/02/13(火) 02:09:160162デフォルトの名無しさん
2007/02/13(火) 02:15:44> Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。
全然違うだろ。↓がコンパイル通るなら一緒だがｗ
import javax.swing.*;
public class Test001 {
void myMethod(int i) {}
public static void main(args) {
"".getThreadGroup();
myMethod(new JButton());
}
}
ちなみに、変数に型の無い言語なら
int i なんて指定出来ないから何でも入る。
昔のVectorの状態を全ての変数や引数でやるワケだ。
0163デフォルトの名無しさん
2007/02/13(火) 02:29:24寝ぼけているのではなく、本気で言ってるのなら、基本から勉強しなおすと良いよ。
016472
2007/02/13(火) 02:33:21そりゃ、Javaアーキテクトは土方じゃないよ。
コーダーが土方っていってる。
うちは、主要なインターフェースを全部作っておいてあげて、
実装はコーダーさんに任せるってやり方をしてる。
実装にもノウハウは必要だけれど、
こういうやり方をしていると、新人もベテランも、
他の言語ほどあんまり差がつかないんだよね。
まぁ、Javaがよくできた言語だということだと思うけど。
多くのJavaのコーダーさんは、言われた通りにしかやらない人が多い。
言語に罪はないが、自主性のない人間を増やしている気がする。
0165デフォルトの名無しさん
2007/02/13(火) 02:41:57>Javaのアップキャスト検出は状況次第じゃないか
アップキャスト検出ではないが、Javaのダウンキャスト検出は状況次第だわ。
ダウンキャスト先が継承関係に無い場合はコンパイル時エラーだな。
俺も基礎からやり直すよorz
0166デフォルトの名無しさん
2007/02/13(火) 02:51:481秒に何百というオーダーがくる、金融系や、OpSなんかでは、
JavaのGCがかなりネックになってしまう。
GCの走るタイミングが読めないし、完了する時間もわからない。
Javaでメモリリークのおこらないシステムにするには、
プログラムの設計だけではだめで、ハードの増強や、
負荷分散の仕組みに金がかかってしまう。
通常の処理をしている分には、Javaは優れているけど、
リアルタイム性がないんだよね。。
0167デフォルトの名無しさん
2007/02/13(火) 03:05:490168デフォルトの名無しさん
2007/02/13(火) 03:11:16感じたが、現実は厳しかったなぁ。
0169デフォルトの名無しさん
2007/02/13(火) 03:27:19まあ段々とそう見なせる状況は広がって行くと思う。
0170デフォルトの名無しさん
2007/02/13(火) 03:56:22じゃぁ、GC用に一個、コアを予約しておくか。
0171デフォルトの名無しさん
2007/02/13(火) 04:21:12GCのない言語だとメモリリークを防ぐには、腕の立つプログラマと長い検証期間が必要だ。
そんなの信用ならん。
0172デフォルトの名無しさん
2007/02/13(火) 04:34:300173デフォルトの名無しさん
2007/02/13(火) 05:01:38パソコンショップで売ってるWindows用のソフト，例えば画像編集，デジカメ写真整理，年賀状作成，動画編集，シューティングゲーム，etc みたいな
ソフトは C++/MFC で組まれてるんじゃないの？
Windows 用のネイティブアプリをまともに作れる言語ってこれしかないような。
生 Win32 API だけで作るのは大変だし。
.NET Framework は相変わらずもっさりだし。
0174デフォルトの名無しさん
2007/02/13(火) 05:12:150175デフォルトの名無しさん
2007/02/13(火) 05:18:24ttp://www.tiobe.com/tiobe_index/index.htm
今後のトレンドを予想してみたい。
ttp://www.tiobe.com/tiobe_index/images/tpci_trends.png
0176デフォルトの名無しさん
2007/02/13(火) 05:25:40徹夜は効率悪いよ。
0177デフォルトの名無しさん
2007/02/13(火) 05:25:55つVB、Delphi、Macromedia Director
あと、MFCとか言い出すと標準C++じゃないから話がややこしくなってくる。
Windows環境はC++コミュニティからも冷めた目で観られてる。
0178デフォルトの名無しさん
2007/02/13(火) 06:40:570179デフォルトの名無しさん
2007/02/13(火) 06:47:10>デジカメ写真整理，年賀状作成，動画編集，シューティングゲーム，
>etc みたいなソフトは C++/MFC で組まれてるんじゃないの？
その通りだよ。そんな実態をすべて忘れてJava最高！といい続ける
妄想宗教スレなわけだ。
0180デフォルトの名無しさん
2007/02/13(火) 06:55:18> Delphi、Macromedia Director
!? !? !?
なあ、Delphiが生き残ってるって初めて聞いたんだが。
0181デフォルトの名無しさん
2007/02/13(火) 08:34:42アプリ系ってもう負け組じゃん。C++は負け組言語と言いたいわけですか。
0182デフォルトの名無しさん
2007/02/13(火) 08:50:04ﾌﾟ
0183デフォルトの名無しさん
2007/02/13(火) 10:24:32（前スレ）JavaやったらC++はきもく感じるとは直接関係ないけど
#include <～>
なんで拡張子hを消したんだろう。
中途半端なこと変えやがって
そのくせboostみたいに他の言語並みの使いやすさに
近づけてくれるものはなかなか標準にならない。
HTTP通信とかスレッドとか標準ライブラリや言語仕様にして
他のOSでも移植しやすいようにしろよ。
事実上よく使われるとかデファクトとかじゃなくて
標準装備になっていると大違い。
0184デフォルトの名無しさん
2007/02/13(火) 12:08:27> >>139
> 完全にとっては代わることはないだろうが、JavaがどんどんC#に
> その役割と立場を喰われているのは事実だろう。
そんなソース無いな。
そもそもライブラリの豊富さですでにJavaに劣っている。
0185デフォルトの名無しさん
2007/02/13(火) 12:10:04> 型の甘い言語って、JavaやC++もどっちもそんなに型に厳しいわけじゃないだろ。
お前みたいに大嘘ツク奴は(ry
> どちらも暗黙のキャストするし、コンパイラが賢い型推論もってるわけでもない。
暗黙のキャストといってもPerlやPHPなどのようなスクリプト言語ほど暗黙の
キャストをする言語ではないが。C++の場合はJavaよりもやたらと暗黙のキャストをするが。
それに、型推論持っていれば型に厳しくなるとは限らないのだが。
0186デフォルトの名無しさん
2007/02/13(火) 12:10:56そのときそのときに案件でしか判断できないとは痛々しいな。
C#の立場はクライアントサイドのみでしか発揮されないよ。
サーバサイドではどうみてもJavaやPHPには勝てない。
0187デフォルトの名無しさん
2007/02/13(火) 12:11:59デーベースと言えば、Javaも Java SE 6(Mustang)
からApache Derbyが標準搭載され、100%PureJavaデータベースが
Java SE 6に取り込まれた。
0188デフォルトの名無しさん
2007/02/13(火) 12:15:04JavaとJavaScriptとを勘違いしていないか？
それとも「明示的な型キャスト」をしてもキャストをできないケースがあるという
意味を勘違いしていないか？
Javaの明示的な型キャストは、プリミティブ型やスーパークラスからサブクラスへのキャスト(ナローイング変換)のときだけ。
暗黙の型キャストはその逆でスーパークラスへのアップキャスト(ワイデニング変換)だけ。
Genericsが出てから、余計な明示的ダウンキャストをしなくて良くなった
というものもあるが。
0189デフォルトの名無しさん
2007/02/13(火) 12:15:35PHP, Perl, JavaScriptなどなど
0190デフォルトの名無しさん
2007/02/13(火) 12:21:17それはオートボクシングのことか。
今でも別れているが。
C#やC++と違い、どんなことがあってもJavaのオブジェクトはすべて参照型。
プリミティブ型もすべて値型。
オートボクシングを使うときは、何かに代入するときに暗黙のうちにボクシングされるだけであって、
C#のように、その値型を持った変数がプリミティブラッパークラスのオブジェクトに変化する「可変」ではない。
そもそもJavaのプリミティブラッパークラスは「不変(イミュータブル)クラス」だ。
「不変」であるという点から、依然として型には厳しい。
値型と参照型両方をもつことができるC#のボクシング&アンボクシング変換とはまったく仕様が違う。
0191デフォルトの名無しさん
2007/02/13(火) 12:24:01> >>151
> Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。
なんか、トンデモ発言だな。
まともにJavaプログラミングしたことがあるのかと
0192デフォルトの名無しさん
2007/02/13(火) 12:26:21> >>85
> まぁ、Javaがよくできた言語だということだと思うけど。
> 多くのJavaのコーダーさんは、言われた通りにしかやらない人が多い。
> 言語に罪はないが、自主性のない人間を増やしている気がする。
Java質問スレで質問しまくってる厨房どもだろ。
大学でJavaの宿題やってる奴が多いから、そっからお前が見かけるような
厨房が産まれる。
しかしそれは真のJavaアーキテクトじゃないな。
Javaの氷山の一角だけを見ている奴がそうなる。
0193デフォルトの名無しさん
2007/02/13(火) 12:34:52> >>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++が速度面で勝っているのは今のところは、三角法の計算や数値演算くらいだ。
0194デフォルトの名無しさん
2007/02/13(火) 12:36:10まさにその通り、昔は人間がやっていたことを
今では簡単に機械が実行できる時代。
それを認めたくない香具師がたまにいるみたいだが。
0195デフォルトの名無しさん
2007/02/13(火) 12:39:26C#も忘れている。デスクトップではJavaより進んでいるとマイクロソフトの関係者は主張している。
VistaのようなOSを手がける彼らが自信を持って言わなくちゃならない当然の発言だろうけど。
JavaもSwingが強くなってくるから、今後、どうなるか解らないだろうねえ。
Linux方面もFedora Coreのデスクトップが徐々に進化してVistaに対抗して
右食ったと思われる派手な視覚効果も追加されている。
となると、クロスプラットフォームという強みを持つJavaも再び見逃せなくなる。
なにせ、Java Web Startがあるし
0196デフォルトの名無しさん
2007/02/13(火) 12:41:14C言語の人気は相変わらずだ。
RubyがRuby on Railsの影響で注目され始めていることがわかるが
結局Javaが圧倒している。
0197デフォルトの名無しさん
2007/02/13(火) 12:44:12だから、それは過去の遺産がC++で作られているから
Javaに移行するとスイッチングコストが高く付くから
C++のままで開発しているだけだよ。
JavaがC++よりも速くなるケースが出てきたのは
最近だし。Swingの高速化についてはまだまだ知られていないみたいだね。
JavaはファイルI/Oやメモリ管理速度がC++よりも速くなっているので
そろそろリプレースしてもいいころだろうけど、
Java SwingはGUIコンポーネントがWindowsに付属するものと
比べると劣るものが多いから移行を躊躇う企業が多いのだと思う。
それにVistaも出ているし
0198デフォルトの名無しさん
2007/02/13(火) 12:44:48C言語時代の名残だろ。伝統的と揶揄されるがシガラミでしかない
0199デフォルトの名無しさん
2007/02/13(火) 12:51:41あったとしてもほとんどない。
この分野はCおよびC++の独壇場でしょ？
多数人の手で大規模なシステム開発をやるならともかく、
一人または少数人で計算速度重視のプログラムを組む場合、
Javaなんて度外視されてるのが現状じゃない？
0200デフォルトの名無しさん
2007/02/13(火) 14:21:50> 聞きたいんだけど、Javaで数値計算のライブラリってあるの？
> あったとしてもほとんどない。
Jakarta Commons Math
> この分野はCおよびC++の独壇場でしょ？
そりゃCは20年くらい先行して現れた言語だからねえ。
> 多数人の手で大規模なシステム開発をやるならともかく、
> 一人または少数人で計算速度重視のプログラムを組む場合、
> Javaなんて度外視されてるのが現状じゃない？
10年前なら真っ先にそうだったね。
だが、もうそんな時代は終わってるよ。
JavaはC++よりもメモリの管理速度やファイル操作が速いので
C++よりも巨大なデータを扱うことに向いている。
0201デフォルトの名無しさん
2007/02/13(火) 15:16:140202デフォルトの名無しさん
2007/02/13(火) 15:21:52じゃあ携帯Javaももう天国になったんだな
うらやましいぜ
0203デフォルトの名無しさん
2007/02/13(火) 15:30:330204デフォルトの名無しさん
2007/02/13(火) 15:32:14C -> C++ の失敗に良く似ているね
こういうケースでは新言語作るべきなんだよ
0205デフォルトの名無しさん
2007/02/13(火) 15:49:28> JavaはC++よりもメモリの管理速度やファイル操作が速いので
JavaVMはC++で作られたアプリケーションだから、
C++より速いメモリ管理やファイル操作がC++によって実現されていることになる。
0206デフォルトの名無しさん
2007/02/13(火) 16:04:23メモリが少なすぎてまだまだ
0207デフォルトの名無しさん
2007/02/13(火) 16:17:01だったらさ、C++はなぜそこだけJavaより遅くなるのかな？
0208デフォルトの名無しさん
2007/02/13(火) 16:37:25実際に遅いかどうかは別として、こまめにメモリを確保・解放して
メモリの使用量を抑制するか、十分なメモリを確保したままにして
速度を重視するかでトレードオフの関係が成り立つから、
速度を犠牲にしてメモリの使用量を減らすことを優先することもできる。
JavaでもSUNが速度を重視する設計を選択しただけで、逆に速度を犠牲にして
メモリの使用量を抑制する実装もあり得る。
根本的なところだと、C++の速度とかJavaの速度というのは奇妙な表現で、
同じソースからコンパイルしたネイティブコード／クラスファイルでも、
コンパイラやライブラリ等の実装次第で実行速度はいくらでも変わってくる。
コンパイラやライブラリの実装の良し悪しと言語の良し悪しとは、別の問題。
0209デフォルトの名無しさん
2007/02/13(火) 16:44:54ではどうやってJavaより遅いそのC++でJVMを実装していると考えているのだろうか
0210デフォルトの名無しさん
2007/02/13(火) 17:50:53>JavaはC++よりもメモリの管理速度やファイル操作が速いので
とかぬかしてるだけな気がするんだが。
確かに C++ の処理系で実行時最適化できる実装はないし
標準のストリーム I/O は糞以下だが。
0211デフォルトの名無しさん
2007/02/13(火) 20:12:14javaの配列はどんな感じ？
1.1倍？
0212デフォルトの名無しさん
2007/02/13(火) 22:32:13>1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
>JavaのGCがかなりネックになってしまう。
>GCの走るタイミングが読めないし、完了する時間もわからない。
某UFJ銀行関連はJava使ってたような・・・。
あと、WebSphereとかの商用APサーバなんかは、そこそこの
チューナーがいればJavaだから遅いなんて思う事はまずないが。
金融系を語る奴に限って金融系の開発をしたことあるのか激しく疑問なんだが。
0213デフォルトの名無しさん
2007/02/13(火) 23:24:17言語はそれぞれ得意分野があるもんだ。
C/C++はハード側の関心事により最適化できるようになってるし、
Javaはよりユーザ側の関心事に最適化できるようになっている。
ハードの足かせのない世界を指向するJavaを、より「ソフトウェア」と
呼べる分、一プログラマとしてはJavaを支持する。
組み込みソフト業界も良く知ってるけど、やっぱりハード側の仕様に
振り回されるだけの便利屋的な存在になりさがってるしね。
Javaの「WriteOnece,RunAnywhere」の思想とその実現への姿勢は、
最近は余り取り上げられなくなったけど、やはり革命的だと思ってる。
「立てよ国民。我々にとって地球は狭過ぎた！」
0214デフォルトの名無しさん
2007/02/14(水) 00:36:10VB用に帳票印刷を手作りしたときには役に立った。
C++は言語としてはいまだに一番好きだけど、これだけでアプリケーションを組む
のは、化学実験室に連れて行かれて試薬でクッキー作れといわれるぐらい嫌。
0215デフォルトの名無しさん
2007/02/14(水) 00:37:41ときどきC言語は移植性が高いというのを見つけるけどさ
BASICなどに比べると方言が少ないとかぐらいでしょ。
処理系依存たっぷり
昔から進歩していない標準ライブラリ
そんなC言語と互換を持たせたC++
0216デフォルトの名無しさん
2007/02/14(水) 00:39:14>化学実験室に連れて行かれて試薬でクッキー作れといわれるぐらい嫌。
いや、それ面白そうじゃん？ ちょーやりてー
0217デフォルトの名無しさん
2007/02/14(水) 00:41:39ANSI C に準拠してるヤツはかなり互換性いいぞ。
てか、C++の互換性の無さにはウンザリ。
あれじゃ、標準規格があって無いようなもんだ。
0218デフォルトの名無しさん
2007/02/14(水) 00:44:40特にJavaの奴は誤差が頻繁に出るからクレーム付けたら「1円くらいどうでもいいだら」なんて言うし。
最低。
0219デフォルトの名無しさん
2007/02/14(水) 00:47:55それはお前のまわりだけだろ？
得意としてる言語に関わらず、そんなヤツには合ったことないぞ。
で、まわりにそんなヤツが多いってことは、お前もどうせその同類だろ。
0220デフォルトの名無しさん
2007/02/14(水) 00:49:280221デフォルトの名無しさん
2007/02/14(水) 00:51:27COBOLが最も得意とする分野なのですが。＞事務計算
0222デフォルトの名無しさん
2007/02/14(水) 00:56:48>>218がコボラだつったの。
俺はよく事務計算については知らないんだけど、COBOLは他の言語に対して
事務計算の分野においてどういうアドバンテージがあるのか教えてくれない？
0223デフォルトの名無しさん
2007/02/14(水) 01:00:40事務計算くらいしかできん。と言うならわからんでもないが。
0224デフォルトの名無しさん
2007/02/14(水) 01:04:07C の環境依存部分は、ほとんどの場合利用できる関数(とヘッダ)なので
環境依存部分をファイルに分離して Win/Mac/Unix 対応くらいならできる。
これが QB/VB/N88 に対応しろって言われたら頭抱えて途方にくれるよ。
そのくらい違う。
Java はそもそもどこでも動くはず。と言うか動くべき。
0225デフォルトの名無しさん
2007/02/14(水) 01:07:08>Java はそもそもどこでも動くはず。と言うか動くべき。
でも、動かない。プッ
0226デフォルトの名無しさん
2007/02/14(水) 01:11:26あらゆる環境で完璧に動くよ。
0227デフォルトの名無しさん
2007/02/14(水) 01:34:25０点。もう少し頭を使いましょう。
0228デフォルトの名無しさん
2007/02/14(水) 02:02:56だからC++プログラマの技術力が
ロボットの技術力に追いつかないということだよ。
わかりやすい例に喩えると、
ファクトリーオートメーションを導入している工場と
そうでない工場との違いだよ。
Javaというものは、人間が行えばミスがおかしいものを
ロボットに任せて自動化させたようなもの。
それによって効率が向上しているというものだ。
C++はBoostを使わないときは、人間がやらなくても
いいことをわざわざやろうとするからJavaの最適化技術に勝てず
ある分野ではJavaに最強の座を奪われている。
そこでBoostを導入しようとするけれども、言語仕様に
もとから欠陥がありシガラミがあるため限界がある。
それに、Boostは数十人の優秀な技術者を集めて作った
JavaコンパイラやJVMの技術力には勝てずにいるということも
大きな特徴。
ここでC++が再び、全ての分野でJavaより高速化できるかどうかは、
Boostのようなライブラリの強化にかかっていると思うね。
Javaも Java SE 6になってからソースコードが公開されGPL2.0になったから
今頃、Boost開発者は一生懸命Java SE 6のソースコードを解析して
最適化技術をリバースエンジニアリングしているところじゃないかな？
0229デフォルトの名無しさん
2007/02/14(水) 02:09:17> つか、>>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
0230デフォルトの名無しさん
2007/02/14(水) 02:14:19知ったか厨なんてこの程度だな。
>>229
中々面白い。
0231デフォルトの名無しさん
2007/02/14(水) 02:17:02Javaは配列自体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()を使うかなどで速度も変わってしまう。
0232デフォルトの名無しさん
2007/02/14(水) 02:20:11> >>166
> >1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
> >JavaのGCがかなりネックになってしまう。
> >GCの走るタイミングが読めないし、完了する時間もわからない。
> 某UFJ銀行関連はJava使ってたような・・・。
拡張子がdoになっているので、UFJダイレクトはフロントエンド付近に
Apache Strutsを使っているようだね。
というか銀行の「ダイレクト」系はどこもJavaばっかだね。
三井住友もイーバンクもそうだし。
証券会社もそう。楽天証券、イートレード証券なども。しかもローソク足表示にはJavaAppletを使ってる。
最近じゃ、YahooでもJavaを使っているところがある。
お金が絡むところは何かしらJavaが関与しているみたいだ。
0233デフォルトの名無しさん
2007/02/14(水) 02:22:25昔の言語とくらべると「できないことは無い」
というだけで「移植性が高い」と言っているだけだろうね。
Javaの移植性とはまた違う。今なら、Javaのほうが移植性が高く見える
ことは間違いないけど。
0234デフォルトの名無しさん
2007/02/14(水) 02:23:34> 数値計算というか事務計算をやらせようとするとC++厨もJava厨もろくでもない物しか作れない。
> 特にJavaの奴は誤差が頻繁に出るからクレーム付けたら「1円くらいどうでもいいだら」なんて言うし。
> 最低。
たまたまそいつがBigDecimalやBigIntegerの使い方知らなかっただけだろ。
はっきりいってそいつのスキルの問題だな。言語の問題じゃないな。
0235デフォルトの名無しさん
2007/02/14(水) 02:25:1910進数演算が得意なだけだろう。
日立のCOBOLerがJavaよりも優位な点は、
メソッドを使わず演算子だけでBihIntegerのようなクラスを
使うことができると主張していたな。
たかがそれだけがJavaに対するアドバンテージかよと思った。
過去の遺産が残っているから仕方が無くCOBOLを使ってるだけってのが
殆どだろうがな
0236デフォルトの名無しさん
2007/02/14(水) 02:26:55よほど、Sunに知られていないOSや、Java SEやJavaMEが入らない
リソースが小さい古臭いOSじゃない限りそういうことはないだろう。
0237デフォルトの名無しさん
2007/02/14(水) 02:27:36知ったか厨？
言っておくが、>>228と>>229は両方とも俺が書いたんだが。
0238デフォルトの名無しさん
2007/02/14(水) 02:29:020239デフォルトの名無しさん
2007/02/14(水) 02:34:24>229 の引用先の内容まで君が書いたわけじゃないんだろう?
0240デフォルトの名無しさん
2007/02/14(水) 02:37:03だから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
0241デフォルトの名無しさん
2007/02/14(水) 02:39:280242デフォルトの名無しさん
2007/02/14(水) 02:41:55いやだから、>239 で引用されている内容は中々面白いとおもうが、
>238 は全然そうではない。それだけの話。
0243デフォルトの名無しさん
2007/02/14(水) 02:42:55×>238、 >239
○>228、 >229
0244デフォルトの名無しさん
2007/02/14(水) 03:13:08wikipediaが閉鎖の危機になったというニュースを聞きつけて
ニュー速に集まってそういう勘違いをする厨とは違うよ。
Wikipediaに使われているものはWikiだから即座に編集可能だから
ぱっと見ただけでは信用できないという話だけだね。
Wikipediaの仕組みは管理者がコントロールをしているので
だいたいわかってる。管理者にDQNなやつもいるみたいだけどさ。
日本語版Wikipediaは創始者が腐女子みたいな馬鹿女で感情的になりやすく人の話を
ろくに聞かないヤバイ奴だってってことも知ってる。
>>242
そりゃWikipediaにも載っていないことも書いているが。
Javaの歯車製造機械はC++が製造した歯車を動力の一部に動いているが
それがJavaを動かす上で特に問題だと言うことは無い、という意味に喩えればわかるかな？
住んでいる土地が違うだけだよ。
0245デフォルトの名無しさん
2007/02/14(水) 03:46:20>日本語版Wikipediaは創始者が腐女子みたいな馬鹿女で感情的になりやすく人の話を
>ろくに聞かないヤバイ奴だってってことも知ってる。
（・∀・）
なるほど、つまりそいつに追い出されたのか。m9（^Д^）ﾌﾟｷﾞｬー
0246デフォルトの名無しさん
2007/02/14(水) 03:49:59追い出されてないがw
だが、奴が日本版Wikipediaの印象を悪くしているのは確かだ。
0247デフォルトの名無しさん
2007/02/14(水) 06:06:370248デフォルトの名無しさん
2007/02/14(水) 06:15:20Strutsとか使ってる部分は、金融系のプログラムっていうのとは違うでしょうが。。
>>193
プロファイラってOptimizeitとかだね。
SoftReferenceを使うのは当然だけれども。
8way CPU とか何台も買ってくれるような顧客はなかなかいないし、
リアルタイム性を確保するのは結構大変だよ。
最近はJavaでもいけるかな、って案件も増えてきたけど。
いい方向に進んでいるとは思う。
0249デフォルトの名無しさん
2007/02/14(水) 07:32:27周辺に結論も書いてあるというのに
0250デフォルトの名無しさん
2007/02/14(水) 11:56:12> プロファイラってOptimizeitとかだね。
Java標準のでもいけるけど。
Eclipseのでもいけるし。
> SoftReferenceを使うのは当然だけれども。
> 8way CPU とか何台も買ってくれるような顧客はなかなかいないし、
プロファイラやSoftReferenceと8way CPUとは直接関係ないと思うんだけど。
> リアルタイム性を確保するのは結構大変だよ。
組み込みじゃないのにリアルタイムに拘ってどうするのだろう。
マルチスレッドじゃ不満？
0251デフォルトの名無しさん
2007/02/14(水) 12:39:100252デフォルトの名無しさん
2007/02/14(水) 13:42:56マニピュレータでも使うのか？
スレッドだけで解決できないのかね？
0253デフォルトの名無しさん
2007/02/14(水) 16:27:21>最適化技術をリバースエンジニアリングしているところじゃないかな？
ﾜﾗﾀ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
0254デフォルトの名無しさん
2007/02/14(水) 16:45:08勿論最適化されやすいコードを書くような努力はしているだろうけど。
それとも今度のBoostにはGCがやっているのか。
0255デフォルトの名無しさん
2007/02/14(水) 16:51:06> 今頃、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節や例外基底クラスが
ないことが致命的な欠陥となっていることが実に香ばしいねえ。
0256デフォルトの名無しさん
2007/02/14(水) 16:54:14for(int i = 0; i < 10000; i++){
try{
//何か
} catch (Exception e){
//何か
}
}
よりも
try{
for(int i = 0; i < 10000; i++){
//何か
}
} catch (Exception e){
//何か
}
の方が速いから書き直せとファビョるタイプなんだろうなあ。
今じゃ最適化が進んでどちらのコードでも速度はさほど変わらないのにねえ。
0257デフォルトの名無しさん
2007/02/14(水) 17:07:00l|, ､ ､ |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
0258デフォルトの名無しさん
2007/02/14(水) 17:07:16int 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にやらせると
面白い結果も現れるんだけどねえ。
0259デフォルトの名無しさん
2007/02/14(水) 17:08:060260デフォルトの名無しさん
2007/02/14(水) 17:27:53ショウサイ・キボンティーヌ
0261デフォルトの名無しさん
2007/02/14(水) 17:34:01同じJava信奉者でもマ板のおじゃばさまに遙かに劣る
0262デフォルトの名無しさん
2007/02/14(水) 18:27:39いやいやそんなことはない。
そもそもC++で書けば桁が違う、論外だと思っているのがC++厨
0263デフォルトの名無しさん
2007/02/14(水) 18:51:59だから藻前は金融系の仕事をしたことあるのか？と小一時間。
漏れは一応あるんだが、藻前の言う病的なリアルタイム性なんか
逆に要求されないんだが。
やたら無駄にクラスタはしてる印象ある。まあ万が一を怖がるから当然だが。
藻前の知っている金融機関はどこかの農協なんだろうけど、
都銀くらいで仕事してから語ってくれ。
藻前こそJavaとC++を適材適所で使うことを覚えた方がいい。
0264デフォルトの名無しさん
2007/02/14(水) 19:02:05走るトランザクション数多いけど、Javaや言語がどーこーよりも
RDBの性能の方が影響でかいから、「Javaだと不安」ってのは
仕事したことあるのか？と疑われても当然だ罠
設計をしたことない底辺プログラマーにありがちな妄想と言われるのがオチ。
0265デフォルトの名無しさん
2007/02/14(水) 19:06:00なんか最近のC++は関数型に近くなってるよね
0266デフォルトの名無しさん
2007/02/14(水) 19:09:180267デフォルトの名無しさん
2007/02/14(水) 19:41:140268デフォルトの名無しさん
2007/02/14(水) 19:54:30多少は早くならんか
0269デフォルトの名無しさん
2007/02/14(水) 20:04:22プログラマが選べるようにして、コンピュータが速くなってきたからJavaでは
GCを再び採用したみたいな感じなんだけどね・・
今後、コンピュータが速くなっても速度差の比は変わらないわけだけど、
でも、"C++>Java>要求仕様A"に該当するならどちらでも好きな方を
(開発しやすい方ならJavaでしょうかね・・)使えばいいし、
"C++>要求仕様B>Java"ならC/C++を使うしかないことになるんだよね。
たぶんJavaﾏﾝｾｰの人は"要求仕様B"が存在しないと思ってるんだろうけど、
やっぱあるんだよねえ、残念ながら・・
俺ゲームやってるけど、やっぱ無理としか言えない。Java3Dでできれば
楽でいいなあとか思うけどやっぱ無理かな。10年後は知らないけど。
やっとアセンブラ/CからC++に移行してるような感じだからね。
でも確実に差は埋まってるし、コンピュータの速度が上がってきてるから、
"要求仕様A"の数は増えてきるんじゃない?Webアプリなんかそうだろうし。
ただ、ゲームに限らないけど、何かを作るときには、最初に言語を決めなきゃ
いけないわけで、その時に最終的にできるものはなるべく速くて省メモリがいい
という要求はよくある話で、つまり無限に速ければ速いほどいいという要求の
場合はやっぱり要求仕様Bってことになっちゃうんだよなあ。
0270デフォルトの名無しさん
2007/02/14(水) 20:16:08今でも映像・音声の圧縮はアセンブリ言語が当たり前（少なくとも俺が使う範囲では）。
ただし、それに対するフロントエンドはリンカでくっつけられるので自然とC/C++になるけど。
0271デフォルトの名無しさん
2007/02/14(水) 20:31:26速度を要するところでは低級言語で、という教科書に書いてる
ような結論になるわけだ。さすが教科書。
>本当に速いものが欲しければアセンブリ言語。
さらに望むなら専用チップに焼き込みだ!でしょうか・・?
0272デフォルトの名無しさん
2007/02/14(水) 22:06:560273デフォルトの名無しさん
2007/02/14(水) 22:14:51C++をキモく感じる感情自体も事実だろ。
このスレはどっちが優れているか？ではなくて、
キモく感じるかどうか？が趣旨だしな
0274デフォルトの名無しさん
2007/02/14(水) 22:22:440275デフォルトの名無しさん
2007/02/14(水) 22:25:48そういう話はC++煽り厨から耳にタコができるくらい聞いたから飽きた
もういい。数値演算だけは速いんだからC++でゲームでも作っていればいい。
0276デフォルトの名無しさん
2007/02/14(水) 22:26:530277デフォルトの名無しさん
2007/02/14(水) 22:28:04有害かどうか、って言うのはどうやって決めるよ？
0278デフォルトの名無しさん
2007/02/14(水) 22:28:07今なら、HDLもJavaで書く時代だw
BYU JHDL, Open Source FPGA CAD Tools
http://www.jhdl.org/
Java-HDLだからな。
SystemCもVerilogもいらんw
0279デフォルトの名無しさん
2007/02/14(水) 22:28:36感情よりも実用性、効率性を考えるとC++の用途は
限られてくる。
0280デフォルトの名無しさん
2007/02/14(水) 22:34:43>キモく感じるかどうか？が趣旨だしな
おぉそうだったな、そりゃ森三中とモリマンどっちが優れてる？と
変わらないくらいばかばかしい比較だからな。
俺はC++はキモかわいくて、Javaはパンチが足りない美形みたいなイメージだな。
もしくは萌え熟女と白肌美少女かな。
0281デフォルトの名無しさん
2007/02/14(水) 22:38:14C++不要論は別スレ立ててやればいんじゃね
0282デフォルトの名無しさん
2007/02/14(水) 23:09:380283デフォルトの名無しさん
2007/02/14(水) 23:15:30C++作ったBjarneがとにかく早く導入したかったから=0にしたとD&Eに書いている。
0284デフォルトの名無しさん
2007/02/14(水) 23:21:500285デフォルトの名無しさん
2007/02/14(水) 23:46:37それってJavaでHDLを書けるっていうだけで
JavaそのものがHDLになる訳じゃないじゃん？
0286デフォルトの名無しさん
2007/02/14(水) 23:55:370287デフォルトの名無しさん
2007/02/15(木) 00:01:130288デフォルトの名無しさん
2007/02/15(木) 00:36:210289デフォルトの名無しさん
2007/02/15(木) 01:24:15C++厨は腐女子かw
0290デフォルトの名無しさん
2007/02/15(木) 01:29:18だがそれも重大な進歩である。
ここから家電Javaへの道が拓かれる
0291デフォルトの名無しさん
2007/02/15(木) 02:21:52高レベル処理ならスクリプトやJavaになるなぁ。
C++って選択肢は選びたいと思わない。
0292デフォルトの名無しさん
2007/02/15(木) 02:27:080293デフォルトの名無しさん
2007/02/15(木) 02:50:220294デフォルトの名無しさん
2007/02/15(木) 02:53:590295デフォルトの名無しさん
2007/02/15(木) 02:54:180296デフォルトの名無しさん
2007/02/15(木) 02:54:370297デフォルトの名無しさん
2007/02/15(木) 02:58:310298デフォルトの名無しさん
2007/02/15(木) 04:10:590299デフォルトの名無しさん
2007/02/15(木) 04:38:27なんのためのVMなんだよ・・・
0300デフォルトの名無しさん
2007/02/15(木) 10:09:320301デフォルトの名無しさん
2007/02/15(木) 12:04:24http://hp.vector.co.jp/authors/VA000092/jokes/strup.html
0302デフォルトの名無しさん
2007/02/15(木) 12:13:180303デフォルトの名無しさん
2007/02/15(木) 14:40:18前スレで既出
0304デフォルトの名無しさん
2007/02/15(木) 15:49:25>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
0305デフォルトの名無しさん
2007/02/15(木) 15:58:37ちょwww おまっwwwwwwww まじかっwwwwwwwwwwwwwwwwwwwwwwwwwww
それ、途中で例外でたら処理の流れ違うからwwwwwwwwwwwwwwwwwwwwww
ネタ? ネタなんだろ? ｷﾓJava厨的にはこんなん当たり前?
>ファビョるタイプなんだろうなあ。
抱腹絶倒wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
アルバイトに一通りソースチェックしてもらっちゃうよwwwwwwwwwwwwww
0306デフォルトの名無しさん
2007/02/15(木) 18:58:150307デフォルトの名無しさん
2007/02/15(木) 19:01:27Java使いはもぐりだろ。
0308デフォルトの名無しさん
2007/02/15(木) 20:02:29ほとんど自演だから
0309デフォルトの名無しさん
2007/02/15(木) 22:13:320310デフォルトの名無しさん
2007/02/15(木) 23:51:33俺たちにはニューラルネットワークがあるかｒGCはいらない。
だがC++脳にはGCが必要だ。
0311デフォルトの名無しさん
2007/02/15(木) 23:56:22{
Data x;
} <- 確実にデストラクタが呼ばれるから。
disposeについてよく知らんが
あることを楽にするため別の厄介なことが生まれたように感じる。
0312デフォルトの名無しさん
2007/02/15(木) 23:58:29> >>256
> ちょwww おまっwwwwwwww まじかっwwwwwwwwwwwwwwwwwwwwwwwwwww
> それ、途中で例外でたら処理の流れ違うからwwwwwwwwwwwwwwwwwwwwww
> ネタ? ネタなんだろ? ｷﾓJava厨的にはこんなん当たり前?
> >ファビョるタイプなんだろうなあ。
> 抱腹絶倒wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
> アルバイトに一通りソースチェックしてもらっちゃうよwwwwwwwwwwwwww
「ちょwwwおまっっwwww」とはこっちが言いたいんだが。
今のJavaCの最適化能力を甘く見ているだろう。
二者のコードのパフォーマンスには当然ながら若干差はあるが、
Java SE5, Java 6から劇的な変化が起きているぞ。
どちらのコードもほぼ変わらない。
現在のJavaコンパイラはその程度、自動的に最適化してくれるように
なっていることを知らないとはC++厨は実に香ばしいな。
試しに古いJavaコンパイラ + JVMと新しいJavaコンパイラ + JVMを使って
パフォーマンスの変化を比較してみると良い。
俺も初めて知ったときは驚いたが、ループ内にtry-catch構文を入れても
その逆の配置にしてもパフォーマンスは大して変わらない事がわかった。
それがJavaの恐ろしさというやつよ。
0313デフォルトの名無しさん
2007/02/16(金) 00:05:58クラス名と同じって言うのは変な感じがする。
デストラクタが~をつけたっていうのはもっと変な感じがする。
テキストエディタのダブルクリックじゃ~は選択されない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; ← コンパイルエラー
以下略
};
0314デフォルトの名無しさん
2007/02/16(金) 00:09:35class xxx : public base
{
static const int b = 5;
以下略
};
というのができるようになったらしいが
常に最新のC++が使えるわけじゃない。
0315デフォルトの名無しさん
2007/02/16(金) 00:20:08確かに恐ろしい最適化能力だな。人間を超えている。
0316デフォルトの名無しさん
2007/02/16(金) 00:21:22横からC#厨が失礼だけど、>>305の言いたいのはパフォーマンスの話じゃないと思うんだ。
>>256の上の例は例外が発生したとき、forループを抜けずにcatchブロックで処理をしてインクリメント。
しかし、下の例は例外が発生した瞬間にforループを抜け、catchブロックで処理をする。
この処理自体の違いに突っ込んでるんじゃないかと。
0317デフォルトの名無しさん
2007/02/16(金) 00:30:130318デフォルトの名無しさん
2007/02/16(金) 00:32:55例外処理も最適化（自分の思った形にロジック変更）されるらしいと
思い込んでるんで勘弁してやってください
0319デフォルトの名無しさん
2007/02/16(金) 00:34:460320デフォルトの名無しさん
2007/02/16(金) 00:35:45> >>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()を間違った方法でオーバーライドしてパフォーマンスを劣化させるだろう事が想像つく。
0321デフォルトの名無しさん
2007/02/16(金) 00:35:57close()の間違いじゃなかろうな
0322デフォルトの名無しさん
2007/02/16(金) 00:37:27こいつが言ってるdispose()はclose()のことだろう。
ファイルI/OやDBなどのセッションクローズのことを
言いたいだけだろう。
デストラクタとfinallyどっちがマシだ、といったらfinallyのほうが
ましな構造をしているのだが、C++厨は認めたくないらしい。
0323デフォルトの名無しさん
2007/02/16(金) 00:39:23http://mag.autumn.org/Content.modf?id=20050506145337
0324デフォルトの名無しさん
2007/02/16(金) 00:40:39> >>312
> 横からC#厨が失礼だけど、>>305の言いたいのはパフォーマンスの話じゃないと思うんだ。
> >>256の上の例は例外が発生したとき、forループを抜けずにcatchブロックで処理をしてインクリメント。
> しかし、下の例は例外が発生した瞬間にforループを抜け、catchブロックで処理をする。
> この処理自体の違いに突っ込んでるんじゃないかと。
それも最適化されるんだよ。やってみ。C#ではどうなるのか知らんが。Javaでは
速度差は大して変わらなくなる。
>>318
ああ思い込んでいるとも。実際その通りになるんだからな。
0325デフォルトの名無しさん
2007/02/16(金) 00:41:00インクリメントしてくれなくても構わん場合がほとんどな気がするが。
仮にファイルのIOで一回目で例外発生したなら残り9999回も例外でるだろうし。
0326デフォルトの名無しさん
2007/02/16(金) 00:44:49Javaの最適化技術を甘く見ていると恥をかくので注意すること。
http://www.sgnet.co.jp/java/chapter0503.html
0327デフォルトの名無しさん
2007/02/16(金) 00:46:190328デフォルトの名無しさん
2007/02/16(金) 00:46:26ビーデーのメガネデブ川俣 晶かよw
その日記に自らJavaが嫌いになったJavaコミュニティが嫌いになったと
書いてる奴だろw ユニシスの某馬鹿社員と気が合いそうな奴で笑える。
0329デフォルトの名無しさん
2007/02/16(金) 00:50:49ソースきぼ
0330デフォルトの名無しさん
2007/02/16(金) 00:52:34こんなソース書いてる奴は作法がなっとらんわ。
0331デフォルトの名無しさん
2007/02/16(金) 00:59:43ヒープの解放の自動化は自慢するのに、
それ以外の資源については手作業でごりごり書くしかない。
それが「まし」だと思い込まされてることに気づかない。
0332デフォルトの名無しさん
2007/02/16(金) 01:02:13あいにくだがfinallyを引き合いにした話じゃないし
前レスのtryの話の続きじゃない
0333デフォルトの名無しさん
2007/02/16(金) 01:02:39>>256のパフォーマンスがさして変わらない理由は、
Java One Tokyo 2005のセッション
「Java Performance Myths Exposed」を聞いた者だけがわかる。
いま資料が無いかググっているところ
0334デフォルトの名無しさん
2007/02/16(金) 01:04:400335デフォルトの名無しさん
2007/02/16(金) 01:04:41それが一般化してるならまだしも、
知ってる奴が限定されてんなら
思いっきり性能改善対象になるだろ。
知らない奴が多数なんだから。
つか、資料よろ
0336311
2007/02/16(金) 01:09:16finallyはfinallyでC++にあっても便利だと思うし、
C++のデストラクタのような即効性があって
Close書き忘れを実行時に発見できるもの便利だと思う。
{
Data * x; ポインタだと自動じゃ呼ばれないけどね。
}
0338デフォルトの名無しさん
2007/02/16(金) 01:12:41見つけた。
http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-3268.pdf
若干コードが異なるが、
新しいOSとJVMではfor文無いでtry-catchをつけようがつけまいが、
さしてパフォーマンスは変わらないことがよくわかる。
古いOSだと恐ろしいほど差が出ている。
>>334
所要時間は？
0339デフォルトの名無しさん
2007/02/16(金) 01:14:58for文無いでtry-catchを書いてぬるぽを発生させた場合での
パフォーマンスもあるので、>>256の言ってることは正しい可能性が高い。
0340デフォルトの名無しさん
2007/02/16(金) 01:15:52C++0xではコンストラクタからメンバ初期化子構文で別のコンストラクタを呼べるようになるという噂。
>>314
そこでenumハック
ところで313-314も256と同じくらいアレだと思うんだ。
0341デフォルトの名無しさん
2007/02/16(金) 01:16:18会員登録していればHTMLでも見ることができるらしい。
http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-3268.html
0342デフォルトの名無しさん
2007/02/16(金) 01:20:22意味合い(というかムード)がぜんぜん違うと思うんだが。
前者は逐次処理毎に例外を扱い、後者は一連のひとまとめの中で例外を扱う、みたいな。
ひとくくりにされて同じだと言われると、算法的になんとも気持ちの悪い感じを受けてしまう。
0343デフォルトの名無しさん
2007/02/16(金) 01:21:20（どっちの構文が優れているかはともかくとして）
例外の発生するしないに関わらず実行されることには違いないだろ。
0344デフォルトの名無しさん
2007/02/16(金) 01:24:05C++0xが早くできねーかな。
Javaにいいところ取られっぱなしだよ。
そうそうenumだよね。実はよく使っている。
Javaとは違い細かいことうるさくないのが逆にC/C++のいいところでもあるけど
なんだかなー
0345デフォルトの名無しさん
2007/02/16(金) 01:26:07デストラクタは X::~X() { close(); } を一度書くだけ。
0346デフォルトの名無しさん
2007/02/16(金) 01:29:230347デフォルトの名無しさん
2007/02/16(金) 01:29:27X::~X() { if(!isClosed) throw "おまえcloseし忘れてないか"; }
みたいな機能Javaにあるの？
0348デフォルトの名無しさん
2007/02/16(金) 01:31:030349デフォルトの名無しさん
2007/02/16(金) 01:33:01それcatchの中でやればよくね？
0350デフォルトの名無しさん
2007/02/16(金) 01:36:24for文の中に例外処理が入ってるってのを
感覚的に気持ち悪いって思える方が信頼できる。
「最適化できますから」と力説されても気持ち悪いもんは気持ち悪い。
0351デフォルトの名無しさん
2007/02/16(金) 01:37:35C/C++だと何かメンドクセーgoto使っちゃえの世界だな。
goto減らす代わりにフラグとifが増やすのってめくそはなくそに思うんよ。
めくその方がちょっとましかもしれないけどさ。
0352デフォルトの名無しさん
2007/02/16(金) 01:38:44外のクラスのメンバにアクセスできるのと出来ないのがあるんだってね。
面白そうだね。
C++はできないタイプのほうしかない。
0353デフォルトの名無しさん
2007/02/16(金) 01:40:38これの、そういえばって、
>>346
関数の中に関数を書けたら
そういうニーズに対応できるね
ってレスしようとしてやめた。
0354デフォルトの名無しさん
2007/02/16(金) 01:45:22複数の catch に同じ開放コードを書くのはうんざり
0355デフォルトの名無しさん
2007/02/16(金) 01:47:00具体的に、どんな構文だったらマシになるかな？
0356デフォルトの名無しさん
2007/02/16(金) 01:50:54http://www.kmonos.net/alang/d/exception-safe.html
0357デフォルトの名無しさん
2007/02/16(金) 01:54:590358デフォルトの名無しさん
2007/02/16(金) 01:56:08俺C++しかしらないけど、一応こういう書き方ができる（誰もやらないが）。
Javaでも似たような書き方ができないか？
try {
try {
//...
} catch (...) { //全ての例外を捕捉
//... 共通の後処理
throw;
}
} catch(const MyException& e) {
//...
} catch(const std::exception& e) {
//...
}
0359デフォルトの名無しさん
2007/02/16(金) 01:58:02try {
} catch {
} catch {
・
・
・
} commoncatch {
} finally {
}
commoncatch はどれかの catch を通ったらcatch処理後、finally実行前に実行される。
catch されないときは実行されない。素人考えかな？
0360デフォルトの名無しさん
2007/02/16(金) 02:03:23それだったら、switchみたいにcatchをbreakで抜けるようにすればよくね？
0361デフォルトの名無しさん
2007/02/16(金) 02:04:47まんま同じように書けるよ。
0362デフォルトの名無しさん
2007/02/16(金) 04:59:53それなら、Apache Jakarta Commons DBUtilsや
Apache Jakarta Commons IOを
使えばJavaでもfinallyを書かなくて済むようになると言えてしまうぞ。
ついでにDBの場合、Hibernateを使えば
さらに開発が楽になりfinallyだろうがデストラクタだろうが
煩わしいものが無くなる。
0363デフォルトの名無しさん
2007/02/16(金) 05:02:02catch節抜きで
try {
//例外が発生する可能性があるコード。
} finally {
//try節にreturn文やbreak,continueが無ければ必ず実行される。
}
こうやればあなたの夢は叶います。
0364デフォルトの名無しさん
2007/02/16(金) 05:04:26そもそもclose()する必要がないオブジェクトに対しては
そんなものがいらないのでデストラクタなんぞ不要。
0365デフォルトの名無しさん
2007/02/16(金) 05:12:46Connection#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){
・
・
}
・
・
}
0366デフォルトの名無しさん
2007/02/16(金) 05:13:28それもそうだ。外側に置いた方が、古いOSやJVMでも
パフォーマンスを改善できるのだからな。
0367デフォルトの名無しさん
2007/02/16(金) 05:18:17そこでJakartaなどのプロジェクト が様々な解決方法を提供しているわけだが。
Java5から登場したアノテーションを使うという手もあるだろう。
次世代Javaから登場する予定のクロージャに期待せよ。
0368デフォルトの名無しさん
2007/02/16(金) 05:26:10Javaなら、そういうこと>>365のようにfinallyでやる。
>>355-356
面倒くさければまとめて
catch(Exception e)
だけで補足するという手がある。
ただしこれだと、開発やデバッグに支障を来すぞ。
こういう問題は、EclipseなどのIDEで自動化すれば済むこと。
Eclipseでは、try-catchで過去みたいあるコード領域をマウスでドラッグして
「try-catchで囲む」を実行すると、どの例外をthrowsするのか
メソッドから、調べて、catchすべき例外をリストアップしてくれるぞ。
さらにコードテンプレートでcatch節に書く内容も定めることができる。
>>359
throwsで外部に任せるという手もある。だがそれは例外機構の原理と設計を理解してから。
0369デフォルトの名無しさん
2007/02/16(金) 05:42:53C++とBoostの関係と似たような物なのだろうか。
0370デフォルトの名無しさん
2007/02/16(金) 08:20:04Java+Eclipse+Jakarta=ｽｹﾞｰ
ってことなんだな。
もうエディタにコンパイラが内蔵してあるようなものでしょ。
俺がメインに使うC+++VisualStudio2005は
徐々に機能アップしているけど
C++のコード生成自動化はJavaやC#に比べると限界が近いな。
0371デフォルトの名無しさん
2007/02/16(金) 08:23:02最近のgoogleはC++で検索できるようになってるみたいだけど。
アルファベット1文字と+記号
0372デフォルトの名無しさん
2007/02/16(金) 09:53:43何が言いたいの？
0373デフォルトの名無しさん
2007/02/16(金) 12:43:05Boostと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にせずデザインパターンを巧みに使用して
汎用性と拡張性を高めている。
0374デフォルトの名無しさん
2007/02/16(金) 13:24:50なんでWindows叩きをしてるの？
0375デフォルトの名無しさん
2007/02/16(金) 13:34:12主にWindowsだからじゃね？
0376デフォルトの名無しさん
2007/02/16(金) 13:57:170377デフォルトの名無しさん
2007/02/16(金) 14:00:12>C++標準APIが低レベルＡＰＩを提供しており
>標準APIに不足している高レベルな部分をBoostが提供しているということ。
こう置き換えても余り変わらない希ガス。
確かに、Java標準ライブラリはスレッドからGUIまで、C++標準に無い部分まで手広く抑えてるけど。
0378デフォルトの名無しさん
2007/02/16(金) 14:17:30低レベルAPIのはずなのに分離している。
0379デフォルトの名無しさん
2007/02/16(金) 14:25:340380デフォルトの名無しさん
2007/02/16(金) 14:33:41>>312 >>324 こいつwww ヤバイwwwwwwwwwwwwwwwwwwww
こんなに面白そうなｵﾓﾁｬ釣り上げたのに意外とレスつかないね。
やっぱム板は冷静な人多いね。
むしろ自分が初心者いじめてるイジメッコにしか見えんw
まじで初心者ならごめんなさいね、あなたのためにちゃんとレスしてる人もいるので
その人たちの善意を無駄にしないようにねw
追伸
十年ロムってろw
0381デフォルトの名無しさん
2007/02/16(金) 14:41:170382デフォルトの名無しさん
2007/02/16(金) 15:15:18>>381 ワリーw VIPPERごっこあきたからもうやめるわ、初心者しかつれねーしw
C++にはfinallyいらねって書いてるけど、めんどくせーからfinally使わせろよって
思うときは結構あるんだよね。
C++はあれだけゴチャマゼとか言われてるのにfinallyがないのが結構不思議なんだよな。
例外は直接関係ないけどC#にはDisposeとusingでC++風デストラクタの呼び出しできて
(Disposeだけどな)結構便利かな、いちいちusing書かせんなよって思うけど。
この辺はJavaよりあとに出ただけあって微妙にいいよな。
>いずれにしても次世代Javaではクロージャの導入が検討されている。
最近はjavaから離れてるし実際に業務で使用できないのはいちいちチェックしないから
よく知らないけど、これなに?ってここで聞いていい?
引用は>>320からだけど>>320以外に答えてほしいw
追伸
>>320 十年ロムってろw
0383デフォルトの名無しさん
2007/02/16(金) 15:32:18http://www-06.ibm.com/jp/developerworks/linux/010706/j_l-prog2.html
だけど、>>320が分からん。
関数が環境付きで持ち運びできることと、例外発生時に後処理が確実に呼ばれるようにすることの関連が良く分からん。
だれか教えて。
0384デフォルトの名無しさん
2007/02/16(金) 15:39:420385デフォルトの名無しさん
2007/02/16(金) 15:40:310386デフォルトの名無しさん
2007/02/16(金) 15:41:25おお、なんとかわいそうなお人。
0387デフォルトの名無しさん
2007/02/16(金) 15:43:28俺は期待してるぞ。
0388382
2007/02/16(金) 15:58:11>>383
わざわざありがとー
デストラクタ・例外のあたりはもういいかな、
以下はクロージャと >>832 へのネタ振りよろしくーw
0389デフォルトの名無しさん
2007/02/16(金) 16:39:33C++の言語仕様って、それを外すとろくな代替がないことが多いんだ。
そういう意味では無駄がないと言えなくもない。
finallyはデストラクタがあるから要らないと考えれば納得できないか？
0390デフォルトの名無しさん
2007/02/16(金) 17:31:29> ちょっwww
> >>312 >>324 こいつwww ヤバイwwwwwwwwwwwwwwwwwwww
> こんなに面白そうなｵﾓﾁｬ釣り上げたのに意外とレスつかないね。
> やっぱム板は冷静な人多いね。
お前が冷静じゃないだけだろ。
C++厨は相変わらず絶対に自分の間違いを認めないんだなw
何もかも全て自分の都合の良いようにしか考えることができない惨めなC++厨。
あとのお前のレスはすべて言い訳だな。
それに便乗する>>382も時代の流れを認めずC++に固執している姿が伺える。
こいつらを見ていると、
C plus plus のの略CPPは本当はCCPlus(CCP)、いや、
C++厨は嘘と脅しと虐殺で大陸を統治するCinese Communist Partyの連中なのでは
ないかと思えてくる。
0391デフォルトの名無しさん
2007/02/16(金) 17:33:55> いらん恥かいちゃったねw 言い訳しませんw
すでにしてるだろうw
ところでお前は>>256の主張をまだ認めることができないんだなｗ
0392デフォルトの名無しさん
2007/02/16(金) 17:40:54クロージャによって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");
}
});
}
0393デフォルトの名無しさん
2007/02/16(金) 17:40:59られています。C++のRAIIに匹敵する機能です。
withLock(lock) {
...
}
java.util.concurrentのLockをsynchronzied文同様に囲ってしまう
機能です。これは、コンパイル後、
try {
...
} finally {
lock.unlock();
}
に書き換えられるようです。
＃ざっと流し読みしただけなので間違いあるかもしれません。
0394デフォルトの名無しさん
2007/02/16(金) 18:08:350395デフォルトの名無しさん
2007/02/16(金) 20:28:48もちろん、>>373が馬鹿だからw
0396デフォルトの名無しさん
2007/02/16(金) 21:24:50お前、顔真っ赤だぞ
0397デフォルトの名無しさん
2007/02/16(金) 21:32:290398デフォルトの名無しさん
2007/02/17(土) 00:13:22>>395の顔はしわくちゃになってます。
0399デフォルトの名無しさん
2007/02/17(土) 00:39:260400デフォルトの名無しさん
2007/02/17(土) 00:53:15よりによって去年の8月の構文だしてくるかよ……
0401デフォルトの名無しさん
2007/02/17(土) 01:09:200403デフォルトの名無しさん
2007/02/17(土) 12:20:51お前、256(もしくは320)？
391を含ませている辺り悪意を感じるな。
382が恥をかいたといっているのはクロージャ知らない
事に対してではないの？
あと、256の例の前後で処理の流れがぜんぜん違うのは問題
無しなの？
0404デフォルトの名無しさん
2007/02/17(土) 12:56:22クロージャといえばこんなんあった
0405デフォルトの名無しさん
2007/02/17(土) 15:08:49細かい探りを入れると惨めになってくよ。
ここは有益な情報が入ったから、よいとしようジャマイカ
0406デフォルトの名無しさん
2007/02/17(土) 15:10:18何このコード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>
>
>
>
>
>
>
{ };
0407デフォルトの名無しさん
2007/02/17(土) 15:12:040408デフォルトの名無しさん
2007/02/17(土) 15:29:05(defun >>391 ()
(princ "ところでお前は>>256の主張をまだ認めることができないんだなｗ")
(incf 恥の上塗りcnt)))
0409デフォルトの名無しさん
2007/02/17(土) 16:00:05関数名に >> まで使えるのか。lisp 恐るべし。
0410デフォルトの名無しさん
2007/02/17(土) 16:21:260411デフォルトの名無しさん
2007/02/17(土) 19:23:550412デフォルトの名無しさん
2007/02/17(土) 19:37:030413デフォルトの名無しさん
2007/02/17(土) 19:39:29>>338のPDFを見て実際に実験してみれば
C++厨のほうが恥の上塗りになるだろうさ
0414デフォルトの名無しさん
2007/02/17(土) 19:56:20電車に間に合うかどうかで決めることの愚かしさ。
0415デフォルトの名無しさん
2007/02/17(土) 20:52:43C++の人は変態と言ってあげると喜びます
0416デフォルトの名無しさん
2007/02/17(土) 20:57:510417デフォルトの名無しさん
2007/02/17(土) 21:00:210418デフォルトの名無しさん
2007/02/17(土) 21:37:33俺はCOBOLer全盛時にASM屋だったケド同じだな。
やる場所がちがうだけだろ。
0419デフォルトの名無しさん
2007/02/17(土) 21:39:18今は通用しないのかな？
0420デフォルトの名無しさん
2007/02/17(土) 21:44:17Just in Timeコンパイラのことか？
今なら、電車に間に合わないときは乗ってから
携帯電話でSuicaチャージするんだよ。
っていうネタを想像した。
0421デフォルトの名無しさん
2007/02/17(土) 21:55:07最低でも一駅分の切符がないとｗ
0422デフォルトの名無しさん
2007/02/17(土) 21:58:46今でも田舎では通用するよ
0423デフォルトの名無しさん
2007/02/17(土) 21:59:59最低でも一駅分のお金がないと買えないw
0424デフォルトの名無しさん
2007/02/17(土) 22:10:13クレジットカードからチャージするオートチャージという機能がある。
0425デフォルトの名無しさん
2007/02/17(土) 22:12:100426デフォルトの名無しさん
2007/02/17(土) 22:19:310427デフォルトの名無しさん
2007/02/17(土) 22:31:270428デフォルトの名無しさん
2007/02/17(土) 22:34:13半年以上書き込みがなくてもレス数があれば落ちないし。
0429デフォルトの名無しさん
2007/02/17(土) 23:42:560430デフォルトの名無しさん
2007/02/17(土) 23:44:20COBOLです
0431デフォルトの名無しさん
2007/02/17(土) 23:50:080432デフォルトの名無しさん
2007/02/18(日) 00:03:01んなこたあない。改札がない駅はまだ幾らでもある。
0433デフォルトの名無しさん
2007/02/18(日) 00:06:25彼は「Windowsがないシステムはありえない」と強調しているからな。
COBOLが使われていたことが影響してMSの宣伝文句でCOBOL.NETに
乗せられてるんだろ。
それに、緑の窓口のプラズマディスプレイにはよく赤い×印のポップアップが出る。
0434デフォルトの名無しさん
2007/02/18(日) 00:40:140435デフォルトの名無しさん
2007/02/18(日) 00:50:40ちょ、それ改札通ってないｗ
0436デフォルトの名無しさん
2007/02/18(日) 00:54:37ちょ､それ例外起こってない
っていうことか
0437デフォルトの名無しさん
2007/02/18(日) 04:29:42>>>408
>>>338のPDFを見て実際に実験してみれば
>C++厨のほうが恥の上塗りになるだろうさ
>>256 のネタいじったら毎回反論君プログラムが実行されるの?
＿＿＿_
／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼
／ ⌒（__人__）⌒ ＼ ＜Javaの最適化を甘く見ているだろう
| |r┬-| |
＼ `ー'´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
＿＿＿_
／_ノ ヽ､_＼
ﾐ ﾐ ﾐ oﾟ(（●）) (（●）)ﾟo ﾐ ﾐ ﾐ
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼ /⌒)⌒)⌒)
| / / / |r┬-| | (⌒)/ / / /／ ＜ だっておwwwwwwwwwwwwww
| :::::::::::(⌒) | | | ／ ゝ :::::::::::/
| ノ | | | ＼ / ） /
ヽ / `ー'´ ヽ / ／ バ
| | l||l 从人 l||l l||l 从人 l||l バ ン
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､ ン
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
0438デフォルトの名無しさん
2007/02/18(日) 04:36:260439デフォルトの名無しさん
2007/02/18(日) 04:37:09くだらない。何かちょっといっただけで毎日>>437のAAがレスされるの？
じつにくだらない
0440デフォルトの名無しさん
2007/02/18(日) 04:50:11どっちなのか知りたいね。
0441デフォルトの名無しさん
2007/02/18(日) 04:57:33俺は>>437じゃないがお前の書き込み見てると>>437のAAでレスしたくなったぞw
0442デフォルトの名無しさん
2007/02/18(日) 06:54:290443デフォルトの名無しさん
2007/02/18(日) 09:57:56cppとjavaの優劣をつけたいもんなのか？
俺、どっちも使うけど別に違いなんてその言語の味みたいなもんだろ。
必死になる気持ちがわからねぇよ
0444デフォルトの名無しさん
2007/02/18(日) 10:01:31「やったァ、俺の勝ちぃぃぃぃぃぃ！ お前は俺より格下な！ 下、下ﾌﾟｹﾞﾗ」
っていう最高の気分になれるじゃん。
ここのスレの人間はみんなそれを目指して頑張ってるんだよ。
0445デフォルトの名無しさん
2007/02/18(日) 10:08:39両方使えばﾖｸﾈ？新しいの覚えると、先のは頭から削除されるのか？
0446デフォルトの名無しさん
2007/02/18(日) 10:35:15AA略 ＜くだらない。何かちょっといっただけで毎日>>437のAAがレスされるの？
＜じつにくだらない
AA略 ＜ だっておwwwwwwwwwwwwww
0447デフォルトの名無しさん
2007/02/18(日) 13:26:30釣りに引っ掛かる変なやつをいじって遊ぶところだろ >>256 とかの
>>256
>>305
>>312
>>315
>>316
>>318
>>324
>>333
この辺の流れか、いかにもアホそうなやつが沸いてるのは
0448デフォルトの名無しさん
2007/02/18(日) 13:54:250449デフォルトの名無しさん
2007/02/19(月) 12:52:10なぜおまえはそんなに必死なのだ。
0450デフォルトの名無しさん
2007/02/19(月) 14:13:51どうせWindowsユーザでJavaで作られたソフトを使う人なんて多くないだろ
0451デフォルトの名無しさん
2007/02/19(月) 14:45:55オンラインバンキングをなめんなよw
0452デフォルトの名無しさん
2007/02/19(月) 15:24:52いるいないじゃなくて多いか少ないかの問題なんだが？
よく勘違いする奴って、何かと相手の意見を勘違いして
自分の脳内だけで意見のゴリ押しするから嫌われるんだよ
0453デフォルトの名無しさん
2007/02/19(月) 15:25:58あぁ～～そぉ、お前ってネットバンキングのプログラム作ってんの
あぁそうか、そりゃすごいね。それはそれですごいよ。だから何？
0454デフォルトの名無しさん
2007/02/19(月) 15:27:10待つようにと告知されてなかったっけ？まぁ、Javaでそれが出来ればOSに依存せずに済む罠。
0455デフォルトの名無しさん
2007/02/19(月) 15:58:52>多いか少ないかの問題なんだが？
何が問題なんだか。
>Javaで作られたソフトを使う人
が少ないと、
>Javaやっているからって偉そうに
しちゃいけないのか？
何その園児のケンカ。
0456デフォルトの名無しさん
2007/02/19(月) 16:17:52いるだろ、オンライントレーディングをなめんなよw
0457デフォルトの名無しさん
2007/02/19(月) 16:57:23最近全然行ってねーや
0458デフォルトの名無しさん
2007/02/19(月) 17:06:1710年前の世界で思考停止している人ですかな
0459デフォルトの名無しさん
2007/02/19(月) 17:55:34>どうせWindowsユーザでJavaで作られたソフトを使う人なんて多くないだろ
そーいえばWindowsでよく使うJavaで作られたソフトって何使ってる?
俺、Eclipseぐらいしか使ってないかな、
サーバサイドは無しでどんなのあるの?
0460Javaやっていれば優秀だと思い込んでいるようです
2007/02/19(月) 17:59:20>>450は何時の時代の人なんだろう。
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
0461デフォルトの名無しさん
2007/02/19(月) 18:04:23Windowsアプリケーションを作っている人の割合を示すソースの提示を要求しよう。
これでJavaの方が上ってならそれはそれでどうでも良いことだがｗ
0462デフォルトの名無しさん
2007/02/19(月) 18:28:48C++からｺﾑｽﾞｶｼｰ機能は取り除きました! みたいな感じ。
んで、java厨は「こんなｺﾑｽﾞｶｼｰ機能は有害なんです。」ってわめーてるのw
おめーがつかえねーだけだろw
0463デフォルトの名無しさん
2007/02/19(月) 18:39:40そうだよ、それが何か？
0464デフォルトの名無しさん
2007/02/19(月) 18:45:52こっちこられても困るし
仮にC++が滅亡しても1ヶ月もあれば余裕でJava厨になれるし
ゆとり教育にぴったりってのも素晴らしいメリットだよね
0465デフォルトの名無しさん
2007/02/19(月) 18:46:22／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼
／ ⌒（__人__）⌒ ＼ ＜そうだよ、それが何か？
| |r┬-| |
＼ `ー'´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
＿＿＿_
／_ノ ヽ､_＼
ﾐ ﾐ ﾐ oﾟ(（●）) (（●）)ﾟo ﾐ ﾐ ﾐ
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼ /⌒)⌒)⌒)
| / / / |r┬-| | (⌒)/ / / /／ ＜ だっておwwwwwwwwwwwwww
| :::::::::::(⌒) | | | ／ ゝ :::::::::::/
| ノ | | | ＼ / ） /
ヽ / `ー'´ ヽ / ／ バ
| | l||l 从人 l||l l||l 从人 l||l バ ン
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､ ン
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
0466デフォルトの名無しさん
2007/02/19(月) 18:51:24複雑なものをできるだけ単純に見せかける。
Javaの良し悪しは別として、言語の進歩ってそういうものだよ。
人間の頭は簡単には進化しないのだから。
0467デフォルトの名無しさん
2007/02/19(月) 18:54:08吹いたw
お前粘着かw
0468デフォルトの名無しさん
2007/02/19(月) 18:54:500469デフォルトの名無しさん
2007/02/19(月) 18:55:52どうしたら>>458をそう曲解できるのだろう。
>>458は>>450の二行目のことを言っているだけだと思うのだがw
0470デフォルトの名無しさん
2007/02/19(月) 18:57:32作っている人の数で判断してどうするんだw
>>450の花井から、使っている人の数を確認したかっただけじゃないのか？
0471デフォルトの名無しさん
2007/02/19(月) 18:57:56そうおもうなら、おまえはアセンブラでシコシコ書いていればいいよ
0472デフォルトの名無しさん
2007/02/19(月) 18:58:20> 有害に感じてくれていいと思うよ
> こっちこられても困るし
> 仮にC++が滅亡しても1ヶ月もあれば余裕でJava厨になれるし
無理。甘く見すぎや。
0473デフォルトの名無しさん
2007/02/19(月) 19:03:36うちの会社そんくらいの期間でJava未経験から粗製乱造して出荷してますから
営業が強いって、いいよね
0474デフォルトの名無しさん
2007/02/19(月) 19:03:48取り去ってみたけど、後で必要が生じて付け足すのはバカバカしい。
0475デフォルトの名無しさん
2007/02/19(月) 19:05:520476デフォルトの名無しさん
2007/02/19(月) 19:10:40テンプレート(C++) -> なし(昔のJava) -> ジェネリック
ちゃんとJava厨にも使えるように難しい使い方はできないようにしてあるけどね
バカバカしいでしょw
0477デフォルトの名無しさん
2007/02/19(月) 19:10:430478デフォルトの名無しさん
2007/02/19(月) 19:12:200479デフォルトの名無しさん
2007/02/19(月) 19:26:090480デフォルトの名無しさん
2007/02/19(月) 19:27:460481デフォルトの名無しさん
2007/02/19(月) 20:11:570482デフォルトの名無しさん
2007/02/19(月) 20:28:09>誰でもいいからﾎﾟｲﾎﾟｲ釣れるネタ書き込めよ、燃料無いとこのスレつまらんから。
そういう下らない事はマ板でどうぞ。
0483デフォルトの名無しさん
2007/02/19(月) 20:51:08C++?
お前ら何言ってんの
これからの時代はC#だろ
0484デフォルトの名無しさん
2007/02/19(月) 20:54:46ム板のほうがたまにいいレスつく確率が高そうなきがすんだよね
>>466 とか具体例だしてほしいんだけど、C++とJavaの違う部分でGC以外
0485デフォルトの名無しさん
2007/02/19(月) 21:13:320486デフォルトの名無しさん
2007/02/19(月) 21:27:380487デフォルトの名無しさん
2007/02/19(月) 21:43:02そんな煽りをするなら、
アセンブラ -> C/C++
ちゃんとC++厨にも使えるように難しい使い方はできないようにしてあるけどね
バカバカしいでしょw
0488デフォルトの名無しさん
2007/02/19(月) 21:43:27意味ねえ。リフレクションも使えねえし
0489デフォルトの名無しさん
2007/02/19(月) 21:48:30Monoならまあ、考えなくもないが結局それならPython使うよ。
0490デフォルトの名無しさん
2007/02/19(月) 22:20:280491デフォルトの名無しさん
2007/02/19(月) 23:39:49Rubyに乗り換えたいけど、使い物になるにはまだまだ時間かかりそうだな。
0492デフォルトの名無しさん
2007/02/19(月) 23:51:41なれるかボケ
0493デフォルトの名無しさん
2007/02/20(火) 00:28:50多くのC++厨がJavaのライブラリを覚え直すのが面倒くさいと主張している。
それが証拠だな。
今からデータベースやネットワーク、セキュリティの勉強やらパーシステンスAPIの
勉強やらをたった一ヶ月ですべて済ませられるかな。
0494デフォルトの名無しさん
2007/02/20(火) 00:36:36>ちゃんとC++厨にも使えるように難しい使い方はできないようにしてあるけどね
アセンブラのなにが難しいんだ? アセンブラ自体はシンプルだろ。
0495デフォルトの名無しさん
2007/02/20(火) 00:37:58そうか？俺はあまり聞かない気がする。
Wikipedia的にソース希望。
0496デフォルトの名無しさん
2007/02/20(火) 00:39:310497デフォルトの名無しさん
2007/02/20(火) 00:48:43わざわざ覚えなおす理由がわからん、一度本でも読めば十中八九理解できるし
細かいとこは必要なときに調べればいいだろ。
はなからデータベースしらんとかネットワークしらんとか前提でいってるならしらん。
0498デフォルトの名無しさん
2007/02/20(火) 00:49:130499デフォルトの名無しさん
2007/02/20(火) 00:51:24お前、チョンなどの三国人みたいにWikipedia改竄するなよ。
0500デフォルトの名無しさん
2007/02/20(火) 00:52:03たかくくりすぎだな。
お前にEJB使いこなせるか？
0501デフォルトの名無しさん
2007/02/20(火) 00:54:11C++では想像もつかなかったコンパイルエラーに悩まされるだろう
0502デフォルトの名無しさん
2007/02/20(火) 00:55:14EJBを使いこなす必要のある仕事がどれぐらいあるんだ?
0503デフォルトの名無しさん
2007/02/20(火) 00:56:23やりゃわかるべ。
ひとつひとつは別に難しくないけど、覚えること多すぎ。
0504デフォルトの名無しさん
2007/02/20(火) 01:02:33STL使えるとJavaのコレクションはｵｺﾁｬﾏ用にしかみえない。
効率悪くてやるきなくす。コード書かせすぎ。
0505デフォルトの名無しさん
2007/02/20(火) 01:14:44Strutsのプロジェクトに参加するぐらいならネットで調べながらでもできるから、
できると思ってる人の気持ちはわかる。
0506デフォルトの名無しさん
2007/02/20(火) 01:16:08Javaの方が数段優れてるように思えてくる。
0507デフォルトの名無しさん
2007/02/20(火) 01:17:27速いし、やれる事が沢山ある。
趣味プログラマーだからそう感じるんだろうけど（・・；）
仕事だったら生産性悪い気がする。
0508デフォルトの名無しさん
2007/02/20(火) 01:18:18JavaプログラマーとC++プログラマーはどっちが技術のレベルが高いの？
0509デフォルトの名無しさん
2007/02/20(火) 01:23:30C++とJavaの知識領域は、実はあまりかぶるところが無いと思う。
両方（というか他の言語も）やる奴以外、技術レベルはあまり高くないと言えるかも。
0510デフォルトの名無しさん
2007/02/20(火) 01:23:450511デフォルトの名無しさん
2007/02/20(火) 01:28:29いるわけで。
とはいえ、厳密に言語として比較するのは難しいので、同じ仮想マシン上で動くプログラムを作成するという条件で比較するといいと思う。
つまり、C++/CLIとJ#だ。
おれはC++の勝ちだと思う。
0512デフォルトの名無しさん
2007/02/20(火) 01:32:08これでは、比較にならないぞ。
ってか、偽言語を広めるな > MS
0513デフォルトの名無しさん
2007/02/20(火) 01:33:27早く改良しやがれ！
0514デフォルトの名無しさん
2007/02/20(火) 01:36:250515デフォルトの名無しさん
2007/02/20(火) 01:49:08もちろん冗談だが。
JAVAはVM込みで進化するので、C＋＋と比較すること自体おかしい。
0516デフォルトの名無しさん
2007/02/20(火) 01:58:510517デフォルトの名無しさん
2007/02/20(火) 02:02:22ﾊﾞｰｼﾞｮﾝｱｯﾌﾟしない言語に乗り換えないの？
0518デフォルトの名無しさん
2007/02/20(火) 02:03:10どれ使っていいかの判断が辛いことだな。
それなりに本やWEBで追っているつもりだが、大変だ。
あと、おっさんが日経なんとかで見つけた技術を使いたがって鬱陶しい。
Cとか、C++の案件はやり方について上がうるさくないのはいいね。
でも、そろそろboostくらいは覚えるかな。
0519デフォルトの名無しさん
2007/02/20(火) 02:07:25インテル系の石は直交性低いせいで無駄に難しくなってるよ。
0520デフォルトの名無しさん
2007/02/20(火) 02:08:14STLのほうがどうみても効率悪いだろ。
Objectクラスが無い時点でもうすでにオコチャマだな。
不満があるなら、Jakarta Commons Collectionsを使え。
0521デフォルトの名無しさん
2007/02/20(火) 02:09:20機能が多いだけならそりゃ勝てる。
だが、実用性という観点を考える、C++は負ける。
0522デフォルトの名無しさん
2007/02/20(火) 02:10:12それもおまいの修行が足りないんだよ。
0523デフォルトの名無しさん
2007/02/20(火) 02:27:460524デフォルトの名無しさん
2007/02/20(火) 03:19:53C++の変態的動作に比べればぬるいぬるい
0525デフォルトの名無しさん
2007/02/20(火) 03:26:420526デフォルトの名無しさん
2007/02/20(火) 03:30:24だめだ。
equals()もhashcode()もwait()もnotify()も実装できない言語なんぞたかが知れてる
0527デフォルトの名無しさん
2007/02/20(火) 03:30:40>不満があるなら、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++では想像もつかなかった実行時エラーのほうが多そうだな。キャストのせいでな。
0528デフォルトの名無しさん
2007/02/20(火) 03:33:13> Jakarta Commons Collectionsでも基本的に全部Objectで扱うように
> なってるんだよな、おかげでJakarta Commons Collections使っても
> キャストしまくりじゃねーか。
つGenerics対応版
0529デフォルトの名無しさん
2007/02/20(火) 03:37:01> >Objectクラスが無い時点でもうすでにオコチャマだな。
> これが、理解できん。
equals(), hashCode()をオーバーライドできないから糞ってこと。
コレクションに格納できるオブジェクトは、とくにMapはequals(), hashCode()の
実装に大きくかかっている。
> Jakarta Commons Collectionsでも基本的に全部Objectで扱うように
> なってるんだよな、おかげでJakarta Commons Collections使っても
> キャストしまくりじゃねーか。
新しいCollectionsはGenericsに対応してその問題は解決している。
もっとちゃんとググれ。
0530デフォルトの名無しさん
2007/02/20(火) 03:41:50url書けよ、余計なものばっかり引っ掛かるぞ。リファレンスのurlな
>equals()もhashcode()もwait()もnotify()も実装できない言語なんぞたかが知れてる
自分で実装しろよ、equals()ってわらかしてんのか?
0531デフォルトの名無しさん
2007/02/20(火) 03:43:30template関数で出来ると思いますが。共通の基底型が無くたって、
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の進歩で、コストは償却されます」と言われるんだろうけど。
0532デフォルトの名無しさん
2007/02/20(火) 03:49:22>コレクションに格納できるオブジェクトは、とくにMapはequals(), hashCode()の
>実装に大きくかかっている。
STL知らんのまるだしかよ。
0533デフォルトの名無しさん
2007/02/20(火) 03:49:52ほれ
http://sourceforge.net/projects/collections
0534デフォルトの名無しさん
2007/02/20(火) 03:50:46それで、intが64bitに変わったときはどうするんだ？
0535デフォルトの名無しさん
2007/02/20(火) 03:51:56> あと、Genericsも5.0時代の実装ではキャストが消えてないみたいですが。
Genericsはパフォーマンス目的ではなく type safeが目的だからな。
0536デフォルトの名無しさん
2007/02/20(火) 03:55:12戻り値もtemplateにしますかね。
>>535
C++並になれてよかったね。
0537デフォルトの名無しさん
2007/02/20(火) 03:57:28リファレンスのurlっていってるだろーが
0538デフォルトの名無しさん
2007/02/20(火) 04:03:52それだと、実装しない馬鹿対策には弱い。
Mapに実装しないと意味がない。
いまどき非finalメソッドが遅くなるなんていっていってるのは都市伝説信者だな。
Javaの理論と実践: パフォーマンスの都市伝説
http://www-06.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html
都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる
都市伝説その3: 不変オブジェクトはパフォーマンスを悪化させる
0539デフォルトの名無しさん
2007/02/20(火) 04:14:07> >>534
> 戻り値もtemplateにしますかね。
そのクラスのオブジェクトのパターンが2の32乗通り以上あった場合どうするんだ？
しかも、馬鹿が書いたクラスのオブジェクトのフィールドの一つ一つがすでに
2の32乗の範囲を超えている。
> >>535
> C++並になれてよかったね。
むしろ、C++のほうがtype safe性に弱いのでJava並みになれていないことがC++の落ち度だが。
0540デフォルトの名無しさん
2007/02/20(火) 04:14:24甘えるな。
あとはそれでなんとかなるだろ
0541デフォルトの名無しさん
2007/02/20(火) 04:15:30STLのequals()はhashCode()との『契約』をちゃんと満たしているか？
"Design by Contract" をちゃんと満たしているか？
0542デフォルトの名無しさん
2007/02/20(火) 04:19:260543デフォルトの名無しさん
2007/02/20(火) 04:25:00>Javaの理論と実践: パフォーマンスの都市伝説
>http://www-06.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html
>都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる
>都市伝説その3: 不変オブジェクトはパフォーマンスを悪化させる
だれもそんな話してないから。
あと、STL知らんのならわざわざSTLについてかかなくていいよ。
なんか、この前のJava最適化君がわいてるようなｵｶﾝ。
0544デフォルトの名無しさん
2007/02/20(火) 04:26:18HashMapのキーに使用できるオブジェクトの
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()に置き換えて考えてくれ
0545デフォルトの名無しさん
2007/02/20(火) 04:27:29> いまどき非finalメソッドが遅くなるなんていっていってるのは都市伝説信者だな。
> >Javaの理論と実践: パフォーマンスの都市伝説
> >http://www-06.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html
> >都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる
> >都市伝説その3: 不変オブジェクトはパフォーマンスを悪化させる
> だれもそんな話してないから。
> 共通の基底型の関数をオーバーライドして、仮想関数呼び出し相当のコストを払うのはもったいない。
ほら、してるよ。
0546デフォルトの名無しさん
2007/02/20(火) 04:27:57>>540
0547デフォルトの名無しさん
2007/02/20(火) 04:29:49>実装しない馬鹿対策には弱い。
ってどういうこと？C++でtemplateを使う場合は、むしろ関数宣言が無ければコンパイルエラーで落ちてくれますが。
「基底型の関数をオーバーライドせずに使うのは問題」というのなら確かにそう。
でもJavaも変わらない気が。Object#hashcode()があるからある意味安全だと思うけど。
無駄なfinal宣言を避けろって、これは「些細なパフォーマンスの期待で、インターフェースを汚すことは無い」と言う話だよね。
パフォーマンスのJIT最適化も、これなんでしょう？
>「JITコンパイルでインライン化されるから、早さは変わらない」と言われるんだろうけど。
>>539
その肥大したクラス階層を総称的にtemplateで扱えますよ。
むしろ、その泥沼状態はJavaでも変わらない気が。
安全じゃないキャストが出来てしまう、のは確かにC++の泥沼感を示している。
全部dynamic_castに制限すれば、Java並になれるけどね。そこはJavaでの洗練が感じられる。
>>540
その手の"契約"は、静的にはtemplate解決失敗時の(意味不明な)エラーと assert()で行うのがC++では普通かな。
あと、STLの連想コンテナは'<'演算子に基づくもので、Javaのようにハッシュとequals()に基づくものじゃないよ。
だからそんな契約も必要ない。ていうか共通の基底型が無くて出来ない。
0548デフォルトの名無しさん
2007/02/20(火) 04:33:39>ほら、してるよ。
C++の話だ
0549デフォルトの名無しさん
2007/02/20(火) 04:34:150550547
2007/02/20(火) 04:35:59あと、"動的には"assert()で契約を行う・・だった。でもこのへんはJavaも一緒か
>>549 うん orz
0551デフォルトの名無しさん
2007/02/20(火) 04:44:41> >>538
> 無駄なfinal宣言を避けろって、これは「些細なパフォーマンスの期待で、インターフェースを汚すことは無い」と言う話だよね。
「virtualを付けると遅くなるから、virtualがデフォルトであるJavaのメソッドにはfinalをつけなければならない」
こう主張しているジジイがたまにいるんだよね。
> 共通の基底型の関数をオーバーライドして、仮想関数呼び出し相当のコストを払うのはもったいない。
あんたもこんな発言をしたからそのジジイとかわらないんじゃないかな。
> >>539
> その肥大したクラス階層を総称的にtemplateで扱えますよ。
意味わかって言ってるのかね。JavaのintはどんなOSであっても32bitsと決まっている。
だがC++のintはプラットフォームによってころころ変わる。そんな環境下で、intが64bits前提で
hashCode()を実装した奴とintが32bits前提で実装した奴のそれぞれのhashCode()を持ったクラスを
集約したクラスをつくるときに面倒なことが起きる、ということを想像できないのかね。
しかもそいつらが作ったクラスがブラックボックスだったら、ますます厄介なことになるぞ。
0552デフォルトの名無しさん
2007/02/20(火) 04:45:33> その手の"契約"は、静的にはtemplate解決失敗時の(意味不明な)エラーと assert()で行うのがC++では普通かな。
> あと、STLの連想コンテナは'<'演算子に基づくもので、Javaのようにハッシュとequals()に基づくものじゃないよ。
> だからそんな契約も必要ない。
まるでComparable<T>#CompareTo(T)みたいだな。
しかし、hashCode()なしではHashMapやhashSetの
パフォーマンスに弊害がでるものではないかな。
ついでにこれらのクラスにもそのComparableインタフェースが実装されている。
0553デフォルトの名無しさん
2007/02/20(火) 04:46:20だが、それをJavaに置き換えて「Javaは遅いニダ！」とファビョる馬鹿もいるんだよね
0554デフォルトの名無しさん
2007/02/20(火) 04:47:180555デフォルトの名無しさん
2007/02/20(火) 04:51:200556デフォルトの名無しさん
2007/02/20(火) 05:05:59Javaなら
>「JITコンパイルでインライン化されるから、早さは変わらない」
って最初に書いたのに・・orz
だから俺も、Javaで組むときには無駄にはfinalつけるようなことはしない。
C++のときは、非仮想に出来るだけ持っていく
>>539ではクラスの数の話、>>534ではint型の大きさの話をするから混ざって訳分からなかったけど、環境依存の話？
確かにそれはカオス。VMで型の大きさが決まっていることは素晴らしく楽だね。
>>552
まあ、標準にハッシュ表がないからねえ。
>>554
C++は、< 演算子を用いた ∀i ，!(*(i+1) < *i) による"等価"を用いて、そのequals()契約と同等のことをしてます。
式が適当でスマソ
0557デフォルトの名無しさん
2007/02/20(火) 08:21:50意味がわからん
0558デフォルトの名無しさん
2007/02/20(火) 09:57:15メモリも512テラぐらいつむか
0559デフォルトの名無しさん
2007/02/20(火) 10:07:41何言いたいのか解らないが
メモリ512テラ載せれるマシンってあんのかよ
0560デフォルトの名無しさん
2007/02/20(火) 11:31:49Itanium はプロセッサ自体は 1PiB まででしたっけ？
0561デフォルトの名無しさん
2007/02/20(火) 13:03:34そうか、おまいがしらなかったのか。ファッキン！ファッキン！
0562デフォルトの名無しさん
2007/02/20(火) 13:04:56散々言われているようにSTLはOOP的でないので、
Javaやってからだときもく感じるのは別に不思議ではない。
で、お前がきもいと感じるかどうかと有害かどうかは別問題なんだ。
0563デフォルトの名無しさん
2007/02/20(火) 13:05:04通常はそこまでいらんわ。
EclipseやNetBeansでは1GBくらいが妥当。
0564デフォルトの名無しさん
2007/02/20(火) 13:06:27糞だということだけはわかる。
0565デフォルトの名無しさん
2007/02/20(火) 13:28:000566デフォルトの名無しさん
2007/02/20(火) 14:23:060567デフォルトの名無しさん
2007/02/20(火) 14:59:41ﾋﾟｭ.ｰ ( ＾３＾） ＜エェー これからも僕を応援して下さいね（＾３＾）。
＝〔~∪java~〕
＝ ◎――◎ java＆サン
0568デフォルトの名無しさん
2007/02/20(火) 15:24:28使用するキーとなるオブジェクトは必ずComparableインタフェースを
実装しなければならないという決まりがあるよ。
0569デフォルトの名無しさん
2007/02/20(火) 15:24:50Javaすれにわざわざコピペご苦労
0570デフォルトの名無しさん
2007/02/20(火) 15:49:35このスレにきてる人の大部分は、
すでに知ってるか、知らなくてもすぐに調べられる人だと思うよ
0571デフォルトの名無しさん
2007/02/20(火) 15:54:470572デフォルトの名無しさん
2007/02/20(火) 15:57:13脊髄反射乙。たった2行なんだから、全部読んでからレスしてね。
0573デフォルトの名無しさん
2007/02/20(火) 16:04:040574デフォルトの名無しさん
2007/02/20(火) 16:09:020575デフォルトの名無しさん
2007/02/20(火) 16:12:36std::set, std::mapクラステンプレートには
使用するキーとなるオブジェクトを比較するファンクタのクラスを
指定しないといけないよ。
ただしデフォルトではoperator <で比較するファンクタが指定されるから
キーとなるオブジェクトの型がoperator <を持っていればそれを使えるよ。
0576デフォルトの名無しさん
2007/02/20(火) 18:55:480577デフォルトの名無しさん
2007/02/20(火) 19:13:540578デフォルトの名無しさん
2007/02/20(火) 19:20:09C++しか知らない奴は存在しえない。
0579デフォルトの名無しさん
2007/02/20(火) 19:22:30ｱﾌｫでつか・・・
0580デフォルトの名無しさん
2007/02/20(火) 19:30:200581デフォルトの名無しさん
2007/02/20(火) 20:32:00> C++を知っててCを知らないことはあり得ないから
ありえるよ。いきなりC++からやった奴なんてCのポインタの
使い方間違えるし。
> C++しか知らない奴は存在しえない。
現実をみよう
0582デフォルトの名無しさん
2007/02/20(火) 20:33:02ろくなやつがいない。まさにVB厨と変わらないレベル
までエディタ + シェル + Ant でJavaを始めた奴のほうがまとも
0583デフォルトの名無しさん
2007/02/20(火) 21:03:52低レベルな視点を全く身につけられないJavaは害悪以外の何者でもない。
0584デフォルトの名無しさん
2007/02/20(火) 21:04:59全部事務用言語じゃねーか。そんなの「こなす」とか言ってるレベルで駄目。
すくなくともLisp、Ruby|Python, javascriptぐらいはやってからこのレベルの高いスレに
参加してほしい。
0585デフォルトの名無しさん
2007/02/20(火) 21:15:12何時の時代の話をしているんだこのハゲはw
0586デフォルトの名無しさん
2007/02/20(火) 21:15:43似たようなスクリプト言語ばっかだな
RubyとLisp程度でいいだろw
0587デフォルトの名無しさん
2007/02/20(火) 21:29:39結論には同意するが、似てるのは「スクリプト」と言う点だけだろと突っ込み入れておく。
特に lisp はその中でも異色。
0588デフォルトの名無しさん
2007/02/20(火) 21:41:280589デフォルトの名無しさん
2007/02/20(火) 21:47:050590デフォルトの名無しさん
2007/02/20(火) 21:59:20それで「C++できる」にカウントするのか？
0591デフォルトの名無しさん
2007/02/20(火) 22:44:440592デフォルトの名無しさん
2007/02/20(火) 22:45:10型推論とも違うし
0593デフォルトの名無しさん
2007/02/20(火) 23:10:46ファイルパスの扱いとか、環境非依存にしようがない所ぐらいしか
環境依存部分はないと思うのだが。
環境非依存にすることが出来るのにも関わらず、
環境依存になってしまっている例を挙げれるものなら挙げてみ
0594デフォルトの名無しさん
2007/02/20(火) 23:14:310595デフォルトの名無しさん
2007/02/21(水) 00:10:080596デフォルトの名無しさん
2007/02/21(水) 00:30:26キャストの話をしてるんだ
0597デフォルトの名無しさん
2007/02/21(水) 00:45:190598デフォルトの名無しさん
2007/02/21(水) 00:51:16- Garbage collection
- Memory model for concurrency
- Concurrency libraries
GCがあり、並行プログラミングに強いJavaではもうおなじみのものだな。
0599デフォルトの名無しさん
2007/02/21(水) 00:54:24それ、あるね。
Windows使っている人に、Java入れてよってなかなかね。
JREのダウンロードサイトもなんかわかりにくいし。
0600デフォルトの名無しさん
2007/02/21(水) 01:35:30C++よりパフォーマンス悪くして何を目指してるんだろう。
一番アフォくさいのはGCや生配列扱うときのの添え字チェックだよ
テストでまかなえるのにわざわざパフォーマンス下げるなよ・・・
なんで有限回数しか回らないんだからコアダンプ吐くまでテストすりゃ十分じゃん。
メモリの生きてる範囲小さくしていけばメモリリークも十分テストで網羅できるし、
パフォーマンス意識してキャッシュライン考えるとGC悪じゃん。
数百万出せば逆アセからメモリリーク出そうな場所特定してくれるツールもあるんだしさー
c++は今のままで十分、改造するなら別の言語として作って欲しいわ
0601デフォルトの名無しさん
2007/02/21(水) 01:42:560602デフォルトの名無しさん
2007/02/21(水) 01:43:24勝手にはいるから問題ない
0603デフォルトの名無しさん
2007/02/21(水) 01:43:280604デフォルトの名無しさん
2007/02/21(水) 01:46:21つJETコンパイラ
0605デフォルトの名無しさん
2007/02/21(水) 01:48:36> >>598みたいなしくみ必要ないんじゃない？
> C++よりパフォーマンス悪くして何を目指してるんだろう。
> 一番アフォくさいのはGCや生配列扱うときのの添え字チェックだよ
そう思うなら、超巨大な配列を作ればいい。
Javaなら、Bufferクラスを使って
> テストでまかなえるのにわざわざパフォーマンス下げるなよ・・・
> なんで有限回数しか回らないんだからコアダンプ吐くまでテストすりゃ十分じゃん。
『アジャイルソフトウェア開発の奥義』ではそんな言い訳は許されない。
0606デフォルトの名無しさん
2007/02/21(水) 01:52:02にはそれ以外も挙げられてるが、>>586のJava使いは
それらの重要性は理解できずに割愛したんだろう。
0607デフォルトの名無しさん
2007/02/21(水) 01:59:44まて、お前英語読めるか？
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.
その記事を見ただけでは信用するに値するかどうかもわからん
0608デフォルトの名無しさん
2007/02/21(水) 02:02:31ありがと。でも、これよりまとまったページ知ってる？
0609デフォルトの名無しさん
2007/02/21(水) 02:06:30To 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 ;
↑こういう紛らわしいことは辞めて欲しいんだけどな。
ソースが読みにくくなる。
0610デフォルトの名無しさん
2007/02/21(水) 02:07:510611デフォルトの名無しさん
2007/02/21(水) 02:10:10vector( 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より後発で導入するとは
0612デフォルトの名無しさん
2007/02/21(水) 02:19:440613デフォルトの名無しさん
2007/02/21(水) 02:30:39String foo = "hogehoge" + "fugafuga";
って書けるだけいいからさあ。
0614デフォルトの名無しさん
2007/02/21(水) 02:33:54最近はかってに入るのか。。
>>604
JITコンパイラの利点は無くなっちゃうのかな。
0615デフォルトの名無しさん
2007/02/21(水) 02:39:02Javaだって汎用のヤツはなかったんじゃないか？
いつの間にか
ArrayList<int> a = new ArrayList<int>() { 1, 2, 3 };
と書けたりするようになったのか？
0616デフォルトの名無しさん
2007/02/21(水) 06:30:06http://developer.apple.com/jp/briefing/cocoa.html
0617デフォルトの名無しさん
2007/02/21(水) 08:43:58いまはこれで我慢しとけ。
std::string foo = "hogehoge" "fugafuga";
0618デフォルトの名無しさん
2007/02/21(水) 09:01:400619デフォルトの名無しさん
2007/02/21(水) 09:07:05待ちのスレッドをスピンロックに変えるらしい
C++でのプロファイル後オプチマイズもJITはやってくれるだろうし
複雑なプログラムではJAVAが速いのは自明な気がする
0620デフォルトの名無しさん
2007/02/21(水) 10:30:02プロなら好みで言語は選べないし，
趣味でやるなら好きな方でやればいいじやない
0621デフォルトの名無しさん
2007/02/21(水) 11:17:49> >>602
> 最近はかってに入るのか。。
> >>604
> JITコンパイラの利点は無くなっちゃうのかな。
ならねえところ無くならねえ。
分散ではいちいち手動再婚パイルなんてかったるいから。
0622デフォルトの名無しさん
2007/02/21(水) 11:20:58Javaにはそんなイニシャライザはない。
「Java スタティックイニシャライザ」
「Java インスタンスイニシャライザ」でググってみ
0623デフォルトの名無しさん
2007/02/21(水) 11:29:04だよね。ありがと。
>>611のやつは、組み込みの配列型だけではなくて一般のクラスでも、
std::vector<int> v = { 1, 2, 3 };
と書けるようにすることが目的だったはず。
0624デフォルトの名無しさん
2007/02/21(水) 11:45:07『アジャイルソフトウェア開発』はただの迷信だよ
http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm
http://www.aoky.net/articles/steve_yegge/egomania_itself.htm
0625デフォルトの名無しさん
2007/02/21(水) 12:21:52お前迷信というまえにこの本をちゃんと読んだのか？
>>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
0626デフォルトの名無しさん
2007/02/21(水) 13:07:34http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2142.html
0627デフォルトの名無しさん
2007/02/21(水) 13:12:14示したURLの記事をちゃんと読めば、迷信をどういう意味で使っているか
分かるはずだし、この意味での迷信であれば、本を取り上げることは全くの
反論になってないことも分かるはず。
0628デフォルトの名無しさん
2007/02/21(水) 13:42:590629↓こいつ病気です
2007/02/21(水) 13:49:25スレ伸びてるけど今日はあんまり病的な人はいませんねー
0630デフォルトの名無しさん
2007/02/21(水) 13:56:270631デフォルトの名無しさん
2007/02/21(水) 13:58:03しょんぼりだわ。
0632デフォルトの名無しさん
2007/02/21(水) 14:21:340633デフォルトの名無しさん
2007/02/21(水) 14:28:28だよなー、たまに沸いてくるへんなやつが、知りもしないのにたたいてるのみると
なんか得体の知れないものを必死にたたく○○厨みたいで笑えるけど。
0634デフォルトの名無しさん
2007/02/21(水) 14:49:21>> >>598みたいなしくみ必要ないんじゃない？
>> C++よりパフォーマンス悪くして何を目指してるんだろう。
>> 一番アフォくさいのはGCや生配列扱うときのの添え字チェックだよ
>そう思うなら、超巨大な配列を作ればいい。
パンが無いならケーキみたいで笑えるw
0635デフォルトの名無しさん
2007/02/21(水) 17:16:54> 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");
}
}
}
0636デフォルトの名無しさん
2007/02/21(水) 17:17:34> 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
0637デフォルトの名無しさん
2007/02/21(水) 17:25:16> 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)
でやってるワケだが、あの２つのどこが同じなんだ…？
0638デフォルトの名無しさん
2007/02/21(水) 18:46:050639デフォルトの名無しさん
2007/02/21(水) 21:48:470640デフォルトの名無しさん
2007/02/21(水) 23:35:05あの2つってどの2つ？
0641デフォルトの名無しさん
2007/02/22(木) 00:12:09意味がわからないので解説よろ
0642デフォルトの名無しさん
2007/02/22(木) 00:18:47何が言いたいのかわからんのだねど。
速度の話をするなら、ちゃんと時間を計算しようね。
0643デフォルトの名無しさん
2007/02/22(木) 00:28:430644デフォルトの名無しさん
2007/02/22(木) 00:45:04>>256のことだと思われ
0645デフォルトの名無しさん
2007/02/22(木) 01:27:41俺は635じゃないけど、当然 test02 のほうが速いだろ。
0646デフォルトの名無しさん
2007/02/22(木) 01:43:19なるほど。これは香ばしいな。
>>645
速いとか、遅いとかじゃなくて、test01とtest02は、異なる処理なので、
mpegエンコードは、レイトレーシングより速いってぐらい意味のない比較だと思う。
0647645
2007/02/22(木) 01:53:30そうなんだけど、>>256 以降のやりとりをみればわかるが、
それが理解できないやつがいるので、そいつを釣り上げてみるかなって思っただけ。
test02 のほうが速いと書けば食いつきそうなので。
0648デフォルトの名無しさん
2007/02/22(木) 02:07:25オーバードライブオフ、スポーツモードみたいなモンジャマイカ？
0649デフォルトの名無しさん
2007/02/22(木) 02:12:01> >>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だと恐ろしいほど差が出ている。
0650デフォルトの名無しさん
2007/02/22(木) 02:12:35>>649を読め
0651デフォルトの名無しさん
2007/02/22(木) 02:21:22／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼
／ ⌒（__人__）⌒ ＼ ＜速度に若干は差がでるもの、
| |r┬-| | ほぼ変わらないと言う意味だ。
＼ `ー'´ ／
ノ ＼
／´ ヽ
| ｌ ＼
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､.
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
＿＿＿_
／_ノ ヽ､_＼
ﾐ ﾐ ﾐ oﾟ(（●）) (（●）)ﾟo ﾐ ﾐ ﾐ
/⌒)⌒)⌒. ::::::⌒（__人__）⌒:::＼ /⌒)⌒)⌒)
| / / / |r┬-| | (⌒)/ / / /／ ＜ だっておwwwwwwwwwwwwww
| :::::::::::(⌒) | | | ／ ゝ :::::::::::/
| ノ | | | ＼ / ） /
ヽ / `ー'´ ヽ / ／ バ
| | l||l 从人 l||l l||l 从人 l||l バ ン
ヽ -一''''''"~~｀`'ー--､ -一'''''''ー-､ ン
ヽ ＿＿＿＿(⌒)(⌒)⌒) ) (⌒＿(⌒)⌒)⌒))
0652デフォルトの名無しさん
2007/02/22(木) 02:30:52ループの構造まで（人間が望むように）変えてくれるものなんすか？
コンパイラの中の人も大変だ。
0653デフォルトの名無しさん
2007/02/22(木) 02:55:130654デフォルトの名無しさん
2007/02/22(木) 05:52:130655デフォルトの名無しさん
2007/02/22(木) 09:52:130656デフォルトの名無しさん
2007/02/22(木) 10:05:49釣りですか？
それとも馬鹿ですか？
0657デフォルトの名無しさん
2007/02/22(木) 10:06:200658デフォルトの名無しさん
2007/02/22(木) 13:03:43コードは間違ってた、元のPDFだけ読んでください、と言えるヤツなら、
まだ救いがあるんだが。
0659デフォルトの名無しさん
2007/02/22(木) 13:17:05なぜここまで自演してまで必死になるのだろうか。
0660デフォルトの名無しさん
2007/02/22(木) 13:20:430661デフォルトの名無しさん
2007/02/22(木) 13:20:59> 言語には次の２種類しか存在しないということです
> ――皆が不満を顕にするものか，あるいは，誰も使いもしないものか，です。
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ﾞ､ ￣ .／ , |::!
/ ﾍ ヾ ヽ､ _,. ' / |:'
0662デフォルトの名無しさん
2007/02/22(木) 13:34:480663デフォルトの名無しさん
2007/02/22(木) 13:41:020665デフォルトの名無しさん
2007/02/22(木) 14:11:21これじゃなきゃダメ！なんて限定する必要もなし。
使えるものをどんどん吸収すべし！
0666デフォルトの名無しさん
2007/02/22(木) 14:23:37双方のコードの速度差がゼロに近似する
0667デフォルトの名無しさん
2007/02/22(木) 14:42:13> Technology Review 誌による Stroustrup へのインタビュー記事。
> 現代のソフトウェアが抱える諸問題についての話題を軸としながら，
> 氏のプログラミングに対する科学的あるいは工学的な視点をうかがう。
> C++ の設計に関して悔やむところなど何も無いと述べる氏の語り口は非常に明朗としていていっそ清々しい。
↑まさにC++信者を庇うためにわざとストラウストラップが言った言葉。
それに「非常に明朗としていていっそ清々しい。」とまでいうのはC++信者。
0668デフォルトの名無しさん
2007/02/22(木) 14:42:32C++厨もバイトコード知らないよ
0669デフォルトの名無しさん
2007/02/22(木) 14:44:06起こってしまえば処理の流れが違うんだから比べる意味がわからない。
0670デフォルトの名無しさん
2007/02/22(木) 14:51:26Javaはあれと同じレベルなのか。
0671デフォルトの名無しさん
2007/02/22(木) 14:51:43ttp://d.hatena.ne.jp/keyword/%A5%D0%A5%A4%A5%C8%A5%B3%A1%BC%A5%C9
0672デフォルトの名無しさん
2007/02/22(木) 14:59:42Emacs-Lisp もある。
0673デフォルトの名無しさん
2007/02/22(木) 15:00:49何で知る必要があるの？
C++の処理系でバイトコードをはくやつなんてあった？
0674デフォルトの名無しさん
2007/02/22(木) 15:02:18変な日本語
0675デフォルトの名無しさん
2007/02/22(木) 15:09:340676デフォルトの名無しさん
2007/02/22(木) 15:09:45Visual C++のManeged C++とC++/CLIは.NETのCILを吐くぞ。
0677デフォルトの名無しさん
2007/02/22(木) 15:10:260678デフォルトの名無しさん
2007/02/22(木) 15:14:08漸近するの間違いじゃね？
0679デフォルトの名無しさん
2007/02/22(木) 15:21:51Managed C++とかC++/CLIって、
正直なところ、C++に入れてもらえてないんじゃない？
しかも、C++/CLIでは、C++のテンプレート用の実行時コード生成もあるから、
Javaのバイトコードと比較するのもアレな感じだし。
0680デフォルトの名無しさん
2007/02/22(木) 15:23:55ラベル付きbreakが進化したgotoだろ
typedefは・・・・・・えーと、現代的なIDEを使って自動入力してください。
0681デフォルトの名無しさん
2007/02/22(木) 15:25:34try-catchがgoto替わり
0682デフォルトの名無しさん
2007/02/22(木) 15:27:01日本語では他動詞と自動詞の区別なんて曖昧だけど
0683デフォルトの名無しさん
2007/02/22(木) 15:29:13だからVMの種類やバージョンを変えてみそ
って話。
古いJVMであのプログラムを動かすとtryの中にforのほうが
明らかに早いことがわかる。
しかし新しいJVMだとforに中にtryを置こうと大差なくなってきている。
とくに-serverオプションを付けるとその様子が顕著に表れてくる。
0684デフォルトの名無しさん
2007/02/22(木) 15:29:35クラスやインタフェースがtypedef替わりになる。
0685デフォルトの名無しさん
2007/02/22(木) 15:36:16それは、
http://www-06.ibm.com/jp/developerworks/java/060310/j_j-jtp02216.shtml
に書かれているアンチパターンのこと？
0686デフォルトの名無しさん
2007/02/22(木) 15:41:14class とにかくロングロングなとにかくどうしようもなくウルトラスーパー長～いクラス名
これを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の不満も解消されるであろう。
0687デフォルトの名無しさん
2007/02/22(木) 15:41:56>>677がそれで自業自得に陥るならそれでも構わんだろう
0688デフォルトの名無しさん
2007/02/22(木) 16:02:371: >>685 に書いてある通り、使えない。
2: そもそもコード間違ってない？
3: メソッドを全部記述するなんて面倒なこといちいちできるわけがない。
あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
4: staticのみ？ 論外。
そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。
0689デフォルトの名無しさん
2007/02/22(木) 18:18:59君は現実の世界でもそういうかみ合わない会話をしているのかね?
0690デフォルトの名無しさん
2007/02/22(木) 18:47:08> 2: そもそもコード間違ってない？
メソッドをpubilcに
する
> 3: メソッドを全部記述するなんて面倒なこといちいちできるわけがない。
だいたクラスなんて大した数のメソッド持ってないだろ。
そんなことで面倒くさがるなら、自動化ツールで自動生成すればいい。
Jakarta Velocityでテンプレート作れ。
そもそも、一つのクラスにメソッド100近く作る奴はDQN。
Javaでは一つのクラスに付きメソッド255個までしかつくることができないようになっているが。
クラスが1000行超えたら分割しないといけない。
ついでにメソッドも40行超えたら分割しろ。
> あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。
『鉄則：分割し、統治せよ。』
さらについかしてみよう。
■その５
同じプロジェクト内ならリファクタリング(名前変更)で解決。
■その６
クラス名の一部をパッケージ名に変更してクラス名を短縮。
■その７
0691デフォルトの名無しさん
2007/02/22(木) 18:50:06> >>686
> 4: staticのみ？ 論外。
> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。
仮に、こんな長ったらしい型があったとしよう。
Map<List<List<Set<Map<List>>>>>
ここで、頻繁に変更するヶ所が一番最深部のListだけであるなら、
ラッパーでまとめるという手も考えるべきだ。
こんなクラスにまとめてしまえ
Wrapper<List>
0692デフォルトの名無しさん
2007/02/22(木) 19:46:32>だいたクラスなんて大した数のメソッド持ってないだろ。
>そんなことで面倒くさがるなら、自動化ツールで自動生成すればいい。
Javaはtypedef一つするにしてもそんな面倒なことやらなきゃいけないんですね。
>> あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
>> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。
>『鉄則：分割し、統治せよ。』
受け答えが成立していません。誤魔化さずに真面目に答えてください。
0693デフォルトの名無しさん
2007/02/22(木) 19:51:52>■その５
>同じプロジェクト内ならリファクタリング(名前変更)で解決。
>
>■その６
>クラス名の一部をパッケージ名に変更してクラス名を短縮。
Genericsで型名が長くなる場合にはどうしようもないよね
0694デフォルトの名無しさん
2007/02/22(木) 20:09:07もしくはそれに近い方法で使えない？
そしたら短い名前で参照できるのでわ
0695デフォルトの名無しさん
2007/02/22(木) 20:12:13名前のためだけにそういうことをするのはかなりキモい
0696デフォルトの名無しさん
2007/02/22(木) 20:14:23C++/CLIはISOに蹴られますた
ttp://blogs.wankuma.com/episteme/archive/2006/09/12/38394.aspx
0697デフォルトの名無しさん
2007/02/22(木) 20:16:100698デフォルトの名無しさん
2007/02/22(木) 20:30:22> >>690
> >だいたクラスなんて大した数のメソッド持ってないだろ。
> >そんなことで面倒くさがるなら、自動化ツールで自動生成すればいい。
> Javaはtypedef一つするにしてもそんな面倒なことやらなきゃいけないんですね。
そもそも、typedefに拘ること自体、くだらない。
実装多重継承ができないくらいでいらいらするなんぞ恥ずかしいこと。
君が、無駄にメソッドを大量生成するというeXtreme Programmingの鉄則に
反する愚かな行いをしていることはよくわかった。
> >> あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
> >> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。
> >『鉄則：分割し、統治せよ。』
> 受け答えが成立していません。誤魔化さずに真面目に答えてください。
やはり、お前は人の話を聞かず、
オブジェクト指向を否定し、「アジャイルソフトウェア開発」までをも否定するというのか。
君は本当にそんなにGenericsのGenericsになってる「長い型」が本当に必要なのか
今一度、考え直すべきだ。
君の性格のことだから、配列でも同じようなことをやっているのだろう。
君はおそらく、多次元配列を作って混乱しているのだろう。
それに有用性があるというならわかる。
そうでもないにもかかわらず多次元配列に拘っているようだったら、考え直せ。
だからこそ、分割し、統治せよ、と説いているのだ。君は「解放・閉鎖原則」についてもっとよく勉強すべきだ。
君は、KISSについても勉強すべきだろう。
0699デフォルトの名無しさん
2007/02/22(木) 20:32:135つのクラス設計原則(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
汎用的なひとつのインタフェースよりも、多くの特化したインタフェースを利用する。
0700デフォルトの名無しさん
2007/02/22(木) 20:33:16The 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.
再利用できるのはクラスではなく一連のグループ。
0701デフォルトの名無しさん
2007/02/22(木) 20:33:33The 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.
0702デフォルトの名無しさん
2007/02/22(木) 20:33:48C++ができるとは言わせないぞ！
0703デフォルトの名無しさん
2007/02/22(木) 20:35:26ゆえに、JavaScriptは厳密にはオブジェクト指向言語ではない。
ゆえに、Perlは厳密にはオブジェクト指向言語ではない。
ゆえに、PHPは厳密にはオブジェクト指向言語ではない。
ゆえに、VBは厳密にはオブジェクト指向言語ではない。
ゆえに、Perlは厳密にはオブジェクト指向言語ではない。
0704デフォルトの名無しさん
2007/02/22(木) 20:35:410705デフォルトの名無しさん
2007/02/22(木) 20:39:36以下にロバート・C・マーチンによる書籍『アジャイルソフトウェア開発の奥義』に記載されている
7つの「設計の悪臭」を紹介する。これらのうち、どれか1つでもその傾向が感じられたなら、すで
にわなに陥っていると考えてもよいだろう。
兆候 説明
1. 硬さ 変更しにくいシステム。1つの変更によってシステムのほかの部分に影響が及び、
多くの変更を余儀なくさせるようなソフトウェア
2. もろさ 1つの変更によって、その変更とは概念的に関連のない個所まで壊れてしまうようなソフトウェア
3. 移植性のなさ ほかのシステムでも再利用できる部分をモジュールとして切り離すことが困難なソフトウェア
4. 扱いにくさ 正しいことをするよりも、誤ったことをする方が安易なソフトウェア
5. 不必要な複雑さ 本質的な意味を持たない構造を内包しているようなソフトウェア
6. 不必要な繰り返し 同じような構造を繰り返し含み、抽象化してまとめられる部分がまとまっていないソフトウェア
7. 不透明さ 読みにくく、分かりにくい。その意図がうまく伝わってこないソフトウェア
ロバート・C・マーチンによる7つの設計の悪臭
0706デフォルトの名無しさん
2007/02/22(木) 20:39:41Javaを批判するC++厨にはこの悪臭のニオイがプンプンとする
以下にロバート・C・マーチンによる書籍『アジャイルソフトウェア開発の奥義』に記載されている
7つの「設計の悪臭」を紹介する。これらのうち、どれか1つでもその傾向が感じられたなら、すで
にわなに陥っていると考えてもよいだろう。
兆候 説明
1. 硬さ 変更しにくいシステム。1つの変更によってシステムのほかの部分に影響が及び、
多くの変更を余儀なくさせるようなソフトウェア
2. もろさ 1つの変更によって、その変更とは概念的に関連のない個所まで壊れてしまうようなソフトウェア
3. 移植性のなさ ほかのシステムでも再利用できる部分をモジュールとして切り離すことが困難なソフトウェア
4. 扱いにくさ 正しいことをするよりも、誤ったことをする方が安易なソフトウェア
5. 不必要な複雑さ 本質的な意味を持たない構造を内包しているようなソフトウェア
6. 不必要な繰り返し 同じような構造を繰り返し含み、抽象化してまとめられる部分がまとまっていないソフトウェア
7. 不透明さ 読みにくく、分かりにくい。その意図がうまく伝わってこないソフトウェア
ロバート・C・マーチンによる7つの設計の悪臭
0707デフォルトの名無しさん
2007/02/22(木) 20:40:44原則名 説明
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）
クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない
0708デフォルトの名無しさん
2007/02/22(木) 20:42:36クラスの「役割（責任）」＝「変更理由」は1つに絞るべきである。
クラスが複数の役割を持っていれば、クラスを変更する理由も複数になってしまう。
また複数の役割を持ったクラスの役割は互いに結合してしまい、片方を変更すれ
ばその変更の影響が他方にも影響してしまう。つまり、複数の理由から1つのクラ
スを変更することがないようにすべきである。
2. オープン・クローズドの原則（OCP：Open-Closed Principle）
モジュールの振る舞いが拡張可能であれば、「拡張に対して開かれている」といえる。
また、モジュールの振る舞いを変更しても、既存のソース・コードやバイナリ・コードが影
響を受けることがなければ、「修正に対して閉じている」といえる。矛盾しているように思え
るこの2つの属性は「抽象」と「ポリモーフィズム」で実現できる。抽象クラスやインターフ
ェイスを定義して、その派生クラスを新たに追加すれば、既存のコードを修正することな
くモジュールの振る舞いを拡張できる。
0709デフォルトの名無しさん
2007/02/22(木) 20:42:453. リスコフの置換原則（LSP：Liskov Substituion Principle）
クライアントが使用している基本クラス型を派生クラス型に置き換えても正常に動作しなくては
ならない。そのためには派生クラスは基本クラスの振る舞いの妥当性を維持する必要がある。
基本クラス以下の機能しか持たない派生クラスは、基本クラスと置き換えることはできない。
バートランド・メイヤーによって提唱された「契約による設計（DBC：Design By Contract）」を使用
すれば、この原則を適用できるようになる。「契約による設計」では、クラスの振る舞いを、クラスが
持つ各メソッドの事前条件と事後条件、クラスの不変条件によって明文化する。
.NETにおいて契約による設計を行うには、Debugクラス（System.Diagnostics名前空間）のAssert
メソッドを使用してアサーションを行い、契約に対する違反を検出する方法がある。またもう1つの
方法としてユニットテストがある。ユニットテストはクラスの振る舞いに関する契約を記述し、チェッ
クするための有効な手段である。
0710デフォルトの名無しさん
2007/02/22(木) 20:43:014. 依存関係逆転の原則（DIP：Dependency Inversion Principle）
従来の手続き型プログラミングでは、上位レベルの方針が下位レベルの実装に依存してしまう。
これでは、実装の詳細を担当する下位モジュールの変更が上位モジュールにまで及び、その変
更を余儀なくされてしまう。オブジェクト指向プログラミングでは、「抽象」を導入することでその依
存性を逆転させる。つまり上位レベルで「抽象インターフェイス」を定義し、下位レベルでこの「抽象
インターフェイス」を実装する。このようにして方針と実装の詳細をともに「抽象インターフェイス」に
依存させるのだ。
上位レベルのモジュールをクライアントとして考えた場合に、従来の方法では、下位レベルのモジュ
ールのインターフェイスにクライアントが依存していた。つまり、本来クライアントが受けるべきサービ
スのインターフェイスの所有者は、下位レベルのモジュールであると考えられる。しかし、この原則に
従えばクライアント側でサービスのインターフェイスを宣言することになり、「インターフェイスはクライ
アントに属する」ことになる。オブジェクト指向設計では、このようにインターフェイスの所有権を逆転
させることがとても重要になってくる。
5. インターフェイス分離の原則（ISP：Interface Segregation Principle）
クラスを利用するクライアントが複数存在するような場合に、各クライアントに共通の大きなインタ
ーフェイスを利用させてしまうと、各クライアントは利用しないメソッドにまで依存してしまう。つまり、
各クライアントが利用していないメソッドに対する変更の影響まで受けてしまう可能性があるというこ
とだ。そこで各クライアントが呼び出す必要のあるサービスの単位でクライアントをグループ分けし、
そのグループに特化したインターフェイスを準備することで、異なるサービス間での関連性を分断す
ることが可能となる。
0711デフォルトの名無しさん
2007/02/22(木) 20:43:45typedef で追いつめられたから必死で流そうとしてるのか
0712デフォルトの名無しさん
2007/02/22(木) 21:03:05>そもそも、typedefに拘ること自体、くだらない。
これは敗北宣言（= Javaではtypedefは実現できない）とみなしてよろしいですね？
あなたが挙げた方法のいずれもtypedefの簡便さに比べると相当劣っているどころか
いちいち面倒な作業を要求されるように見えます。
KISSについてご存じなようですが、あなたのやり方はシンプルからはほど遠いものだと思います。
>君が、無駄にメソッドを大量生成するというeXtreme Programmingの鉄則に
>反する愚かな行いをしていることはよくわかった。
いわれのないレッテル貼りはやめてください。typedefと関係ありません。
>君は本当にそんなにGenericsのGenericsになってる「長い型」が本当に必要なのか
>今一度、考え直すべきだ。
Genericsという仕組みがある以上型名が長くなるのは仕方ないと思いますが
そのような型を使ってはいけないと言うのですか？
それはGenericsの柔軟性を大きく損なう行為ではないでしょうか。
0713デフォルトの名無しさん
2007/02/22(木) 21:06:52なぜ追いつめられたことにするのかな？
現実逃避か？
0714デフォルトの名無しさん
2007/02/22(木) 21:07:14> >>698
> >そもそも、typedefに拘ること自体、くだらない。
> これは敗北宣言（= Javaではtypedefは実現できない）とみなしてよろしいですね？
なにその悔しまみれな発言w
0715デフォルトの名無しさん
2007/02/22(木) 21:07:42C++はグローバル変数や関数使えるんだろ？
マクロで糞仕様にもできるんだろ？
c++でOOPじゃない糞コードは山ほどあるだろ。
0716デフォルトの名無しさん
2007/02/22(木) 21:08:12それに、C++厨はオブジェクト指向設計の原則も守れないことを
認めてしまったか
0717デフォルトの名無しさん
2007/02/22(木) 21:34:570718デフォルトの名無しさん
2007/02/22(木) 21:35:05Javaのジェネリクスだとそう何重にもネストして使うことは少ない気がする。
最近のC++はOOPよりもジェネリックプログラミングや
テンプレートメタプログラミングに傾斜していて、
JavaはOOP一筋を貫いているという違いからだろうけど。
それとは関係ないが、>>686を見てみると、
「とんでもないネーミングをした奴のコード」と書いてあって、ジェネリクスには一言も触れていない。
つまりそう頻繁にはやらないということを前提で書いているように俺は思う。
それに対して、ジェネリクスであっという間に長い型名が出来てしまうが、その度に
そんな面倒なことはやりたくないと言ったら、話が噛み合わなくなるのは当然かなという気がする。
0719デフォルトの名無しさん
2007/02/22(木) 21:52:45どこに書いてあるの
0720デフォルトの名無しさん
2007/02/22(木) 21:55:03古臭い仕組みを使って表現しないといけないというのはなんとなく腑に落ちない
別の表現形式を考えたほうがいいのかもな……
そのうちジェネリックスに特化した構文が出てくると思う。
0721デフォルトの名無しさん
2007/02/22(木) 21:55:12金庫には本来金しか入れないわけだが、このC++厨は金以外のものでも
くだらないものでも何でも入れたがる。
だから、どんな型のブツが入るかわからないから、パラメタライズしておきたい
って話だろう。
普通の人間なら、金しか入れないので、そこに入れるものは金だけだと
わかっているのでそのクラスをいちいちパラメタライズしない。
class Coffer {
private Money money;
//その他の情報
}
ところがこのC++厨は・・・・
class Coffer<List<List<T>>, List<List<貴重品>,List<List<骨董品>>> ........ > { }
などなどとなんでもかんでも詰め込みすぎる。
こういう価値観の違いがあるのではないだろうか？
0722デフォルトの名無しさん
2007/02/22(木) 21:56:16普通は、クラスを分割するものなんだけどねえ
0723デフォルトの名無しさん
2007/02/22(木) 21:57:29みたなもの作ってメソッド引数に入れるってことも普通は考えるのだが。
C++厨はどこまでも拘る。
0724デフォルトの名無しさん
2007/02/22(木) 21:58:47よっぽどtypedefが効いたんだな
0725デフォルトの名無しさん
2007/02/22(木) 22:08:28そういう例なら人間が詰め込もうと思ったからテンプレート引数が長くなっている。
JavaでだってC++でだってまともな人間はそんなコードは書かない。
C++では何気なくBoostなどのテンプレートを多用するライブラリを使うと、
使っている人間は意識していないのに、気が付けば巨大なテンプレート引数の並びが生まれる。
それが関わったコンパイルエラーに遭遇して初めてその巨大さを知らされる羽目となる。
今のC++はそこが嫌だね。0xでどうなるか見物だけど。
0726デフォルトの名無しさん
2007/02/22(木) 22:13:50全然反論になってないよ。
人の話を聞けないからそういうレスしかできないんだね
0727デフォルトの名無しさん
2007/02/22(木) 22:15:43> >>721
> そういう例なら人間が詰め込もうと思ったからテンプレート引数が長くなっている。
> JavaでだってC++でだってまともな人間はそんなコードは書かない。
このスレにいるtypedef馬鹿をいると、とてもそうとは思えないんだよな。
やけにやたらとtypedefに拘るということは、
彼はまともな人間ではないC++厨ということか。
> C++では何気なくBoostなどのテンプレートを多用するライブラリを使うと、
> 使っている人間は意識していないのに、気が付けば巨大なテンプレート引数の並びが生まれる。
それがおかしい。オブジェクト指向設計原則を守っていない証拠
0728デフォルトの名無しさん
2007/02/22(木) 22:21:320729デフォルトの名無しさん
2007/02/22(木) 22:23:09君が連投してないということを示すために
書き込んだレス番号のリストを教えて欲しい。
0730デフォルトの名無しさん
2007/02/22(木) 22:32:55>それに、C++厨はオブジェクト指向設計の原則も守れないことを
>認めてしまったか
このへんはまさにいろんな制限に縛られるのが大好きなマゾっ子Java厨の発想だな。
その時々でさまざま選択ができる自由とそれらに伴うメリットとリスクを抱えて歩むのがC++厨だ。
0731デフォルトの名無しさん
2007/02/22(木) 22:37:09馬鹿だとか厨とか言われてもなあ。
0732デフォルトの名無しさん
2007/02/22(木) 22:41:04どこが？
0733デフォルトの名無しさん
2007/02/22(木) 22:41:55>>708-710 について、C++厨の俺が思うに
>1
あの忌まわしき「多重継承」によって、C++はJavaのinterfaceの行っている
「実装とインターフェースの分離」以上の機能の分割も可能にしている。
テンプレート・メタプログラミングでよく使われる「ポリシー･クラス」がその例だ。
>2
もちろん、C++にもJavaと同じ「データ抽象」と「ポリモルフィズム」がある。
C++にはそれに加え、型自体を抽象化できる仕組みがある。
例えば、STLはコンテナ・イテレータ・アルゴリズムに抽象化した。
そして、ユーザ定義のコンテナ・イテレータ・アルゴリズムを、既存のコードの変更無く投入できるコンパイル時ポリモルフィズムがある。
>3
C++では、public継承して作成されたクラスは、その親クラスとしての振る舞いも求められる。
C++で契約による設計を行いたければ、コンストラクタでのチェックに加え、NVIパターンを使えばよい。
公開するインターフェースとカスタマイズ可能な振る舞いを分割することは、
基本クラスでの事前条件・事後条件のチェックの機会を与える。
>4
もちろん、C++の持つ「データ抽象＋仮想関数による振る舞いの変更」は、Javaと同等。
さらに、上記3でも指摘したように、NVIパターンを使えば基本クラスから派生クラスへと
カスタマイズできる振る舞いの範囲に制約を課し、より上位レベルからの扱いが安全に行える。
>5
あの『オブジェクト指向における再利用のためのデザインパターン』がC++書かれているように、
その分離は自然に行える。
0734デフォルトの名無しさん
2007/02/22(木) 22:42:22おかしな奴だ。
それでマゾ？
なら、お前は道路に放り出されて
車に轢かれてもかまわないというのだな？
お前みたいに、馬鹿みたいにわざわざ、車の通りが激しい
渋滞もしていない高速道路を徒歩で横断するのがC++厨なのかw
0735デフォルトの名無しさん
2007/02/22(木) 22:44:02で、それらの鉄則をすべて守ることはできるのかな？
日頃から、ドライバ開発や組み込み系しかやってない
馬鹿には守ることができなさそうなことだが
0736デフォルトの名無しさん
2007/02/22(木) 22:48:44下を見ればどうしようもない奴がいることは十分承知。
#中身への言及じゃないことに萎えた
#そんなこと言い出したらJavaでも、なんでもかんでもpublicとかstaticにしていくバカがいるからダメだ
#・・といえてしまう orz
0737デフォルトの名無しさん
2007/02/22(木) 22:49:24なんか過剰反応してんなぁ。マゾっ子とは表現したけど、別にそれ自体は俺も悪いこと
だとは思わんし、C++はよくも悪くもアウトローの言語だ。
>なら、お前は道路に放り出されて
放り出されるんじゃない。自ら飛び出ることができるんだ。
>お前みたいに、馬鹿みたいにわざわざ、車の通りが激しい
>渋滞もしていない高速道路を徒歩で横断するのがC++厨なのかw
ごめん、なに言ってんのかわかんない。日本語でおk
0738デフォルトの名無しさん
2007/02/22(木) 22:49:56ねえ、どのレスを書いたか教えてよ
0739デフォルトの名無しさん
2007/02/22(木) 22:51:37C++だとtypedefなしにテンプレートはまともに使えない。
だからtypedefがないJavaでジェネリクスが使えると信じられない奴が出てくるのは全然不思議ではない。
そういう奴はC++のテンプレートとJavaのジェネリクスは同じようなものだと思っているからたちが悪い。
class Hoge;
typedef Foo<Hoge> FooX;
typedef Bar<FooX> BazType;
BazTypeの実態はBar<Foo<Hoge> >、これはわざとらしいけど、
実際これに近い感じでテンプレート引数は膨れていく。
> オブジェクト指向設計原則を守っていない証拠
ある意味当然だ。Boostなどはもはやオブジェクト指向プログラミングとは別次元の世界と化している。
勿論そっちにはそっちの流儀の設計原則があって
それを守っているはずだ（すまん、そこまで俺は知らない）。
0740デフォルトの名無しさん
2007/02/22(木) 22:56:37> 放り出されるんじゃない。自ら飛び出ることができるんだ。
みんなそういうけど、そのつもりがなくても慣れないと
気が付いたら飛び出てしまっていることがあるのもまた事実。
折角の防御機構だって入門書レベルで扱われることはまず無い。
放り出されると言われても現状では仕方が無い。
0741デフォルトの名無しさん
2007/02/22(木) 22:58:12>>アウトローの言語
言い得て妙の表現ですな。ほんとにその通りｗ
C++というのは、お行儀の良いコードを書くこともできるし、コンパイラを軽くだまくらかすこともできるし、無茶苦茶もできる。
コンパイラもそれを拒絶しない言語だもんね。
言語設計に信念のあるJavaとは本質的に違うし競合もしないのに、何で皆ムキになるのかね。
ピザとピザパンはどっちが美味いかと喧嘩してるようなもんだ。
0742デフォルトの名無しさん
2007/02/22(木) 23:03:10>ピザとピザパンはどっちが美味いかと喧嘩してるようなもんだ。
そりゃ絶対に譲れんな、ピザ(C++)のほうが美味しいに決まってる！
0743デフォルトの名無しさん
2007/02/22(木) 23:07:08だから「オブジェクト指向設計原則」を守るべきだと
0744デフォルトの名無しさん
2007/02/22(木) 23:09:23> >>734
> なんか過剰反応してんなぁ。マゾっ子とは表現したけど、別にそれ自体は俺も悪いこと
> だとは思わんし、C++はよくも悪くもアウトローの言語だ。
> >なら、お前は道路に放り出されて
> 放り出されるんじゃない。自ら飛び出ることができるんだ。
やってることが、北朝鮮の瀬戸際外交だな。
> >お前みたいに、馬鹿みたいにわざわざ、車の通りが激しい
> >渋滞もしていない高速道路を徒歩で横断するのがC++厨なのかw
よめねえのか。
廃墟のように車の通りが一切無いかまたは
渋滞していれば高速道路を横断しても車に轢き殺されずに済むって事だろ。
通常通りなら、時速100kmの車に轢き殺されてあの世に逝く確率の方が非常に高い。
そういうこと。
0745デフォルトの名無しさん
2007/02/22(木) 23:09:40書き換え禁止で参照返せないじゃん。
0746デフォルトの名無しさん
2007/02/22(木) 23:10:21まぁ、それが怖いヤツは決められたレールの上だけ歩いてなさいってこった。
それは確かに安全なことだし悪いことじゃない。が、安全なハズのレールの
上だって事故が起きないわけじゃないってことをお忘れなく。
0747デフォルトの名無しさん
2007/02/22(木) 23:11:23ピザでも食ってろデブ
0748デフォルトの名無しさん
2007/02/22(木) 23:11:37final
0749デフォルトの名無しさん
2007/02/22(木) 23:12:59マルチパラダイムなC++はピザパンのほうだな。
0750デフォルトの名無しさん
2007/02/22(木) 23:13:02あれは本当いただけないな。Javaの安全志向の設計から外れてる。
ところでこの件に関してゴスリンは設計ミスだったと今は思ってんの？
それともそんなんJavaには要らねぇよって今も主張してんの？
0751デフォルトの名無しさん
2007/02/22(木) 23:14:56ちがうでしょ。
immutable
0752デフォルトの名無しさん
2007/02/22(木) 23:18:53それもfinalで実現できる。不変クラスでググレ
0753デフォルトの名無しさん
2007/02/22(木) 23:26:590754デフォルトの名無しさん
2007/02/22(木) 23:31:34よく聞こえませんよ？
日本語でおｋ
0755デフォルトの名無しさん
2007/02/22(木) 23:32:180756デフォルトの名無しさん
2007/02/22(木) 23:33:430757デフォルトの名無しさん
2007/02/22(木) 23:35:16ジョークみたいだけどな
0758デフォルトの名無しさん
2007/02/22(木) 23:36:100759デフォルトの名無しさん
2007/02/22(木) 23:36:320760デフォルトの名無しさん
2007/02/22(木) 23:36:48だから～、不変クラスの意味でimmutableって言ったんだけど。
finalキーワードだけでは実現できないでしょーが。
0761デフォルトの名無しさん
2007/02/22(木) 23:37:26どうりでC++Templateばかりやってると頭禿げるわけだ
0762デフォルトの名無しさん
2007/02/22(木) 23:39:06Java好きな人ってこんなキモい人ばっかなの？
付き合いたくない……
0763デフォルトの名無しさん
2007/02/22(木) 23:44:50おおむね、finalキーワードを中心にできているようなもんだあれは。
クラスとメソッド引数をすべてfinalにして、フィールドはprivate finalにして
setterメソッドを作らず、コンストラクタとgetterメソッドを使うときは
すべてclone()でコピーしてから代入する。
配列やコレクションだと、それらの要素にまで影響が及ばないように
ちょっと面倒くさいことをするが、Collectionsクラスを使えばどうってことでもない。
0764デフォルトの名無しさん
2007/02/22(木) 23:45:24またそんな煽り
C++好きな人ってこういう言い訳しかできないの？
付き合いたくない・・・・
0765デフォルトの名無しさん
2007/02/22(木) 23:45:47プーチン大統領のことだったんだ
0766デフォルトの名無しさん
2007/02/22(木) 23:46:04何がいいたいの？
0767デフォルトの名無しさん
2007/02/22(木) 23:46:29http://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のサンプル発見
0768デフォルトの名無しさん
2007/02/22(木) 23:48:53全然関係ない話を延々コピペしてるし
0769デフォルトの名無しさん
2007/02/22(木) 23:53:03設計原則を守れないとは、さすがアウトローＣ＋＋厨w
0770デフォルトの名無しさん
2007/02/22(木) 23:54:53人工衛星破壊実験でスペースでブリをばらまいて
宇宙環境を破壊して国際社会に迷惑をかける中国共産党みたいだw
さしずめ、Chinese++といったところかwwwww
0771デフォルトの名無しさん
2007/02/22(木) 23:56:30それを>>742みたいに一言「final」なんていった日にゃ、
C++のconstのつもりでfinalを使ってはまる人続出だぞ。
誰向けの回答だよ。
0772デフォルトの名無しさん
2007/02/22(木) 23:56:34かれはサングラスをかけるとエージェントスミスになるクラッカーだからw
C++のほうがウィルスやスパイウェアを作りやすいから、いかにも
プチハゲ(エージェントスミス)って漢字だw
0773デフォルトの名無しさん
2007/02/22(木) 23:59:03多くのJavaプログラマはconstもfinalもただの定数程度にしか思ってないだろう。
ちょっと慣れてくると、finalは一回しか代入できない定数や継承を禁ずるために
あると考えるようになる。確かに、不変クラスのことを知らない奴はﾏﾀﾞ多いな。
配列をfinalにしても配列の要素まではfinalにならない、clone()しなければ不変にならない
ってことを知らない奴もまだいるねえ。JavaのオブジェクトがC++のポインタと同じように
作用することもしらず、「浅いクローニング」「深いクローニング」の意味を知らない奴はまだまだいるねえ
0774デフォルトの名無しさん
2007/02/23(金) 00:01:11世も末だな。
0775デフォルトの名無しさん
2007/02/23(金) 00:05:400776デフォルトの名無しさん
2007/02/23(金) 00:06:04final 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 */ }
}
配列を使うと確かに複雑だ。
0777デフォルトの名無しさん
2007/02/23(金) 00:07:40Javaの static importは使わせたくないな。
やつら、やたらとstaticが好きで過剰に使いすぎるから
0778デフォルトの名無しさん
2007/02/23(金) 00:08:29それしか言えなくなって、だんだん>>770 >>772 >>777みたいになっていくのが哀れ。
0779デフォルトの名無しさん
2007/02/23(金) 00:08:30クラスがイミュータブル・クラスでなければ、書き換え禁止で参照渡しすることはできないんだよね。
どんなクラスでも、イミュータブルにできるわけじゃないし。解決にはならない。
結局、安全面を妥協して書き換え可能な形で参照返すか、実行効率を犠牲にしてコピーを作成するしか無いんだよね。
俺は、普段はC++を使っていて、Javaを毛嫌いしているわけじゃないが、この仕様だけには納得がいかなかった。
0780デフォルトの名無しさん
2007/02/23(金) 00:08:360781デフォルトの名無しさん
2007/02/23(金) 00:09:14その辺がわかってる人だと、何でJavaのStringは不変クラスで、
C++のstd::stringはそうじゃないのか、みたいなことも、
難なく納得してもらえるんだけどなあ。
そうじゃない人は、言語にかかわらずアレだけど。
（ついでに。ごめん、>>771の2行目の「>>742」は「>>748」の間違い。）
0782デフォルトの名無しさん
2007/02/23(金) 00:13:47お前らは走行中のトラックの前に飛び出すことができるなら
引かれて死ぬと解ってても思わず飛び出しちゃうのか？
なるほど、Java厨の為にはガチガチの制限が必要なわけだ。
0783デフォルトの名無しさん
2007/02/23(金) 00:13:48おまえみたいに段々と身も心もstaticにしかなれない奴になるよりはましだよw
0784デフォルトの名無しさん
2007/02/23(金) 00:16:21お前は比喩がわかってない。
お前は、融通が効かない。C++のやりすぎだ。
C++やってるやつには、実際、そうやって死ぬ奴がおおいじゃないか。
0785デフォルトの名無しさん
2007/02/23(金) 00:16:57設計原則を守る人は関係ない話をコピペしてスレを流して良いのか。へえ
0786デフォルトの名無しさん
2007/02/23(金) 00:16:590787デフォルトの名無しさん
2007/02/23(金) 00:17:22設計原則を守りたくないからそういう言い訳しかできないわけか
0788デフォルトの名無しさん
2007/02/23(金) 00:17:37そんなこと言うわりにC++のSTLはオブジェクト指向的じゃない、なんていうじゃん。
「コンテナ」というオブジェクトに、「アルゴリズム」という形でメッセージを送るんだろ。
俺にはオブジェクト指向的に思えるんですが。
ああ、Javaには動的多態しかないからしょうがないか。継承しないと多態できないと信じてるし。
0789デフォルトの名無しさん
2007/02/23(金) 00:17:38誰が巧いこと言えといった
0790デフォルトの名無しさん
2007/02/23(金) 00:18:05で、スレを流したことはどうなのさ
0791デフォルトの名無しさん
2007/02/23(金) 00:18:23Proxyかぶせればどんなインスタンスもイミュータブルに出来るよ。
やらんけど
0792デフォルトの名無しさん
2007/02/23(金) 00:18:32達人プログラマの世界にようこそ。
0793デフォルトの名無しさん
2007/02/23(金) 00:19:09> >>773
> その辺がわかってる人だと、何でJavaのStringは不変クラスで、
> C++のstd::stringはそうじゃないのか、みたいなことも、
> 難なく納得してもらえるんだけどなあ。
だから、JavaにはmutableなStringBuffer, StringBuilderがあるわけだが。
+, +=演算子で文字列連結を使えばimmutableでも構わないってのもあるが(但し、+=は問題外)
> そうじゃない人は、言語にかかわらずアレだけど。
> （ついでに。ごめん、>>771の2行目の「>>742」は「>>748」の間違い。）
0794デフォルトの名無しさん
2007/02/23(金) 00:19:23What?
0795デフォルトの名無しさん
2007/02/23(金) 00:21:35>C++やってるやつには、実際、そうやって死ぬ奴がおおいじゃないか。
そこはあえて否定しないが、GCがあるはずのJavaでメモリリーク起こしたり
ポインタがないはずのJavaでNullPointerException起こすヤツも後を絶たんだろうが。
0796デフォルトの名無しさん
2007/02/23(金) 00:21:35Collectionsやclone()をうまくつかえばどんなクラスでもImmutableにすることは簡単だ。
やたらとImmutableにする意味は無いが。
0797デフォルトの名無しさん
2007/02/23(金) 00:23:49Java人口が増えてきたからな。
ちょっと数年前ならC/C++でもポインタで躓いたやつがぞろぞろいたことだろう。
今じゃ、ぬるぽやクラスパスやらオブジェクト指向で躓く奴が多いな。
C/C++人口が減ってJava人口が増えてきたからそうなっているだけに過ぎないってことよ。
どこの大学もJavaを教えるところばかりだからな。
0798デフォルトの名無しさん
2007/02/23(金) 00:24:34stat・ic, stat・i・cal
()
━━ a. 静止した, 静的な; 【コンピュータ】スタティックな, 固定された状態の; 変化に乏しい, つまらない; 静体の; 静力学の; 【電気】静電［空電］の.
━━ n. （-ic） 静電, 空電（妨害）; 〔米話〕 非難, 批判.
なるほど。
static大好きなC/C++厨＝変化に乏しい,つまらない厨が多い
0799デフォルトの名無しさん
2007/02/23(金) 00:25:080800デフォルトの名無しさん
2007/02/23(金) 00:25:20Java嫌いなC/C++屋はJavaのあら探しをして非難するのが大好き
0801デフォルトの名無しさん
2007/02/23(金) 00:25:51おそらく、C/C++経験者がJavaをやり出した結果に・・・
0802デフォルトの名無しさん
2007/02/23(金) 00:26:240803デフォルトの名無しさん
2007/02/23(金) 00:27:02Javaにこだわりを持ってるのはわかるけどね・・・
intとかの組み込み型と同じように、文字列を扱えるようにするためには、
JavaではStringを不変クラスにする必要があった、ってわけ。
さもないと、文字列を引数にしてメソッドを呼び出すと、その文字列が変わったりするから。
C++なら、メソッド（や関数）の宣言を見て、引数がconst std::string &だったら、
そのメソッドは文字列の中身を書き換えないと期待していいから、
C++のstd::stringは不変クラスにする必要はなかった。
0804デフォルトの名無しさん
2007/02/23(金) 00:29:41詭弁： ごく稀な反例をとりあげる。
メモリリークは本質的にムツカシイところがあるからなあ・・・・・。
でもＧＣ付の言語とそうでないやつを比較することがおこがましい。
それから、ヌルポが起きるんだからいいんじゃないか。嫌なのはヌルポなのにそのまま動いてわけのわからん動作をしたり
脆弱性の原因になるやつな。
0805デフォルトの名無しさん
2007/02/23(金) 00:32:30C++はうまくやらないとこれを見事にぶち壊しにしてしまい、自分自身の作った迷路で数週間悩む事になる。
いや、数週間というのは大げさすぎるかもしれない。
大抵の場合、一生あっても足りないのだから。
0806デフォルトの名無しさん
2007/02/23(金) 00:34:540807デフォルトの名無しさん
2007/02/23(金) 00:39:44俺が言いたかったのはいろいろとユーザに制限を課しているわりには
リスクから守りきれてないじゃないかってこと。
0808デフォルトの名無しさん
2007/02/23(金) 00:51:52C++厨は有害に感じるなぁ。
0809デフォルトの名無しさん
2007/02/23(金) 00:52:36その例だとどちらも制限からの脱却に思えるんだが。
ＧＣがあったほうが、変な解放コードいらんし、ヌルポ吐いてしてくれたほうが、回避処理書かなくてすむ。
0810デフォルトの名無しさん
2007/02/23(金) 00:53:54そういうこと。ＧＣとかＯＯＰＬのイロハも知らずにＣ＋＋最強！！！とか思ってるやつが威張ってるから困る。
0811デフォルトの名無しさん
2007/02/23(金) 00:55:42>ＧＣがあったほうが、変な解放コードいらんし、
そのハズなのにメモリリークするなんて、なんかおかしくね？
>ヌルポ吐いてしてくれたほうが、回避処理書かなくてすむ。
そもそもポインタがないハズなのにヌルポを気にせにゃならんて、なんかおかしくね？
0812デフォルトの名無しさん
2007/02/23(金) 00:57:29脆弱性の原因になる/誤動作を引き起こす→例外を吐いて終了する
絶対に開放できないメモリリーク→参照が切れていないオブジェクトを発見すれば開放できるメモリリーク
リスクもバグ特定のコストも格段に変わっていると思うけどな。
0813デフォルトの名無しさん
2007/02/23(金) 00:58:190814デフォルトの名無しさん
2007/02/23(金) 01:48:34煽ると、髪の毛が抜けてくる香具師がいるからほどほどにしとけよw
0815デフォルトの名無しさん
2007/02/23(金) 02:27:33Java いじめっこ でも根本がいつも危うい柱で成り立っているので、コツを掴めば簡単に形勢逆転
0816デフォルトの名無しさん
2007/02/23(金) 02:31:54鉄壁を破るのは容易ではないぞ
0817デフォルトの名無しさん
2007/02/23(金) 02:45:19java信者を装ったC++工作員おつ
0818デフォルトの名無しさん
2007/02/23(金) 02:48:13> >>809
> >ＧＣがあったほうが、変な解放コードいらんし、
> そのハズなのにメモリリークするなんて、なんかおかしくね？
メモリリークを起こす確率がC++とくらべうんと低いんだけど。
それだけでもアドバンテージはでかいけど。
それだけに旧来のバグが少ないソフトウェアも産みやすくなったわけだし。
> >ヌルポ吐いてしてくれたほうが、回避処理書かなくてすむ。
> そもそもポインタがないハズなのにヌルポを気にせにゃならんて、なんかおかしくね？
Javaにもポインタはあるけど
0819デフォルトの名無しさん
2007/02/23(金) 02:50:42マ板では「年寄り(C/C++)が若者（Java）を苛めているという構図」というスレがあったのに
今ではその形成もとっくのとうに逆転しているのかw
まるで、将来日本でも起こりそうな、年金問題や外交問題などを巡る世代間対立みたいだなw
0820デフォルトの名無しさん
2007/02/23(金) 05:29:330821デフォルトの名無しさん
2007/02/23(金) 06:01:50普通の値と同じように、オブジェクトへのポインタの値をコピーして渡すわけだから、
そのオブジェクトのメソッドで内部を書き換えることは出来てもオブジェクトの参照自体を変えることはできないよね。
finalは値が一回しか入らないことだけを約束するわけだけど、メソッド引数は値を書き換える意味がない以上、常にfinalでも差し支えないはず。
返り値に加えたり、別の引数オブジェクトにセットしたりすれば別だけど。というかそれの互換のためだけに何も言わないんじゃないのかと
0822デフォルトの名無しさん
2007/02/23(金) 06:58:24Java厨 ： 実行環境に無駄に自信がある
0823デフォルトの名無しさん
2007/02/23(金) 11:23:29>intとかの組み込み型と同じように、文字列を扱えるようにするためには、
というより、ハッシュの理由の方が大きいと思う。
ハッシュが正しく働くためには、生成から消滅まで固定のhashCodeが必要だけど、
文字列がmutableになると、実現が難しい。
0824デフォルトの名無しさん
2007/02/23(金) 12:06:42そうかな？HashSetやHashMapが内部でclone()を呼び出すようになってれば、
使う側はmutable/immutableを気にしなくて済んだはずだと思うけど。
この辺の設計については、安全性よりパフォーマンスを取ったんだと思う。
0825デフォルトの名無しさん
2007/02/23(金) 16:50:30> よく考えてみたらJavaはプリミティブもオブジェクトも値渡しなんだからメソッド引数はすべてfinalでよくね？
値渡しはプリミティブだけだが。
0826デフォルトの名無しさん
2007/02/23(金) 16:58:05んなことはない。finalにしないメリットは
mutableでデータを頻繁に操作できることにある
0827デフォルトの名無しさん
2007/02/23(金) 16:59:23clone()つかっても扱われるオブジェクトのclone()が
ちゃんと深いクローニングを実装していなければ本末転倒だし
0828デフォルトの名無しさん
2007/02/23(金) 17:01:20意味としては>>821ってことだろ。これを値渡しって表現するのは間違いだと思うが。
オブジェクトの参照を渡すのに、参照の値をコピーして渡してるから値渡しって言うなら、
機械語レベルではあらゆる言語が値渡しになる。
いや、レジスタで渡すんだから、純粋な参照渡しのみか？
引数全てにfinalってのは普通。finalついてなかったらwarning出すってのは、
最近だとCodeCheckとか使わなくても、コンパイラで出せるんじゃなかったっけ？
0829デフォルトの名無しさん
2007/02/23(金) 17:04:06仮引数にfinalつけたところで、immutableになるわけじゃない。
仮引数のfinalとその値のmutable性は別の問題。
constとは違う。
0830デフォルトの名無しさん
2007/02/23(金) 17:26:01あ、そういわれれば。
immutableもdeepcopyも、静的にチェックできないという点では同じか。
0831デフォルトの名無しさん
2007/02/23(金) 17:56:41> >>825
> 引数全てにfinalってのは普通。finalついてなかったらwarning出すってのは、
> 最近だとCodeCheckとか使わなくても、コンパイラで出せるんじゃなかったっけ？
でない。CheckStyleのみ
0832デフォルトの名無しさん
2007/02/23(金) 17:57:23んなことわかってる。
Wikipediaあら引用した上のサンプルコードみたいな個として初めて不変
0833デフォルトの名無しさん
2007/02/23(金) 20:13:26> 値渡しはプリミティブだけだが。
おいおい。Javaには参照渡しはないぞ。
0834デフォルトの名無しさん
2007/02/23(金) 20:19:18> これを値渡しって表現するのは間違いだと思うが。
もとっから、そーゆー定義だから仕方ない。
辞書に文句つけても仕方あるまい。
0835デフォルトの名無しさん
2007/02/23(金) 21:00:300836デフォルトの名無しさん
2007/02/23(金) 21:26:39渡してるものは結局参照なんだから参照渡しって言う方が妥当。
0837デフォルトの名無しさん
2007/02/23(金) 22:04:43と毎回断らないといけないのが面倒だったんじゃね？
0838デフォルトの名無しさん
2007/02/23(金) 22:30:090839デフォルトの名無しさん
2007/02/23(金) 22:30:310840デフォルトの名無しさん
2007/02/23(金) 22:31:14残念なことにJavaを超える仕様ではなかった。
次は、D言語に期待せざるを得ない。
0841デフォルトの名無しさん
2007/02/23(金) 22:33:00ｋｗｓｋ
0842デフォルトの名無しさん
2007/02/23(金) 22:36:42いや、そんなオレ用語の定義について一生懸命語られても……
0843デフォルトの名無しさん
2007/02/23(金) 22:39:47過去の遺産をシガラミとしてひきずっているため(ry
0844デフォルトの名無しさん
2007/02/23(金) 22:40:14もちょっとｋｗｓｋ
0845デフォルトの名無しさん
2007/02/23(金) 22:42:32「参照を渡してるから参照渡しと呼ぶべき」とか言う馬鹿を相手にする方が面倒だと思う。
0846デフォルトの名無しさん
2007/02/23(金) 23:01:01●C言語時代の負の遺産、そして柵(シガラミ)と悪しき伝統
●年寄りのように変化を否定(XPの「変化ヲ抱擁セヨ」に反する)
●メモリリークを頻発する野蛮な配列外アクセス・オーバーフロー
●モジュール間の関係を密にしてしまうストーカーのようなグローバル変数
●神聖なるソフトウェア工学を否定するDLL HELL
●酷く薄汚いスパゲティコードを生み出すヘッダファイル
●不審で不明な使途にも利用可能な構造体、共用体、typedef
●不審で不明な使途にも利用可能なテンプレート
●素晴らしいほどに無駄に余計なvirtual修飾子
●あの忌まわしきハンガリアン記法を助長する言語仕様
●ダイヤモンドのようにブライト(bLight)に輝く実装多重継承
●しかしそのダイヤモンドには決して明るい(BRIGHT)輝きはなく
荒廃(BLIGHT)とした破滅(BLIGHT)を持つ二つの伝統を引き継ぐ
●暗黒時代から引き継がれたstring
●失われた古代の技術Smalltalkをも否定するstaticなプログラマを量産するグローバル関数
●規格・仕様の乱立。そして10年前のプログラムもコンパイルできない(規格が乱立する)群雄割拠の世界
●さらなるデスマーチと過労死者を生み出すコードも作ることが可能な腐敗した演算子オーバーロード
0847デフォルトの名無しさん
2007/02/23(金) 23:25:420848デフォルトの名無しさん
2007/02/24(土) 02:43:23自動的に読み替える脳ってのは一体どうやって育まれるのだろう
0849デフォルトの名無しさん
2007/02/24(土) 03:02:13これなんかのコピペ?
自分で考えたの? ｱﾎｼﾞｬﾈｰﾉwww
0850デフォルトの名無しさん
2007/02/24(土) 03:17:52どっちかと言うとＣプログラマーが貴重になってくるだろう
どっちかと言うとJavaのライバルはC#だろ
0851デフォルトの名無しさん
2007/02/24(土) 03:27:25最適化君乙w
0852デフォルトの名無しさん
2007/02/24(土) 03:40:35俺はDを見守るぜ
0853デフォルトの名無しさん
2007/02/24(土) 03:49:18たくさん書いてくれてご苦労さんと言いたいけど。
「それらを読んで理解しただけでは力はつかないよ」と警告しておこう。
理解ではなく認識しないとね。
これって
「まとめて、命名てあり、意思疎通の助けになる」という意味で
「レイヤーの違うデザパタ」みたいだね。
0854デフォルトの名無しさん
2007/02/24(土) 09:11:56テンプレートについては何も意見無しですか。
0855デフォルトの名無しさん
2007/02/24(土) 09:15:15>●不審で不明な使途にも利用可能なテンプレート
書いてあるよ
0856デフォルトの名無しさん
2007/02/24(土) 10:20:24> このスレを見ている人はこんなスレも見ています。(ver 0.20)
>
> 45歳以上の転職Part7 -25 OR 6 TO 4- [転職]
> JR東日本 社会人採用対策スレッド 2006 Part6 [転職]
(;´Д｀)
0857デフォルトの名無しさん
2007/02/24(土) 10:50:01「Javaだけ分かっている奴」から始まる一連のレスに対して、
「両方分かってる奴」が頑張って説明するスレですかね・・・。
0858デフォルトの名無しさん
2007/02/24(土) 11:21:10まあ、ご苦労さん。
0859デフォルトの名無しさん
2007/02/24(土) 13:16:170860デフォルトの名無しさん
2007/02/24(土) 13:26:45多分、君にはそう考える能力はないと思うよ。
君の方が十分アホだからw
0861デフォルトの名無しさん
2007/02/24(土) 13:27:20D言語はどうしたw
0862デフォルトの名無しさん
2007/02/24(土) 13:28:28同じ人が見ているなw
0863デフォルトの名無しさん
2007/02/24(土) 13:29:19それいっちゃ、
大抵のＣ＋＋プログラマ＝C++初心者
ってことになっちまう
0864デフォルトの名無しさん
2007/02/24(土) 13:29:36まさに当てはまる。
0865デフォルトの名無しさん
2007/02/24(土) 13:30:51勘違いしている彼らのことだから
0866デフォルトの名無しさん
2007/02/24(土) 13:39:42生の配列を喜んで使ってたり、何でもかんでもvirtualつけてたり、
C言語のプログラムでもないのにハンガリアンを使ってたり、
不用意にダイアモンド継承を作ったりする人ばっかり？
デスマ確定ですね。ご愁傷様。
0867デフォルトの名無しさん
2007/02/24(土) 14:13:460868デフォルトの名無しさん
2007/02/24(土) 14:27:18読んだことある人も多そうだけど一応紹介。
http://local.joelonsoftware.com/mediawiki/index.php/%E9%96%93%E9%81%95%E3%81%A3%E3%81%9F%E3%82%B3%E3%83%BC%E3%83%89%E3%81%AF%E9%96%93%E9%81%95%E3%81%A3%E3%81%A6%E8%A6%8B%E3%81%88%E3%82%8B%E3%82%88%E3%81%86%E3%81%AB%E3%81%99%E3%82%8B
0869デフォルトの名無しさん
2007/02/24(土) 14:40:10dw 接頭 double word型 dwSize
fp または f 接頭 単精度浮動小数点型 fpPrice
db または d 接頭 倍精度浮動小数点型 dPi
p または lp 接頭 ポインタ型 lpDirectSound
s 接頭 文字列型 sPlayerName
sz 接頭 ゼロ終端文字列型 szFileName
fn 接頭 関数ポインタ型 fnCallback
hwnd または h 接頭 ウィンドウハンドル型(Windowsのみ) hMainWindow
m_ 接頭 クラスのメンバ変数 m_nx
_ 接尾 クラスのメンバ変数 ny_
C 接頭 クラス CHoge
tag 接頭 構造体 tagRECT
まじでこんなことして欲しくないけどな
0870デフォルトの名無しさん
2007/02/24(土) 14:43:05http://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%B3%E3%82%AC%E3%83%AA%E3%83%BC%E8%A8%98%E6%B3%95
出典: フリー百科事典『ウィキペディア（Wikipedia）』
移動: ナビゲーション, 検索
[改名提案] 改名提案：この記事のタイトルに関して「ハンガリアン記法」
に改名が提案されています。詳細はこの項目のノートを参照してください。
ハンガリー記法（ハンガリーきほう、Hungarian notation）とは、プログラマが
プログラムのソースコードを書く際に、変数名やクラス名などの識別子に特
別な接頭文字、または接尾文字をつけることで、他の人がその識別子を見た
ときに、識別子の使用方法・データ型情報・スコープ範囲などを分かるように
するための命名法である。
C/C++のような型をコンパイル時にチェックする機構のある言語においては、
わざわざ型を変数名に付加する必要はないという意見もある（使用法を間違
えればコンパイラが警告・エラーを生成するため）。
なお、ハンガリー記法のハンガリーは考案者がハンガリー出身のプログラマ
ーチャールズ・シモニー(Charles Simonyi)であることに由来する。
本来、シモニーの考案したハンガリー記法とは、変数の意味や使用目的から
接頭辞を決定することであり、型では区別できない情報を変数名に付与するこ
とで、紛らわしい変数の意味を明白にし混同をさけるためのものであった。たと
えば、論理座標とデバイス座標、X軸とY軸、ドルと円などで、これらは単純に
型による安全性に頼ることはできない。
0871デフォルトの名無しさん
2007/02/24(土) 14:50:57まさにそれが、>>868 >>870に書かれてある間違ったハンガリアン記法。
誤解から生まれたシステムハンガリアン記法。
0872デフォルトの名無しさん
2007/02/24(土) 14:54:34ドルと円の混用もコンパイラの型チェックで検査できるから、
ハンガリー記法は完全に無用の長物。
0873デフォルトの名無しさん
2007/02/24(土) 14:55:19ていうか
word型の時点で既に嫌い。
0874デフォルトの名無しさん
2007/02/24(土) 14:58:18opaque typedef が次期標準に入るのは難しい情勢じゃないですかね？
0875デフォルトの名無しさん
2007/02/24(土) 15:01:28あら、そうなの。残念。
0876デフォルトの名無しさん
2007/02/24(土) 15:08:42でも、pBufferはやめるようにした。
pByteBuffer、pIntBufferはやったことない。
ポインタにpじゃなくてlpはねーよな。
文字列は、VCつかっていると
相手に合わせて一時的に型を変えなきゃいけないから
ゼロ終端文字列型（さらにUNICODE、SHIFT-JIS）、
BSTR、VARIANTの文字列、std::stringの区別に使ったりする。
COMやAPI呼ぶ都合で仕方ない。あーふべん。
OS提供のAPIとかが呼べるあたりCのいいところでもあるんだけどね。
STLなどテンプレートライブラリはバイナリ互換じゃないから嫌い。
0877デフォルトの名無しさん
2007/02/24(土) 15:09:49http://en.wikipedia.org/wiki/Hungarian_notation
>>872
早く導入して欲しいね。
コンパイラのチェックは目のチェックとは比較にならないから。
0878デフォルトの名無しさん
2007/02/24(土) 15:21:40pBufferって、newとかmallocでやってるの？
俺は可能な限りstd::vector<unsigned char> buffer;としておいて、
&buffer[0]をpBufferのつもりで使うけど。
OSのAPIを呼び出すのは、どの言語でも面倒（か不可能）だから、
まあしゃーない、とは思うけど。
0879878
2007/02/24(土) 15:24:44STLが嫌いなんだね。
0880デフォルトの名無しさん
2007/02/24(土) 15:34:03そう思うなら、Wikipedia更新して
0881デフォルトの名無しさん
2007/02/24(土) 15:36:22いずれにしてもハンガリアンは魅力的じゃないな
0882デフォルトの名無しさん
2007/02/24(土) 15:46:30いままであまり使っていないし深く理解してないので
これからもあまり使わないだけ。
高速化の話とか仕事でよく出てくる。
最初に必要なメモリ確保して以降new/deleteしないほうがいいよねっていわれちゃった。
そんなの無視してstd::vectorやnew/deleteしまくっているけど。
DLL化の話が出るので引数にstd::string使うのまずいだろうな～
でも特定のバージョンのVCからしか使わないから構わないとか
> std::vector<unsigned char> buffer;
それいいよね。使ったことあるけど普段使ってない。
早くboostが標準になんねーかな。
std::vector<std::auto_ptr>はできないとか
そもそもstd::auto_ptrの使い道がないとか
STLむずかしーよ。
0883デフォルトの名無しさん
2007/02/24(土) 15:48:51なら、「仮引数の」finalの有無が、そのクラスのmutable性に何の関係があるのか教えてくれ。
単に、
>>821の仮引数は全部finalでいいだろ、ってのに対して、
>>826でフィールドのfinalの有無はmutable性に影響があるって、見当違いな反論しただけか？
0884デフォルトの名無しさん
2007/02/24(土) 15:50:21そこまで気合入ってない。
俺はよそのページのリンク貼るだけ。
>>881
dwとかlpは本来のハンガリアンじゃ無いってレスがしたかっただけ。
実は俺も使う気なかったりする。
0885デフォルトの名無しさん
2007/02/24(土) 15:51:32カタカナ用語とか略語なんてやめて日本語でストレートに言っちゃいな。
0886デフォルトの名無しさん
2007/02/24(土) 15:54:01これってメンバ変数であることが
わっかりやっすい
けど、見た目が
かっこう悪いんだこれ
0887デフォルトの名無しさん
2007/02/24(土) 16:04:27同意。
>>883
const&の話題は>>752が解釈を間違ってるから、そこから先は無意味と思う。
0888デフォルトの名無しさん
2007/02/24(土) 16:08:13必要なメモリが最初からわかってるならできるけど。
特に問題ないならstd::vectorやらstd::mapやらstd::setやら。
あと、高速化については、代入（operator=）を避けて、なるべくswapでやるとか。
DLLでstd::stringは微妙。とりあえずstd::stringにしておいて、
必要ならラッパを書くことでまけといてもらう。
std::auto_ptrは使えない。C++0xで廃止されることを願う（けど無理かも）。
0889デフォルトの名無しさん
2007/02/24(土) 16:15:31何だかカッコよさげな響き
0890デフォルトの名無しさん
2007/02/24(土) 16:18:59非推奨にはなるだろうが互換性のため次期標準ではまだ消えないと思う。
ところで今度提案されているmove_ptrはどう？
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm
0891デフォルトの名無しさん
2007/02/24(土) 16:26:04何だかお風呂が綺麗になりそうな響き
0892デフォルトの名無しさん
2007/02/24(土) 16:33:56shared_ptrとか代替が入ればもちろん不要だけど、
それが無い今は有用だと思うんだが（「標準」という強みがあるから）。
//newするかもしれないし、しないかもしれない。
//でも受け側で消せ、ということがソースから分かる。
auto_ptr<A> a = cache.get();
まぁ俺はboost使いづらいプロジェクトのときは
削除子付きのauto_ptr作ってて、それ使うことが多いけど。
つかmove_ptrでググったら、unique_ptrとか出てくるらしいな。
どんなのか知らんけど。
0893デフォルトの名無しさん
2007/02/24(土) 16:34:09完全には理解してないけど、moveと&&を導入するより、
swapでがんばった方がわかりやすくない？
個人的に、引数に&pBufferを渡すと、指してる先のオブジェクトを交換する、
みたいなことはやってるんで、そう思うだけなのかもしれないけど。
0894デフォルトの名無しさん
2007/02/24(土) 16:35:05move_ptr 単体で語るよりも move semantics 全般で語ったほうが良いような．
move_ptr 単体だけでは auto_ptr とほとんど変わらないというか，
"move" の構文が q = p; から q = std::move( p ); になるだけなんじゃ？
他の move-aware なコンポーネント (たとえば move-aware vector) と組み合わせて
初めて move_ptr の真価が発揮されるような？
あと，現状では move_ptr じゃなくて unique_ptr という名前のほうが優勢な感じかと．
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1771.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html
0895デフォルトの名無しさん
2007/02/24(土) 16:49:49move が可能 (moveble) ならば，効率的で nothrow な swap が自動的に実装できますから，
template< class T >
void swap( T &x, T &y )
{ T tmp( std::move( x ) ); x = std::move( y ); y = std::move( tmp ); }
move を導入できるなら，それに越したことはないと思います．
(逆に swap で move を実装することは本質的には不可能です．
特定の文脈における move は swap で実装可能ですけれど)
ただし，逆に move が不可能で swap が可能な場合も当然存在しうるので，
その場合には swap でがんばるという選択は当然あると思います．
0896デフォルトの名無しさん
2007/02/24(土) 16:50:24何だかいやらしい響き
0897デフォルトの名無しさん
2007/02/24(土) 16:56:00俺としては、自分一人か、
まともにC++使える奴らとなら、C++での開発で良い。
それ以外はjavaとかそっち方面が良いな。
被害を抑えるために。
0898デフォルトの名無しさん
2007/02/24(土) 17:13:50何だかいやらしいのはお前
0899デフォルトの名無しさん
2007/02/24(土) 17:29:36まあ、コンパイラがきちんと面倒見てくれるならOKかな。
T tmp( std::move( x ) ); y = std::move( x );
と書いたらエラーを出してくれるくらいに。
0900デフォルトの名無しさん
2007/02/24(土) 17:40:59それにxの型が組込型などだったら問題なく実行できるだろうし。
0901デフォルトの名無しさん
2007/02/24(土) 17:43:20（少なくとも現状のC++だと）関数の戻り値でswapするのは無理では？
0902デフォルトの名無しさん
2007/02/24(土) 17:46:18std::moveも、言語のセマンティクスでサポートしてほしいかなと。
組み込み型で問題なく実行できたあと、喜び勇んでテンプレートにしたら、
全然動かないなんてつらいでしょ。
0903デフォルトの名無しさん
2007/02/24(土) 18:02:44確かに。その意味でも、moveの方が強力で汎用的。
0904デフォルトの名無しさん
2007/02/24(土) 18:06:120905デフォルトの名無しさん
2007/02/24(土) 18:13:40いや、そもそも接頭辞を付けなきゃならない時点で終わってる。
そんなものつけるべきじゃない。
グローバル変数やグローバル関数を使うのを辞めて
メソッド名はなるべく動詞にして
staticの場合、
クラス名.メソッド名
インスタンスの場合、
インスタンス名.メソッド名
のような表記にすればいい。
0906デフォルトの名無しさん
2007/02/24(土) 18:14:44紅茶はどうした
スターウォーズの宇宙人はどうした。
0907デフォルトの名無しさん
2007/02/24(土) 18:16:29だからグローバル変数を使わなければ
そんな格好悪い記法つかわなくても済むんだって
0908デフォルトの名無しさん
2007/02/24(土) 18:17:43ZopeやらRuby on Railsやらが出るたびにスクリプト言語に
シェアが食われていくJavaの方が先にお亡くなりかもよ。
0909デフォルトの名無しさん
2007/02/24(土) 18:21:36わかっててわざと言ってるような気がするが、
m_ ってデータメンバーにつけるようなヤツは
グローバル変数には g_ ってつける。
これらは引数やローカル変数と区別する為。
0910デフォルトの名無しさん
2007/02/24(土) 18:39:51どう勘違いしたのか分からんけど、グローバルとか動詞とか関係無いから。
意味を元に接頭辞＝アプリケーションハンガリアン。
例えば座標の変数の場合、絶対座標はabsを、相対座標はrelを頭に付けるとかの話。
0911デフォルトの名無しさん
2007/02/24(土) 18:42:01＞std::moveも、言語のセマンティクスでサポートしてほしいかなと。
今 C++0x に向けて提案されている仕様では，return 文においては
move (右辺値参照への変換) を適用できることが自明なので
言語側が自動的に move を適用してくれるようになります．
一方で明示的に std::move が必要な文脈，
つまり他にオブジェクトのエイリアスが存在して破壊的なコピー (move) が
適用できるかどうかを構文からは判断しかねるような文脈では，
言語側が勝手に move を適用するのはまずいですし，言語サポートは無理があるかと．
というか， Java ほとんど関係なくてスレ違いですね．
Java を詳しく知ってる人から見ると move semantics がどう見えるのかは
聞いてみたいんですけれど．
0912デフォルトの名無しさん
2007/02/24(土) 18:53:18みんなポインタで扱えばmove semanticsの出る幕はないだろうからね。
0913デフォルトの名無しさん
2007/02/24(土) 18:58:22Javaに詳しくなくてごめんねぇ。
returnがコピーではなくてmoveだというのは、std::moveが出てくる前から、
最適化の一種として行われていたと思うけど。
明示的にstd::moveが必要な部分でも、変数の初期化忘れをコンパイラが
チェックしてくれるのと同じくらいの厳密さ（いい加減さ）で、
中身がなくなってしまった変数をチェックしてくれるのはアリだと思います。
0914デフォルトの名無しさん
2007/02/24(土) 19:01:43時間的・空間的効率も重視されるC++では値型は重要だし。
>>911
javaはプリミティブ以外に値型が無いから&&演算子自体不要かと。
0915デフォルトの名無しさん
2007/02/24(土) 19:04:03数年前にPerl厨やPHP厨も同じこといってたけど、
Javaは未だになくならないねえ。
JavaとPerlやPHP, Rubyなどの言語とは、そもそも畑違いの世界だから。
世界が違うんだよ。銀行で使われる言語と、たんなるコミュニティサイトでしか
使われないような言語とを比べている時点で終わってる。
0916デフォルトの名無しさん
2007/02/24(土) 19:04:49だったら、グローバル変装のほうにだけg_とつけておいて
メンバのほうには一切付けなくてもいいとおもうんだけどなあ。
どうせなら、そんな名前よりも、名詞形にすればいいのに
0917デフォルトの名無しさん
2007/02/24(土) 19:05:43その表記もイマイチだねえ。
クラス名や名前空間で補った方がいいんじゃないかな
0918デフォルトの名無しさん
2007/02/24(土) 19:11:260919デフォルトの名無しさん
2007/02/24(土) 19:14:57その変には技術的にすごく興味があるけど、C++でやることじゃない。実験をするなら影響の少ない
無人島でやってほしいものだ。
0920デフォルトの名無しさん
2007/02/24(土) 19:16:27そうかなあ。トレンドの振れ幅が大きいのは、
Javaにしかできない、という分野がないからじゃない？
http://www.tiobe.com/tpci.htm
0921デフォルトの名無しさん
2007/02/24(土) 19:17:43ちょっと感情的になってない？
File.getAbsoluteFileとかも普通クラスわけたりしないっしょ？
絶対座標と相対座標を足すことも普通にあるし。
あと別に積極的に使った方が良いとか言ってる訳じゃないよ。
「終わってる」と言う程のことじゃないと思ってるだけで。
0922デフォルトの名無しさん
2007/02/24(土) 19:21:58何だか終わってしまったような響き
0923デフォルトの名無しさん
2007/02/24(土) 19:24:12何だか挑戦的な響き
0924デフォルトの名無しさん
2007/02/24(土) 19:25:06デフォルトでオブジェクトが参照型になっており
clone()メソッドがあるJavaでは気にすることでもなさそうだな。
それに、無駄なコピーは
FlyWeightパターンやProxyパターンで解決できる。
よく使う値はFactory Methodパターンでキャッシュしておくという手もある。
0925デフォルトの名無しさん
2007/02/24(土) 19:26:38場合によりけりだね。
パッケージ名なら、import文で短縮できる。
無駄な接頭辞をつけるよりはまし。
変数宣言の前に、コメント欄に何か書いておくってのもいいと思うし。
0926デフォルトの名無しさん
2007/02/24(土) 19:29:450927デフォルトの名無しさん
2007/02/24(土) 19:30:33それはどうかね。
Javaにしかできないことはあるとは思うけど。
Javaにしかできないわけではないけど、
Java以外の言語でも扱える分野では
例えば基幹系ではCOBOLや.NET、
携帯電話ではBREWがあるけれど
Java以外の言語でもできるからといって
それがよいのかっていうと疑問だけどね。
とくにBREW開発現場の実情は悲惨なものだ。
あれは携帯Java開発よりもひどい。
基幹系ではCOBOLはもう時代遅れで
Javaの優位性には勝てないし。
PHPやPerl, Rubyで金融開発は
できなくもないけど、かなり不向きだと思うね。
そもそも、スクリプト言語は大規模開発には弱いし。
0928デフォルトの名無しさん
2007/02/24(土) 19:32:03それはターミナル
0929デフォルトの名無しさん
2007/02/24(土) 19:33:04それで、Javaでハンガリアン記法を
使って開発効率が上がったという話があるのなら
聞いてみたい。
0930デフォルトの名無しさん
2007/02/24(土) 19:33:14いまいちイメージが掴めない・・・。
座標とかで例をお願い。
0931デフォルトの名無しさん
2007/02/24(土) 19:33:38接頭辞を「無駄」と言い切ってそこまで排除したがる理由って何？
そこでコメントを持ち出すとか本末転倒じゃん。
0932デフォルトの名無しさん
2007/02/24(土) 19:43:07割とオールマイティーにこなせるのが強いという話でさ。
0933911
2007/02/24(土) 19:45:45＞みんなポインタで扱えばmove semanticsの出る幕はないだろうからね。
効率云々の話を置いておいたとしても，ポインタ (参照) だけを使うという発想には
GC の有無も深く関わってくると思うので，そう単純ではないように思います．
>>913
＞中身がなくなってしまった変数をチェックしてくれるのはアリだと思います。
これは move の泣き所だとは思いますけれど……．
空の状態が有効なクラスとそうでないクラスがありえて，その区別は
最終的には意味レベルの話になると思うので
こういうチェックは難しいのではないかなと思います．
>>914
＞javaはプリミティブ以外に値型が無いから&&演算子自体不要かと。
やはりそういうことになりますかね． move は，値型というか
値の深いコピーを基本とする言語 (C++) 特有の発想と言えるのかな．
0934911
2007/02/24(土) 19:47:12＞みんなポインタで扱えばmove semanticsの出る幕はないだろうからね。
効率云々の話を置いておいたとしても，ポインタ (参照) だけを使うという発想には
GC の有無も深く関わってくると思うので，そう単純ではないように思います．
>>913
＞中身がなくなってしまった変数をチェックしてくれるのはアリだと思います。
これは move の泣き所だとは思いますけれど……．
空の状態が有効なクラスとそうでないクラスがありえて，その区別は
最終的には意味レベルの話になると思うので
こういうチェックは難しいのではないかなと思います．
>>914
＞javaはプリミティブ以外に値型が無いから&&演算子自体不要かと。
やはりそういうことになりますかね． move は，値型というか
値の深いコピーを基本とする言語 (C++) 特有の発想と言えるのかな．
0935デフォルトの名無しさん
2007/02/24(土) 19:48:08だから俺は勧めてる訳じゃ無いんだって・・・。俺も使ってないし。
ただ、ちょっとした補足代わりにabsとか付けてる人が居ても悪くは無いっしょ？
0936911
2007/02/24(土) 19:48:14＞みんなポインタで扱えばmove semanticsの出る幕はないだろうからね。
効率云々の話を置いておいたとしても，ポインタ (参照) だけを使うという発想には
GC の有無も深く関わってくると思うので，そう単純ではないように思います．
>>913
＞中身がなくなってしまった変数をチェックしてくれるのはアリだと思います。
確かに，中身のなくなったオブジェクトが晒されるというのは
move の最大の泣き所だとは思いますけれど……．
ただ，空の状態が意味を成すクラスとそうでないクラスがありえて，その区別は
最終的には意味レベルの話になると思うので
こういうチェックは難しいのではないかなと思います．
>>914
＞javaはプリミティブ以外に値型が無いから&&演算子自体不要かと。
やはりそういうことになりますかね． move は，値型というか
値の深いコピーを基本とする言語 (C++) 特有の発想と言えるのかな．
0937デフォルトの名無しさん
2007/02/24(土) 19:48:39Javaならthis.やsuper.があるのがいい。
this.という接頭辞をつけるだけでメンバ変数だとわかる。
時と場合にもよるけれども
省略した接頭辞はわかりにくい。
接頭辞を付けたければできる限りフルネームで。しかもキャメルケースで。
たんなるカウンタ変数ならiでもいい。
0938デフォルトの名無しさん
2007/02/24(土) 19:48:45たとえばget接頭辞とset接頭辞
ﾌﾟｯ！set接頭辞
0939デフォルトの名無しさん
2007/02/24(土) 19:48:49// 絶対値
int a;
// 相対値
int b;
ってので無いことを祈ります。
0940デフォルトの名無しさん
2007/02/24(土) 19:49:01Javaならthis.やsuper.があるのがいい。
this.という接頭辞をつけるだけでメンバ変数だとわかる。
時と場合にもよるけれども
省略した接頭辞はわかりにくい。
接頭辞を付けたければできる限りフルネームで。しかもキャメルケースで。
たんなるカウンタ変数ならiでもいい。
値型と参照型との区別を曖昧にしなければ
ハンガリアン記法はいらない
0941デフォルトの名無しさん
2007/02/24(土) 19:49:43だからグローバル変数と区別する為じゃねぇって言ってんだろが。
つか、グローバル変装ってなんだよ？
0942デフォルトの名無しさん
2007/02/24(土) 19:50:54「しかできない」という視点では見ず、
「Javaで作った方が効率が良い」という視点でみないと
意味がないと思うね。
C++にしかできないことも、今じゃ狭められてきている。
D言語が勢力を拡大し、Javaがドライバ開発や家電方面にまですそ野を広げると
C++にしかできないことはもう本当にごく僅かと限られてくると思うね。
0943デフォルトの名無しさん
2007/02/24(土) 19:51:410944デフォルトの名無しさん
2007/02/24(土) 19:52:01おいおい、C++には絶対に譲れない、他の言語にできないことがあるぞ。
既存のコードの保守、だ。
0945デフォルトの名無しさん
2007/02/24(土) 19:52:02absというとアンチロックブレーキシステムや、ABS樹脂、
絶対値を求めるabs()しか思いつかないなあ
0946デフォルトの名無しさん
2007/02/24(土) 19:52:22そうなれば俺もJavaしなきゃいけなくなるわけだ
0947デフォルトの名無しさん
2007/02/24(土) 19:52:42Javaならアノテーションで解決できてしまうで。
0948911
2007/02/24(土) 19:52:450949デフォルトの名無しさん
2007/02/24(土) 19:52:56だから俺は勧めてる訳じゃ無いんだって・・・。俺も使ってないし。
ただ、ちょっとした補足代わりにabsとか付けてる人が居ても悪くは無いっしょ？
0950デフォルトの名無しさん
2007/02/24(土) 19:53:06それは無駄。
おれだったら
absolutedValueにする
0951デフォルトの名無しさん
2007/02/24(土) 19:53:41thisをつけるメリットって高いと思うけど、
つけたりつけなかったりするのは、混乱の元。
なんで、this必須にしなかったのだろう?
0952デフォルトの名無しさん
2007/02/24(土) 19:54:37やば。自分で書いてワラてしまた。
グローバルに世界規模に、世界中を回って変装することじゃね？
ローカル変数と区別するにしても
Javaならthis.をつければいいだけだしねえ。
0953デフォルトの名無しさん
2007/02/24(土) 19:54:59なんか、書込に失敗したとかでて、
重複投稿になってしもた
0954デフォルトの名無しさん
2007/02/24(土) 19:55:12多重継承があるC++にはありえない。
多重継承は、使いようによっては面白い。特定の条件に限るけど。
もう一度書く。特定の条件に限るけど。
0955デフォルトの名無しさん
2007/02/24(土) 19:55:23負の遺産か
0956デフォルトの名無しさん
2007/02/24(土) 19:55:41大丈夫、D言語がある。
0957デフォルトの名無しさん
2007/02/24(土) 19:56:28それは決してイバって言うことじゃないだろ。
絶対値のabsも絶対座標のabsも同じabsoluteじゃん。
そこに考えが至らないのはプログラマーとしてどうかと思う。
>>950
absolutedなんて単語はない（少なくとも一般的ではない）
0958デフォルトの名無しさん
2007/02/24(土) 19:57:29つけなくても、IDEが自動的に判別して色分けしてくれる。
つけたほうがいいけどさ。
それも、CheckStyleやEclipseが警告してくれるから無問題。
必須にしなかった理由を言ったら、
なんでインスタンスフィールドのprivateを必須にしなかったんだろう
とか、とんでもない方向に話が進みそうだ。
0959デフォルトの名無しさん
2007/02/24(土) 19:58:08>絶対値を求めるabs
そのabsじゃん
0960デフォルトの名無しさん
2007/02/24(土) 19:58:34そういえば、super()やsuper.メソッド名()ないんだっけかC++には。
ついでにオーバーロードしたコンストラクタを呼び出せる
this()もないんかいな？
0961デフォルトの名無しさん
2007/02/24(土) 19:58:51http://pc10.2ch.net/test/read.cgi/tech/1172314713/
0962デフォルトの名無しさん
2007/02/24(土) 20:00:15absoluteValueな。
考えはいたっても、
間違っても、例えばアンチブロックブレーキシステム
に関するソフトウェアを開発したときには、
やたらめったらにabsなんて使って欲しくないな。
0963デフォルトの名無しさん
2007/02/24(土) 20:02:31スレタイがな。
趣旨はそういう目的じゃないし、用途が違うし。
JavaやるとC++の負の側面がみえる
JavaやるとC++のマイナス面がよく見えてくる
みたいな名前のほうがいいね
0964デフォルトの名無しさん
2007/02/24(土) 20:02:53特定の条件って
単一の基底クラス(Object)を必要としない、
ってやつだろ。それなら心配無用。
0965デフォルトの名無しさん
2007/02/24(土) 20:05:53じゃあ、アンチブロック（ｒｙに関するソフトウェアを開発するときは
abs() は使用禁止にして getAbsoluteValue() って関数を再定義しなくちゃな。
0966デフォルトの名無しさん
2007/02/24(土) 20:07:08長いと見辛いから理解出来る程度に短くしてるだけで。
画像編集ライブラリでブレーキシステムは無いだろ。
あとシステムハンガリアンとは別物なんで、混同しないで下さい。
0967デフォルトの名無しさん
2007/02/24(土) 20:08:03クラス内のクラスにC++と同様に独立したクラスと
親クラスのメンバにアクセスできるのがあるね。
C++的には子クラスのインスタンスをコンストラクトするときに
親クラスのインスタンスを渡すってな感じなのか。
struct Parent
{
struct Child
{
Parent * parent;
Child(Parent * pParent)
: parent(pParent)
{
}
} child; // (C)
Parent()
: child(this) // (A)
{
// (B)
}
};
ってやると、
(A)のところで、このthisはまだParentコンストラクタで
初期化してないって警告が出る。
そもそも(B)や(C)じゃなくて(A)で初期化する仕様が気に入らない。
Childではいちいちparent->～ってしなきゃいけない。
>>960
thisは使えるよ。
0968デフォルトの名無しさん
2007/02/24(土) 20:08:350969デフォルトの名無しさん
2007/02/24(土) 20:09:03即アプリケーションハンガリアンがなんで
システムハンガリアンがなんだったか忘れてしまいそうな響き
0970デフォルトの名無しさん
2007/02/24(土) 20:09:290971デフォルトの名無しさん
2007/02/24(土) 20:09:41なんでパッケージとか名前空間とかを使おうよ、
って話にならないの？
0972デフォルトの名無しさん
2007/02/24(土) 20:10:590973デフォルトの名無しさん
2007/02/24(土) 20:12:32例出してよ。
アプリケーションハンガリアンが何かわかってレスしてる？
0974デフォルトの名無しさん
2007/02/24(土) 20:14:10スレの中身にこれ以上ないぐらい即してるだろｗ
0975デフォルトの名無しさん
2007/02/24(土) 20:15:00絶対値もとめるときはabs namespace
絶対名前空間
なんだがSFな響き
0976デフォルトの名無しさん
2007/02/24(土) 20:18:42例って、アンチロックブレーキシステムと、絶対値求める関数を区別する例？
Car.abs()、math::abs()。
0977デフォルトの名無しさん
2007/02/24(土) 20:21:07それ違うぞ。
0978デフォルトの名無しさん
2007/02/24(土) 20:23:02違うｗ
0979デフォルトの名無しさん
2007/02/24(土) 20:23:57まちがえた、アンチロックだった
アンチブロックじゃねえよw
0980デフォルトの名無しさん
2007/02/24(土) 20:24:15そこは名前空間で解決しようや
0981デフォルトの名無しさん
2007/02/24(土) 20:27:34相対座標と絶対座標の変数名の話。
相対なら、windowXとかじゃなくてrelWindowXという話で、
名前空間って何よ？ってこと。
0982デフォルトの名無しさん
2007/02/24(土) 20:28:38> 俺はJavaを知らんが
> クラス内のクラスにC++と同様に独立したクラスと
> 親クラスのメンバにアクセスできるのがあるね。
内部クラスならJavaにもある。
> C++的には子クラスのインスタンスをコンストラクトするときに
> 親クラスのインスタンスを渡すってな感じなのか。
> ってやると、
> (A)のところで、このthisはまだParentコンストラクタで
> 初期化してないって警告が出る。
> そもそも(B)や(C)じゃなくて(A)で初期化する仕様が気に入らない。
> Childではいちいちparent->～ってしなきゃいけない。
Javaでも同じだし、そりゃ当たり前。そもそも、コンストラクタ
によって初めてthisができあがるんだから、初期化できなくて当然。
どうしてもやりたければ、Javaの場合は、内部クラスをstaticにするね。
んで、staticイニシャライザやprivate staticメソッドを使って初期化する。
0983デフォルトの名無しさん
2007/02/24(土) 20:29:05名前空間があるから駄目ってことはない。
0984デフォルトの名無しさん
2007/02/24(土) 20:30:32良いスレタイ案あるか？
ないなら俺が考える。
JavaやるとC++の暗黒面が見えてくる
とかでもいいか？
0985デフォルトの名無しさん
2007/02/24(土) 20:31:51と書いておけば、C++屋も起こらないだろうと
思うが、どうよ？
0986デフォルトの名無しさん
2007/02/24(土) 20:32:41どうせ同じ展開になるなら既に立ってるスレでいいじゃん。
真面目に語りたいならもう少し真っ当なスレタイにするべきだろ。
0987デフォルトの名無しさん
2007/02/24(土) 20:32:53absをabsoluteと書くのは同じこと。
本質は同じ型・同じ単位で、混同してはいけない値の種類を変数名に付けること。
0988デフォルトの名無しさん
2007/02/24(土) 20:34:42レガシーも勘違いされるし。
Javaやると
C++がセピア色に見えてくる //まあまあ
JavaやるとC++＝バブルと連想する //煽り？
JavaやるとC++が負の遺産に見えてくる //世界遺産でもそういうのあるので煽りではないとおもう
0989デフォルトの名無しさん
2007/02/24(土) 20:35:09こういう煽りがないと客がこんだろ。
Considered harmful
ってタイトルじゃなきゃ誰も読まなかったぜ。
0990デフォルトの名無しさん
2007/02/24(土) 20:36:11今までスレタイに厨がつくスレはろくな
使われカタしなかったことを思い出すよ。
本当に厨ややってスレが荒れるだけなんｄなよな。
しかもJava嫌いな奴が集まってVBやDelphiやC#厨が
AAでスレを荒らす。
そういうのばかり。
0991デフォルトの名無しさん
2007/02/24(土) 20:36:42どうでもいいがもう少し落ち着いてレスしろよｗ
0992デフォルトの名無しさん
2007/02/24(土) 20:37:04java厨乙
0993デフォルトの名無しさん
2007/02/24(土) 20:37:19feel harmfulじゃないか
0994デフォルトの名無しさん
2007/02/24(土) 20:38:060995デフォルトの名無しさん
2007/02/24(土) 20:38:33JavaやるとC++はおほほほほほwwwwww
http://pc10.2ch.net/test/read.cgi/tech/1171237942/
0996デフォルトの名無しさん
2007/02/24(土) 20:39:17高校受験レベルの受動態が理解できてない。
0997デフォルトの名無しさん
2007/02/24(土) 20:39:190998デフォルトの名無しさん
2007/02/24(土) 20:39:540999デフォルトの名無しさん
2007/02/24(土) 20:40:121000デフォルトの名無しさん
2007/02/24(土) 20:40:251001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。