5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:2007/02/11(日) 14:53:43
C++に対する各界の反応:

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

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

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

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

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

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

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

2 :デフォルトの名無しさん:2007/02/11(日) 14:54:23
重複乙

3 :デフォルトの名無しさん:2007/02/11(日) 14:56:24
>>1



4 :デフォルトの名無しさん:2007/02/11(日) 14:59:32
前スレ
JavaやったらC++はきもく感じる
http://pc10.2ch.net/test/read.cgi/tech/1168423655/

5 :デフォルトの名無しさん:2007/02/11(日) 15:01:57
>>1
>良い言語はクリエイターが自身が使うためにデザインしたものである:C, Perl, Smalltalk, Lsip.

Lsip ???

6 :デフォルトの名無しさん:2007/02/11(日) 16:01:07
C++をJava並の制約で使えば同じでしょ

7 :デフォルトの名無しさん:2007/02/11(日) 16:17:16
Jだと生ソケットできないからC系しかないじゃないか><!
そんな俺はエッチな女の子

8 :デフォルトの名無しさん:2007/02/11(日) 16:17:41
両方糞

9 :デフォルトの名無しさん:2007/02/11(日) 16:21:48
有害かぁ
確かにC++には確実に生産性に悪影響を与える
メモリ管理の問題が未解決だなぁ
前スレに「解決している」って書いていた人がいたけど。
これについて少し書いてみてくれないか?>詳しい人

10 :デフォルトの名無しさん:2007/02/11(日) 16:23:34
>>7
JNI使えよ

11 :デフォルトの名無しさん:2007/02/11(日) 16:23:38
フレームワークを使えばメモリ管理は、それにお任せ。

12 :デフォルトの名無しさん:2007/02/11(日) 16:25:05
javaやってると、こんなクソスレ立てちゃうんだから
javaが精神にきわめて悪いのは、立証されたな


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

13 :デフォルトの名無しさん:2007/02/11(日) 16:25:26
バベル案内
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
>C++と比較すれば、Javaは言語として同程度だ。いや、今のなし。ずっといい。文字列があるもの。…

14 :デフォルトの名無しさん:2007/02/11(日) 16:33:01
>>10
解決方法がわかってなんだか肩透かし
今の気持ちを譬えるなら恋人と爆弾を同時に手に入れた気分
ありがとう!

15 :14:2007/02/11(日) 16:37:59
そんな問題じゃなかった..

16 :デフォルトの名無しさん:2007/02/11(日) 16:41:56
>>6
その制約を守らない奴がいるから、
同じではない。

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

17 :デフォルトの名無しさん:2007/02/11(日) 16:42:22
>>9
つまり、Javaの放射性同位体がC++なのだ。

18 :デフォルトの名無しさん:2007/02/11(日) 16:42:45
>>12
キチガイほどそういう発言をする

19 :デフォルトの名無しさん:2007/02/11(日) 16:43:49
前スレからのコピペだけど。ドゾー


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


20 :デフォルトの名無しさん:2007/02/11(日) 16:44:11
C++ Java
backwards compatible with C backwards compatibility only with previous versions
trusts the programmer protects the programmer
exposes low-level facilities memory access only through objects
concise expression explicit operation
allows explicitly overriding types type safety
procedural or object-oriented or functional or generic object-oriented
operator overloading meaning of operators immutable
powerful (abstraction) capabilities of language feature-rich, easy to use standard library

21 :デフォルトの名無しさん:2007/02/11(日) 16:44:30
マジ文字列型って困りものだよな

22 :デフォルトの名無しさん:2007/02/11(日) 16:45:38
と返しておけばそれで成り立つと思ってしまうのが
Java信者の浅はかなところ。

23 :デフォルトの名無しさん:2007/02/11(日) 16:45:50
わかりにくいから貼り付けなおそ。

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

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


24 :デフォルトの名無しさん:2007/02/11(日) 16:46:24
>>22
そういう発言を脊髄反射するおまえみたいなC++厨のほうが浅はかだよ。
まだまだC++の欠点は膨大にある。

25 :デフォルトの名無しさん:2007/02/11(日) 16:50:25
俺にとってはstd::stringは標準の文字列とはいえない。
言語でちゃんと標準の文字列が存在しないというか
C言語の文字へのポインタが文字列っていう考えのまま。


26 :デフォルトの名無しさん:2007/02/11(日) 16:51:13
だったらあげてみれば?

27 :デフォルトの名無しさん:2007/02/11(日) 16:52:31
ありゃ、>>25 に割り込まれた...。

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

28 :デフォルトの名無しさん:2007/02/11(日) 16:56:26
もう前スレですでにかたられてることだと思うが


29 :デフォルトの名無しさん:2007/02/11(日) 16:56:44
std::stringは既存の古いライブラリで使うとき

std::string x;
x.c_str()

ってしなきゃならない。

30 :デフォルトの名無しさん:2007/02/11(日) 17:01:05
JavaのコンパイラStringクラスをサポートしてるってだけで
あんまり変わらん気がするけど

31 :デフォルトの名無しさん:2007/02/11(日) 17:05:00
文字コード意識しなくてもいいStringクラスなら
JavaでもC++でもどっちでも歓迎

32 :デフォルトの名無しさん:2007/02/11(日) 17:09:53
この世の文字列を使うDLLの
主要なものほとんどがstd::stringをサポートしない限り
JavaのStringと対等とは思えない。

33 :デフォルトの名無しさん:2007/02/11(日) 17:11:25
この世の列挙を使うDLLの
主要なものほとんどがstd::listをサポートしない限り
標準じゃないのに標準テンプレート。

34 :デフォルトの名無しさん:2007/02/11(日) 17:11:59
>>32
いやstd::stringは糞だろ。

35 :デフォルトの名無しさん:2007/02/11(日) 17:16:19
FDiVqcgvuVgDxiOTPHGOXBPvlQQraSm+OHEV1LTPbQQ=


36 :デフォルトの名無しさん:2007/02/11(日) 17:23:21
なかなかの盛況っぷりだな

37 :デフォルトの名無しさん:2007/02/11(日) 17:25:05
Smalltalkがすばらしいことだけはわかった

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

39 :デフォルトの名無しさん:2007/02/11(日) 17:58:41
ジョエル・スプロウスキー、て。

40 :デフォルトの名無しさん:2007/02/11(日) 20:05:42
D言語次第では既存コード保守用言語に成り下がるかもね

41 :デフォルトの名無しさん:2007/02/11(日) 20:14:20
>結局OSや重要なOSSはみなCだから
じゃあ、これからもずっとCじゃね。
Cで十分な所に、あえてC++を持ち出す意味は無い。

42 :デフォルトの名無しさん:2007/02/11(日) 20:30:31
boost::any使えばjavaと同じようにコード書けるね

43 :デフォルトの名無しさん:2007/02/11(日) 21:07:45
boostが標準になって
まともな言語だな

44 :デフォルトの名無しさん:2007/02/11(日) 21:11:03
boost無しなら正直Javaの方がマシ

45 :デフォルトの名無しさん:2007/02/11(日) 21:52:13
>>42
んなあほな。

46 :デフォルトの名無しさん:2007/02/11(日) 22:34:23
javaのUMLからコード自動生成って便利なの?

47 :デフォルトの名無しさん:2007/02/11(日) 22:41:06
便利だと思っている人が使えば絶対に便利。

48 :デフォルトの名無しさん:2007/02/11(日) 23:01:04
しかし今はもう、C++vsJavaという構図はあまりないだろうに・・
クライアントで敗北したJavaはサーバサイドという土地を開拓したが、
原住民のPerl/PHPの思わぬ抵抗に大苦戦みたいな感じだな。

49 :デフォルトの名無しさん:2007/02/11(日) 23:31:01
Java全然知らないのだが、「Java並行処理プログラミング」読んでる。
まだ3章までしか読めてないが、
楽チンな言語かと思いきや、可視性のあたり結構ムズくない?
マルチスレッド始めたらはC++の方がお気楽な気がする。

50 :デフォルトの名無しさん:2007/02/11(日) 23:35:24
まあ言語関係なしにスレッドは概念が難しいもんねぇ・・

51 :デフォルトの名無しさん:2007/02/11(日) 23:40:54
Javaで促成栽培されたPGもどきが非常に有害な件について

52 :デフォルトの名無しさん:2007/02/11(日) 23:46:07
>>49
ピアソンのやつ?その本Java関連の本の中で一番むずかしい。

53 :デフォルトの名無しさん:2007/02/11(日) 23:58:37
>>52
ピアソンのは知らないっす。
http://www.amazon.co.jp/o/ASIN/4797337206/

54 :デフォルトの名無しさん:2007/02/12(月) 00:12:50
>>53
今調べてみたらピアソンじゃなかったっす。orz
http://www.amazon.co.jp/o/ASIN/4881359185/

55 :デフォルトの名無しさん:2007/02/12(月) 00:34:55
>>48
eclipseみたいにクライアントにも侵食してはいるがね。
まあ、SUNのデザイナはセンス0ってことは同意。

56 :デフォルトの名無しさん:2007/02/12(月) 01:52:24
>>44
しかしboostがある
むしろboostがjava作ってほしかった

57 :デフォルトの名無しさん:2007/02/12(月) 02:04:17
ttp://gedo-style.net/g/?v=350091&d=d.jpg

58 :デフォルトの名無しさん:2007/02/12(月) 02:56:02
ttp://gedo-style.net/g/?v=350098&d=d.jpg

59 :デフォルトの名無しさん:2007/02/12(月) 03:31:33
C++?   チンコプラプラ?w
C#?    チンコシャープ?w

C?     ちんこ?w



(・∀・)カエレ!    

60 :デフォルトの名無しさん:2007/02/12(月) 03:41:05
(・∀・)カエレ!    
(・∀・)カエレ!    
(・∀・)カエレっ!

61 :デフォルトの名無しさん:2007/02/12(月) 03:44:12
>>38
> もうC++ってアンチも多い人気アイドル的存在だな。

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

> とっつきにくいし難しいし、いつまでも手の届かない存在みたいな。
> そんで、できなきゃいつまでもドカタグラマー。

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

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

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



62 :デフォルトの名無しさん:2007/02/12(月) 03:44:15
> VBがJavaに食われたように、10年後にJavaはPHP/Rubyに食われて死んでるかも

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


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

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

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

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

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

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


63 :デフォルトの名無しさん:2007/02/12(月) 03:47:12
>>38
> 言語としての弱点はあるけど、結局OSや重要なOSSはみなCだから、Cが直接

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

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




64 :デフォルトの名無しさん:2007/02/12(月) 03:51:04


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

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

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



66 :デフォルトの名無しさん:2007/02/12(月) 03:51:38
>>46
便利だが、ツールが高価。100万くらい金払えってレベル

67 :デフォルトの名無しさん:2007/02/12(月) 03:58:09
>>48
> しかし今はもう、C++vsJavaという構図はあまりないだろうに・・

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

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

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


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

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

68 :デフォルトの名無しさん:2007/02/12(月) 04:03:25
>>55
NetBeansやJava Studio Creatorは
そうでもなさそうだ。

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

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

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


69 :デフォルトの名無しさん:2007/02/12(月) 04:06:48
おめーら必死だなw
結局何がいいんだ?
javaでおk?

70 :デフォルトの名無しさん:2007/02/12(月) 04:07:45
>>56
boostがあってもC++が抱えている欠点を
完全に消すことはできんよ。

>>59
Cωはどうした。

71 :デフォルトの名無しさん:2007/02/12(月) 04:11:05
でも。おめーらスキル高そうだな。。。
今俺javaやってるよ。

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

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

PHPって外向け用でしょ。

72 :デフォルトの名無しさん:2007/02/12(月) 04:54:15
>>67
まぁ、小規模サイトで、Servlet,JSP,Strutsなんてのをやらないですむのは助かるよ。
大規模な開発やると、Javaのコーダーは土方だしな。
C++は新規開発はへったけど、やれる奴少ないから、ちょっといじっただけでも
評価があがるのは助かる。
まぁ、普段はCでドライバ書いてますが。これが一番楽。

73 :デフォルトの名無しさん:2007/02/12(月) 05:29:39
http://gedo-style.net/g/?v=350137&d=d.jpg

74 :デフォルトの名無しさん:2007/02/12(月) 05:58:53
そうか、人気がなくなってきた言語をあえて習得しておくという戦略もありか。
COBOLとかに手を出す気にはなれないけど。さすがに。

75 :デフォルトの名無しさん:2007/02/12(月) 06:07:04
団魂世代がいなくなるから、
COBOLできる人が必要になるって、
COBOLやってたやつがいってた。。。

どうなんだ?

76 :デフォルトの名無しさん:2007/02/12(月) 06:22:36
Dは演算子オーバーロードあるんだっけ?
あるならゲーム屋的に異存はないですよ。

77 :デフォルトの名無しさん:2007/02/12(月) 06:38:20
http://www.kmonos.net/alang/d/operatoroverloading.html

78 :デフォルトの名無しさん:2007/02/12(月) 07:05:29
C++は言語に有害な点が多い
Javaは関わっている人間に有害な者が多い

79 :デフォルトの名無しさん:2007/02/12(月) 07:12:20
(・∀・)うまい! だいたいシステムエンジニアって変なやつ多いよなw

80 :デフォルトの名無しさん:2007/02/12(月) 09:39:53
クライアントでは遅くて使い物にならずC++に負けて(Swing?プ)、
サーバでは開発しづらくてRubyにさえ負けはじめ(やっぱLAMPが楽っす)、
ついにJavaWorldも廃刊だ。おまけに自慢の言語仕様もC#には負けちまう。
もうどこにも居場所はないんだよ。

81 :デフォルトの名無しさん:2007/02/12(月) 13:36:07
クライアントで頑張ってるのはCの方です。

82 :デフォルトの名無しさん:2007/02/12(月) 13:37:18
>>54==>>49
お前が読んでいる本見たら・・・
出版社: 翔泳社 (2000/08)

随分と時代遅れだな。


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

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

83 :デフォルトの名無しさん:2007/02/12(月) 13:37:51
>>69
Javaでオッケー


84 :デフォルトの名無しさん:2007/02/12(月) 13:43:01
>>71
> でも。おめーらスキル高そうだな。。。
> 今俺javaやってるよ。
> 営業なのにスキルがいるのよ。
> 仕事で話多いのが、VB.NETとjavaでうちのソフトと連帯してのシステム開発だな。

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

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

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

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


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



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

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

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

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

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

87 :デフォルトの名無しさん:2007/02/12(月) 13:51:33
>>73
君が悔しがってるのは解るが>>57-58に対抗して
「中規模業務系まで」という表現が意味不明だ。
それが許すものは、苦しいがむしろPerlやPHP程度だろう。
PerlやPHPが許されるのは中規模よりもむしろ小規模だが、
業務系よりもむしろ、お遊び系だ。

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




88 :デフォルトの名無しさん:2007/02/12(月) 13:51:57
>>74
人気よりも、魅力のある言語を習得した方が良い。
関数型言語とか

89 :デフォルトの名無しさん:2007/02/12(月) 13:52:49
>>75
過去の遺産を完全に破棄すれば、結局
COBOLも不要になる。
過去のCOBOL遺産をどうしても再利用したいときだけ
使われるに過ぎない。
だが、仕様書をきっちり書いて残していれば
COBOLがどうこうなんて関係無いがな

90 :デフォルトの名無しさん:2007/02/12(月) 13:53:55
>>78
> C++は言語に有害な点が多い
> Javaは関わっている人間に有害な者が多い

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


91 :デフォルトの名無しさん:2007/02/12(月) 14:11:33
>>80
> クライアントでは遅くて使い物にならずC++に負けて(Swing?プ)、

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


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


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

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

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

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

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

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


92 :デフォルトの名無しさん:2007/02/12(月) 14:11:40
> サーバでは開発しづらくてRubyにさえ負けはじめ(やっぱLAMPが楽っす)、

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

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

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


93 :デフォルトの名無しさん:2007/02/12(月) 14:14:15
>>86
意味が解らないんだが。
その本の題名を説明して貰わないと。
断片だけで煽るのはやめようや。
PHPやPerlは畑が違うんだからな。

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





94 :デフォルトの名無しさん:2007/02/12(月) 14:22:14
>>91
C++よりJavaのほうが速いことがあるなんて、
今更得意げになって語るほど目新しくないよ。

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

95 :デフォルトの名無しさん:2007/02/12(月) 14:44:51
JavaのGUIが速いってWindows限定の話じゃネーの

96 :デフォルトの名無しさん:2007/02/12(月) 14:45:16
今はビジネスロジックよりコンカレント工学のほうが笑える

97 :デフォルトの名無しさん:2007/02/12(月) 15:01:22
ここで話してる人たちとは畑が違うだろうけど
研究や金融系の計算プログラムはほとんどCかC++(もしくはフォートラン)だぞ
Javaで書かれたプログラムなんぞ見たことすらないんだが

98 :デフォルトの名無しさん:2007/02/12(月) 15:24:49
> 現在のJavaは、単純なインタープリタ方式に比べ、ネイティブ・プログラムとのパフォーマンスの差は小さくなっています。

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

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

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

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


99 :デフォルトの名無しさん:2007/02/12(月) 16:42:45
> ここまでに説明したとおり、現在Javaが主に使われているサーバ側アプリケーションにおいては、性能が理由でJavaが使えないということはほとんどないと言えます。

100 :デフォルトの名無しさん:2007/02/12(月) 18:02:21
画像処理をメインでやってるんだけど
javaにすると本当に処理速度あがるの?

101 :デフォルトの名無しさん:2007/02/12(月) 18:23:13
>97
金融なら、こいつがJava。(ただし、JR東の中の人が使う画面はCurlで書いてる)
ttp://www.tis.co.jp/product/CreditCube/index.html
SUICAの売上とか残高とか、全部これで管理されてるよ。

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

102 :デフォルトの名無しさん:2007/02/12(月) 18:35:33
両方勉強した俺は勝ち組かな。
片方しか出来ない馬鹿乙

103 :デフォルトの名無しさん:2007/02/12(月) 18:40:25
そんな低レベルなやつはこのスレにいないよ、きっと。まさか。

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

105 :デフォルトの名無しさん:2007/02/12(月) 18:45:21
printlnとかな

106 :デフォルトの名無しさん:2007/02/12(月) 18:54:55
printlnやだね。

107 :デフォルトの名無しさん:2007/02/12(月) 19:36:24
>>101
C++よりjavaが速度あがるわけじゃないのね


108 :デフォルトの名無しさん:2007/02/12(月) 19:40:03
>>107
もちろんC++よりも速くなるよー

109 :デフォルトの名無しさん:2007/02/12(月) 19:40:31
>>91
なんかJavaのさえない実績をあおるC++信者に、必死に妄想で対応する
Java信者のいつもの構図だな

110 :デフォルトの名無しさん:2007/02/12(月) 20:03:25
画像処理がc++よりもjavaが高速にできるなら
なんでadobeは、いまからc++画像処理ライブラリー作るとか言ってるの?
javaでいいのに

111 :デフォルトの名無しさん:2007/02/12(月) 20:06:05
C++にする方が需要が大きい(とAdobeは考えたに違いない)から。

112 :デフォルトの名無しさん:2007/02/12(月) 20:24:46
>>110
PerlだろうがPythonだろうがJavaだろうが大抵の言語はC/C++向けの拡張インターフェースを
持っていて、C++で書かれたライブラリを簡単に取り込めるけど。
Javaで書かれたライブラリはまずJavaでしか使われないよね。速度が問題じゃないよ。

113 :デフォルトの名無しさん:2007/02/12(月) 20:34:45
リアルタイム画像処理はjavaでは無理
sse使えないし

114 :デフォルトの名無しさん:2007/02/12(月) 20:52:44
自分で使ったメモリは、自分で片付けないと、
不安でしょうがない

115 :デフォルトの名無しさん:2007/02/12(月) 20:57:23
でもほんとサーバでPHP/Perl/C#に負けるようになったらJavaは
衰退するんだろうな・・。いい言語だとは思うんだけどさ。
俺は実務指向だから、はやらなくなったものはやっぱ使わなくなるかな。

116 :デフォルトの名無しさん:2007/02/12(月) 22:03:47
PHP・Perlに負けることはねえだろ。
Rubyが高速化したら負けるけど。

117 :デフォルトの名無しさん:2007/02/12(月) 22:05:47
Rubyも見た目がキモイんですけど?

118 :デフォルトの名無しさん:2007/02/12(月) 22:12:10
>>117
先入観無しで一度使ってみるよろし。
Javaでコード書くのダルくなること請け合い、C++は言うに及ばず。

119 :デフォルトの名無しさん:2007/02/12(月) 22:15:30
ネットや雑誌でRubyの勢いは感じるんだけど
実際使ってる案件見たことないんだよ

120 :デフォルトの名無しさん:2007/02/12(月) 22:18:00
>>119
キモイからじゃね?

121 :デフォルトの名無しさん:2007/02/12(月) 22:19:42
キモかったら見ないって理屈が通るなら
俺の会社は誰からも見えないよ

122 :デフォルトの名無しさん:2007/02/12(月) 22:20:08
>>119
とりあえず今は、ちょっとしたツール作るときに使ってる。

123 :デフォルトの名無しさん:2007/02/12(月) 22:21:10
>>94
> >>91
> C++よりJavaのほうが速いことがあるなんて、
> 今更得意げになって語るほど目新しくないよ。

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

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


124 :デフォルトの名無しさん:2007/02/12(月) 22:21:49
常識的に考えてC++よりキモイのは無いだろ。
だけど、そのキモさが良いんだけど。

125 :デフォルトの名無しさん:2007/02/12(月) 22:21:57
>>95
それでもいいよ。デスクトップOSの大部分がWindowsなんだから。
サーバはLinuxやSolarisなどがよく使われていても
結局はJavaを使うケースがあるんだし


126 :デフォルトの名無しさん:2007/02/12(月) 22:25:10
EclipseとVisualStudioを比べて前者のほうが速いと感じたことは一度もないよ。

127 :デフォルトの名無しさん:2007/02/12(月) 22:26:28
>>97
> 研究や金融系の計算プログラムはほとんどCかC++(もしくはフォートラン)だぞ

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


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

128 :デフォルトの名無しさん:2007/02/12(月) 22:27:23
>>100
処理速度が上がることを期待するより、
開発効率、メンテナンス性や拡張性が上がることを期待した方が良い。

129 :デフォルトの名無しさん:2007/02/12(月) 22:28:44
>>109
具体的にどこが妄想で対応しているのか、
示せるかな?

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

130 :デフォルトの名無しさん:2007/02/12(月) 22:29:02
>>110
過去の遺産が影響しているからだろう

131 :デフォルトの名無しさん:2007/02/12(月) 22:29:19
燃料投下
ttp://local.joelonsoftware.com/mediawiki/index.php/Java%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%AB%E3%81%AE%E5%8D%B1%E9%99%BA

132 :デフォルトの名無しさん:2007/02/12(月) 22:29:25
>>111
だから過去の遺産がC++で作られており、
今さらJavaに以降するにはコストがかかるからだろう

133 :デフォルトの名無しさん:2007/02/12(月) 22:32:07
>>114
そうこうしているうちに、
Javaの最適化技術が驚くほど進化しているわけだが。

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

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

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




134 :デフォルトの名無しさん:2007/02/12(月) 22:32:52
>>126
Eclipseの方が便利だけどな

135 :デフォルトの名無しさん:2007/02/12(月) 22:36:34
>>115
> でもほんとサーバでPHP/Perl/C#に負けるようになったらJavaは
> 衰退するんだろうな・・。いい言語だとは思うんだけどさ。

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

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

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


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

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

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




136 :デフォルトの名無しさん:2007/02/12(月) 22:37:23
>>118
スクリプト厨とか煽られたことがないか?

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

137 :デフォルトの名無しさん:2007/02/12(月) 22:38:08
>>119
RoRが面白いだけだ。
Java分野でもおんなじようなもんがあるがな。
Spring FrameworkとかSeasar2とか

138 :デフォルトの名無しさん:2007/02/12(月) 22:39:08
>>126
バージョンによるがな。
Eclipseは3.2になってから高速化した。
だが、使い方次第ではえらくのろまになる。

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

139 :デフォルトの名無しさん:2007/02/12(月) 22:41:30
>>131
またJoel on Softwareの関係者か。
あれはM$信者だろ。ただの煽り。
C#が出た頃に、M$の関係者や信者が
「Javaはもう衰退する! これからの時代はC#だ! Javaなんて勉強しないでC#を勉強しろ!」
と煽っていたことを思い出す。
だが、あれから6年経ってもJavaはいっこうに衰退せず、C#もろくに普及しなかった。

その程度の煽りだろうね

140 :デフォルトの名無しさん:2007/02/12(月) 22:42:26
>>131
こんなスレで低能な言い争いを続けてる連中にそんな長文が
読めるわけだろ。そんなんじゃ燃料にならねぇよ、馬鹿。

141 :デフォルトの名無しさん:2007/02/12(月) 22:43:19
>>136
それほどスクリプト言語に思い入れがあるわけじゃないよ。
でも使い捨てのツール書くニーズなんかは誰にでもあるわけで。

142 :デフォルトの名無しさん:2007/02/12(月) 22:43:46
C#か、なにもかもなつかしい

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

143 :デフォルトの名無しさん:2007/02/12(月) 22:45:05
>>139
完全にとっては代わることはないだろうが、JavaがどんどんC#に
その役割と立場を喰われているのは事実だろう。

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

145 :デフォルトの名無しさん:2007/02/12(月) 22:49:38
>>143
全くそんな気がしないんだけど。
なんかソースあるの?

146 :デフォルトの名無しさん:2007/02/12(月) 22:54:43
>>145
C#の案件をググれ。それら全てが、JavaがC#に喰われた分だ。

147 :デフォルトの名無しさん:2007/02/12(月) 22:55:51
>>143
仮にJavaが全てC#に置き換わったとしても、
Java屋は別に困らんのじゃないだろうか。
それほど移行コストがかかるとは思えん。

148 :デフォルトの名無しさん:2007/02/12(月) 23:49:25
>>75
まともに動いてたCOBOLのシステムを捨て去りJavaで書き直すも誤動作連発。
日本終了。

149 :デフォルトの名無しさん:2007/02/13(火) 00:12:33
このスレJavaはC++より速い!ってやつが一人で頑張ってるようにしか見えないんだが

150 :デフォルトの名無しさん:2007/02/13(火) 00:15:21
c#はselectやfromを取り入れるそうだよ。
データベースがネイティブに使えるんかな?

151 :デフォルトの名無しさん:2007/02/13(火) 00:32:57
>144
スクリプト系は型が甘いっていうか

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

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

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

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

152 :デフォルトの名無しさん:2007/02/13(火) 00:38:35
Javaは全然使ったことが無いが、明示的な型を持たないから糞と聞いていたのに
型はあったのか・・・

153 :デフォルトの名無しさん:2007/02/13(火) 00:40:09
>>143
> >>139
> 完全にとっては代わることはないだろうが、JavaがどんどんC#に
> その役割と立場を喰われているのは事実だろう。

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




154 :デフォルトの名無しさん:2007/02/13(火) 00:41:50
>152
つーかOOPLで型無し言語ってあるのか?
オブジェクトがクラス情報(かそれに近いシステム)持ってなきゃ
ポリモル出来ない気がするんだが。

155 :デフォルトの名無しさん:2007/02/13(火) 00:47:54
>>152,>>154
まずはなにをもって型があるとするかだろ。
まぁ、型の強弱はあっても全く型の無い言語なんてそれこそ少数派だろ。

156 :デフォルトの名無しさん:2007/02/13(火) 01:02:52
つ JavaScriptなどのプロトタイプベースのOOPL

157 :デフォルトの名無しさん:2007/02/13(火) 01:11:58
JDK1.4までは値と型は一応分かれてなかったっけか
内部ではどう扱っていたんだかわからんが

158 :デフォルトの名無しさん:2007/02/13(火) 01:22:16
>>151
それは所謂、強い型付けってことでしょう。
Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。
まあ、そもそも型安全でないC/C++よりはマシですどね。

159 :デフォルトの名無しさん:2007/02/13(火) 01:37:53
>>158
アップキャストとダウンキャストの区別がdj

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

160 :はっさく:2007/02/13(火) 01:57:29
俺はE言語を開発してるんだけど、だめかなあ。

161 :デフォルトの名無しさん:2007/02/13(火) 02:09:16
Javaのアップキャスト検出は状況次第じゃないか

162 :デフォルトの名無しさん:2007/02/13(火) 02:15:44
>158
> Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。

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

import javax.swing.*;

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

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

163 :デフォルトの名無しさん:2007/02/13(火) 02:29:24
>>161
寝ぼけているのではなく、本気で言ってるのなら、基本から勉強しなおすと良いよ。

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

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

165 :デフォルトの名無しさん:2007/02/13(火) 02:41:57
>>161
>Javaのアップキャスト検出は状況次第じゃないか
アップキャスト検出ではないが、Javaのダウンキャスト検出は状況次第だわ。
ダウンキャスト先が継承関係に無い場合はコンパイル時エラーだな。
俺も基礎からやり直すよorz

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

167 :デフォルトの名無しさん:2007/02/13(火) 03:05:49
今はマルチコアなんだし、GCもコストフリーなんじゃない?

168 :デフォルトの名無しさん:2007/02/13(火) 03:11:16
昔、一太郎arkってあったな。今後はどんどんJavaで作られるのかって流れを
感じたが、現実は厳しかったなぁ。

169 :デフォルトの名無しさん:2007/02/13(火) 03:27:19
>>167
まあ段々とそう見なせる状況は広がって行くと思う。

170 :デフォルトの名無しさん:2007/02/13(火) 03:56:22
>>167
じゃぁ、GC用に一個、コアを予約しておくか。

171 :デフォルトの名無しさん:2007/02/13(火) 04:21:12
今時ハードの増強や負荷分散の仕組みくらい安いもんだろ。方法論が確立してるしな。
GCのない言語だとメモリリークを防ぐには、腕の立つプログラマと長い検証期間が必要だ。
そんなの信用ならん。

172 :デフォルトの名無しさん:2007/02/13(火) 04:34:30
いくらメモリリークから逃れてもリソースリークしたらそこまでだろう

173 :デフォルトの名無しさん:2007/02/13(火) 05:01:38
このスレ,PHPが出てきたりと,Webアプリの話が多いけど,Windows用のクライアントアプリって今でも C++/MFC が全盛じゃないの?

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

174 :デフォルトの名無しさん:2007/02/13(火) 05:12:15
.hと.cppに同じことを書いてると、俺何やってんだろうと感じる><

175 :デフォルトの名無しさん:2007/02/13(火) 05:18:24
TIOBE Programming Community Index
ttp://www.tiobe.com/tiobe_index/index.htm

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

176 :デフォルトの名無しさん:2007/02/13(火) 05:25:40
みんな、寝ろよ。
徹夜は効率悪いよ。

177 :デフォルトの名無しさん:2007/02/13(火) 05:25:55
>>173
つVB、Delphi、Macromedia Director
あと、MFCとか言い出すと標準C++じゃないから話がややこしくなってくる。
Windows環境はC++コミュニティからも冷めた目で観られてる。

178 :デフォルトの名無しさん:2007/02/13(火) 06:40:57
90%位のシェアの市場を冷めた目で見てどうするんだ・・・

179 :デフォルトの名無しさん:2007/02/13(火) 06:47:10
>パソコンショップで売ってるWindows用のソフト,例えば画像編集,
>デジカメ写真整理,年賀状作成,動画編集,シューティングゲーム,
>etc みたいなソフトは C++/MFC で組まれてるんじゃないの?
その通りだよ。そんな実態をすべて忘れてJava最高!といい続ける
妄想宗教スレなわけだ。

180 :デフォルトの名無しさん:2007/02/13(火) 06:55:18
>>177
> Delphi、Macromedia Director
!? !? !?
なあ、Delphiが生き残ってるって初めて聞いたんだが。

181 :デフォルトの名無しさん:2007/02/13(火) 08:34:42
>>179
アプリ系ってもう負け組じゃん。C++は負け組言語と言いたいわけですか。

182 :デフォルトの名無しさん:2007/02/13(火) 08:50:04
>アプリ系ってもう負け組じゃん。
プ

183 :デフォルトの名無しさん:2007/02/13(火) 10:24:32
(俺C++使いでJava使わないんだが)
(前スレ)JavaやったらC++はきもく感じるとは直接関係ないけど
#include <〜>
なんで拡張子hを消したんだろう。

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

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

184 :デフォルトの名無しさん:2007/02/13(火) 12:08:27
>>143
> >>139
> 完全にとっては代わることはないだろうが、JavaがどんどんC#に
> その役割と立場を喰われているのは事実だろう。

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


185 :デフォルトの名無しさん:2007/02/13(火) 12:10:04
>>144
> 型の甘い言語って、JavaやC++もどっちもそんなに型に厳しいわけじゃないだろ。

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

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

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

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





186 :デフォルトの名無しさん:2007/02/13(火) 12:10:56
>>146
そのときそのときに案件でしか判断できないとは痛々しいな。
C#の立場はクライアントサイドのみでしか発揮されないよ。
サーバサイドではどうみてもJavaやPHPには勝てない。



187 :デフォルトの名無しさん:2007/02/13(火) 12:11:59
>>150
デーベースと言えば、Javaも Java SE 6(Mustang)
からApache Derbyが標準搭載され、100%PureJavaデータベースが
Java SE 6に取り込まれた。

188 :デフォルトの名無しさん:2007/02/13(火) 12:15:04
>>152
JavaとJavaScriptとを勘違いしていないか?
それとも「明示的な型キャスト」をしてもキャストをできないケースがあるという
意味を勘違いしていないか?

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

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

というものもあるが。


189 :デフォルトの名無しさん:2007/02/13(火) 12:15:35
>>154
PHP, Perl, JavaScriptなどなど

190 :デフォルトの名無しさん:2007/02/13(火) 12:21:17
>>157
それはオートボクシングのことか。
今でも別れているが。

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


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




191 :デフォルトの名無しさん:2007/02/13(火) 12:24:01
>>158
> >>151

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


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




192 :デフォルトの名無しさん:2007/02/13(火) 12:26:21
>>164
> >>85

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

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

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


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

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

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

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

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

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

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




194 :デフォルトの名無しさん:2007/02/13(火) 12:36:10
>>171
まさにその通り、昔は人間がやっていたことを
今では簡単に機械が実行できる時代。

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



195 :デフォルトの名無しさん:2007/02/13(火) 12:39:26
>>173 >>177

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


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


196 :デフォルトの名無しさん:2007/02/13(火) 12:41:14
>>175
C言語の人気は相変わらずだ。

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


197 :デフォルトの名無しさん:2007/02/13(火) 12:44:12
>>179
だから、それは過去の遺産がC++で作られているから
Javaに移行するとスイッチングコストが高く付くから
C++のままで開発しているだけだよ。

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

それにVistaも出ているし


198 :デフォルトの名無しさん:2007/02/13(火) 12:44:48
>>183
C言語時代の名残だろ。伝統的と揶揄されるがシガラミでしかない

199 :デフォルトの名無しさん:2007/02/13(火) 12:51:41
聞きたいんだけど、Javaで数値計算のライブラリってあるの?
あったとしてもほとんどない。
この分野はCおよびC++の独壇場でしょ?
多数人の手で大規模なシステム開発をやるならともかく、
一人または少数人で計算速度重視のプログラムを組む場合、
Javaなんて度外視されてるのが現状じゃない?

200 :デフォルトの名無しさん:2007/02/13(火) 14:21:50
>>199
> 聞きたいんだけど、Javaで数値計算のライブラリってあるの?
> あったとしてもほとんどない。
Jakarta Commons Math

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

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

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


201 :デフォルトの名無しさん:2007/02/13(火) 15:16:14
勘違いしては困るがCは神言語だろ。C++は神になりそこなったクズってだけ。

202 :デフォルトの名無しさん:2007/02/13(火) 15:21:52
もうC++よかメモリ管理もファイル操作も速くなったのか
じゃあ携帯Javaももう天国になったんだな
うらやましいぜ

203 :デフォルトの名無しさん:2007/02/13(火) 15:30:33
もうっていうか最初からBrewはクソだろ。

204 :デフォルトの名無しさん:2007/02/13(火) 15:32:14
Perl の OO 拡張や V6 で失敗したのが
C -> C++ の失敗に良く似ているね
こういうケースでは新言語作るべきなんだよ

205 :デフォルトの名無しさん:2007/02/13(火) 15:49:28
>>200
> JavaはC++よりもメモリの管理速度やファイル操作が速いので
JavaVMはC++で作られたアプリケーションだから、
C++より速いメモリ管理やファイル操作がC++によって実現されていることになる。

206 :デフォルトの名無しさん:2007/02/13(火) 16:04:23
>>202
メモリが少なすぎてまだまだ


207 :デフォルトの名無しさん:2007/02/13(火) 16:17:01
>>205
だったらさ、C++はなぜそこだけJavaより遅くなるのかな?

208 :デフォルトの名無しさん:2007/02/13(火) 16:37:25
>>207
実際に遅いかどうかは別として、こまめにメモリを確保・解放して
メモリの使用量を抑制するか、十分なメモリを確保したままにして
速度を重視するかでトレードオフの関係が成り立つから、
速度を犠牲にしてメモリの使用量を減らすことを優先することもできる。

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

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


209 :デフォルトの名無しさん:2007/02/13(火) 16:44:54
>>207はあらゆる状況でC++のメモリ・ファイル操作はJavaより遅いかのごとく語っているが、
ではどうやってJavaより遅いそのC++でJVMを実装していると考えているのだろうか

210 :デフォルトの名無しさん:2007/02/13(火) 17:50:53
つか、>>200 が勝手に
>JavaはC++よりもメモリの管理速度やファイル操作が速いので
とかぬかしてるだけな気がするんだが。

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

211 :デフォルトの名無しさん:2007/02/13(火) 20:12:14
std::vectorは cの単純配列より1.2倍ぐらい遅いというのを見たことがある
javaの配列はどんな感じ?
1.1倍?

212 :デフォルトの名無しさん:2007/02/13(火) 22:32:13
>>166
>1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
>JavaのGCがかなりネックになってしまう。
>GCの走るタイミングが読めないし、完了する時間もわからない。

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

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

213 :デフォルトの名無しさん:2007/02/13(火) 23:24:17
いつまでもつまらん議論しなさんな。
言語はそれぞれ得意分野があるもんだ。

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

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

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

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



214 :デフォルトの名無しさん:2007/02/14(水) 00:36:10
実用上、C++の手を借りることが多いのはCOMコンポーネントを作るときかな。
VB用に帳票印刷を手作りしたときには役に立った。

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


215 :デフォルトの名無しさん:2007/02/14(水) 00:37:41
C++じゃなくてC言語の話だけどさ
ときどきC言語は移植性が高いというのを見つけるけどさ
BASICなどに比べると方言が少ないとかぐらいでしょ。

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

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

216 :デフォルトの名無しさん:2007/02/14(水) 00:39:14
>>214
>化学実験室に連れて行かれて試薬でクッキー作れといわれるぐらい嫌。

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

217 :デフォルトの名無しさん:2007/02/14(水) 00:41:39
>>215
ANSI C に準拠してるヤツはかなり互換性いいぞ。
てか、C++の互換性の無さにはウンザリ。
あれじゃ、標準規格があって無いようなもんだ。

218 :デフォルトの名無しさん:2007/02/14(水) 00:44:40
数値計算というか事務計算をやらせようとするとC++厨もJava厨もろくでもない物しか作れない。
特にJavaの奴は誤差が頻繁に出るからクレーム付けたら「1円くらいどうでもいいだら」なんて言うし。
最低。

219 :デフォルトの名無しさん:2007/02/14(水) 00:47:55
>>218
それはお前のまわりだけだろ?
得意としてる言語に関わらず、そんなヤツには合ったことないぞ。

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

220 :デフォルトの名無しさん:2007/02/14(水) 00:49:28
COBOLERでそ

221 :デフォルトの名無しさん:2007/02/14(水) 00:51:27
>>220
COBOLが最も得意とする分野なのですが。>事務計算

222 :デフォルトの名無しさん:2007/02/14(水) 00:56:48
>>221
>>218がコボラだつったの。

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

223 :デフォルトの名無しさん:2007/02/14(水) 01:00:40
COBOLって言うほど事務計算得意な言語でもないと思う。

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

224 :デフォルトの名無しさん:2007/02/14(水) 01:04:07
>>215
C の環境依存部分は、ほとんどの場合利用できる関数(とヘッダ)なので
環境依存部分をファイルに分離して Win/Mac/Unix 対応くらいならできる。

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

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

225 :デフォルトの名無しさん:2007/02/14(水) 01:07:08
>>224
>Java はそもそもどこでも動くはず。と言うか動くべき。

でも、動かない。プッ

226 :デフォルトの名無しさん:2007/02/14(水) 01:11:26
>>225
あらゆる環境で完璧に動くよ。

227 :デフォルトの名無しさん:2007/02/14(水) 01:34:25
>でも、動かない。プッ
0点。もう少し頭を使いましょう。

228 :デフォルトの名無しさん:2007/02/14(水) 02:02:56
>>209
だからC++プログラマの技術力が
ロボットの技術力に追いつかないということだよ。

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

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

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

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

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

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




229 :デフォルトの名無しさん:2007/02/14(水) 02:09:17
>>210
> つか、>>200 が勝手に
> >JavaはC++よりもメモリの管理速度やファイル操作が速いので
> とかぬかしてるだけな気がするんだが。


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

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

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

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

230 :デフォルトの名無しさん:2007/02/14(水) 02:14:19
>>228
知ったか厨なんてこの程度だな。

>>229
中々面白い。

231 :デフォルトの名無しさん:2007/02/14(水) 02:17:02
>>211
Javaは配列自体Javaより遅いからねえ。
今なら、配列の替わりにBufferのサブクラスとChannelクラスを使うことでCの配列のと
同じくらいの高速化を実現できるといえばできるけど。

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


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

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

232 :デフォルトの名無しさん:2007/02/14(水) 02:20:11
>>212
> >>166
> >1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
> >JavaのGCがかなりネックになってしまう。
> >GCの走るタイミングが読めないし、完了する時間もわからない。
> 某UFJ銀行関連はJava使ってたような・・・。

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

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


233 :デフォルトの名無しさん:2007/02/14(水) 02:22:25
>>215
昔の言語とくらべると「できないことは無い」
というだけで「移植性が高い」と言っているだけだろうね。
Javaの移植性とはまた違う。今なら、Javaのほうが移植性が高く見える
ことは間違いないけど。

234 :デフォルトの名無しさん:2007/02/14(水) 02:23:34
>>218
> 数値計算というか事務計算をやらせようとするとC++厨もJava厨もろくでもない物しか作れない。
> 特にJavaの奴は誤差が頻繁に出るからクレーム付けたら「1円くらいどうでもいいだら」なんて言うし。
> 最低。

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


235 :デフォルトの名無しさん:2007/02/14(水) 02:25:19
>>222
10進数演算が得意なだけだろう。
日立のCOBOLerがJavaよりも優位な点は、
メソッドを使わず演算子だけでBihIntegerのようなクラスを
使うことができると主張していたな。

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

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


236 :デフォルトの名無しさん:2007/02/14(水) 02:26:55
>>225
よほど、Sunに知られていないOSや、Java SEやJavaMEが入らない
リソースが小さい古臭いOSじゃない限りそういうことはないだろう。


237 :デフォルトの名無しさん:2007/02/14(水) 02:27:36
>>230
知ったか厨?

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

238 :デフォルトの名無しさん:2007/02/14(水) 02:29:02
まあ、けっこうGUIライブラリにバグがあったりしたけどね。


239 :デフォルトの名無しさん:2007/02/14(水) 02:34:24
>>237
>229 の引用先の内容まで君が書いたわけじゃないんだろう?

240 :デフォルトの名無しさん:2007/02/14(水) 02:37:03
>>239
だからWikiで信用できないなら
この大元のソースを見ればいいだろう。

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


241 :デフォルトの名無しさん:2007/02/14(水) 02:39:28
WikipediaをWikiと略すやつはクズ。これは間違いない。

242 :デフォルトの名無しさん:2007/02/14(水) 02:41:55
>>240
いやだから、>239 で引用されている内容は中々面白いとおもうが、
>238 は全然そうではない。それだけの話。

243 :デフォルトの名無しさん:2007/02/14(水) 02:42:55
訂正
×>238、 >239
○>228、 >229

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

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

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

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






245 :デフォルトの名無しさん:2007/02/14(水) 03:46:20
>>244
>日本語版Wikipediaは創始者が腐女子みたいな馬鹿女で感情的になりやすく人の話を
>ろくに聞かないヤバイ奴だってってことも知ってる。
(・∀・)
なるほど、つまりそいつに追い出されたのか。m9(^Д^)プギャー

246 :デフォルトの名無しさん:2007/02/14(水) 03:49:59
>>245
追い出されてないがw

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

247 :デフォルトの名無しさん:2007/02/14(水) 06:06:37
Boostが、いつの間にJITコンパイルやGCのためのライブラリになったのやら

248 :デフォルトの名無しさん:2007/02/14(水) 06:15:20
>>232
Strutsとか使ってる部分は、金融系のプログラムっていうのとは違うでしょうが。。

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

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

249 :デフォルトの名無しさん:2007/02/14(水) 07:32:27
>>228は自分が何を問われていたのかわかっていないらしいな
周辺に結論も書いてあるというのに

250 :デフォルトの名無しさん:2007/02/14(水) 11:56:12
>>248
> プロファイラってOptimizeitとかだね。
Java標準のでもいけるけど。
Eclipseのでもいけるし。


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

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

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


251 :デフォルトの名無しさん:2007/02/14(水) 12:39:10
マルチスレッドとリアルタイムじゃ話が違うだろ

252 :デフォルトの名無しさん:2007/02/14(水) 13:42:56
鯖でリアルタイム?
マニピュレータでも使うのか?

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

253 :デフォルトの名無しさん:2007/02/14(水) 16:27:21
>今頃、Boost開発者は一生懸命Java SE 6のソースコードを解析して
>最適化技術をリバースエンジニアリングしているところじゃないかな?
ワラタwww
初心者は >>228 の書き込みを鵜呑みにしないようにwww どうみてもネタですからwww

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

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

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

254 :デフォルトの名無しさん:2007/02/14(水) 16:45:08
Boostは所詮ライブラリだから、最適化はコンパイラ任せでBoostの関与するところではないだろ。
勿論最適化されやすいコードを書くような努力はしているだろうけど。

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

255 :デフォルトの名無しさん:2007/02/14(水) 16:51:06
>>253
> 今頃、Boost開発者は一生懸命Java SE 6のソースコードを解析して
> >最適化技術をリバースエンジニアリングしているところじゃないかな?
> ワラタwww
> 初心者は >>228 の書き込みを鵜呑みにしないようにwww どうみてもネタですからwww

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

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

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


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

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

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

256 :デフォルトの名無しさん:2007/02/14(水) 16:54:14
>>253

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

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

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

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

257 :デフォルトの名無しさん:2007/02/14(水) 17:07:00
   l       \    ヽ
   l|, 、  、 |iヽ, ヽ \.   ヽ
 l  i ! | i  | |l'、ト ヽ iヽ ヽ  ',
 |  / | |. i  |.|| i.|ヽ |、 | ',   i  i
 ! / |_| | |i  ,;トi‐トi、! l  .i|  i
,.|!,.+''"^| |` | |i}  ' ュノェ|i,`i  l.| i
l |/;:=ニ|i  l |   /rj:ヽ\ i  l i l
' '/ iニ)ヽ,ヽ |!.   ' {::::::;、! 〉iー | | |  
;〈 !:::::::c!      `'ー'' ' }i | i.| |    
 ` `''"    、  //// /;:i | | !. |    きもちよかった?
、////      '     /,ノi,   i. |
、,ゝ、    --−'    /   i |  |. i
 | lヽ、        /    | i  | !
i |l l| |`''‐ 、   , イ | |    | i  |. !
| ||i,| |    ` ''"  | /l| l  |i  |l l  ! i
| l|!,>‐!          |〃i:|'i i | |.i |i | |i
i l iヽ.,!        |メ,/ | /ノi i. ! il i |i
/' |.:.:.:.``''ー-、     !  〉,|/ |/i' l |i l |ヽ
; r'.:.:.:.:.:.:.:.:.:.:.:.``''ー-'、ノ:|、_ ノ '  i,| l i|. l
/、、__.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:i.:.:ヽ   | |.i |. |
.:.:.:\`'ー-、___:.:.:ー'";/|:\  ' ト;| |
:.:.:.:.:.:\:.:.:.:.::..:.:.:.:.:.:.:.: ̄.:.:.:.:.:|.:.:.:.`ヽ、|.i

258 :デフォルトの名無しさん:2007/02/14(水) 17:07:16
>>253
int c = 0;
long first = System.nanoTime();
for (int i = 0; i < 10000; i++) {
c = (A <= B) ? A : B;
}
long last = System.nanoTime() - first;

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

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

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

259 :デフォルトの名無しさん:2007/02/14(水) 17:08:06
>>257がキモオタくさくてキモち悪かった



260 :デフォルトの名無しさん:2007/02/14(水) 17:27:53
>>257
ショウサイ・キボンティーヌ

261 :デフォルトの名無しさん:2007/02/14(水) 17:34:01
ここのJava最速君はどうしようもないな
同じJava信奉者でもマ板のおじゃばさまに遙かに劣る

262 :デフォルトの名無しさん:2007/02/14(水) 18:27:39
>>258
いやいやそんなことはない。
そもそもC++で書けば桁が違う、論外だと思っているのがC++厨

263 :デフォルトの名無しさん:2007/02/14(水) 18:51:59
>>248
だから藻前は金融系の仕事をしたことあるのか?と小一時間。

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

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

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

264 :デフォルトの名無しさん:2007/02/14(水) 19:02:05
金融系よりも株式系(?)とかのあっちの方が
走るトランザクション数多いけど、Javaや言語がどーこーよりも
RDBの性能の方が影響でかいから、「Javaだと不安」ってのは
仕事したことあるのか?と疑われても当然だ罠

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

265 :デフォルトの名無しさん:2007/02/14(水) 19:06:00
とりあえずC++0xがどうなるか見て見ないことには
なんか最近のC++は関数型に近くなってるよね

266 :デフォルトの名無しさん:2007/02/14(水) 19:09:18
オブジェクト指向が間違いだったことに皆が気付く日も近いのか

267 :デフォルトの名無しさん:2007/02/14(水) 19:41:14
一人だけ無駄に必死なやつがいるな

268 :デフォルトの名無しさん:2007/02/14(水) 19:54:30
積極的に最適化してくれというメソッドをアノテーションで指摘してやったら
多少は早くならんか

269 :デフォルトの名無しさん:2007/02/14(水) 20:04:22
ちなみに歴史的経緯は、GCが遅いことの反省からC++ではスタックとヒープを
プログラマが選べるようにして、コンピュータが速くなってきたからJavaでは
GCを再び採用したみたいな感じなんだけどね・・

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

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

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

270 :デフォルトの名無しさん:2007/02/14(水) 20:16:08
本当に速いものが欲しければアセンブリ言語。
今でも映像・音声の圧縮はアセンブリ言語が当たり前(少なくとも俺が使う範囲では)。

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

271 :デフォルトの名無しさん:2007/02/14(水) 20:31:26
つまるところ、ことたりるところはより高級な言語で、
速度を要するところでは低級言語で、という教科書に書いてる
ような結論になるわけだ。さすが教科書。

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

272 :デフォルトの名無しさん:2007/02/14(水) 22:06:56
プログラムの焼きこみとHDL(or専用回路)は本質的に違う訳だが


273 :デフォルトの名無しさん:2007/02/14(水) 22:14:51
無限に早ければいいと言う要求があるのは事実だろうけど、
C++をキモく感じる感情自体も事実だろ。

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

274 :デフォルトの名無しさん:2007/02/14(水) 22:22:44
Javaでキモいのはmainだな

275 :デフォルトの名無しさん:2007/02/14(水) 22:25:48
>>269
そういう話はC++煽り厨から耳にタコができるくらい聞いたから飽きた
もういい。数値演算だけは速いんだからC++でゲームでも作っていればいい。





276 :デフォルトの名無しさん:2007/02/14(水) 22:26:53
純粋仮想関数の =0; はキモすぎ。

277 :デフォルトの名無しさん:2007/02/14(水) 22:28:04
キモく感じるか、ならC++使いでもキモく感じているだろうよ
有害かどうか、って言うのはどうやって決めるよ?

278 :デフォルトの名無しさん:2007/02/14(水) 22:28:07
>>272
今なら、HDLもJavaで書く時代だw

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

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

279 :デフォルトの名無しさん:2007/02/14(水) 22:28:36
>>273
感情よりも実用性、効率性を考えるとC++の用途は
限られてくる。

280 :デフォルトの名無しさん:2007/02/14(水) 22:34:43
>ここのスレはどっちが優れているか?ではなくて、
>キモく感じるかどうか?が趣旨だしな
おぉそうだったな、そりゃ森三中とモリマンどっちが優れてる?と
変わらないくらいばかばかしい比較だからな。
俺はC++はキモかわいくて、Javaはパンチが足りない美形みたいなイメージだな。
もしくは萌え熟女と白肌美少女かな。

281 :デフォルトの名無しさん:2007/02/14(水) 22:38:14
確かにキモさを語るべきだな
C++不要論は別スレ立ててやればいんじゃね

282 :デフォルトの名無しさん:2007/02/14(水) 23:09:38
白肌美少女=Whitespace

283 :デフォルトの名無しさん:2007/02/14(水) 23:15:30
>>276
C++作ったBjarneがとにかく早く導入したかったから=0にしたとD&Eに書いている。

284 :デフォルトの名無しさん:2007/02/14(水) 23:21:50
構造体のコンストラクタとかどうよ?

285 :デフォルトの名無しさん:2007/02/14(水) 23:46:37
>>278
それってJavaでHDLを書けるっていうだけで
JavaそのものがHDLになる訳じゃないじゃん?


286 :デフォルトの名無しさん:2007/02/14(水) 23:55:37
http://124.38.226.66/bbs/156147/img/0053778307.JPG

287 :デフォルトの名無しさん:2007/02/15(木) 00:01:13
かわいい

288 :デフォルトの名無しさん:2007/02/15(木) 00:36:21
>>286 は Java と C++ どちらですか?

289 :デフォルトの名無しさん:2007/02/15(木) 01:24:15
>>280
C++厨は腐女子かw

290 :デフォルトの名無しさん:2007/02/15(木) 01:29:18
>>285
だがそれも重大な進歩である。

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

291 :デフォルトの名無しさん:2007/02/15(木) 02:21:52
低レベル処理がやりたかったらasmやcに行くし
高レベル処理ならスクリプトやJavaになるなぁ。
C++って選択肢は選びたいと思わない。

292 :デフォルトの名無しさん:2007/02/15(木) 02:27:08
両方をふらふら行き来しなければならないときには、選択肢の1つになると思う。

293 :デフォルトの名無しさん:2007/02/15(木) 02:50:22
桑島法子「C++厨は脳の手術をするべきだと思います」

294 :デフォルトの名無しさん:2007/02/15(木) 02:53:59
C++厨の脳にはガーベッジコレクタを搭載すべきだ。

295 :デフォルトの名無しさん:2007/02/15(木) 02:54:18
いや、Javaチップを埋め込んでやればいい。

296 :デフォルトの名無しさん:2007/02/15(木) 02:54:37
ついでに人格補正チップも埋め込むと良い。

297 :デフォルトの名無しさん:2007/02/15(木) 02:58:31
GCを搭載した結果出るのがそんな発言ならまだGCは不要だろうな

298 :デフォルトの名無しさん:2007/02/15(木) 04:10:59
Java脳で全てを解釈しようとするからそうなる。

299 :デフォルトの名無しさん:2007/02/15(木) 04:38:27
Javaチップなんて・・・
なんのためのVMなんだよ・・・

300 :デフォルトの名無しさん:2007/02/15(木) 10:09:32
ttp://gedo-style.net/g/?v=351494&d=d.jpg

301 :デフォルトの名無しさん:2007/02/15(木) 12:04:24
Bjarne Stroustrup Interview about C++
http://hp.vector.co.jp/authors/VA000092/jokes/strup.html

302 :デフォルトの名無しさん:2007/02/15(木) 12:13:18
ゲーム屋って、組み込み系だと思うな。

303 :デフォルトの名無しさん:2007/02/15(木) 14:40:18
>301
前スレで既出

304 :デフォルトの名無しさん:2007/02/15(木) 15:49:25
>>255
>Object#finalize()とfinallyとの区別が付いていないんじゃないかな。
ちょwww 意味わかってないんなら適当にレスすんなよwwwwwwwwwwww

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

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

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

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

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

305 :デフォルトの名無しさん:2007/02/15(木) 15:58:37
>>256
ちょwww おまっwwwwwwww まじかっwwwwwwwwwwwwwwwwwwwwwwwwwww
それ、途中で例外でたら処理の流れ違うからwwwwwwwwwwwwwwwwwwwwww
ネタ? ネタなんだろ? キモJava厨的にはこんなん当たり前?

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

306 :デフォルトの名無しさん:2007/02/15(木) 18:58:15
このスレ伸びすぎ

307 :デフォルトの名無しさん:2007/02/15(木) 19:01:27
デストラクタの話が出たときに、dispose()に思い当たらない
Java使いはもぐりだろ。

308 :デフォルトの名無しさん:2007/02/15(木) 20:02:29
>>306
ほとんど自演だから

309 :デフォルトの名無しさん:2007/02/15(木) 22:13:32
4人くらいで回してる感じだよな

310 :デフォルトの名無しさん:2007/02/15(木) 23:51:33
>>297
俺たちにはニューラルネットワークがあるかrGCはいらない。
だがC++脳にはGCが必要だ。

311 :デフォルトの名無しさん:2007/02/15(木) 23:56:22
個人的にはデストラクタが好き。

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

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

312 :デフォルトの名無しさん:2007/02/15(木) 23:58:29
>>305
> >>256
> ちょwww おまっwwwwwwww まじかっwwwwwwwwwwwwwwwwwwwwwwwwwww
> それ、途中で例外でたら処理の流れ違うからwwwwwwwwwwwwwwwwwwwwww
> ネタ? ネタなんだろ? キモJava厨的にはこんなん当たり前?
> >ファビョるタイプなんだろうなあ。
> 抱腹絶倒wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
> アルバイトに一通りソースチェックしてもらっちゃうよwwwwwwwwwwwwww


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

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

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

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

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

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





313 :デフォルトの名無しさん:2007/02/16(金) 00:05:58
コンストラクタ(C++ね)は嫌い。

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

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

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

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

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

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


314 :デフォルトの名無しさん:2007/02/16(金) 00:09:35
後から
class xxx : public base 

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

315 :デフォルトの名無しさん:2007/02/16(金) 00:20:08
>>256の上下でコードの意味が違うのだがJavaはそんなところまで最適化してくれるようになったの?
確かに恐ろしい最適化能力だな。人間を超えている。

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

317 :デフォルトの名無しさん:2007/02/16(金) 00:30:13
Javaマスター曰く金融の世界では上下で同じ意味らしいよ

318 :デフォルトの名無しさん:2007/02/16(金) 00:32:55
>>316
例外処理も最適化(自分の思った形にロジック変更)されるらしいと
思い込んでるんで勘弁してやってください

319 :デフォルトの名無しさん:2007/02/16(金) 00:34:46
つか、いつまで粘着してんの。くだらねえ。

320 :デフォルトの名無しさん:2007/02/16(金) 00:35:45
>>304
> >>255
> >Object#finalize()とfinallyとの区別が付いていないんじゃないかな。
> ちょwww 意味わかってないんなら適当にレスすんなよwwwwwwwwwwww
> >C++厨はfinallyとfinalize()との区別が付いていないようだね。
> >finallyは例外処理に使うものなんだけどねえ。
> finallyは例外の話だよ

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

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

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

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

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

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

321 :デフォルトの名無しさん:2007/02/16(金) 00:35:57
>>307
close()の間違いじゃなかろうな

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


323 :デフォルトの名無しさん:2007/02/16(金) 00:39:23
こんなの見つけた
http://mag.autumn.org/Content.modf?id=20050506145337

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

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

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



325 :デフォルトの名無しさん:2007/02/16(金) 00:41:00
>>256が実際どんな処理かは知らんが、例外が発生したらcatchで処理して
インクリメントしてくれなくても構わん場合がほとんどな気がするが。

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

326 :デフォルトの名無しさん:2007/02/16(金) 00:44:49
古いサイトではこんな都市伝説があるが、これもJ2SE1.4までの話。
Javaの最適化技術を甘く見ていると恥をかくので注意すること。

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


327 :デフォルトの名無しさん:2007/02/16(金) 00:46:19
自動変数のデストラクタの特徴は例外が発生しようがしまいが、(スコープを抜けるときに)必ず実行してから終了するというものなのだが。 


328 :デフォルトの名無しさん:2007/02/16(金) 00:46:26
>>323
ビーデーのメガネデブ川俣 晶かよw
その日記に自らJavaが嫌いになったJavaコミュニティが嫌いになったと
書いてる奴だろw ユニシスの某馬鹿社員と気が合いそうな奴で笑える。



329 :デフォルトの名無しさん:2007/02/16(金) 00:50:49
>>326
ソースきぼ

330 :デフォルトの名無しさん:2007/02/16(金) 00:52:34
256が最適化されようがされなかろうが、
こんなソース書いてる奴は作法がなっとらんわ。

331 :デフォルトの名無しさん:2007/02/16(金) 00:59:43
dispose()、close()、flush()、ほかにもあるかもしれない。
ヒープの解放の自動化は自慢するのに、
それ以外の資源については手作業でごりごり書くしかない。
それが「まし」だと思い込まされてることに気づかない。

332 :デフォルトの名無しさん:2007/02/16(金) 01:02:13
>>322
あいにくだがfinallyを引き合いにした話じゃないし
前レスのtryの話の続きじゃない

333 :デフォルトの名無しさん:2007/02/16(金) 01:02:39
>>329-330

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

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




334 :デフォルトの名無しさん:2007/02/16(金) 01:04:40
ちゃんと残りの9999回例外吐いてくれたよ@JDK6

335 :デフォルトの名無しさん:2007/02/16(金) 01:04:41
>>333
それが一般化してるならまだしも、
知ってる奴が限定されてんなら
思いっきり性能改善対象になるだろ。
知らない奴が多数なんだから。
つか、資料よろ

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


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


337 :311:2007/02/16(金) 01:10:47
>>333
何か知らんが例外の負荷が低いって良い話じゃない。

338 :デフォルトの名無しさん:2007/02/16(金) 01:12:41
>>335

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


>>334
所要時間は?

339 :デフォルトの名無しさん:2007/02/16(金) 01:14:58
>>338のPDFファイルの9枚目には
for文無いでtry-catchを書いてぬるぽを発生させた場合での
パフォーマンスもあるので、>>256の言ってることは正しい可能性が高い。


340 :デフォルトの名無しさん:2007/02/16(金) 01:15:52
>>313
C++0xではコンストラクタからメンバ初期化子構文で別のコンストラクタを呼べるようになるという噂。

>>314
そこでenumハック

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

341 :デフォルトの名無しさん:2007/02/16(金) 01:16:18
>>338の元のページはこれ

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

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


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

343 :デフォルトの名無しさん:2007/02/16(金) 01:21:20
とりあえずJavaのfinallyもC++の(ローカル変数に対する)デストラクタも、
(どっちの構文が優れているかはともかくとして)
例外の発生するしないに関わらず実行されることには違いないだろ。

344 :デフォルトの名無しさん:2007/02/16(金) 01:24:05
>>340
C++0xが早くできねーかな。
Javaにいいところ取られっぱなしだよ。

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

345 :デフォルトの名無しさん:2007/02/16(金) 01:26:07
Javaのfinallyはtry { } finally { x.close(); } を毎回書くが
デストラクタは X::~X() { close(); } を一度書くだけ。

346 :デフォルトの名無しさん:2007/02/16(金) 01:29:23
ただの finally よりも、例外が発生した時だけ実行される finally がほしい。

347 :デフォルトの名無しさん:2007/02/16(金) 01:29:27
何かJavaよくしらんけど
 X::~X() { if(!isClosed) throw "おまえcloseし忘れてないか"; } 
みたいな機能Javaにあるの?

348 :デフォルトの名無しさん:2007/02/16(金) 01:31:03
9999回リトライしない場合は上下のコードに大した速度差はないな

349 :デフォルトの名無しさん:2007/02/16(金) 01:33:01
>>346
それcatchの中でやればよくね?

350 :デフォルトの名無しさん:2007/02/16(金) 01:36:24
なんでもいいけど、
for文の中に例外処理が入ってるってのを
感覚的に気持ち悪いって思える方が信頼できる。
「最適化できますから」と力説されても気持ち悪いもんは気持ち悪い。

351 :デフォルトの名無しさん:2007/02/16(金) 01:37:35
>>346
C/C++だと何かメンドクセーgoto使っちゃえの世界だな。
goto減らす代わりにフラグとifが増やすのってめくそはなくそに思うんよ。
めくその方がちょっとましかもしれないけどさ。

352 :デフォルトの名無しさん:2007/02/16(金) 01:38:44
そういえば、Javaってクラスの中のクラスから
外のクラスのメンバにアクセスできるのと出来ないのがあるんだってね。
面白そうだね。
C++はできないタイプのほうしかない。

353 :デフォルトの名無しさん:2007/02/16(金) 01:40:38
>>352
これの、そういえばって、

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

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

354 :デフォルトの名無しさん:2007/02/16(金) 01:45:22
>>349
複数の catch に同じ開放コードを書くのはうんざり

355 :デフォルトの名無しさん:2007/02/16(金) 01:47:00
>>354
具体的に、どんな構文だったらマシになるかな?

356 :デフォルトの名無しさん:2007/02/16(金) 01:50:54
D言語のscope(failure)とか
http://www.kmonos.net/alang/d/exception-safe.html

357 :デフォルトの名無しさん:2007/02/16(金) 01:54:59
へー。VBのon errorにちょっと似てる?

358 :デフォルトの名無しさん:2007/02/16(金) 01:56:08
>>354
俺C++しかしらないけど、一応こういう書き方ができる(誰もやらないが)。
Javaでも似たような書き方ができないか?
try {
try {
//...
} catch (...) { //全ての例外を捕捉
//... 共通の後処理
throw;
}
} catch(const MyException& e) {
//...
} catch(const std::exception& e) {
//...
}

359 :デフォルトの名無しさん:2007/02/16(金) 01:58:02
>>355
try {
} catch {
} catch {
   ・
   ・
   ・
} commoncatch {
} finally {
}

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

360 :デフォルトの名無しさん:2007/02/16(金) 02:03:23
>>359
それだったら、switchみたいにcatchをbreakで抜けるようにすればよくね?

361 :デフォルトの名無しさん:2007/02/16(金) 02:04:47
>>358
まんま同じように書けるよ。

362 :デフォルトの名無しさん:2007/02/16(金) 04:59:53
>>345
それなら、Apache Jakarta Commons DBUtilsや
Apache Jakarta Commons IOを
使えばJavaでもfinallyを書かなくて済むようになると言えてしまうぞ。

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


363 :デフォルトの名無しさん:2007/02/16(金) 05:02:02
>>346
catch節抜きで

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

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

364 :デフォルトの名無しさん:2007/02/16(金) 05:04:26
>>345
そもそもclose()する必要がないオブジェクトに対しては
そんなものがいらないのでデストラクタなんぞ不要。

365 :デフォルトの名無しさん:2007/02/16(金) 05:12:46
>>347
Connection#isClosed()ならある。

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

366 :デフォルトの名無しさん:2007/02/16(金) 05:13:28
>>350
それもそうだ。外側に置いた方が、古いOSやJVMでも
パフォーマンスを改善できるのだからな。

367 :デフォルトの名無しさん:2007/02/16(金) 05:18:17
>>351
そこでJakartaなどのプロジェクト が様々な解決方法を提供しているわけだが。
Java5から登場したアノテーションを使うという手もあるだろう。

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

368 :デフォルトの名無しさん:2007/02/16(金) 05:26:10
>>358
Javaなら、そういうこと>>365のようにfinallyでやる。


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


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


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


369 :デフォルトの名無しさん:2007/02/16(金) 05:42:53
なんだかんだ言って、JavaもJakartaみたいに外部ライブラリを使わないといかんのかな・・
C++とBoostの関係と似たような物なのだろうか。

370 :デフォルトの名無しさん:2007/02/16(金) 08:20:04
俺は初期のJavaの解説をちょっと見た程度の知識しかないが
Java+Eclipse+Jakarta=スゲー
ってことなんだな。

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

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

371 :デフォルトの名無しさん:2007/02/16(金) 08:23:02
CとかC++って検索しにくかったな。
最近のgoogleはC++で検索できるようになってるみたいだけど。

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

372 :デフォルトの名無しさん:2007/02/16(金) 09:53:43
>>364
何が言いたいの?


373 :デフォルトの名無しさん:2007/02/16(金) 12:43:05
>>369
BoostとJakartaはあまりにも違うだろ。
Javaでは言語仕様にBoostのようなライブラリが含まれている。

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

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

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


374 :デフォルトの名無しさん:2007/02/16(金) 13:24:50
>>373
なんでWindows叩きをしてるの?

375 :デフォルトの名無しさん:2007/02/16(金) 13:34:12
C++がもっともつかわれているプラットフォームは
主にWindowsだからじゃね?

376 :デフォルトの名無しさん:2007/02/16(金) 13:57:17
Jakarta Commonsは低レベルだけど、スルーしないでほしい。

377 :デフォルトの名無しさん:2007/02/16(金) 14:00:12
>BoostのAPIとC++標準APIとの違いは 
>C++標準APIが低レベルAPIを提供しており 
>標準APIに不足している高レベルな部分をBoostが提供しているということ。 

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



378 :デフォルトの名無しさん:2007/02/16(金) 14:17:30
つうか、BoostはC++に標準で組み込まれてもいいはずの
低レベルAPIのはずなのに分離している。

379 :デフォルトの名無しさん:2007/02/16(金) 14:25:34
次期標準のC++0xでBoostの一部が取り込まれますから。

380 :デフォルトの名無しさん:2007/02/16(金) 14:33:41
ちょっwww
>>312 >>324 こいつwww ヤバイwwwwwwwwwwwwwwwwwwww
こんなに面白そうなオモチャ釣り上げたのに意外とレスつかないね。
やっぱム板は冷静な人多いね。
むしろ自分が初心者いじめてるイジメッコにしか見えんw

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

追伸
十年ロムってろw

381 :デフォルトの名無しさん:2007/02/16(金) 14:41:17
とりあえずVIPPERを装いたいんならwを大文字にしろ

382 :デフォルトの名無しさん:2007/02/16(金) 15:15:18
>>320 やっぱ、こいつも初心者? それともC++知らないだけ?

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

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

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

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

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

383 :デフォルトの名無しさん:2007/02/16(金) 15:32:18
>>382 Pythonの例だけど、closure
http://www-06.ibm.com/jp/developerworks/linux/010706/j_l-prog2.html

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

384 :デフォルトの名無しさん:2007/02/16(金) 15:39:42
クロージャも知らないプログラマが存在するのにはびっくり。

385 :デフォルトの名無しさん:2007/02/16(金) 15:40:31
>>832はJava頭のままC++を使わされて、どつぼに嵌ったかわいそうな人。


386 :デフォルトの名無しさん:2007/02/16(金) 15:41:25
>>832
おお、なんとかわいそうなお人。

387 :デフォルトの名無しさん:2007/02/16(金) 15:43:28
頑張れよ >>832
俺は期待してるぞ。

388 :382:2007/02/16(金) 15:58:11
いらん恥かいちゃったねw 言い訳しませんw

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

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

389 :デフォルトの名無しさん:2007/02/16(金) 16:39:33
>>382
C++の言語仕様って、それを外すとろくな代替がないことが多いんだ。
そういう意味では無駄がないと言えなくもない。
finallyはデストラクタがあるから要らないと考えれば納得できないか?

390 :デフォルトの名無しさん:2007/02/16(金) 17:31:29
>>380
> ちょっwww
> >>312 >>324 こいつwww ヤバイwwwwwwwwwwwwwwwwwwww
> こんなに面白そうなオモチャ釣り上げたのに意外とレスつかないね。
> やっぱム板は冷静な人多いね。

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

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

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




391 :デフォルトの名無しさん:2007/02/16(金) 17:33:55
>>388
> いらん恥かいちゃったねw 言い訳しませんw

すでにしてるだろうw

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


392 :デフォルトの名無しさん:2007/02/16(金) 17:40:54
以下はMLからの引用だが。Java SE 7(Dolphin)から導入予定の
クロージャによってfinallyを書く手間を省けるコードの例

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

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

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




393 :デフォルトの名無しさん:2007/02/16(金) 17:40:59
また、上記ブログでは、さらに同期に関して興味深い使用例が取り上げ
られています。C++のRAIIに匹敵する機能です。
withLock(lock) {
...
}

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

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



394 :デフォルトの名無しさん:2007/02/16(金) 18:08:35
これでtry finallyマンセーやろうが減ればいいんだけど。

395 :デフォルトの名無しさん:2007/02/16(金) 20:28:48
>>374
もちろん、>>373が馬鹿だからw

396 :デフォルトの名無しさん:2007/02/16(金) 21:24:50
>>395
お前、顔真っ赤だぞ

397 :デフォルトの名無しさん:2007/02/16(金) 21:32:29
酔ってないよ!!

398 :デフォルトの名無しさん:2007/02/17(土) 00:13:22
語尾にwを沢山つけていた
>>395の顔はしわくちゃになってます。


399 :デフォルトの名無しさん:2007/02/17(土) 00:39:26
つるつるすべすべだよ!!

400 :デフォルトの名無しさん:2007/02/17(土) 00:53:15
>>392
よりによって去年の8月の構文だしてくるかよ……

401 :デフォルトの名無しさん:2007/02/17(土) 01:09:20
finally好きでごめんな

402 :デフォルトの名無しさん:2007/02/17(土) 05:27:51
>>256
>>305
>>312
>>315
>>316
>>318
>>324
>>333
>>391
良スレあげ

403 :デフォルトの名無しさん:2007/02/17(土) 12:20:51
>>402
お前、256(もしくは320)?
391を含ませている辺り悪意を感じるな。
382が恥をかいたといっているのはクロージャ知らない
事に対してではないの?

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

404 :デフォルトの名無しさん:2007/02/17(土) 12:56:22
ttp://d.hatena.ne.jp/uskz/20070206/
クロージャといえばこんなんあった

405 :デフォルトの名無しさん:2007/02/17(土) 15:08:49
>>403
細かい探りを入れると惨めになってくよ。
ここは有益な情報が入ったから、よいとしようジャマイカ

406 :デフォルトの名無しさん:2007/02/17(土) 15:10:18
>>404
何このコードw

namespace lunatic { namespace lambda {

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


407 :デフォルトの名無しさん:2007/02/17(土) 15:12:04
つかクロージャ知らないなんてマとして認められんだろ。

408 :デフォルトの名無しさん:2007/02/17(土) 15:29:05
(let ((恥の上塗りcnt 0))
  (defun >>391 ()
    (princ "ところでお前は>>256の主張をまだ認めることができないんだなw")
    (incf 恥の上塗りcnt)))


409 :デフォルトの名無しさん:2007/02/17(土) 16:00:05
>>408
関数名に >> まで使えるのか。lisp 恐るべし。

410 :デフォルトの名無しさん:2007/02/17(土) 16:21:26
ワロ

411 :デフォルトの名無しさん:2007/02/17(土) 19:23:55
クロージャ使うのはひと苦労じゃ

412 :デフォルトの名無しさん:2007/02/17(土) 19:37:03
そんな寒いオヤヂギャグ


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

414 :デフォルトの名無しさん:2007/02/17(土) 19:56:20
駅で切符を買ってから改札を通るか、改札を通ってから切符を買うかを
電車に間に合うかどうかで決めることの愚かしさ。

415 :デフォルトの名無しさん:2007/02/17(土) 20:52:43
>>406
C++の人は変態と言ってあげると喜びます

416 :デフォルトの名無しさん:2007/02/17(土) 20:57:51
じゃあ、C++厨に向かって「きんもー☆」っと女の子に言わせるように指示しておくよ


417 :デフォルトの名無しさん:2007/02/17(土) 21:00:21
韮沢さんと大槻教授の噛み合わない論戦を見ているようだ。

418 :デフォルトの名無しさん:2007/02/17(土) 21:37:33
大昔のBASICとマシン語のやりとりとかわらんっつか、
俺はCOBOLer全盛時にASM屋だったケド同じだな。
やる場所がちがうだけだろ。

419 :デフォルトの名無しさん:2007/02/17(土) 21:39:18
電車に間に合わないときは乗ってから買うんだよ
今は通用しないのかな?

420 :デフォルトの名無しさん:2007/02/17(土) 21:44:17
>>419
Just in Timeコンパイラのことか?

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

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

421 :デフォルトの名無しさん:2007/02/17(土) 21:55:07
>>419
最低でも一駅分の切符がないとw

422 :デフォルトの名無しさん:2007/02/17(土) 21:58:46
>>419
今でも田舎では通用するよ

423 :デフォルトの名無しさん:2007/02/17(土) 21:59:59
>>421
最低でも一駅分のお金がないと買えないw

424 :デフォルトの名無しさん:2007/02/17(土) 22:10:13
VIEW Suicaや登録したPASMOではタッチしたときに残額が足りなければ、
クレジットカードからチャージするオートチャージという機能がある。

425 :デフォルトの名無しさん:2007/02/17(土) 22:12:10
人が立ってる側の改札なら突破できるぞ?

426 :デフォルトの名無しさん:2007/02/17(土) 22:19:31
自動改札も簡単に突破できるが?

427 :デフォルトの名無しさん:2007/02/17(土) 22:31:27
ム板で鉄道の話して勢い最大とかありえない

428 :デフォルトの名無しさん:2007/02/17(土) 22:34:13
基本的にこの板は活発でないもん。
半年以上書き込みがなくてもレス数があれば落ちないし。


429 :デフォルトの名無しさん:2007/02/17(土) 23:42:56
鉄道のシステムはJavaですかC++ですか?

430 :デフォルトの名無しさん:2007/02/17(土) 23:44:20
>>429
COBOLです

431 :デフォルトの名無しさん:2007/02/17(土) 23:50:08
TGVも?

432 :デフォルトの名無しさん:2007/02/18(日) 00:03:01
>>421
んなこたあない。改札がない駅はまだ幾らでもある。

433 :デフォルトの名無しさん:2007/02/18(日) 00:06:25
JR情報システムの社長はWindowsとドトネトに激しく拘っていたからな。
彼は「Windowsがないシステムはありえない」と強調しているからな。
COBOLが使われていたことが影響してMSの宣伝文句でCOBOL.NETに
乗せられてるんだろ。

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


434 :デフォルトの名無しさん:2007/02/18(日) 00:40:14
無人駅がかなりある。

435 :デフォルトの名無しさん:2007/02/18(日) 00:50:40
>>432
ちょ、それ改札通ってないw

436 :デフォルトの名無しさん:2007/02/18(日) 00:54:37
なるほど、つまり

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

っていうことか

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

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

          ____   
       / \  /\ キリッ
.     / (ー)  (ー)\      
    /   ⌒(__人__)⌒ \    <Javaの最適化を甘く見ているだろう
    |      |r┬-|    |   
     \     `ー'´   /
    ノ            \
  /´               ヽ              
 |    l              \
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、.    
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

          ____
        /_ノ  ヽ、_\
 ミ ミ ミ  o゚((●)) ((●))゚o      ミ ミ ミ
/⌒)⌒)⌒. ::::::⌒(__人__)⌒:::\   /⌒)⌒)⌒)
| / / /     |r┬-|    | (⌒)/ / / //  < だっておwwwwwwwwwwwwww
| :::::::::::(⌒)    | |  |   /  ゝ  :::::::::::/
|     ノ     | |  |   \  /  )  /
ヽ    /     `ー'´      ヽ /    /     バ
 |    |   l||l 从人 l||l      l||l 从人 l||l  バ   ン
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、    ン
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

438 :デフォルトの名無しさん:2007/02/18(日) 04:36:26
社内にいる車掌が改札だからな


439 :デフォルトの名無しさん:2007/02/18(日) 04:37:09
>>437
くだらない。何かちょっといっただけで毎日>>437のAAがレスされるの?
じつにくだらない

440 :デフォルトの名無しさん:2007/02/18(日) 04:50:11
最適化されるってレスしてるやつは、本気でそう思ってるのかネタでレスしてるのか
どっちなのか知りたいね。

441 :デフォルトの名無しさん:2007/02/18(日) 04:57:33
>>439
俺は>>437じゃないがお前の書き込み見てると>>437のAAでレスしたくなったぞw

442 :デフォルトの名無しさん:2007/02/18(日) 06:54:29
本人登場。まぁ言い返せないんだろうね。

443 :デフォルトの名無しさん:2007/02/18(日) 09:57:56
このスレ、今日はじめて見たんだが……(といっても全部じゃない)
cppとjavaの優劣をつけたいもんなのか?
俺、どっちも使うけど別に違いなんてその言語の味みたいなもんだろ。
必死になる気持ちがわからねぇよ

444 :デフォルトの名無しさん:2007/02/18(日) 10:01:31
自分の使ってる言語が偉いことになれば、自動的に自分が偉いことになるじゃん。
「やったァ、俺の勝ちぃぃぃぃぃぃ! お前は俺より格下な! 下、下プゲラ」
っていう最高の気分になれるじゃん。
ここのスレの人間はみんなそれを目指して頑張ってるんだよ。

445 :デフォルトの名無しさん:2007/02/18(日) 10:08:39
>>444
両方使えばヨクネ?新しいの覚えると、先のは頭から削除されるのか?

446 :デフォルトの名無しさん:2007/02/18(日) 10:35:15
>>439
AA略 <くだらない。何かちょっといっただけで毎日>>437のAAがレスされるの?
     <じつにくだらない
AA略 < だっておwwwwwwwwwwwwww

447 :デフォルトの名無しさん:2007/02/18(日) 13:26:30
>>443
釣りに引っ掛かる変なやつをいじって遊ぶところだろ >>256 とかの
>>256
>>305
>>312
>>315
>>316
>>318
>>324
>>333
この辺の流れか、いかにもアホそうなやつが沸いてるのは

448 :デフォルトの名無しさん:2007/02/18(日) 13:54:25
とりあえずage進行で発言してるやつはアフォなヤツが多いのは解る

449 :デフォルトの名無しさん:2007/02/19(月) 12:52:10
>>447
なぜおまえはそんなに必死なのだ。


450 :デフォルトの名無しさん:2007/02/19(月) 14:13:51
Javaやっているからって偉そうにすんなよ
どうせWindowsユーザでJavaで作られたソフトを使う人なんて多くないだろ

451 :デフォルトの名無しさん:2007/02/19(月) 14:45:55
いるだろ。
オンラインバンキングをなめんなよw

452 :デフォルトの名無しさん:2007/02/19(月) 15:24:52
> 多くないだろ
いるいないじゃなくて多いか少ないかの問題なんだが?
よく勘違いする奴って、何かと相手の意見を勘違いして
自分の脳内だけで意見のゴリ押しするから嫌われるんだよ

453 :デフォルトの名無しさん:2007/02/19(月) 15:25:58
>>451
あぁ〜〜そぉ、お前ってネットバンキングのプログラム作ってんの
あぁそうか、そりゃすごいね。それはそれですごいよ。だから何?

454 :デフォルトの名無しさん:2007/02/19(月) 15:27:10
あるぇ?この間それ関連でVistaだとサポートされてなくてしばらく対処されるまで
待つようにと告知されてなかったっけ?まぁ、Javaでそれが出来ればOSに依存せずに済む罠。

455 :デフォルトの名無しさん:2007/02/19(月) 15:58:52
>>452
>多いか少ないかの問題なんだが?
何が問題なんだか。

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

何その園児のケンカ。

456 :デフォルトの名無しさん:2007/02/19(月) 16:17:52
>>450
いるだろ、オンライントレーディングをなめんなよw

457 :デフォルトの名無しさん:2007/02/19(月) 16:57:23
将棋倶楽部24ではお世話になったなぁ
最近全然行ってねーや

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

459 :デフォルトの名無しさん:2007/02/19(月) 17:55:34
誰でもいいからポイポイ釣れるネタ書き込めよ、燃料無いとこのスレつまらんから。

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

460 :Javaやっていれば優秀だと思い込んでいるようです:2007/02/19(月) 17:59:20
458 名前:デフォルトの名無しさん 投稿日:2007/02/19(月) 17:06:17
>>450は何時の時代の人なんだろう。
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな
10年前の世界で思考停止している人ですかな

461 :デフォルトの名無しさん:2007/02/19(月) 18:04:23
さて、それではユーザはともかくJavaでプログラミングしている人と
Windowsアプリケーションを作っている人の割合を示すソースの提示を要求しよう。
これでJavaの方が上ってならそれはそれでどうでも良いことだがw

462 :デフォルトの名無しさん:2007/02/19(月) 18:28:48
Javaって、ゆとり教育にぴったり。
C++からコムズカシー機能は取り除きました! みたいな感じ。
んで、java厨は「こんなコムズカシー機能は有害なんです。」ってわめーてるのw
おめーがつかえねーだけだろw

463 :デフォルトの名無しさん:2007/02/19(月) 18:39:40
>>462
そうだよ、それが何か?

464 :デフォルトの名無しさん:2007/02/19(月) 18:45:52
有害に感じてくれていいと思うよ
こっちこられても困るし
仮にC++が滅亡しても1ヶ月もあれば余裕でJava厨になれるし
ゆとり教育にぴったりってのも素晴らしいメリットだよね

465 :デフォルトの名無しさん:2007/02/19(月) 18:46:22
          ____   
       / \  /\ キリッ
.     / (ー)  (ー)\      
    /   ⌒(__人__)⌒ \    <そうだよ、それが何か?
    |      |r┬-|    |   
     \     `ー'´   /
    ノ            \
  /´               ヽ              
 |    l              \
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、.    
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

          ____
        /_ノ  ヽ、_\
 ミ ミ ミ  o゚((●)) ((●))゚o      ミ ミ ミ
/⌒)⌒)⌒. ::::::⌒(__人__)⌒:::\   /⌒)⌒)⌒)
| / / /     |r┬-|    | (⌒)/ / / //  < だっておwwwwwwwwwwwwww
| :::::::::::(⌒)    | |  |   /  ゝ  :::::::::::/
|     ノ     | |  |   \  /  )  /
ヽ    /     `ー'´      ヽ /    /     バ
 |    |   l||l 从人 l||l      l||l 从人 l||l  バ   ン
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、    ン
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

466 :デフォルトの名無しさん:2007/02/19(月) 18:51:24
>>462
複雑なものをできるだけ単純に見せかける。
Javaの良し悪しは別として、言語の進歩ってそういうものだよ。
人間の頭は簡単には進化しないのだから。

467 :デフォルトの名無しさん:2007/02/19(月) 18:54:08
>>460-462
吹いたw
お前粘着かw


468 :デフォルトの名無しさん:2007/02/19(月) 18:54:50
C言語厨は>>458の一言にかなり傷ついたらいしな

469 :デフォルトの名無しさん:2007/02/19(月) 18:55:52
>>460
どうしたら>>458をそう曲解できるのだろう。
>>458>>450の二行目のことを言っているだけだと思うのだがw


470 :デフォルトの名無しさん:2007/02/19(月) 18:57:32
>>461
作っている人の数で判断してどうするんだw
>>450の花井から、使っている人の数を確認したかっただけじゃないのか?


471 :デフォルトの名無しさん:2007/02/19(月) 18:57:56
>>462
そうおもうなら、おまえはアセンブラでシコシコ書いていればいいよ

472 :デフォルトの名無しさん:2007/02/19(月) 18:58:20
>>464
> 有害に感じてくれていいと思うよ
> こっちこられても困るし
> 仮にC++が滅亡しても1ヶ月もあれば余裕でJava厨になれるし

無理。甘く見すぎや。


473 :デフォルトの名無しさん:2007/02/19(月) 19:03:36
>>472
うちの会社そんくらいの期間でJava未経験から粗製乱造して出荷してますから
営業が強いって、いいよね

474 :デフォルトの名無しさん:2007/02/19(月) 19:03:48
不要な機能を取り去る、というのはいいことだと思う。
取り去ってみたけど、後で必要が生じて付け足すのはバカバカしい。

475 :デフォルトの名無しさん:2007/02/19(月) 19:05:52
たとえば演算子オーバーロードのことですかね。

476 :デフォルトの名無しさん:2007/02/19(月) 19:10:40
>>474
テンプレート(C++) -> なし(昔のJava) -> ジェネリック
ちゃんとJava厨にも使えるように難しい使い方はできないようにしてあるけどね
バカバカしいでしょw

477 :デフォルトの名無しさん:2007/02/19(月) 19:10:43
それとも、可変長引数?

478 :デフォルトの名無しさん:2007/02/19(月) 19:12:20
RAIIとか

479 :デフォルトの名無しさん:2007/02/19(月) 19:26:09
Genericとかいらんだろ。Java1の頃が速度以外は一番良かった。

480 :デフォルトの名無しさん:2007/02/19(月) 19:27:46
懐古だが、あの頃はまだ夢があったな

481 :デフォルトの名無しさん:2007/02/19(月) 20:11:57
夢のある言語に乗り換えないの?

482 :デフォルトの名無しさん:2007/02/19(月) 20:28:09
>>459
>誰でもいいからポイポイ釣れるネタ書き込めよ、燃料無いとこのスレつまらんから。
そういう下らない事はマ板でどうぞ。

483 :デフォルトの名無しさん:2007/02/19(月) 20:51:08
Java?
C++?
お前ら何言ってんの
これからの時代はC#だろ

484 :デフォルトの名無しさん:2007/02/19(月) 20:54:46
>>482
ム板のほうがたまにいいレスつく確率が高そうなきがすんだよね
>>466 とか具体例だしてほしいんだけど、C++とJavaの違う部分でGC以外

485 :デフォルトの名無しさん:2007/02/19(月) 21:13:32
C#最強を信じる俺でもC#が盛り上がるとは思えん…

486 :デフォルトの名無しさん:2007/02/19(月) 21:27:38
そうか。スマソ

487 :デフォルトの名無しさん:2007/02/19(月) 21:43:02
>>476
そんな煽りをするなら、












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

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


488 :デフォルトの名無しさん:2007/02/19(月) 21:43:27
>>479
意味ねえ。リフレクションも使えねえし

489 :デフォルトの名無しさん:2007/02/19(月) 21:48:30
C#はウンコ。いいものをパクって我が物顔のいつものMS商法。
Monoならまあ、考えなくもないが結局それならPython使うよ。

490 :デフォルトの名無しさん:2007/02/19(月) 22:20:28
LISP最強

491 :デフォルトの名無しさん:2007/02/19(月) 23:39:49
>>481
Rubyに乗り換えたいけど、使い物になるにはまだまだ時間かかりそうだな。

492 :デフォルトの名無しさん:2007/02/19(月) 23:51:41
> 仮にC++が滅亡しても1ヶ月もあれば余裕でJava厨になれるし
なれるかボケ

493 :デフォルトの名無しさん:2007/02/20(火) 00:28:50
Javaをなめてかかって甘く見ている証拠だな。


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

それが証拠だな。

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

494 :デフォルトの名無しさん:2007/02/20(火) 00:36:36
>アセンブラ -> C/C++
>ちゃんとC++厨にも使えるように難しい使い方はできないようにしてあるけどね
アセンブラのなにが難しいんだ? アセンブラ自体はシンプルだろ。

495 :デフォルトの名無しさん:2007/02/20(火) 00:37:58
> 多くのC++厨がJavaのライブラリを覚え直すのが面倒くさいと主張している
そうか?俺はあまり聞かない気がする。
Wikipedia的にソース希望。

496 :デフォルトの名無しさん:2007/02/20(火) 00:39:31
どうか知らんが実際めんどいぞ。

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

498 :デフォルトの名無しさん:2007/02/20(火) 00:49:13
JavaやるとSTLがきもくてたまらん。OOPLの考え方に反してる。

499 :デフォルトの名無しさん:2007/02/20(火) 00:51:24
>>495
お前、チョンなどの三国人みたいにWikipedia改竄するなよ。

500 :デフォルトの名無しさん:2007/02/20(火) 00:52:03
>>497
たかくくりすぎだな。
お前にEJB使いこなせるか?


501 :デフォルトの名無しさん:2007/02/20(火) 00:54:11
一ヶ月でJavaを覚えられると言っている奴は
C++では想像もつかなかったコンパイルエラーに悩まされるだろう

502 :デフォルトの名無しさん:2007/02/20(火) 00:55:14
>>500
EJBを使いこなす必要のある仕事がどれぐらいあるんだ?

503 :デフォルトの名無しさん:2007/02/20(火) 00:56:23
>>497
やりゃわかるべ。
ひとつひとつは別に難しくないけど、覚えること多すぎ。

504 :デフォルトの名無しさん:2007/02/20(火) 01:02:33
>>498
STL使えるとJavaのコレクションはオコチャマ用にしかみえない。
効率悪くてやるきなくす。コード書かせすぎ。

505 :デフォルトの名無しさん:2007/02/20(火) 01:14:44
C++でATL組めるぐらいまでやれれば、Javaでとりあえず組むぐらいはできるよ。
Strutsのプロジェクトに参加するぐらいならネットで調べながらでもできるから、
できると思ってる人の気持ちはわかる。



506 :デフォルトの名無しさん:2007/02/20(火) 01:16:08
何度言っても配列Overでプログラムを変な落ちかたさせる同僚を見てると
Javaの方が数段優れてるように思えてくる。


507 :デフォルトの名無しさん:2007/02/20(火) 01:17:27
C++いいじゃん。
速いし、やれる事が沢山ある。
趣味プログラマーだからそう感じるんだろうけど(・・;)
仕事だったら生産性悪い気がする。

508 :デフォルトの名無しさん:2007/02/20(火) 01:18:18
JavaとC++、どっちが優れているかは別にして、
JavaプログラマーとC++プログラマーはどっちが技術のレベルが高いの?

509 :デフォルトの名無しさん:2007/02/20(火) 01:23:30
>>508
C++とJavaの知識領域は、実はあまりかぶるところが無いと思う。
両方(というか他の言語も)やる奴以外、技術レベルはあまり高くないと言えるかも。

510 :デフォルトの名無しさん:2007/02/20(火) 01:23:45
できるやつはC++もJavaも両方つかえるんじゃねーか?

511 :デフォルトの名無しさん:2007/02/20(火) 01:28:29
でもまぁ、JavaがC++よりよいと思われることの大部分は、VMによって享受されて
いるわけで。

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

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

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

512 :デフォルトの名無しさん:2007/02/20(火) 01:32:08
C++/CLIとC++はまったくの別物だし、J#とJavaはまったくの別物。
これでは、比較にならないぞ。

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

513 :デフォルトの名無しさん:2007/02/20(火) 01:33:27
JavaもC++もまだまだ改良の余地ありすぎだろ。
早く改良しやがれ!

514 :デフォルトの名無しさん:2007/02/20(火) 01:36:25
つC++0x

515 :デフォルトの名無しさん:2007/02/20(火) 01:49:08
>>512
もちろん冗談だが。

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


516 :デフォルトの名無しさん:2007/02/20(火) 01:58:51
VMバージョン地獄はもういやお

517 :デフォルトの名無しさん:2007/02/20(火) 02:02:22
>>516
バージョンアップしない言語に乗り換えないの?

518 :デフォルトの名無しさん:2007/02/20(火) 02:03:10
Javaの案件やってて鬱になるのは、フレームワークが多すぎて
どれ使っていいかの判断が辛いことだな。
それなりに本やWEBで追っているつもりだが、大変だ。
あと、おっさんが日経なんとかで見つけた技術を使いたがって鬱陶しい。

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

519 :デフォルトの名無しさん:2007/02/20(火) 02:07:25
>>494
インテル系の石は直交性低いせいで無駄に難しくなってるよ。

520 :デフォルトの名無しさん:2007/02/20(火) 02:08:14
>>504
STLのほうがどうみても効率悪いだろ。
Objectクラスが無い時点でもうすでにオコチャマだな。


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



521 :デフォルトの名無しさん:2007/02/20(火) 02:09:20
>>511
機能が多いだけならそりゃ勝てる。
だが、実用性という観点を考える、C++は負ける。

522 :デフォルトの名無しさん:2007/02/20(火) 02:10:12
>>518
それもおまいの修行が足りないんだよ。


523 :デフォルトの名無しさん:2007/02/20(火) 02:27:46
STLの作者のOOPL嫌いは有名

524 :デフォルトの名無しさん:2007/02/20(火) 03:19:53
>>501
C++の変態的動作に比べればぬるいぬるい

525 :デフォルトの名無しさん:2007/02/20(火) 03:26:42
>>520 Objectクラスがなくてもtemplateがあればいいじゃない

526 :デフォルトの名無しさん:2007/02/20(火) 03:30:24
>>525
だめだ。
equals()もhashcode()もwait()もnotify()も実装できない言語なんぞたかが知れてる

527 :デフォルトの名無しさん:2007/02/20(火) 03:30:40
>STLのほうがどうみても効率悪いだろ。
>不満があるなら、Jakarta Commons Collectionsを使え。
Jakarta Commons Collectionsっていうのをちょっとだけ調べてみたけど
たんにSTLをJavaで無理なく実装してみた感じのものなのか?
まぁ、Java使うときはこれ使っとくよ。

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

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

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

528 :デフォルトの名無しさん:2007/02/20(火) 03:33:13
>>527
> Jakarta Commons Collectionsでも基本的に全部Objectで扱うように
> なってるんだよな、おかげでJakarta Commons Collections使っても
> キャストしまくりじゃねーか。

つGenerics対応版




529 :デフォルトの名無しさん:2007/02/20(火) 03:37:01
>>527
> >Objectクラスが無い時点でもうすでにオコチャマだな。
> これが、理解できん。

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


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


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



530 :デフォルトの名無しさん:2007/02/20(火) 03:41:50
>新しいCollectionsはGenericsに対応してその問題は解決している。
url書けよ、余計なものばっかり引っ掛かるぞ。リファレンスのurlな

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

531 :デフォルトの名無しさん:2007/02/20(火) 03:43:30
>>529 

template関数で出来ると思いますが。共通の基底型が無くたって、

template<typename T>
int hashcode(const T& t) { return t.hashcode(); }

とやれば、hashcode()関数を持つクラスなら hasecode(Hoge)で全部呼んでくれます。

共通の基底型の関数をオーバーライドして、仮想関数呼び出し相当のコストを払うのはもったいない。
「JITコンパイルでインライン化されるから、早さは変わらない」と言われるんだろうけど。


あと、Genericsも5.0時代の実装ではキャストが消えてないみたいですが。
http://www.javainthebox.net/laboratory/J2SE1.5/LangSpec/Generics/Generics.html
「最近のVMの進歩で、コストは償却されます」と言われるんだろうけど。

532 :デフォルトの名無しさん:2007/02/20(火) 03:49:22
>equals(), hashCode()をオーバーライドできないから糞ってこと。
>コレクションに格納できるオブジェクトは、とくにMapはequals(), hashCode()の
>実装に大きくかかっている。
STL知らんのまるだしかよ。

533 :デフォルトの名無しさん:2007/02/20(火) 03:49:52
>>530
ほれ
http://sourceforge.net/projects/collections


534 :デフォルトの名無しさん:2007/02/20(火) 03:50:46
>>531
それで、intが64bitに変わったときはどうするんだ?


535 :デフォルトの名無しさん:2007/02/20(火) 03:51:56
>>531
> あと、Genericsも5.0時代の実装ではキャストが消えてないみたいですが。

Genericsはパフォーマンス目的ではなく type safeが目的だからな。



536 :デフォルトの名無しさん:2007/02/20(火) 03:55:12
>>534
戻り値もtemplateにしますかね。

>>535
C++並になれてよかったね。

537 :デフォルトの名無しさん:2007/02/20(火) 03:57:28
>>533
リファレンスのurlっていってるだろーが

538 :デフォルトの名無しさん:2007/02/20(火) 04:03:52
>>531
それだと、実装しない馬鹿対策には弱い。
Mapに実装しないと意味がない。

いまどき非finalメソッドが遅くなるなんていっていってるのは都市伝説信者だな。

Javaの理論と実践: パフォーマンスの都市伝説
http://www-06.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html
都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる
都市伝説その3: 不変オブジェクトはパフォーマンスを悪化させる


539 :デフォルトの名無しさん:2007/02/20(火) 04:14:07
>>536
> >>534
> 戻り値もtemplateにしますかね。
そのクラスのオブジェクトのパターンが2の32乗通り以上あった場合どうするんだ?
しかも、馬鹿が書いたクラスのオブジェクトのフィールドの一つ一つがすでに
2の32乗の範囲を超えている。

> >>535
> C++並になれてよかったね。
むしろ、C++のほうがtype safe性に弱いのでJava並みになれていないことがC++の落ち度だが。


540 :デフォルトの名無しさん:2007/02/20(火) 04:14:24
>>537
甘えるな。
あとはそれでなんとかなるだろ

541 :デフォルトの名無しさん:2007/02/20(火) 04:15:30
>>530
STLのequals()はhashCode()との『契約』をちゃんと満たしているか?

"Design by Contract" をちゃんと満たしているか?


542 :デフォルトの名無しさん:2007/02/20(火) 04:19:26
まず、Jakarta Commons Collections のGenerics対応版のリファレンスのURL書けよ

543 :デフォルトの名無しさん:2007/02/20(火) 04:25:00
>いまどき非finalメソッドが遅くなるなんていっていってるのは都市伝説信者だな。
>Javaの理論と実践: パフォーマンスの都市伝説
>http://www-06.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html
>都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる
>都市伝説その3: 不変オブジェクトはパフォーマンスを悪化させる
だれもそんな話してないから。

あと、STL知らんのならわざわざSTLについてかかなくていいよ。

なんか、この前のJava最適化君がわいてるようなオカン。

544 :デフォルトの名無しさん:2007/02/20(火) 04:26:18
STLのequals()は以下をちゃんと満たしているか?

HashMapのキーに使用できるオブジェクトの
equals()メソッドの実装は以下の条件を満たさなければMapの
実装を破壊するわけだが。

null以外においてa == aは常にtrueを返さなければならない。
a == b がtrueを返すならば b == aもtrueを返さなければならない。
a == b, b == cがどちらもtrueを返すならば a == cもtrueを変え餌無ければならない。
a == b がtrueならば、a == b は何回呼び出されようと終始一貫して trueを返さなければならない。
a == b ならば a.hashCode()とb.hashCode()は必ず同じ値にならなければならない。
a(またはb)が不変または一切変更されないときは、首尾一貫してつねに同じ数値を返さなければならない。


==はequals()に置き換えて考えてくれ



545 :デフォルトの名無しさん:2007/02/20(火) 04:27:29
>>543
> いまどき非finalメソッドが遅くなるなんていっていってるのは都市伝説信者だな。
> >Javaの理論と実践: パフォーマンスの都市伝説
> >http://www-06.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html
> >都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる
> >都市伝説その3: 不変オブジェクトはパフォーマンスを悪化させる
> だれもそんな話してないから。

> 共通の基底型の関数をオーバーライドして、仮想関数呼び出し相当のコストを払うのはもったいない。

ほら、してるよ。


546 :デフォルトの名無しさん:2007/02/20(火) 04:27:57
>>542
>>540

547 :デフォルトの名無しさん:2007/02/20(火) 04:29:49
>>538
>実装しない馬鹿対策には弱い。 
ってどういうこと?C++でtemplateを使う場合は、むしろ関数宣言が無ければコンパイルエラーで落ちてくれますが。
「基底型の関数をオーバーライドせずに使うのは問題」というのなら確かにそう。
でもJavaも変わらない気が。Object#hashcode()があるからある意味安全だと思うけど。


無駄なfinal宣言を避けろって、これは「些細なパフォーマンスの期待で、インターフェースを汚すことは無い」と言う話だよね。
パフォーマンスのJIT最適化も、これなんでしょう?
>「JITコンパイルでインライン化されるから、早さは変わらない」と言われるんだろうけど。 


>>539
その肥大したクラス階層を総称的にtemplateで扱えますよ。
むしろ、その泥沼状態はJavaでも変わらない気が。


安全じゃないキャストが出来てしまう、のは確かにC++の泥沼感を示している。
全部dynamic_castに制限すれば、Java並になれるけどね。そこはJavaでの洗練が感じられる。


>>540
その手の"契約"は、静的にはtemplate解決失敗時の(意味不明な)エラーと assert()で行うのがC++では普通かな。

あと、STLの連想コンテナは'<'演算子に基づくもので、Javaのようにハッシュとequals()に基づくものじゃないよ。
だからそんな契約も必要ない。ていうか共通の基底型が無くて出来ない。


548 :デフォルトの名無しさん:2007/02/20(火) 04:33:39
>> 共通の基底型の関数をオーバーライドして、仮想関数呼び出し相当のコストを払うのはもったいない。

>ほら、してるよ。
C++の話だ

549 :デフォルトの名無しさん:2007/02/20(火) 04:34:15
>>547はチーム開発経験が浅いのかね

550 :547:2007/02/20(火) 04:35:59
安価間違えたorz >540→>>541

あと、"動的には"assert()で契約を行う・・だった。でもこのへんはJavaも一緒か

>>549 うん orz

551 :デフォルトの名無しさん:2007/02/20(火) 04:44:41
>>547
> >>538
> 無駄なfinal宣言を避けろって、これは「些細なパフォーマンスの期待で、インターフェースを汚すことは無い」と言う話だよね。

「virtualを付けると遅くなるから、virtualがデフォルトであるJavaのメソッドにはfinalをつけなければならない」
こう主張しているジジイがたまにいるんだよね。

> 共通の基底型の関数をオーバーライドして、仮想関数呼び出し相当のコストを払うのはもったいない。

あんたもこんな発言をしたからそのジジイとかわらないんじゃないかな。


> >>539
> その肥大したクラス階層を総称的にtemplateで扱えますよ。

意味わかって言ってるのかね。JavaのintはどんなOSであっても32bitsと決まっている。
だがC++のintはプラットフォームによってころころ変わる。そんな環境下で、intが64bits前提で
hashCode()を実装した奴とintが32bits前提で実装した奴のそれぞれのhashCode()を持ったクラスを
集約したクラスをつくるときに面倒なことが起きる、ということを想像できないのかね。
しかもそいつらが作ったクラスがブラックボックスだったら、ますます厄介なことになるぞ。



552 :デフォルトの名無しさん:2007/02/20(火) 04:45:33
> >>541
> その手の"契約"は、静的にはtemplate解決失敗時の(意味不明な)エラーと assert()で行うのがC++では普通かな。
> あと、STLの連想コンテナは'<'演算子に基づくもので、Javaのようにハッシュとequals()に基づくものじゃないよ。
> だからそんな契約も必要ない。

まるでComparable<T>#CompareTo(T)みたいだな。

しかし、hashCode()なしではHashMapやhashSetの
パフォーマンスに弊害がでるものではないかな。

ついでにこれらのクラスにもそのComparableインタフェースが実装されている。
 



553 :デフォルトの名無しさん:2007/02/20(火) 04:46:20
>>548
だが、それをJavaに置き換えて「Javaは遅いニダ!」とファビョる馬鹿もいるんだよね

554 :デフォルトの名無しさん:2007/02/20(火) 04:47:18
>>544の要求を満たすequals()相当のメソッドがないSTLはかなりやばいね

555 :デフォルトの名無しさん:2007/02/20(火) 04:51:20
STLはしらねーし、リファレンスはないし話にならねーな

556 :デフォルトの名無しさん:2007/02/20(火) 05:05:59
>>551
Javaなら
>「JITコンパイルでインライン化されるから、早さは変わらない」
って最初に書いたのに・・orz
だから俺も、Javaで組むときには無駄にはfinalつけるようなことはしない。
C++のときは、非仮想に出来るだけ持っていく


>>539ではクラスの数の話、>>534ではint型の大きさの話をするから混ざって訳分からなかったけど、環境依存の話?
確かにそれはカオス。VMで型の大きさが決まっていることは素晴らしく楽だね。


>>552
まあ、標準にハッシュ表がないからねえ。


>>554
C++は、< 演算子を用いた ∀i ,!(*(i+1) < *i) による"等価"を用いて、そのequals()契約と同等のことをしてます。
式が適当でスマソ

557 :デフォルトの名無しさん:2007/02/20(火) 08:21:50
Javaのハッシュによる辞書とC++のツリーによる辞書を比べてどうするんだ
意味がわからん


558 :デフォルトの名無しさん:2007/02/20(火) 09:57:15
Javaが遅いとか言われているしスパコン並みの超高速CPUでも買うか。
メモリも512テラぐらいつむか

559 :デフォルトの名無しさん:2007/02/20(火) 10:07:41
>>558
何言いたいのか解らないが
メモリ512テラ載せれるマシンってあんのかよ

560 :デフォルトの名無しさん:2007/02/20(火) 11:31:49
Win x64 でも 16TiB までしかサポートしてませんね。
Itanium はプロセッサ自体は 1PiB まででしたっけ?

561 :デフォルトの名無しさん:2007/02/20(火) 13:03:34
>>555
そうか、おまいがしらなかったのか。ファッキン!ファッキン!

562 :デフォルトの名無しさん:2007/02/20(火) 13:04:56
>>498
散々言われているようにSTLはOOP的でないので、
Javaやってからだときもく感じるのは別に不思議ではない。

で、お前がきもいと感じるかどうかと有害かどうかは別問題なんだ。

563 :デフォルトの名無しさん:2007/02/20(火) 13:05:04
>>558
通常はそこまでいらんわ。
EclipseやNetBeansでは1GBくらいが妥当。


564 :デフォルトの名無しさん:2007/02/20(火) 13:06:27
すくなくともCのポインタはPerlのポインタより
糞だということだけはわかる。


565 :デフォルトの名無しさん:2007/02/20(火) 13:28:00
Perlにポインタなんてあったっけ。

566 :デフォルトの名無しさん:2007/02/20(火) 14:23:06
ある

567 :デフォルトの名無しさん:2007/02/20(火) 14:59:41
     ∧_∧
ピュ.ー (  ^3^) <エェー これからも僕を応援して下さいね(^3^)。
  =〔~∪java~〕
  = ◎――◎                      java&サン


568 :デフォルトの名無しさん:2007/02/20(火) 15:24:28
ちなみに、TreeSet, TreeMapクラスに
使用するキーとなるオブジェクトは必ずComparableインタフェースを
実装しなければならないという決まりがあるよ。

569 :デフォルトの名無しさん:2007/02/20(火) 15:24:50
>>567
Javaすれにわざわざコピペご苦労

570 :デフォルトの名無しさん:2007/02/20(火) 15:49:35
>>568
このスレにきてる人の大部分は、
すでに知ってるか、知らなくてもすぐに調べられる人だと思うよ

571 :デフォルトの名無しさん:2007/02/20(火) 15:54:47
C++しか知らない奴の多くが知らないことだと思うよ

572 :デフォルトの名無しさん:2007/02/20(火) 15:57:13
>>571
脊髄反射乙。たった2行なんだから、全部読んでからレスしてね。

573 :デフォルトの名無しさん:2007/02/20(火) 16:04:04
煽り厨乙

574 :デフォルトの名無しさん:2007/02/20(火) 16:09:02
厨厨乙

575 :デフォルトの名無しさん:2007/02/20(火) 16:12:36
じゃあ逆にC++を書けば釣り合う。

std::set, std::mapクラステンプレートには
使用するキーとなるオブジェクトを比較するファンクタのクラスを
指定しないといけないよ。

ただしデフォルトではoperator <で比較するファンクタが指定されるから
キーとなるオブジェクトの型がoperator <を持っていればそれを使えるよ。

576 :デフォルトの名無しさん:2007/02/20(火) 18:55:48
Javaしか知らない奴はVB厨と同レベル

577 :デフォルトの名無しさん:2007/02/20(火) 19:13:54
C++しか知らない奴も然り。

578 :デフォルトの名無しさん:2007/02/20(火) 19:20:09
C++を知っててCを知らないことはあり得ないから
C++しか知らない奴は存在しえない。

579 :デフォルトの名無しさん:2007/02/20(火) 19:22:30
>>578
アフォでつか・・・

580 :デフォルトの名無しさん:2007/02/20(火) 19:30:20
VB、Java、C++をそつなくこなす俺が最強

581 :デフォルトの名無しさん:2007/02/20(火) 20:32:00
>>578
> C++を知っててCを知らないことはあり得ないから

ありえるよ。いきなりC++からやった奴なんてCのポインタの
使い方間違えるし。

> C++しか知らない奴は存在しえない。

現実をみよう



582 :デフォルトの名無しさん:2007/02/20(火) 20:33:02
Visual C++にいきなり手を出した奴なんて
ろくなやつがいない。まさにVB厨と変わらないレベル

までエディタ + シェル + Ant でJavaを始めた奴のほうがまとも

583 :デフォルトの名無しさん:2007/02/20(火) 21:03:52
Javaも所詮は環境依存なのにそのままどこに持っていっても動くとか勘違いする馬鹿を量産するだけ。
低レベルな視点を全く身につけられないJavaは害悪以外の何者でもない。

584 :デフォルトの名無しさん:2007/02/20(火) 21:04:59
>>580
全部事務用言語じゃねーか。そんなの「こなす」とか言ってるレベルで駄目。

すくなくともLisp、Ruby|Python, javascriptぐらいはやってからこのレベルの高いスレに
参加してほしい。

585 :デフォルトの名無しさん:2007/02/20(火) 21:15:12
>>583
何時の時代の話をしているんだこのハゲはw


586 :デフォルトの名無しさん:2007/02/20(火) 21:15:43
>>584
似たようなスクリプト言語ばっかだな
RubyとLisp程度でいいだろw



587 :デフォルトの名無しさん:2007/02/20(火) 21:29:39
>>586
結論には同意するが、似てるのは「スクリプト」と言う点だけだろと突っ込み入れておく。
特に lisp はその中でも異色。

588 :デフォルトの名無しさん:2007/02/20(火) 21:41:28
スクリプトは処理遅いって思ってる俺は時代遅れ?

589 :デフォルトの名無しさん:2007/02/20(火) 21:47:05
Lispもpythonもコンパイルできるぞ

590 :デフォルトの名無しさん:2007/02/20(火) 21:59:20
>>581
それで「C++できる」にカウントするのか?

591 :デフォルトの名無しさん:2007/02/20(火) 22:44:44
コンパイルできる=高速って考えもあれだが

592 :デフォルトの名無しさん:2007/02/20(火) 22:45:10
スクリプトが型に甘いのでイマイチ

型推論とも違うし

593 :デフォルトの名無しさん:2007/02/20(火) 23:10:46
>>583
ファイルパスの扱いとか、環境非依存にしようがない所ぐらいしか
環境依存部分はないと思うのだが。

環境非依存にすることが出来るのにも関わらず、
環境依存になってしまっている例を挙げれるものなら挙げてみ

594 :デフォルトの名無しさん:2007/02/20(火) 23:14:31
勝手にキャストするほうがおかしいだろ

595 :デフォルトの名無しさん:2007/02/21(水) 00:10:08
何の話をしてるんだ?

596 :デフォルトの名無しさん:2007/02/21(水) 00:30:26
>>595
キャストの話をしてるんだ

597 :デフォルトの名無しさん:2007/02/21(水) 00:45:19
Javaの最大の環境依存性 : JVMの有無

598 :デフォルトの名無しさん:2007/02/21(水) 00:51:16
ISO C++0x に入るもの
- Garbage collection
- Memory model for concurrency
- Concurrency libraries

GCがあり、並行プログラミングに強いJavaではもうおなじみのものだな。

599 :デフォルトの名無しさん:2007/02/21(水) 00:54:24
>>597
それ、あるね。
Windows使っている人に、Java入れてよってなかなかね。
JREのダウンロードサイトもなんかわかりにくいし。

600 :デフォルトの名無しさん:2007/02/21(水) 01:35:30
>>598みたいなしくみ必要ないんじゃない?
C++よりパフォーマンス悪くして何を目指してるんだろう。

一番アフォくさいのはGCや生配列扱うときのの添え字チェックだよ
テストでまかなえるのにわざわざパフォーマンス下げるなよ・・・
なんで有限回数しか回らないんだからコアダンプ吐くまでテストすりゃ十分じゃん。
メモリの生きてる範囲小さくしていけばメモリリークも十分テストで網羅できるし、
パフォーマンス意識してキャッシュライン考えるとGC悪じゃん。
数百万出せば逆アセからメモリリーク出そうな場所特定してくれるツールもあるんだしさー

c++は今のままで十分、改造するなら別の言語として作って欲しいわ


601 :デフォルトの名無しさん:2007/02/21(水) 01:42:56
何が勝手にキャストするのか

602 :デフォルトの名無しさん:2007/02/21(水) 01:43:24
>>599
勝手にはいるから問題ない

603 :デフォルトの名無しさん:2007/02/21(水) 01:43:28
何でもあり言語C++はとどまることを知らず

604 :デフォルトの名無しさん:2007/02/21(水) 01:46:21
>>599
つJETコンパイラ

605 :デフォルトの名無しさん:2007/02/21(水) 01:48:36
>>600
> >>598みたいなしくみ必要ないんじゃない?
> C++よりパフォーマンス悪くして何を目指してるんだろう。
> 一番アフォくさいのはGCや生配列扱うときのの添え字チェックだよ

そう思うなら、超巨大な配列を作ればいい。

Javaなら、Bufferクラスを使って


> テストでまかなえるのにわざわざパフォーマンス下げるなよ・・・
> なんで有限回数しか回らないんだからコアダンプ吐くまでテストすりゃ十分じゃん。

『アジャイルソフトウェア開発の奥義』ではそんな言い訳は許されない。



606 :デフォルトの名無しさん:2007/02/21(水) 01:52:02
http://en.wikipedia.org/wiki/C++0x
にはそれ以外も挙げられてるが、>>586のJava使いは
それらの重要性は理解できずに割愛したんだろう。



607 :デフォルトの名無しさん:2007/02/21(水) 01:59:44
>>606
まて、お前英語読めるか?

The factual accuracy of part of this article is disputed.
The dispute is about the current status of C++0x work (the description below is now outdated).
Please see the relevant discussion on the talk page.

その記事を見ただけでは信用するに値するかどうかもわからん


608 :デフォルトの名無しさん:2007/02/21(水) 02:02:31
>>607
ありがと。でも、これよりまとまったページ知ってる?

609 :デフォルトの名無しさん:2007/02/21(水) 02:06:30
Implicit function call

To call a function always required an explicit use of parenthesis. If a function takes no parameters this formality can be out-of-date declaring the function as implicit.

Obviously an Implicit callable function cannot receive parameters (probably it will not be even permitted to write void as the parameter list), and it must not to be confused with a pointer to function. For example:

long double greekpi() implicit { return 3.14159265358979323846264338327950288L ; }
area = greekpi * 144 ;


↑こういう紛らわしいことは辞めて欲しいんだけどな。
ソースが読みにくくなる。

610 :デフォルトの名無しさん:2007/02/21(水) 02:07:51
暗黙の型キャストもキモイ

611 :デフォルトの名無しさん:2007/02/21(水) 02:10:10
The idea is to introduce a special constructor taking a sequence of objects:

vector( initializer_list<int> seq ) ; // Constructor from a sequence of int.

The sequence initializer (initializer_list) is a template class defined as it follows:

template<class E> class initializer_list
{
public:
initializer_list( const E* first, const E* last ) ;
initializer_list( const E* first, int length ) ;

int size () const ; // Number of elements.
const E* begin() const ; // The first element’s address.
const E* end () const ; // The following address to the last element.
} ;


というか、C++には今までイニシャライザがなかったのか。
Javaより後発で導入するとは

612 :デフォルトの名無しさん:2007/02/21(水) 02:19:44
C++はC++0xになってもコードが美しくないな

613 :デフォルトの名無しさん:2007/02/21(水) 02:30:39
なんでもいいからさっさと標準的なString型を導入しろよ

String foo = "hogehoge" + "fugafuga";

って書けるだけいいからさあ。


614 :デフォルトの名無しさん:2007/02/21(水) 02:33:54
>>602
最近はかってに入るのか。。
>>604
JITコンパイラの利点は無くなっちゃうのかな。

615 :デフォルトの名無しさん:2007/02/21(水) 02:39:02
>>611
Javaだって汎用のヤツはなかったんじゃないか?
いつの間にか
ArrayList<int> a = new ArrayList<int>() { 1, 2, 3 };
と書けたりするようになったのか?


616 :デフォルトの名無しさん:2007/02/21(水) 06:30:06
ObjCが
http://developer.apple.com/jp/briefing/cocoa.html

617 :デフォルトの名無しさん:2007/02/21(水) 08:43:58
>>613
いまはこれで我慢しとけ。

std::string foo = "hogehoge" "fugafuga";

618 :デフォルトの名無しさん:2007/02/21(水) 09:01:40
それ違うw

619 :デフォルトの名無しさん:2007/02/21(水) 09:07:05
相互排他ロック期間が短いなら、JVMはそれを認識して
待ちのスレッドをスピンロックに変えるらしい

C++でのプロファイル後オプチマイズもJITはやってくれるだろうし
複雑なプログラムではJAVAが速いのは自明な気がする

620 :デフォルトの名無しさん:2007/02/21(水) 10:30:02
まだ,この糞スレやってるの?

プロなら好みで言語は選べないし,
趣味でやるなら好きな方でやればいいじやない

621 :デフォルトの名無しさん:2007/02/21(水) 11:17:49
>>614
> >>602
> 最近はかってに入るのか。。
> >>604
> JITコンパイラの利点は無くなっちゃうのかな。

ならねえところ無くならねえ。
分散ではいちいち手動再婚パイルなんてかったるいから。


622 :デフォルトの名無しさん:2007/02/21(水) 11:20:58
>>615
Javaにはそんなイニシャライザはない。
「Java スタティックイニシャライザ」
「Java インスタンスイニシャライザ」でググってみ


623 :デフォルトの名無しさん:2007/02/21(水) 11:29:04
>>622
だよね。ありがと。
>>611のやつは、組み込みの配列型だけではなくて一般のクラスでも、
std::vector<int> v = { 1, 2, 3 };
と書けるようにすることが目的だったはず。

624 :デフォルトの名無しさん:2007/02/21(水) 11:45:07
>>605
『アジャイルソフトウェア開発』はただの迷信だよ
http://www.aoky.net/articles/steve_yegge/good_agile_bad_agile.htm
http://www.aoky.net/articles/steve_yegge/egomania_itself.htm

625 :デフォルトの名無しさん:2007/02/21(水) 12:21:52
>>624
お前迷信というまえにこの本をちゃんと読んだのか?
>>605が言ってるのはこの書籍のことだぞ
アジャイルソフトウェア開発の奥義 (単行本)
ロバート・C・マーチン (著), 瀬谷 啓介 (翻訳)
http://www.amazon.co.jp/
%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD
%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7
%99%BA%E3%81%AE%E5%A5%A5%E7%BE%A9-%E3%83%AD%E3%83%90%E3
%83%BC%E3%83%88%E3%83%BBC%E3%83%BB%E3%83%9E%E3%83%BC%E3
%83%81%E3%83%B3/dp/4797323361

626 :デフォルトの名無しさん:2007/02/21(水) 13:07:34
>>608
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2142.html

627 :デフォルトの名無しさん:2007/02/21(水) 13:12:14
>>625
示したURLの記事をちゃんと読めば、迷信をどういう意味で使っているか
分かるはずだし、この意味での迷信であれば、本を取り上げることは全くの
反論になってないことも分かるはず。

628 :デフォルトの名無しさん:2007/02/21(水) 13:42:59
スレ伸びてるけど今日はあんまり病的な人はいませんねー

629 :↓こいつ病気です:2007/02/21(水) 13:49:25
628 名前:デフォルトの名無しさん 投稿日:2007/02/21(水) 13:42:59
スレ伸びてるけど今日はあんまり病的な人はいませんねー


630 :デフォルトの名無しさん:2007/02/21(水) 13:56:27
warota

631 :デフォルトの名無しさん:2007/02/21(水) 13:58:03
このスレって結局自分が一番使える言語マンセーのカスしかいないなぁ。
しょんぼりだわ。

632 :デフォルトの名無しさん:2007/02/21(水) 14:21:34
ほんと、スレタイの勢いはどこへ行ったのやら。


633 :デフォルトの名無しさん:2007/02/21(水) 14:28:28
>>631
だよなー、たまに沸いてくるへんなやつが、知りもしないのにたたいてるのみると
なんか得体の知れないものを必死にたたく○○厨みたいで笑えるけど。

634 :デフォルトの名無しさん:2007/02/21(水) 14:49:21
>>>600
>> >>598みたいなしくみ必要ないんじゃない?
>> C++よりパフォーマンス悪くして何を目指してるんだろう。
>> 一番アフォくさいのはGCや生配列扱うときのの添え字チェックだよ
>そう思うなら、超巨大な配列を作ればいい。
パンが無いならケーキみたいで笑えるw

635 :デフォルトの名無しさん: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");
}
}
}

636 :デフォルトの名無しさん:2007/02/21(水) 17:17:34
> javac Test0003.java

> java Test0003
test01 0
test01 1
test01 2
test01 3
test01 4
test01 5
test01 exception
test01 6
test01 7
test01 8
test01 9
test02 0
test02 1
test02 2
test02 3
test02 4
test02 5
test02 exception

637 :デフォルトの名無しさん: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)

でやってるワケだが、あの2つのどこが同じなんだ…?

638 :デフォルトの名無しさん:2007/02/21(水) 18:46:05
最適化君の降臨にwktk

639 :デフォルトの名無しさん:2007/02/21(水) 21:48:47
JavaだけやるとC++は有害に感じる 

640 :デフォルトの名無しさん:2007/02/21(水) 23:35:05
>>637
あの2つってどの2つ?

641 :デフォルトの名無しさん:2007/02/22(木) 00:12:09
>>634
意味がわからないので解説よろ

642 :デフォルトの名無しさん:2007/02/22(木) 00:18:47
>>635-637
何が言いたいのかわからんのだねど。
速度の話をするなら、ちゃんと時間を計算しようね。


643 :デフォルトの名無しさん:2007/02/22(木) 00:28:43
違う処理で時間を比較することに意味があるのだろうか。

644 :デフォルトの名無しさん:2007/02/22(木) 00:45:04
>>640
>>256のことだと思われ

645 :デフォルトの名無しさん:2007/02/22(木) 01:27:41
>>642
俺は635じゃないけど、当然 test02 のほうが速いだろ。

646 :デフォルトの名無しさん:2007/02/22(木) 01:43:19
>>644
なるほど。これは香ばしいな。

>>645
速いとか、遅いとかじゃなくて、test01とtest02は、異なる処理なので、
mpegエンコードは、レイトレーシングより速いってぐらい意味のない比較だと思う。

647 :645:2007/02/22(木) 01:53:30
>>646
そうなんだけど、>>256 以降のやりとりをみればわかるが、
それが理解できないやつがいるので、そいつを釣り上げてみるかなって思っただけ。
test02 のほうが速いと書けば食いつきそうなので。

648 :デフォルトの名無しさん:2007/02/22(木) 02:07:25
オートマ車でいえば
オーバードライブオフ、スポーツモードみたいなモンジャマイカ?

649 :デフォルトの名無しさん:2007/02/22(木) 02:12:01
>>646
> >>644
> なるほど。これは香ばしいな。

香ばしいと思う前に、>>338のPDFをよく読んでみろ。
速度に若干は差がでるもの、ほぼ変わらないと言う意味だ。

  前者±ε = 後者
  |前者 - 後者| << ε
  (ε >> 0 (限りなく0に近いという意味))

こういうことだ。

338 名前:デフォルトの名無しさん[sage] 投稿日:2007/02/16(金) 01:12:41
>>335

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




650 :デフォルトの名無しさん:2007/02/22(木) 02:12:35
>>647
>>649を読め

651 :デフォルトの名無しさん:2007/02/22(木) 02:21:22
          ____   
       / \  /\ キリッ
.     / (ー)  (ー)\      
    /   ⌒(__人__)⌒ \    <速度に若干は差がでるもの、
    |      |r┬-|    |       ほぼ変わらないと言う意味だ。
     \     `ー'´   /
    ノ            \
  /´               ヽ              
 |    l              \
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、.    
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

          ____
        /_ノ  ヽ、_\
 ミ ミ ミ  o゚((●)) ((●))゚o      ミ ミ ミ
/⌒)⌒)⌒. ::::::⌒(__人__)⌒:::\   /⌒)⌒)⌒)
| / / /     |r┬-|    | (⌒)/ / / //  < だっておwwwwwwwwwwwwww
| :::::::::::(⌒)    | |  |   /  ゝ  :::::::::::/
|     ノ     | |  |   \  /  )  /
ヽ    /     `ー'´      ヽ /    /     バ
 |    |   l||l 从人 l||l      l||l 从人 l||l  バ   ン
 ヽ    -一''''''"~~``'ー--、   -一'''''''ー-、    ン
  ヽ ____(⌒)(⌒)⌒) )  (⌒_(⌒)⌒)⌒))

652 :デフォルトの名無しさん:2007/02/22(木) 02:30:52
よく知らないんだけど、Javaの最適化ってのは
ループの構造まで(人間が望むように)変えてくれるものなんすか?
コンパイラの中の人も大変だ。

653 :デフォルトの名無しさん:2007/02/22(木) 02:55:13
デストラクタあるからfinallyイラネ

654 :デフォルトの名無しさん:2007/02/22(木) 05:52:13
クラスの設計がクソ

655 :デフォルトの名無しさん:2007/02/22(木) 09:52:13
>>649 は梅宮タツオ級の釣り師と見た。だが、仕掛けが露骨過ぎる。

656 :デフォルトの名無しさん:2007/02/22(木) 10:05:49
>>653
釣りですか?
それとも馬鹿ですか? 

657 :デフォルトの名無しさん:2007/02/22(木) 10:06:20
>>651は真性の馬鹿

658 :デフォルトの名無しさん:2007/02/22(木) 13:03:43
>>651も、>>649のアフォさ加減の前には霞んで見える。
コードは間違ってた、元のPDFだけ読んでください、と言えるヤツなら、
まだ救いがあるんだが。

659 :デフォルトの名無しさん:2007/02/22(木) 13:17:05
日本語読めないC++厨は
なぜここまで自演してまで必死になるのだろうか。

660 :デフォルトの名無しさん:2007/02/22(木) 13:20:43
バイトコードについて何も知らないJava厨よりまし。

661 :デフォルトの名無しさん:2007/02/22(木) 13:20:59
> Bjarne Stroustrup:
> 言語には次の2種類しか存在しないということです
> ――皆が不満を顕にするものか,あるいは,誰も使いもしないものか,です。
ttp://www.radiumsoftware.com/0702.html#070221

    /::::i::::、:::ヽ、:::::\:ヽ:\::::::ヽ:::、::ヽ::、:',
    /::i|::l::ト、ヽ::、:::ヽ:、::::::\::ヽ::::l::::ヽ::i:::i:::!
   /:/:!:::!:|::ヽ:\ヽ::::、:\::::ヽ:::ヽ!::::::i::|:::!::!
   !ハ::|::::i::l:|心、:ヽ::\:ヽ_\、\:::ヽ:::|!::|:|i
    i、:!:|:、N{、ヒjヽゝ\ヾイ ヒj >、ヽi:、|!:|:l
     ヽ:!::トヽ ̄ l! `  ` ̄´ |::l::|:|j:,!:!  駄目だこいつ……早くなんとかしないと……
      ト、::! u         j |::/lj:::!リ
        ヾ、  丶 -    u リイ:|リ                       
        リヽ ‐、ー- 、_   /イ:::i
       rー'"ト:l゙、   ̄   ./  , |::!
      / ヘ ヾ ヽ、 _,. '   / |:'

662 :デフォルトの名無しさん:2007/02/22(木) 13:34:48
ではJavaは誰も不満を抱かない言語なのか

663 :デフォルトの名無しさん:2007/02/22(木) 13:41:02
>>662の脳内では『皆が不満を顕にするもの』の反対語は『誰も不満を抱かないもの』らしい

664 :デフォルトの名無しさん:2007/02/22(木) 14:01:05
>>659
わかりやすい日本語で >>256 をJavaで最適化するとどうなるか教えてください ><

665 :デフォルトの名無しさん:2007/02/22(木) 14:11:21
Javaは悪くないけどさ、別にC++でも良いじゃん?
これじゃなきゃダメ!なんて限定する必要もなし。
使えるものをどんどん吸収すべし!

666 :デフォルトの名無しさん:2007/02/22(木) 14:23:37
>>664
双方のコードの速度差がゼロに近似する


667 :デフォルトの名無しさん:2007/02/22(木) 14:42:13
>>661
> Technology Review 誌による Stroustrup へのインタビュー記事。
> 現代のソフトウェアが抱える諸問題についての話題を軸としながら,
> 氏のプログラミングに対する科学的あるいは工学的な視点をうかがう。
> C++ の設計に関して悔やむところなど何も無いと述べる氏の語り口は非常に明朗としていていっそ清々しい。

↑まさにC++信者を庇うためにわざとストラウストラップが言った言葉。
それに「非常に明朗としていていっそ清々しい。」とまでいうのはC++信者。


668 :デフォルトの名無しさん:2007/02/22(木) 14:42:32
>>660
C++厨もバイトコード知らないよ

669 :デフォルトの名無しさん:2007/02/22(木) 14:44:06
例外さえ起こらなければチェック回数は同じだし
起こってしまえば処理の流れが違うんだから比べる意味がわからない。

670 :デフォルトの名無しさん:2007/02/22(木) 14:51:26
バイトコードと聞くとQuickBASICしか思い浮かばんなぁ。
Javaはあれと同じレベルなのか。

671 :デフォルトの名無しさん:2007/02/22(木) 14:51:43
ttp://ja.wikipedia.org/wiki/%E3%83%90%E3%82%A4%E3%83%88%E3%82%B3%E3%83%BC%E3%83%89
ttp://d.hatena.ne.jp/keyword/%A5%D0%A5%A4%A5%C8%A5%B3%A1%BC%A5%C9

672 :デフォルトの名無しさん:2007/02/22(木) 14:59:42
>>670
Emacs-Lisp もある。

673 :デフォルトの名無しさん:2007/02/22(木) 15:00:49
>>668
何で知る必要があるの?
C++の処理系でバイトコードをはくやつなんてあった?

674 :デフォルトの名無しさん:2007/02/22(木) 15:02:18
>>666
変な日本語

675 :デフォルトの名無しさん:2007/02/22(木) 15:09:34
「近似する」って他動詞だよなぁ

676 :デフォルトの名無しさん:2007/02/22(木) 15:09:45
>>673
Visual C++のManeged C++とC++/CLIは.NETのCILを吐くぞ。

677 :デフォルトの名無しさん:2007/02/22(木) 15:10:26
Javaはいい加減typedefとgotoを導入汁

678 :デフォルトの名無しさん:2007/02/22(木) 15:14:08
>>675
漸近するの間違いじゃね?

679 :デフォルトの名無しさん:2007/02/22(木) 15:21:51
>>676
Managed C++とかC++/CLIって、
正直なところ、C++に入れてもらえてないんじゃない?
しかも、C++/CLIでは、C++のテンプレート用の実行時コード生成もあるから、
Javaのバイトコードと比較するのもアレな感じだし。

680 :デフォルトの名無しさん:2007/02/22(木) 15:23:55
>>677
ラベル付きbreakが進化したgotoだろ
typedefは・・・・・・えーと、現代的なIDEを使って自動入力してください。

681 :デフォルトの名無しさん:2007/02/22(木) 15:25:34
>>677
try-catchがgoto替わり

682 :デフォルトの名無しさん:2007/02/22(木) 15:27:01
>>675
日本語では他動詞と自動詞の区別なんて曖昧だけど

683 :デフォルトの名無しさん:2007/02/22(木) 15:29:13
>>669
だからVMの種類やバージョンを変えてみそ
って話。
古いJVMであのプログラムを動かすとtryの中にforのほうが
明らかに早いことがわかる。
しかし新しいJVMだとforに中にtryを置こうと大差なくなってきている。

とくに-serverオプションを付けるとその様子が顕著に表れてくる。



684 :デフォルトの名無しさん:2007/02/22(木) 15:29:35
>>677
クラスやインタフェースがtypedef替わりになる。

685 :デフォルトの名無しさん:2007/02/22(木) 15:36:16
>>684
それは、
http://www-06.ibm.com/jp/developerworks/java/060310/j_j-jtp02216.shtml
に書かれているアンチパターンのこと?

686 :デフォルトの名無しさん:2007/02/22(木) 15:41:14
>>677の不満
 class とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名
これをtypedefで
 typedef ShortClass とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名;
のようににJavaではtypedefを使うことができない。

そこでこういうとんでもないネーミングをしている奴のコードを
弄る羽目になったときのJavaでの解決方法:

■解決方法その1 - 継承
class ShortClass extends とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名 { }
■解決方法その2 - 委譲(static)
final class ShortClass {
 private ShortClass{}
 private static とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名 a(){
  return とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名
 }
}
■解決方法その3 - 委譲(インスタンス)
final class ShortClass {
 private とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名 a:
 public ShortClass(とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名 a){
  this.a = a;
 }
  public 型 a(){
  this.とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名.その長いクラスのメソッド名()
}
}
■解決方法その4 - static import
import static パッケージ名.とにかくロングロングなとにかくどうしようもなくウルトラスーパー長〜いクラス名.staticメソッドorフィールド名

これで>>677の不満も解消されるであろう。

687 :デフォルトの名無しさん:2007/02/22(木) 15:41:56
>>685
>>677がそれで自業自得に陥るならそれでも構わんだろう

688 :デフォルトの名無しさん:2007/02/22(木) 16:02:37
>>686
1: >>685 に書いてある通り、使えない。
2: そもそもコード間違ってない?
3: メソッドを全部記述するなんて面倒なこといちいちできるわけがない。
  あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
4: staticのみ? 論外。

そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。

689 :デフォルトの名無しさん:2007/02/22(木) 18:18:59
>>683
君は現実の世界でもそういうかみ合わない会話をしているのかね?

690 :デフォルトの名無しさん:2007/02/22(木) 18:47:08
>>688
> 2: そもそもコード間違ってない?
メソッドをpubilcに
する

> 3: メソッドを全部記述するなんて面倒なこといちいちできるわけがない。

だいたクラスなんて大した数のメソッド持ってないだろ。
そんなことで面倒くさがるなら、自動化ツールで自動生成すればいい。
Jakarta Velocityでテンプレート作れ。

そもそも、一つのクラスにメソッド100近く作る奴はDQN。
Javaでは一つのクラスに付きメソッド255個までしかつくることができないようになっているが。
クラスが1000行超えたら分割しないといけない。
ついでにメソッドも40行超えたら分割しろ。


>   あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。

『鉄則:分割し、統治せよ。』


さらについかしてみよう。
■その5
同じプロジェクト内ならリファクタリング(名前変更)で解決。

■その6
クラス名の一部をパッケージ名に変更してクラス名を短縮。
■その7


691 :デフォルトの名無しさん:2007/02/22(木) 18:50:06
>>688
> >>686
> 4: staticのみ? 論外。
> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。


仮に、こんな長ったらしい型があったとしよう。

Map<List<List<Set<Map<List>>>>>


ここで、頻繁に変更するヶ所が一番最深部のListだけであるなら、
ラッパーでまとめるという手も考えるべきだ。

こんなクラスにまとめてしまえ
Wrapper<List>


692 :デフォルトの名無しさん:2007/02/22(木) 19:46:32
>>690
>だいたクラスなんて大した数のメソッド持ってないだろ。
>そんなことで面倒くさがるなら、自動化ツールで自動生成すればいい。

Javaはtypedef一つするにしてもそんな面倒なことやらなきゃいけないんですね。

>>   あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
>> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。
>『鉄則:分割し、統治せよ。』

受け答えが成立していません。誤魔化さずに真面目に答えてください。

693 :デフォルトの名無しさん:2007/02/22(木) 19:51:52
>690
>■その5
>同じプロジェクト内ならリファクタリング(名前変更)で解決。
>
>■その6
>クラス名の一部をパッケージ名に変更してクラス名を短縮。

Genericsで型名が長くなる場合にはどうしようもないよね

694 :デフォルトの名無しさん:2007/02/22(木) 20:09:07
っていうか、クラスって Class 型の変数に代入出来ないの?
もしくはそれに近い方法で使えない?
そしたら短い名前で参照できるのでわ

695 :デフォルトの名無しさん:2007/02/22(木) 20:12:13
すべてのクラスはObjectクラスを継承してるからObject型には入るけど
名前のためだけにそういうことをするのはかなりキモい

696 :デフォルトの名無しさん:2007/02/22(木) 20:14:23
>>679
C++/CLIはISOに蹴られますた
ttp://blogs.wankuma.com/episteme/archive/2006/09/12/38394.aspx

697 :デフォルトの名無しさん:2007/02/22(木) 20:16:10
さしずめそれが妥当だろう

698 :デフォルトの名無しさん:2007/02/22(木) 20:30:22
>>692
> >>690
> >だいたクラスなんて大した数のメソッド持ってないだろ。
> >そんなことで面倒くさがるなら、自動化ツールで自動生成すればいい。
> Javaはtypedef一つするにしてもそんな面倒なことやらなきゃいけないんですね。

そもそも、typedefに拘ること自体、くだらない。
実装多重継承ができないくらいでいらいらするなんぞ恥ずかしいこと。

君が、無駄にメソッドを大量生成するというeXtreme Programmingの鉄則に
反する愚かな行いをしていることはよくわかった。

> >>   あと、元の型と別の型になってるから >>685 に書いてあるのと同じ問題が起こる。
> >> そもそも、ジェネリクスで長い型ができるたびにこんな面倒なことをやりたかないよ。
> >『鉄則:分割し、統治せよ。』
> 受け答えが成立していません。誤魔化さずに真面目に答えてください。

やはり、お前は人の話を聞かず、
オブジェクト指向を否定し、「アジャイルソフトウェア開発」までをも否定するというのか。

君は本当にそんなにGenericsのGenericsになってる「長い型」が本当に必要なのか
今一度、考え直すべきだ。

君の性格のことだから、配列でも同じようなことをやっているのだろう。
君はおそらく、多次元配列を作って混乱しているのだろう。
それに有用性があるというならわかる。
そうでもないにもかかわらず多次元配列に拘っているようだったら、考え直せ。

だからこそ、分割し、統治せよ、と説いているのだ。君は「解放・閉鎖原則」についてもっとよく勉強すべきだ。
君は、KISSについても勉強すべきだろう。


699 :デフォルトの名無しさん:2007/02/22(木) 20:32:13
君は、この原則を守れるか?

5つのクラス設計原則(There are five principles of class design)
The SingleResponsibilityPrinciple(SRP)
責務単一原則
The OpenClosedPrinciple(OCP)
開放閉鎖原則

A module should be open for extension but closed for modification.

モジュールは拡張に対して開いており、変更に対しては閉じている必要がある。
The LiskovSubstitutionPrinciple(LSP)
Liskovの置換原則

Subclasses should be substitutable for their base classes.

サブクラスは基本クラスと置換可能でなければならない。
The DependencyInversionPrinciple(DIP)
依存性逆転原則

Depend upon Abstractions. Do not depend upon concretions.

依存は抽象的にする。実装に対して依存させてはならない。
The InterfaceSegregationPrinciple(ISP)
インタフェース分離原則

Many client specific interfaces are better than one general purpose interface

汎用的なひとつのインタフェースよりも、多くの特化したインタフェースを利用する。

700 :デフォルトの名無しさん:2007/02/22(木) 20:33:16
3つのパッケージ凝集原則(There are three principles of package cohesion)
The ReuseReleaseEquivalencePrinciple(REP)
再利用開放等価原則

The granule of reuse is the granule of release.

再利用できる最小単位はリリースできる最小単位。
The CommonClosurePrinciple(CCP)
共通閉鎖原則

Classes that change together, belong together.

あるクラスの変更により、同時に変更されるクラス。
The CommonReusePrinciple(CRP)
共通再利用原則

Classes that aren't reused together should not be grouped together.

再利用できるのはクラスではなく一連のグループ。

701 :デフォルトの名無しさん:2007/02/22(木) 20:33:33
3つのパッケージ結合原則(There are three principles of package coupling)
The AcyclicDependenciesPrinciple(ADP)
非環式依存原則

The dependencies between packages must not form cycles.

The StableDependenciesPrinciple(SDP)
安定依存原則

Depend in the direction of stability.

The StableAbstractionsPrinciple(SAP)
安定抽象概念原則

Stable packages should be abstract packages.



702 :デフォルトの名無しさん:2007/02/22(木) 20:33:48
この原則を守ることができなければ
C++ができるとは言わせないぞ!

703 :デフォルトの名無しさん:2007/02/22(木) 20:35:26
この原則に則していない言語はオブジェクト指向言語ではない。

ゆえに、JavaScriptは厳密にはオブジェクト指向言語ではない。
ゆえに、Perlは厳密にはオブジェクト指向言語ではない。
ゆえに、PHPは厳密にはオブジェクト指向言語ではない。
ゆえに、VBは厳密にはオブジェクト指向言語ではない。
ゆえに、Perlは厳密にはオブジェクト指向言語ではない。



704 :デフォルトの名無しさん:2007/02/22(木) 20:35:41
ゆえに、Rubyは厳密にはオブジェクト指向言語ではない。


705 :デフォルトの名無しさん:2007/02/22(木) 20:39:36
Javaを批判するC++厨にはこの悪臭のニオイがプンプンとする






 以下にロバート・C・マーチンによる書籍『アジャイルソフトウェア開発の奥義』に記載されている
7つの「設計の悪臭」を紹介する。これらのうち、どれか1つでもその傾向が感じられたなら、すで
にわなに陥っていると考えてもよいだろう。

兆候 説明
1. 硬さ 変更しにくいシステム。1つの変更によってシステムのほかの部分に影響が及び、
               多くの変更を余儀なくさせるようなソフトウェア

2. もろさ 1つの変更によって、その変更とは概念的に関連のない個所まで壊れてしまうようなソフトウェア

3. 移植性のなさ ほかのシステムでも再利用できる部分をモジュールとして切り離すことが困難なソフトウェア

4. 扱いにくさ 正しいことをするよりも、誤ったことをする方が安易なソフトウェア

5. 不必要な複雑さ 本質的な意味を持たない構造を内包しているようなソフトウェア

6. 不必要な繰り返し 同じような構造を繰り返し含み、抽象化してまとめられる部分がまとまっていないソフトウェア

7. 不透明さ 読みにくく、分かりにくい。その意図がうまく伝わってこないソフトウェア
 ロバート・C・マーチンによる7つの設計の悪臭


706 :デフォルトの名無しさん:2007/02/22(木) 20:39:41

Javaを批判するC++厨にはこの悪臭のニオイがプンプンとする






 以下にロバート・C・マーチンによる書籍『アジャイルソフトウェア開発の奥義』に記載されている
7つの「設計の悪臭」を紹介する。これらのうち、どれか1つでもその傾向が感じられたなら、すで
にわなに陥っていると考えてもよいだろう。

兆候 説明
1. 硬さ 変更しにくいシステム。1つの変更によってシステムのほかの部分に影響が及び、
               多くの変更を余儀なくさせるようなソフトウェア

2. もろさ 1つの変更によって、その変更とは概念的に関連のない個所まで壊れてしまうようなソフトウェア

3. 移植性のなさ ほかのシステムでも再利用できる部分をモジュールとして切り離すことが困難なソフトウェア

4. 扱いにくさ 正しいことをするよりも、誤ったことをする方が安易なソフトウェア

5. 不必要な複雑さ 本質的な意味を持たない構造を内包しているようなソフトウェア

6. 不必要な繰り返し 同じような構造を繰り返し含み、抽象化してまとめられる部分がまとまっていないソフトウェア

7. 不透明さ 読みにくく、分かりにくい。その意図がうまく伝わってこないソフトウェア
 ロバート・C・マーチンによる7つの設計の悪臭

707 :デフォルトの名無しさん:2007/02/22(木) 20:40:44
 以下に、『アジャイルソフトウェア開発の奥義』に記載されている、クラスに関する5つの設計原則を紹介する。

原則名 説明
1. 単一責任の原則(SRP:Single Responsibility Principle)
クラスを変更する理由は1つ以上存在してはならない

2. オープン・クローズドの原則(OCP:Open-Closed Principle)
ソフトウェアの構成要素(クラス、モジュール、関数など)は拡張に対して開いていなけれ
ばならず(オープン:Open)、修正に対しては閉じていなければならない(クローズド:Closed)

3. リスコフの置換原則(LSP:Liskov Substituion Principle)
派生型はその基本型と置換可能でなければならない

4. 依存関係逆転の原則(DIP:Dependency Inversion Principle)
a. 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュー
ルも「抽象」に依存すべきである
b. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである

5. インターフェイス分離の原則(ISP:Interface Segregation Principle)
クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない

708 :デフォルトの名無しさん:2007/02/22(木) 20:42:36
1. 単一責任の原則(SRP:Single Responsibility Principle)

 クラスの「役割(責任)」=「変更理由」は1つに絞るべきである。
クラスが複数の役割を持っていれば、クラスを変更する理由も複数になってしまう。
また複数の役割を持ったクラスの役割は互いに結合してしまい、片方を変更すれ
ばその変更の影響が他方にも影響してしまう。つまり、複数の理由から1つのクラ
スを変更することがないようにすべきである。


2. オープン・クローズドの原則(OCP:Open-Closed Principle)

 モジュールの振る舞いが拡張可能であれば、「拡張に対して開かれている」といえる。
また、モジュールの振る舞いを変更しても、既存のソース・コードやバイナリ・コードが影
響を受けることがなければ、「修正に対して閉じている」といえる。矛盾しているように思え
るこの2つの属性は「抽象」と「ポリモーフィズム」で実現できる。抽象クラスやインターフ
ェイスを定義して、その派生クラスを新たに追加すれば、既存のコードを修正することな
くモジュールの振る舞いを拡張できる。



709 :デフォルトの名無しさん:2007/02/22(木) 20:42:45


3. リスコフの置換原則(LSP:Liskov Substituion Principle)

 クライアントが使用している基本クラス型を派生クラス型に置き換えても正常に動作しなくては
ならない。そのためには派生クラスは基本クラスの振る舞いの妥当性を維持する必要がある。
基本クラス以下の機能しか持たない派生クラスは、基本クラスと置き換えることはできない。

 バートランド・メイヤーによって提唱された「契約による設計(DBC:Design By Contract)」を使用
すれば、この原則を適用できるようになる。「契約による設計」では、クラスの振る舞いを、クラスが
持つ各メソッドの事前条件と事後条件、クラスの不変条件によって明文化する。

 .NETにおいて契約による設計を行うには、Debugクラス(System.Diagnostics名前空間)のAssert
メソッドを使用してアサーションを行い、契約に対する違反を検出する方法がある。またもう1つの
方法としてユニットテストがある。ユニットテストはクラスの振る舞いに関する契約を記述し、チェッ
クするための有効な手段である。


710 :デフォルトの名無しさん:2007/02/22(木) 20:43:01

4. 依存関係逆転の原則(DIP:Dependency Inversion Principle)


 従来の手続き型プログラミングでは、上位レベルの方針が下位レベルの実装に依存してしまう。
これでは、実装の詳細を担当する下位モジュールの変更が上位モジュールにまで及び、その変
更を余儀なくされてしまう。オブジェクト指向プログラミングでは、「抽象」を導入することでその依
存性を逆転させる。つまり上位レベルで「抽象インターフェイス」を定義し、下位レベルでこの「抽象
インターフェイス」を実装する。このようにして方針と実装の詳細をともに「抽象インターフェイス」に
依存させるのだ。

 上位レベルのモジュールをクライアントとして考えた場合に、従来の方法では、下位レベルのモジュ
ールのインターフェイスにクライアントが依存していた。つまり、本来クライアントが受けるべきサービ
スのインターフェイスの所有者は、下位レベルのモジュールであると考えられる。しかし、この原則に
従えばクライアント側でサービスのインターフェイスを宣言することになり、「インターフェイスはクライ
アントに属する」ことになる。オブジェクト指向設計では、このようにインターフェイスの所有権を逆転
させることがとても重要になってくる。





5. インターフェイス分離の原則(ISP:Interface Segregation Principle)


 クラスを利用するクライアントが複数存在するような場合に、各クライアントに共通の大きなインタ
ーフェイスを利用させてしまうと、各クライアントは利用しないメソッドにまで依存してしまう。つまり、
各クライアントが利用していないメソッドに対する変更の影響まで受けてしまう可能性があるというこ
とだ。そこで各クライアントが呼び出す必要のあるサービスの単位でクライアントをグループ分けし、
そのグループに特化したインターフェイスを準備することで、異なるサービス間での関連性を分断す
ることが可能となる。

711 :デフォルトの名無しさん:2007/02/22(木) 20:43:45
連投しすぎ……

typedef で追いつめられたから必死で流そうとしてるのか

712 :デフォルトの名無しさん:2007/02/22(木) 21:03:05
>>698
>そもそも、typedefに拘ること自体、くだらない。

これは敗北宣言(= Javaではtypedefは実現できない)とみなしてよろしいですね?
あなたが挙げた方法のいずれもtypedefの簡便さに比べると相当劣っているどころか
いちいち面倒な作業を要求されるように見えます。
KISSについてご存じなようですが、あなたのやり方はシンプルからはほど遠いものだと思います。

>君が、無駄にメソッドを大量生成するというeXtreme Programmingの鉄則に
>反する愚かな行いをしていることはよくわかった。

いわれのないレッテル貼りはやめてください。typedefと関係ありません。

>君は本当にそんなにGenericsのGenericsになってる「長い型」が本当に必要なのか
>今一度、考え直すべきだ。

Genericsという仕組みがある以上型名が長くなるのは仕方ないと思いますが
そのような型を使ってはいけないと言うのですか?
それはGenericsの柔軟性を大きく損なう行為ではないでしょうか。

713 :デフォルトの名無しさん:2007/02/22(木) 21:06:52
>>711
なぜ追いつめられたことにするのかな?
現実逃避か?

714 :デフォルトの名無しさん:2007/02/22(木) 21:07:14
>>712
> >>698
> >そもそも、typedefに拘ること自体、くだらない。
> これは敗北宣言(= Javaではtypedefは実現できない)とみなしてよろしいですね?

なにその悔しまみれな発言w


715 :デフォルトの名無しさん:2007/02/22(木) 21:07:42
いくら書いても、
C++はグローバル変数や関数使えるんだろ?
マクロで糞仕様にもできるんだろ?

c++でOOPじゃない糞コードは山ほどあるだろ。

716 :デフォルトの名無しさん:2007/02/22(木) 21:08:12
多次元配列ばかり作ってることには肯定してしまったのか。

それに、C++厨はオブジェクト指向設計の原則も守れないことを
認めてしまったか


717 :デフォルトの名無しさん:2007/02/22(木) 21:34:57
日本で銃を持つ方法を聞いて「持つ必要あるのか」と聞かれたら「ププー銃持てないんだってー」というアメリカンみたいだ

718 :デフォルトの名無しさん:2007/02/22(木) 21:35:05
ところでC++のテンプレートだと何重ものネストだって使っている気がするけど、
Javaのジェネリクスだとそう何重にもネストして使うことは少ない気がする。

最近のC++はOOPよりもジェネリックプログラミングや
テンプレートメタプログラミングに傾斜していて、
JavaはOOP一筋を貫いているという違いからだろうけど。

それとは関係ないが、>>686を見てみると、
「とんでもないネーミングをした奴のコード」と書いてあって、ジェネリクスには一言も触れていない。
つまりそう頻繁にはやらないということを前提で書いているように俺は思う。
それに対して、ジェネリクスであっという間に長い型名が出来てしまうが、その度に
そんな面倒なことはやりたくないと言ったら、話が噛み合わなくなるのは当然かなという気がする。

719 :デフォルトの名無しさん:2007/02/22(木) 21:52:45
>>716
どこに書いてあるの

720 :デフォルトの名無しさん:2007/02/22(木) 21:55:03
うーん……そういう新しいプログラミング手法を使ってるのにtypedefという
古臭い仕組みを使って表現しないといけないというのはなんとなく腑に落ちない
別の表現形式を考えたほうがいいのかもな……
そのうちジェネリックスに特化した構文が出てくると思う。

721 :デフォルトの名無しさん:2007/02/22(木) 21:55:12
そもそも、長ったらしいGenericsをそんなに使うことがあるのかっつー話をまずしなければ。

金庫には本来金しか入れないわけだが、このC++厨は金以外のものでも
くだらないものでも何でも入れたがる。
だから、どんな型のブツが入るかわからないから、パラメタライズしておきたい
って話だろう。

普通の人間なら、金しか入れないので、そこに入れるものは金だけだと
わかっているのでそのクラスをいちいちパラメタライズしない。

class Coffer {
 private Money money;
 //その他の情報
}

ところがこのC++厨は・・・・

class Coffer<List<List<T>>, List<List<貴重品>,List<List<骨董品>>> ........ > { }
などなどとなんでもかんでも詰め込みすぎる。


こういう価値観の違いがあるのではないだろうか?








722 :デフォルトの名無しさん:2007/02/22(木) 21:56:16
こんなことを擦るんだったら、
普通は、クラスを分割するものなんだけどねえ

723 :デフォルトの名無しさん:2007/02/22(木) 21:57:29
enum { 金庫, 貴重品, 骨董品}
みたなもの作ってメソッド引数に入れるってことも普通は考えるのだが。

C++厨はどこまでも拘る。

724 :デフォルトの名無しさん:2007/02/22(木) 21:58:47
連投しすぎ……

よっぽどtypedefが効いたんだな

725 :デフォルトの名無しさん:2007/02/22(木) 22:08:28
>>721
そういう例なら人間が詰め込もうと思ったからテンプレート引数が長くなっている。
JavaでだってC++でだってまともな人間はそんなコードは書かない。

C++では何気なくBoostなどのテンプレートを多用するライブラリを使うと、
使っている人間は意識していないのに、気が付けば巨大なテンプレート引数の並びが生まれる。
それが関わったコンパイルエラーに遭遇して初めてその巨大さを知らされる羽目となる。
今のC++はそこが嫌だね。0xでどうなるか見物だけど。

726 :デフォルトの名無しさん:2007/02/22(木) 22:13:50
>>724
全然反論になってないよ。
人の話を聞けないからそういうレスしかできないんだね

727 :デフォルトの名無しさん:2007/02/22(木) 22:15:43
>>725
> >>721
> そういう例なら人間が詰め込もうと思ったからテンプレート引数が長くなっている。
> JavaでだってC++でだってまともな人間はそんなコードは書かない。

このスレにいるtypedef馬鹿をいると、とてもそうとは思えないんだよな。
やけにやたらとtypedefに拘るということは、
彼はまともな人間ではないC++厨ということか。


> C++では何気なくBoostなどのテンプレートを多用するライブラリを使うと、
> 使っている人間は意識していないのに、気が付けば巨大なテンプレート引数の並びが生まれる。


それがおかしい。オブジェクト指向設計原則を守っていない証拠

728 :デフォルトの名無しさん:2007/02/22(木) 22:21:32
コピペ止めろ。自分の言葉で語れ。

729 :デフォルトの名無しさん:2007/02/22(木) 22:23:09
>>726
君が連投してないということを示すために
書き込んだレス番号のリストを教えて欲しい。

730 :デフォルトの名無しさん:2007/02/22(木) 22:32:55
>>716
>それに、C++厨はオブジェクト指向設計の原則も守れないことを
>認めてしまったか

このへんはまさにいろんな制限に縛られるのが大好きなマゾっ子Java厨の発想だな。
その時々でさまざま選択ができる自由とそれらに伴うメリットとリスクを抱えて歩むのがC++厨だ。

731 :デフォルトの名無しさん:2007/02/22(木) 22:37:09
テンプレートとオブジェクト指向をごっちゃにしてるアフォに
馬鹿だとか厨とか言われてもなあ。


732 :デフォルトの名無しさん:2007/02/22(木) 22:41:04
>>728
どこが?

733 :デフォルトの名無しさん:2007/02/22(木) 22:41:55
>>726 がんばって書いてみたよ
>>708-710 について、C++厨の俺が思うに

>1 
あの忌まわしき「多重継承」によって、C++はJavaのinterfaceの行っている
「実装とインターフェースの分離」以上の機能の分割も可能にしている。
テンプレート・メタプログラミングでよく使われる「ポリシー・クラス」がその例だ。

>2
もちろん、C++にもJavaと同じ「データ抽象」と「ポリモルフィズム」がある。
C++にはそれに加え、型自体を抽象化できる仕組みがある。
例えば、STLはコンテナ・イテレータ・アルゴリズムに抽象化した。
そして、ユーザ定義のコンテナ・イテレータ・アルゴリズムを、既存のコードの変更無く投入できるコンパイル時ポリモルフィズムがある。

>3
C++では、public継承して作成されたクラスは、その親クラスとしての振る舞いも求められる。
C++で契約による設計を行いたければ、コンストラクタでのチェックに加え、NVIパターンを使えばよい。
公開するインターフェースとカスタマイズ可能な振る舞いを分割することは、
基本クラスでの事前条件・事後条件のチェックの機会を与える。

>4
もちろん、C++の持つ「データ抽象+仮想関数による振る舞いの変更」は、Javaと同等。
さらに、上記3でも指摘したように、NVIパターンを使えば基本クラスから派生クラスへと
カスタマイズできる振る舞いの範囲に制約を課し、より上位レベルからの扱いが安全に行える。

>5
あの『オブジェクト指向における再利用のためのデザインパターン』がC++書かれているように、
その分離は自然に行える。

734 :デフォルトの名無しさん:2007/02/22(木) 22:42:22
>>730
おかしな奴だ。
それでマゾ?

なら、お前は道路に放り出されて
車に轢かれてもかまわないというのだな?

お前みたいに、馬鹿みたいにわざわざ、車の通りが激しい
渋滞もしていない高速道路を徒歩で横断するのがC++厨なのかw

735 :デフォルトの名無しさん:2007/02/22(木) 22:44:02
>>733
で、それらの鉄則をすべて守ることはできるのかな?

日頃から、ドライバ開発や組み込み系しかやってない
馬鹿には守ることができなさそうなことだが

736 :デフォルトの名無しさん:2007/02/22(木) 22:48:44
>>735
下を見ればどうしようもない奴がいることは十分承知。

#中身への言及じゃないことに萎えた
#そんなこと言い出したらJavaでも、なんでもかんでもpublicとかstaticにしていくバカがいるからダメだ
#・・といえてしまう orz

737 :デフォルトの名無しさん:2007/02/22(木) 22:49:24
>>734
なんか過剰反応してんなぁ。マゾっ子とは表現したけど、別にそれ自体は俺も悪いこと
だとは思わんし、C++はよくも悪くもアウトローの言語だ。

>なら、お前は道路に放り出されて

放り出されるんじゃない。自ら飛び出ることができるんだ。

>お前みたいに、馬鹿みたいにわざわざ、車の通りが激しい
>渋滞もしていない高速道路を徒歩で横断するのがC++厨なのかw

ごめん、なに言ってんのかわかんない。日本語でおk

738 :デフォルトの名無しさん:2007/02/22(木) 22:49:56
>>734-735
ねえ、どのレスを書いたか教えてよ

739 :デフォルトの名無しさん:2007/02/22(木) 22:51:37
>>727
C++だとtypedefなしにテンプレートはまともに使えない。
だからtypedefがないJavaでジェネリクスが使えると信じられない奴が出てくるのは全然不思議ではない。
そういう奴はC++のテンプレートとJavaのジェネリクスは同じようなものだと思っているからたちが悪い。
class Hoge;
typedef Foo<Hoge> FooX;
typedef Bar<FooX> BazType;
BazTypeの実態はBar<Foo<Hoge> >、これはわざとらしいけど、
実際これに近い感じでテンプレート引数は膨れていく。

> オブジェクト指向設計原則を守っていない証拠
ある意味当然だ。Boostなどはもはやオブジェクト指向プログラミングとは別次元の世界と化している。
勿論そっちにはそっちの流儀の設計原則があって
それを守っているはずだ(すまん、そこまで俺は知らない)。

740 :デフォルトの名無しさん:2007/02/22(木) 22:56:37
>>737
> 放り出されるんじゃない。自ら飛び出ることができるんだ。
みんなそういうけど、そのつもりがなくても慣れないと
気が付いたら飛び出てしまっていることがあるのもまた事実。

折角の防御機構だって入門書レベルで扱われることはまず無い。
放り出されると言われても現状では仕方が無い。

741 :デフォルトの名無しさん:2007/02/22(木) 22:58:12
>>737
>>アウトローの言語

言い得て妙の表現ですな。ほんとにその通りw
C++というのは、お行儀の良いコードを書くこともできるし、コンパイラを軽くだまくらかすこともできるし、無茶苦茶もできる。
コンパイラもそれを拒絶しない言語だもんね。
言語設計に信念のあるJavaとは本質的に違うし競合もしないのに、何で皆ムキになるのかね。
ピザとピザパンはどっちが美味いかと喧嘩してるようなもんだ。

742 :デフォルトの名無しさん:2007/02/22(木) 23:03:10
>>741
>ピザとピザパンはどっちが美味いかと喧嘩してるようなもんだ。

そりゃ絶対に譲れんな、ピザ(C++)のほうが美味しいに決まってる!

743 :デフォルトの名無しさん:2007/02/22(木) 23:07:08
>>736
だから「オブジェクト指向設計原則」を守るべきだと

744 :デフォルトの名無しさん:2007/02/22(木) 23:09:23
>>737
> >>734
> なんか過剰反応してんなぁ。マゾっ子とは表現したけど、別にそれ自体は俺も悪いこと
> だとは思わんし、C++はよくも悪くもアウトローの言語だ。
> >なら、お前は道路に放り出されて
> 放り出されるんじゃない。自ら飛び出ることができるんだ。

やってることが、北朝鮮の瀬戸際外交だな。


> >お前みたいに、馬鹿みたいにわざわざ、車の通りが激しい
> >渋滞もしていない高速道路を徒歩で横断するのがC++厨なのかw

よめねえのか。

廃墟のように車の通りが一切無いかまたは
渋滞していれば高速道路を横断しても車に轢き殺されずに済むって事だろ。


通常通りなら、時速100kmの車に轢き殺されてあの世に逝く確率の方が非常に高い。
そういうこと。


745 :デフォルトの名無しさん:2007/02/22(木) 23:09:40
Javaって、const が無いのが納得がいかない。

書き換え禁止で参照返せないじゃん。

746 :デフォルトの名無しさん:2007/02/22(木) 23:10:21
>>740
まぁ、それが怖いヤツは決められたレールの上だけ歩いてなさいってこった。
それは確かに安全なことだし悪いことじゃない。が、安全なハズのレールの
上だって事故が起きないわけじゃないってことをお忘れなく。

747 :デフォルトの名無しさん:2007/02/22(木) 23:11:23
>>742
ピザでも食ってろデブ

748 :デフォルトの名無しさん:2007/02/22(木) 23:11:37
>>745
final

749 :デフォルトの名無しさん:2007/02/22(木) 23:12:59
>>742
マルチパラダイムなC++はピザパンのほうだな。

750 :デフォルトの名無しさん:2007/02/22(木) 23:13:02
>>745
あれは本当いただけないな。Javaの安全志向の設計から外れてる。
ところでこの件に関してゴスリンは設計ミスだったと今は思ってんの?
それともそんなんJavaには要らねぇよって今も主張してんの?

751 :デフォルトの名無しさん:2007/02/22(木) 23:14:56
>>748
ちがうでしょ。
immutable

752 :デフォルトの名無しさん:2007/02/22(木) 23:18:53
>>751
それもfinalで実現できる。不変クラスでググレ



753 :デフォルトの名無しさん:2007/02/22(木) 23:26:59
Java厨は連投ばかりしていることを認めてしまったか

754 :デフォルトの名無しさん:2007/02/22(木) 23:31:34
>>753
よく聞こえませんよ?
日本語でおk


755 :デフォルトの名無しさん:2007/02/22(木) 23:32:18
そう言えばゴスリンには、ハゲみたいな愛称ってないんだっけ?

756 :デフォルトの名無しさん:2007/02/22(木) 23:33:43
ゴスりん自体が愛称じゃねえの

757 :デフォルトの名無しさん:2007/02/22(木) 23:35:16
もう一人の禿ストラウストラップなんか名前からして
ジョークみたいだけどな


758 :デフォルトの名無しさん:2007/02/22(木) 23:36:10
びぃよよょ〜ん・すとらう・struts

759 :デフォルトの名無しさん:2007/02/22(木) 23:36:32
ロシアのプチハゲと比べたらましよ


760 :デフォルトの名無しさん:2007/02/22(木) 23:36:48
>>752
だから〜、不変クラスの意味でimmutableって言ったんだけど。
finalキーワードだけでは実現できないでしょーが。

761 :デフォルトの名無しさん:2007/02/22(木) 23:37:26
>>739
どうりでC++Templateばかりやってると頭禿げるわけだ


762 :デフォルトの名無しさん:2007/02/22(木) 23:39:06
ねえ、ものすごく必死に連投してる人がいるみたいだけど、
Java好きな人ってこんなキモい人ばっかなの?
付き合いたくない……

763 :デフォルトの名無しさん:2007/02/22(木) 23:44:50
>>760
おおむね、finalキーワードを中心にできているようなもんだあれは。

クラスとメソッド引数をすべてfinalにして、フィールドはprivate finalにして
setterメソッドを作らず、コンストラクタとgetterメソッドを使うときは
すべてclone()でコピーしてから代入する。

配列やコレクションだと、それらの要素にまで影響が及ばないように
ちょっと面倒くさいことをするが、Collectionsクラスを使えばどうってことでもない。




764 :デフォルトの名無しさん:2007/02/22(木) 23:45:24
>>762
またそんな煽り
C++好きな人ってこういう言い訳しかできないの?
付き合いたくない・・・・


765 :デフォルトの名無しさん:2007/02/22(木) 23:45:47
>>759
プーチン大統領のことだったんだ

766 :デフォルトの名無しさん:2007/02/22(木) 23:46:04
>>755
何がいいたいの?

767 :デフォルトの名無しさん:2007/02/22(木) 23:46:29
イミュータブル
http://ja.wikipedia.org/wiki/%E3%82%A4%E3%83%9F%E3%83%A5%E3%83%BC%E3%82%BF%E3%83%96%E3%83%AB

ここにJavaのサンプル発見

768 :デフォルトの名無しさん:2007/02/22(木) 23:48:53
特に >>699- のあたりがキモい
全然関係ない話を延々コピペしてるし


769 :デフォルトの名無しさん:2007/02/22(木) 23:53:03
>>768
設計原則を守れないとは、さすがアウトローC++厨w

770 :デフォルトの名無しさん:2007/02/22(木) 23:54:53
オブジェクト指向設計原則を守れないC++厨は
人工衛星破壊実験でスペースでブリをばらまいて
宇宙環境を破壊して国際社会に迷惑をかける中国共産党みたいだw

さしずめ、Chinese++といったところかwwwww



771 :デフォルトの名無しさん:2007/02/22(木) 23:56:30
>>763
それを>>742みたいに一言「final」なんていった日にゃ、
C++のconstのつもりでfinalを使ってはまる人続出だぞ。
誰向けの回答だよ。


772 :デフォルトの名無しさん:2007/02/22(木) 23:56:34
そういう意味ではリトビネンコを放射性物質で殺したプチハゲにも似てる。

かれはサングラスをかけるとエージェントスミスになるクラッカーだからw

C++のほうがウィルスやスパイウェアを作りやすいから、いかにも
プチハゲ(エージェントスミス)って漢字だw


773 :デフォルトの名無しさん:2007/02/22(木) 23:59:03
>>771
多くのJavaプログラマはconstもfinalもただの定数程度にしか思ってないだろう。
ちょっと慣れてくると、finalは一回しか代入できない定数や継承を禁ずるために
あると考えるようになる。確かに、不変クラスのことを知らない奴はマダ多いな。
配列をfinalにしても配列の要素まではfinalにならない、clone()しなければ不変にならない
ってことを知らない奴もまだいるねえ。JavaのオブジェクトがC++のポインタと同じように
作用することもしらず、「浅いクローニング」「深いクローニング」の意味を知らない奴はまだまだいるねえ


774 :デフォルトの名無しさん:2007/02/23(金) 00:01:11
不変クラスも知らないようなのがプログラマやってんのか。
世も末だな。

775 :デフォルトの名無しさん:2007/02/23(金) 00:05:40
そりゃ、最近、学生が多いから

776 :デフォルトの名無しさん:2007/02/23(金) 00:06:04
>>767
final class ImmutableCart<T> {
 private final List<T> items;
 
 public ImmutableCart(final List<T> items) {
  //防御的コピーを行った後、リストの要素の実行時タイプチェックを行い、
  //リストの要素をfinalにする。
  this.items = Collections.unmodifiableList(
          Collections.checkedList(
           (List<T>) items.clone(), T.class
          )
         );
 }
 
 public List<T> getItems() {
  return (List<T>) items.clone(); //内部フィールドの防御的コピー
 }
 public int total() { /* return sum of the prices */ }
}

配列を使うと確かに複雑だ。

777 :デフォルトの名無しさん:2007/02/23(金) 00:07:40
オブジェクト指向もわからないC言語厨/C++厨には

Javaの static importは使わせたくないな。

やつら、やたらとstaticが好きで過剰に使いすぎるから


778 :デフォルトの名無しさん:2007/02/23(金) 00:08:29
そんなにオブジェクト指向設計って偉かったのか・・
それしか言えなくなって、だんだん>>770 >>772 >>777みたいになっていくのが哀れ。


779 :デフォルトの名無しさん:2007/02/23(金) 00:08:30
イミュータブル・クラスの意味はわかったが、C++のconst type &とは根本的に違うよな。
クラスがイミュータブル・クラスでなければ、書き換え禁止で参照渡しすることはできないんだよね。

どんなクラスでも、イミュータブルにできるわけじゃないし。解決にはならない。
結局、安全面を妥協して書き換え可能な形で参照返すか、実行効率を犠牲にしてコピーを作成するしか無いんだよね。

俺は、普段はC++を使っていて、Javaを毛嫌いしているわけじゃないが、この仕様だけには納得がいかなかった。

780 :デフォルトの名無しさん:2007/02/23(金) 00:08:36
C/C++は本当にstaticが無いとやっていけないから困る

781 :デフォルトの名無しさん:2007/02/23(金) 00:09:14
>>773
その辺がわかってる人だと、何でJavaのStringは不変クラスで、
C++のstd::stringはそうじゃないのか、みたいなことも、
難なく納得してもらえるんだけどなあ。
そうじゃない人は、言語にかかわらずアレだけど。
(ついでに。ごめん、>>771の2行目の「>>742」は「>>748」の間違い。)



782 :デフォルトの名無しさん:2007/02/23(金) 00:13:47
>>769-770
お前らは走行中のトラックの前に飛び出すことができるなら
引かれて死ぬと解ってても思わず飛び出しちゃうのか? 
なるほど、Java厨の為にはガチガチの制限が必要なわけだ。

783 :デフォルトの名無しさん:2007/02/23(金) 00:13:48
>>778
おまえみたいに段々と身も心もstaticにしかなれない奴になるよりはましだよw

784 :デフォルトの名無しさん:2007/02/23(金) 00:16:21
>>782
お前は比喩がわかってない。

お前は、融通が効かない。C++のやりすぎだ。

C++やってるやつには、実際、そうやって死ぬ奴がおおいじゃないか。



785 :デフォルトの名無しさん:2007/02/23(金) 00:16:57
>>769
設計原則を守る人は関係ない話をコピペしてスレを流して良いのか。へえ

786 :デフォルトの名無しさん:2007/02/23(金) 00:16:59
おまえらはせいぜいアメリカ人にチャイニィーーズゥ!って罵られていればいいさ




787 :デフォルトの名無しさん:2007/02/23(金) 00:17:22
>>785
設計原則を守りたくないからそういう言い訳しかできないわけか


788 :デフォルトの名無しさん:2007/02/23(金) 00:17:37
>>783
そんなこと言うわりにC++のSTLはオブジェクト指向的じゃない、なんていうじゃん。
「コンテナ」というオブジェクトに、「アルゴリズム」という形でメッセージを送るんだろ。
俺にはオブジェクト指向的に思えるんですが。

ああ、Javaには動的多態しかないからしょうがないか。継承しないと多態できないと信じてるし。

789 :デフォルトの名無しさん:2007/02/23(金) 00:17:38
>>783
誰が巧いこと言えといった

790 :デフォルトの名無しさん:2007/02/23(金) 00:18:05
>>787
で、スレを流したことはどうなのさ

791 :デフォルトの名無しさん:2007/02/23(金) 00:18:23
>どんなクラスでも、イミュータブルにできるわけじゃないし。解決にはならない。

Proxyかぶせればどんなインスタンスもイミュータブルに出来るよ。
やらんけど

792 :デフォルトの名無しさん:2007/02/23(金) 00:18:32
>>779
達人プログラマの世界にようこそ。

793 :デフォルトの名無しさん:2007/02/23(金) 00:19:09
>>781
> >>773
> その辺がわかってる人だと、何でJavaのStringは不変クラスで、
> C++のstd::stringはそうじゃないのか、みたいなことも、
> 難なく納得してもらえるんだけどなあ。

だから、JavaにはmutableなStringBuffer, StringBuilderがあるわけだが。
+, +=演算子で文字列連結を使えばimmutableでも構わないってのもあるが(但し、+=は問題外)

> そうじゃない人は、言語にかかわらずアレだけど。
> (ついでに。ごめん、>>771の2行目の「>>742」は「>>748」の間違い。)


794 :デフォルトの名無しさん:2007/02/23(金) 00:19:23
>>790
What?

795 :デフォルトの名無しさん:2007/02/23(金) 00:21:35
>>784
>C++やってるやつには、実際、そうやって死ぬ奴がおおいじゃないか。

そこはあえて否定しないが、GCがあるはずのJavaでメモリリーク起こしたり
ポインタがないはずのJavaでNullPointerException起こすヤツも後を絶たんだろうが。

796 :デフォルトの名無しさん:2007/02/23(金) 00:21:35
>>779
Collectionsやclone()をうまくつかえばどんなクラスでもImmutableにすることは簡単だ。
やたらとImmutableにする意味は無いが。





797 :デフォルトの名無しさん:2007/02/23(金) 00:23:49
>>795
Java人口が増えてきたからな。

ちょっと数年前ならC/C++でもポインタで躓いたやつがぞろぞろいたことだろう。
今じゃ、ぬるぽやクラスパスやらオブジェクト指向で躓く奴が多いな。

C/C++人口が減ってJava人口が増えてきたからそうなっているだけに過ぎないってことよ。

どこの大学もJavaを教えるところばかりだからな。


798 :デフォルトの名無しさん:2007/02/23(金) 00:24:34
>>783
stat・ic, stat・i・cal
()

━━ a. 静止した, 静的な; 【コンピュータ】スタティックな, 固定された状態の; 変化に乏しい, つまらない; 静体の; 静力学の; 【電気】静電[空電]の.
━━ n. (-ic) 静電, 空電(妨害); 〔米話〕 非難, 批判.


なるほど。

static大好きなC/C++厨=変化に乏しい,つまらない厨が多い

799 :デフォルトの名無しさん:2007/02/23(金) 00:25:08
そして>>736

800 :デフォルトの名無しさん:2007/02/23(金) 00:25:20
static大好き=非難大好き

Java嫌いなC/C++屋はJavaのあら探しをして非難するのが大好き


801 :デフォルトの名無しさん:2007/02/23(金) 00:25:51
>>799
おそらく、C/C++経験者がJavaをやり出した結果に・・・

802 :デフォルトの名無しさん:2007/02/23(金) 00:26:24
static static run run run

803 :デフォルトの名無しさん:2007/02/23(金) 00:27:02
>>793
Javaにこだわりを持ってるのはわかるけどね・・・

intとかの組み込み型と同じように、文字列を扱えるようにするためには、
JavaではStringを不変クラスにする必要があった、ってわけ。
さもないと、文字列を引数にしてメソッドを呼び出すと、その文字列が変わったりするから。

C++なら、メソッド(や関数)の宣言を見て、引数がconst std::string &だったら、
そのメソッドは文字列の中身を書き換えないと期待していいから、
C++のstd::stringは不変クラスにする必要はなかった。

804 :デフォルトの名無しさん:2007/02/23(金) 00:29:41
>>795
詭弁: ごく稀な反例をとりあげる。

メモリリークは本質的にムツカシイところがあるからなあ・・・・・。
でもGC付の言語とそうでないやつを比較することがおこがましい。

それから、ヌルポが起きるんだからいいんじゃないか。嫌なのはヌルポなのにそのまま動いてわけのわからん動作をしたり
脆弱性の原因になるやつな。

805 :デフォルトの名無しさん:2007/02/23(金) 00:32:30
オブジェクト指向とは階層的秩序を形成、維持するのに適した考えであるが、
C++はうまくやらないとこれを見事にぶち壊しにしてしまい、自分自身の作った迷路で数週間悩む事になる。
いや、数週間というのは大げさすぎるかもしれない。
大抵の場合、一生あっても足りないのだから。

806 :デフォルトの名無しさん:2007/02/23(金) 00:34:54
なんで"C++は"ってつくんでしょうか

807 :デフォルトの名無しさん:2007/02/23(金) 00:39:44
>>797,>>804
俺が言いたかったのはいろいろとユーザに制限を課しているわりには
リスクから守りきれてないじゃないかってこと。

808 :デフォルトの名無しさん:2007/02/23(金) 00:51:52
つか、このスレみて思うのはC++は有害とまでは思わんが、
C++厨は有害に感じるなぁ。

809 :デフォルトの名無しさん:2007/02/23(金) 00:52:36
>>807
その例だとどちらも制限からの脱却に思えるんだが。
GCがあったほうが、変な解放コードいらんし、ヌルポ吐いてしてくれたほうが、回避処理書かなくてすむ。

810 :デフォルトの名無しさん:2007/02/23(金) 00:53:54
>>808
そういうこと。GCとかOOPLのイロハも知らずにC++最強!!!とか思ってるやつが威張ってるから困る。

811 :デフォルトの名無しさん:2007/02/23(金) 00:55:42
>>809
>GCがあったほうが、変な解放コードいらんし、

そのハズなのにメモリリークするなんて、なんかおかしくね?

>ヌルポ吐いてしてくれたほうが、回避処理書かなくてすむ。

そもそもポインタがないハズなのにヌルポを気にせにゃならんて、なんかおかしくね?

812 :デフォルトの名無しさん:2007/02/23(金) 00:57:29
>>807
脆弱性の原因になる/誤動作を引き起こす→例外を吐いて終了する
絶対に開放できないメモリリーク→参照が切れていないオブジェクトを発見すれば開放できるメモリリーク

リスクもバグ特定のコストも格段に変わっていると思うけどな。

813 :デフォルトの名無しさん:2007/02/23(金) 00:58:19
>>810 逆もまた然り

814 :デフォルトの名無しさん:2007/02/23(金) 01:48:34
>>808
煽ると、髪の毛が抜けてくる香具師がいるからほどほどにしとけよw

815 :デフォルトの名無しさん:2007/02/23(金) 02:27:33
C++ いじめられっこ でも時々強いのもいる
Java いじめっこ でも根本がいつも危うい柱で成り立っているので、コツを掴めば簡単に形勢逆転

816 :デフォルトの名無しさん:2007/02/23(金) 02:31:54
Javaは強力はセキュリティ機構に守られているから
鉄壁を破るのは容易ではないぞ


817 :デフォルトの名無しさん:2007/02/23(金) 02:45:19
>>816
java信者を装ったC++工作員おつ

818 :デフォルトの名無しさん:2007/02/23(金) 02:48:13
>>811
> >>809
> >GCがあったほうが、変な解放コードいらんし、
> そのハズなのにメモリリークするなんて、なんかおかしくね?

メモリリークを起こす確率がC++とくらべうんと低いんだけど。
それだけでもアドバンテージはでかいけど。
それだけに旧来のバグが少ないソフトウェアも産みやすくなったわけだし。


> >ヌルポ吐いてしてくれたほうが、回避処理書かなくてすむ。
> そもそもポインタがないハズなのにヌルポを気にせにゃならんて、なんかおかしくね?

Javaにもポインタはあるけど

819 :デフォルトの名無しさん:2007/02/23(金) 02:50:42
>>815
マ板では「年寄り(C/C++)が若者(Java)を苛めているという構図」というスレがあったのに

今ではその形成もとっくのとうに逆転しているのかw


まるで、将来日本でも起こりそうな、年金問題や外交問題などを巡る世代間対立みたいだなw




820 :デフォルトの名無しさん:2007/02/23(金) 05:29:33
よく考えてみたらJavaはプリミティブもオブジェクトも値渡しなんだからメソッド引数はすべてfinalでよくね?

821 :デフォルトの名無しさん:2007/02/23(金) 06:01:50
誤解を招くかもしれないので、一応。
普通の値と同じように、オブジェクトへのポインタの値をコピーして渡すわけだから、
そのオブジェクトのメソッドで内部を書き換えることは出来てもオブジェクトの参照自体を変えることはできないよね。
finalは値が一回しか入らないことだけを約束するわけだけど、メソッド引数は値を書き換える意味がない以上、常にfinalでも差し支えないはず。
返り値に加えたり、別の引数オブジェクトにセットしたりすれば別だけど。というかそれの互換のためだけに何も言わないんじゃないのかと

822 :デフォルトの名無しさん:2007/02/23(金) 06:58:24
C++厨 : 言語に無駄に自信がある
Java厨 : 実行環境に無駄に自信がある

823 :デフォルトの名無しさん:2007/02/23(金) 11:23:29
>>803
>intとかの組み込み型と同じように、文字列を扱えるようにするためには、
というより、ハッシュの理由の方が大きいと思う。
ハッシュが正しく働くためには、生成から消滅まで固定のhashCodeが必要だけど、
文字列がmutableになると、実現が難しい。

824 :デフォルトの名無しさん:2007/02/23(金) 12:06:42
>>823
そうかな?HashSetやHashMapが内部でclone()を呼び出すようになってれば、
使う側はmutable/immutableを気にしなくて済んだはずだと思うけど。
この辺の設計については、安全性よりパフォーマンスを取ったんだと思う。

825 :デフォルトの名無しさん:2007/02/23(金) 16:50:30
>>820
> よく考えてみたらJavaはプリミティブもオブジェクトも値渡しなんだからメソッド引数はすべてfinalでよくね?
値渡しはプリミティブだけだが。


826 :デフォルトの名無しさん:2007/02/23(金) 16:58:05
>>821
んなことはない。finalにしないメリットは
mutableでデータを頻繁に操作できることにある

827 :デフォルトの名無しさん:2007/02/23(金) 16:59:23
>>824
clone()つかっても扱われるオブジェクトのclone()が
ちゃんと深いクローニングを実装していなければ本末転倒だし

828 :デフォルトの名無しさん:2007/02/23(金) 17:01:20
>>825
意味としては>>821ってことだろ。これを値渡しって表現するのは間違いだと思うが。
オブジェクトの参照を渡すのに、参照の値をコピーして渡してるから値渡しって言うなら、
機械語レベルではあらゆる言語が値渡しになる。
いや、レジスタで渡すんだから、純粋な参照渡しのみか?

引数全てにfinalってのは普通。finalついてなかったらwarning出すってのは、
最近だとCodeCheckとか使わなくても、コンパイラで出せるんじゃなかったっけ?

829 :デフォルトの名無しさん:2007/02/23(金) 17:04:06
>>826
仮引数にfinalつけたところで、immutableになるわけじゃない。
仮引数のfinalとその値のmutable性は別の問題。
constとは違う。

830 :デフォルトの名無しさん:2007/02/23(金) 17:26:01
>>827
あ、そういわれれば。
immutableもdeepcopyも、静的にチェックできないという点では同じか。

831 :デフォルトの名無しさん:2007/02/23(金) 17:56:41
>>828
> >>825
> 引数全てにfinalってのは普通。finalついてなかったらwarning出すってのは、
> 最近だとCodeCheckとか使わなくても、コンパイラで出せるんじゃなかったっけ?

でない。CheckStyleのみ

832 :デフォルトの名無しさん:2007/02/23(金) 17:57:23
>>829
んなことわかってる。
Wikipediaあら引用した上のサンプルコードみたいな個として初めて不変

833 :デフォルトの名無しさん:2007/02/23(金) 20:13:26
>>825
> 値渡しはプリミティブだけだが。
おいおい。Javaには参照渡しはないぞ。

834 :デフォルトの名無しさん:2007/02/23(金) 20:19:18
>>828
> これを値渡しって表現するのは間違いだと思うが。
もとっから、そーゆー定義だから仕方ない。
辞書に文句つけても仕方あるまい。

835 :デフォルトの名無しさん:2007/02/23(金) 21:00:30
つ 参照の値渡し

836 :デフォルトの名無しさん:2007/02/23(金) 21:26:39
渡し方より渡す中身でしょ?
渡してるものは結局参照なんだから参照渡しって言う方が妥当。

837 :デフォルトの名無しさん:2007/02/23(金) 22:04:43
オブジェクトは参照渡しだけど組み込み型は値渡し、
と毎回断らないといけないのが面倒だったんじゃね?


838 :デフォルトの名無しさん:2007/02/23(金) 22:30:09
Javaの視点から見るとC++は九龍城に見える


839 :デフォルトの名無しさん:2007/02/23(金) 22:30:31
汚染区域

840 :デフォルトの名無しさん:2007/02/23(金) 22:31:14
C++0x

残念なことにJavaを超える仕様ではなかった。
次は、D言語に期待せざるを得ない。


841 :デフォルトの名無しさん:2007/02/23(金) 22:33:00
>>840
kwsk

842 :デフォルトの名無しさん:2007/02/23(金) 22:36:42
> 渡してるものは結局参照なんだから参照渡しって言う方が妥当。
いや、そんなオレ用語の定義について一生懸命語られても……

843 :デフォルトの名無しさん:2007/02/23(金) 22:39:47
>>841
過去の遺産をシガラミとしてひきずっているため(ry

844 :デフォルトの名無しさん:2007/02/23(金) 22:40:14
>>843
もちょっとkwsk

845 :デフォルトの名無しさん:2007/02/23(金) 22:42:32
>>837
「参照を渡してるから参照渡しと呼ぶべき」とか言う馬鹿を相手にする方が面倒だと思う。

846 :デフォルトの名無しさん:2007/02/23(金) 23:01:01
C++にあるもの

●C言語時代の負の遺産、そして柵(シガラミ)と悪しき伝統
●年寄りのように変化を否定(XPの「変化ヲ抱擁セヨ」に反する)
●メモリリークを頻発する野蛮な配列外アクセス・オーバーフロー
●モジュール間の関係を密にしてしまうストーカーのようなグローバル変数
●神聖なるソフトウェア工学を否定するDLL HELL
●酷く薄汚いスパゲティコードを生み出すヘッダファイル
●不審で不明な使途にも利用可能な構造体、共用体、typedef
●不審で不明な使途にも利用可能なテンプレート
●素晴らしいほどに無駄に余計なvirtual修飾子
●あの忌まわしきハンガリアン記法を助長する言語仕様
●ダイヤモンドのようにブライト(bLight)に輝く実装多重継承
●しかしそのダイヤモンドには決して明るい(BRIGHT)輝きはなく
 荒廃(BLIGHT)とした破滅(BLIGHT)を持つ二つの伝統を引き継ぐ
●暗黒時代から引き継がれたstring
●失われた古代の技術Smalltalkをも否定するstaticなプログラマを量産するグローバル関数
●規格・仕様の乱立。そして10年前のプログラムもコンパイルできない(規格が乱立する)群雄割拠の世界
●さらなるデスマーチと過労死者を生み出すコードも作ることが可能な腐敗した演算子オーバーロード

847 :デフォルトの名無しさん:2007/02/23(金) 23:25:42
ダイヤモンド継承をblightなダイヤモンドに喩えるとは言い得て妙。





848 :デフォルトの名無しさん:2007/02/24(土) 02:43:23
「C++ではこれもできます」を「C++ではこれをしなくてはなりません」に
自動的に読み替える脳ってのは一体どうやって育まれるのだろう

849 :デフォルトの名無しさん:2007/02/24(土) 03:02:13
>>846
これなんかのコピペ?
自分で考えたの? アホジャネーノwww

850 :デフォルトの名無しさん:2007/02/24(土) 03:17:52
低級言語のC言語系はこれからも無くならない
どっちかと言うとCプログラマーが貴重になってくるだろう

どっちかと言うとJavaのライバルはC#だろ

851 :デフォルトの名無しさん:2007/02/24(土) 03:27:25
>>698-701, >>705-710
最適化君乙w

852 :デフォルトの名無しさん:2007/02/24(土) 03:40:35
>>850
俺はDを見守るぜ

853 :デフォルトの名無しさん:2007/02/24(土) 03:49:18
たくさんプログラムを書けば誰でもたどり着く認識を
たくさん書いてくれてご苦労さんと言いたいけど。
「それらを読んで理解しただけでは力はつかないよ」と警告しておこう。
理解ではなく認識しないとね。

これって
「まとめて、命名てあり、意思疎通の助けになる」という意味で
「レイヤーの違うデザパタ」みたいだね。

854 :デフォルトの名無しさん:2007/02/24(土) 09:11:56
>>846
テンプレートについては何も意見無しですか。

855 :デフォルトの名無しさん:2007/02/24(土) 09:15:15
>>854
>●不審で不明な使途にも利用可能なテンプレート

書いてあるよ

856 :デフォルトの名無しさん:2007/02/24(土) 10:20:24
> ■ おすすめ2ちゃんねる 開発中。。。 by FOX ★
> このスレを見ている人はこんなスレも見ています。(ver 0.20)
>
> 45歳以上の転職Part7 -25 OR 6 TO 4- [転職]
> JR東日本 社会人採用対策スレッド 2006 Part6 [転職]

(;´Д`)

857 :デフォルトの名無しさん:2007/02/24(土) 10:50:01
このスレは「C++だけ分かっている奴」と
「Javaだけ分かっている奴」から始まる一連のレスに対して、
「両方分かってる奴」が頑張って説明するスレですかね・・・。

858 :デフォルトの名無しさん:2007/02/24(土) 11:21:10
C++の初心者がはまるポイントをまとめてくれたのか。
まあ、ご苦労さん。

859 :デフォルトの名無しさん:2007/02/24(土) 13:16:17
C++プログラマにとって一番危険なのは、妄信的な自意識、自信過剰。

860 :デフォルトの名無しさん:2007/02/24(土) 13:26:45
>>849
多分、君にはそう考える能力はないと思うよ。
君の方が十分アホだからw

861 :デフォルトの名無しさん:2007/02/24(土) 13:27:20
>>850
D言語はどうしたw

862 :デフォルトの名無しさん:2007/02/24(土) 13:28:28
>>856
同じ人が見ているなw

863 :デフォルトの名無しさん:2007/02/24(土) 13:29:19
>>858
それいっちゃ、
大抵のC++プログラマ=C++初心者

ってことになっちまう

864 :デフォルトの名無しさん:2007/02/24(土) 13:29:36
>>859
まさに当てはまる。

865 :デフォルトの名無しさん:2007/02/24(土) 13:30:51
ダイヤモンド継承を黄金の輝きと
勘違いしている彼らのことだから



866 :デフォルトの名無しさん:2007/02/24(土) 13:39:42
>>863
生の配列を喜んで使ってたり、何でもかんでもvirtualつけてたり、
C言語のプログラムでもないのにハンガリアンを使ってたり、
不用意にダイアモンド継承を作ったりする人ばっかり?
デスマ確定ですね。ご愁傷様。

867 :デフォルトの名無しさん:2007/02/24(土) 14:13:46
ハンガリアンはM$が推奨していたんだけどね

868 :デフォルトの名無しさん: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

869 :デフォルトの名無しさん:2007/02/24(土) 14:40:10
n または i 接頭 integerなどの整数型 nPower
dw 接頭 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


まじでこんなことして欲しくないけどな

870 :デフォルトの名無しさん:2007/02/24(土) 14:43:05
ハンガリー記法
http://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軸、ドルと円などで、これらは単純に
型による安全性に頼ることはできない。



871 :デフォルトの名無しさん:2007/02/24(土) 14:50:57
>>869
まさにそれが、>>868 >>870に書かれてある間違ったハンガリアン記法。
誤解から生まれたシステムハンガリアン記法。

872 :デフォルトの名無しさん:2007/02/24(土) 14:54:34
C++0xでopaque typedefが導入された日には、
ドルと円の混用もコンパイラの型チェックで検査できるから、
ハンガリー記法は完全に無用の長物。

873 :デフォルトの名無しさん:2007/02/24(土) 14:55:19
dw 接頭 double word型
ていうか
word型の時点で既に嫌い。

874 :デフォルトの名無しさん:2007/02/24(土) 14:58:18
>>872
opaque typedef が次期標準に入るのは難しい情勢じゃないですかね?

875 :デフォルトの名無しさん:2007/02/24(土) 15:01:28
>>874
あら、そうなの。残念。

876 :デフォルトの名無しさん:2007/02/24(土) 15:08:42
C/C++はポインタ使うから俺pつかうよ。
でも、pBufferはやめるようにした。
pByteBuffer、pIntBufferはやったことない。
ポインタにpじゃなくてlpはねーよな。

文字列は、VCつかっていると
相手に合わせて一時的に型を変えなきゃいけないから
ゼロ終端文字列型(さらにUNICODE、SHIFT-JIS)、
BSTR、VARIANTの文字列、std::stringの区別に使ったりする。
COMやAPI呼ぶ都合で仕方ない。あーふべん。
OS提供のAPIとかが呼べるあたりCのいいところでもあるんだけどね。

STLなどテンプレートライブラリはバイナリ互換じゃないから嫌い。

877 :デフォルトの名無しさん:2007/02/24(土) 15:09:49
こっちの方が正確。日本のはアプリケーションハンガリアンの名前すら無いから。
http://en.wikipedia.org/wiki/Hungarian_notation

>>872
早く導入して欲しいね。
コンパイラのチェックは目のチェックとは比較にならないから。

878 :デフォルトの名無しさん:2007/02/24(土) 15:21:40
>>876
pBufferって、newとかmallocでやってるの?
俺は可能な限りstd::vector<unsigned char> buffer;としておいて、
&buffer[0]をpBufferのつもりで使うけど。

OSのAPIを呼び出すのは、どの言語でも面倒(か不可能)だから、
まあしゃーない、とは思うけど。

879 :878:2007/02/24(土) 15:24:44
ああ、ごめんごめん。
STLが嫌いなんだね。

880 :デフォルトの名無しさん:2007/02/24(土) 15:34:03
>>871
そう思うなら、Wikipedia更新して

881 :デフォルトの名無しさん:2007/02/24(土) 15:36:22
>>877
いずれにしてもハンガリアンは魅力的じゃないな

882 :デフォルトの名無しさん:2007/02/24(土) 15:46:30
STLが嫌いという訳じゃないけど
いままであまり使っていないし深く理解してないので
これからもあまり使わないだけ。

高速化の話とか仕事でよく出てくる。
最初に必要なメモリ確保して以降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むずかしーよ。

883 :デフォルトの名無しさん:2007/02/24(土) 15:48:51
>>832
なら、「仮引数の」finalの有無が、そのクラスのmutable性に何の関係があるのか教えてくれ。
単に、
>>821の仮引数は全部finalでいいだろ、ってのに対して、
>>826でフィールドのfinalの有無はmutable性に影響があるって、見当違いな反論しただけか?

884 :デフォルトの名無しさん:2007/02/24(土) 15:50:21
>>880
そこまで気合入ってない。
俺はよそのページのリンク貼るだけ。

>>881
dwとかlpは本来のハンガリアンじゃ無いってレスがしたかっただけ。
実は俺も使う気なかったりする。

885 :デフォルトの名無しさん:2007/02/24(土) 15:51:32
もう誤解の多いハンガリアン記法なんてやめて『意味を元に接頭辞を付ける』でいいよな。
カタカナ用語とか略語なんてやめて日本語でストレートに言っちゃいな。



886 :デフォルトの名無しさん:2007/02/24(土) 15:54:01
m_ 接頭 クラスのメンバ変数

これってメンバ変数であることが
わっかりやっすい
けど、見た目が
かっこう悪いんだこれ

887 :デフォルトの名無しさん:2007/02/24(土) 16:04:27
>>885
同意。

>>883
const&の話題は>>752が解釈を間違ってるから、そこから先は無意味と思う。

888 :デフォルトの名無しさん:2007/02/24(土) 16:08:13
>>882
必要なメモリが最初からわかってるならできるけど。
特に問題ないならstd::vectorやらstd::mapやらstd::setやら。
あと、高速化については、代入(operator=)を避けて、なるべくswapでやるとか。

DLLでstd::stringは微妙。とりあえずstd::stringにしておいて、
必要ならラッパを書くことでまけといてもらう。

std::auto_ptrは使えない。C++0xで廃止されることを願う(けど無理かも)。

889 :デフォルトの名無しさん:2007/02/24(土) 16:15:31
final
何だかカッコよさげな響き

890 :デフォルトの名無しさん:2007/02/24(土) 16:18:59
>>888
非推奨にはなるだろうが互換性のため次期標準ではまだ消えないと思う。

ところで今度提案されているmove_ptrはどう?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm


891 :デフォルトの名無しさん:2007/02/24(土) 16:26:04
Java
何だかお風呂が綺麗になりそうな響き

892 :デフォルトの名無しさん:2007/02/24(土) 16:33:56
>>888
shared_ptrとか代替が入ればもちろん不要だけど、
それが無い今は有用だと思うんだが(「標準」という強みがあるから)。

//newするかもしれないし、しないかもしれない。
//でも受け側で消せ、ということがソースから分かる。
auto_ptr<A> a = cache.get();

まぁ俺はboost使いづらいプロジェクトのときは
削除子付きのauto_ptr作ってて、それ使うことが多いけど。

つかmove_ptrでググったら、unique_ptrとか出てくるらしいな。
どんなのか知らんけど。



893 :デフォルトの名無しさん:2007/02/24(土) 16:34:09
>>890
完全には理解してないけど、moveと&&を導入するより、
swapでがんばった方がわかりやすくない?

個人的に、引数に&pBufferを渡すと、指してる先のオブジェクトを交換する、
みたいなことはやってるんで、そう思うだけなのかもしれないけど。




894 :デフォルトの名無しさん:2007/02/24(土) 16:35:05
>>890
move_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

895 :デフォルトの名無しさん:2007/02/24(土) 16:49:49
>>893
move が可能 (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 でがんばるという選択は当然あると思います.

896 :デフォルトの名無しさん:2007/02/24(土) 16:50:24
swap
何だかいやらしい響き

897 :デフォルトの名無しさん:2007/02/24(土) 16:56:00
auto_ptr好きなんで会話に乗ったけど、スレ違いだったな。

俺としては、自分一人か、
まともにC++使える奴らとなら、C++での開発で良い。
それ以外はjavaとかそっち方面が良いな。
被害を抑えるために。


898 :デフォルトの名無しさん:2007/02/24(土) 17:13:50
>>896

何だかいやらしいのはお前

899 :デフォルトの名無しさん:2007/02/24(土) 17:29:36
>>895
まあ、コンパイラがきちんと面倒見てくれるならOKかな。

T tmp( std::move( x ) ); y = std::move( x );
と書いたらエラーを出してくれるくらいに。


900 :デフォルトの名無しさん:2007/02/24(土) 17:40:59
それはせいぜい実行時エラーだと思う
それにxの型が組込型などだったら問題なく実行できるだろうし。

901 :デフォルトの名無しさん:2007/02/24(土) 17:43:20
>>893
(少なくとも現状のC++だと)関数の戻り値でswapするのは無理では?

902 :デフォルトの名無しさん:2007/02/24(土) 17:46:18
いや、&&なんて新しい記法を導入して言語を変更するのがアリなら、
std::moveも、言語のセマンティクスでサポートしてほしいかなと。

組み込み型で問題なく実行できたあと、喜び勇んでテンプレートにしたら、
全然動かないなんてつらいでしょ。


903 :デフォルトの名無しさん:2007/02/24(土) 18:02:44
>>901
確かに。その意味でも、moveの方が強力で汎用的。

904 :デフォルトの名無しさん:2007/02/24(土) 18:06:12
C++なんて終わった言語なんだからメンテに勤めてればいいよ

905 :デフォルトの名無しさん:2007/02/24(土) 18:13:40
>>885
いや、そもそも接頭辞を付けなきゃならない時点で終わってる。
そんなものつけるべきじゃない。
グローバル変数やグローバル関数を使うのを辞めて
メソッド名はなるべく動詞にして

staticの場合、
 クラス名.メソッド名

インスタンスの場合、
 インスタンス名.メソッド名
のような表記にすればいい。

906 :デフォルトの名無しさん:2007/02/24(土) 18:14:44
>>891
紅茶はどうした
スターウォーズの宇宙人はどうした。


907 :デフォルトの名無しさん:2007/02/24(土) 18:16:29
>>886
だからグローバル変数を使わなければ
そんな格好悪い記法つかわなくても済むんだって





908 :デフォルトの名無しさん:2007/02/24(土) 18:17:43
>>904
ZopeやらRuby on Railsやらが出るたびにスクリプト言語に
シェアが食われていくJavaの方が先にお亡くなりかもよ。

909 :デフォルトの名無しさん:2007/02/24(土) 18:21:36
>>907
わかっててわざと言ってるような気がするが、
m_ ってデータメンバーにつけるようなヤツは
グローバル変数には g_ ってつける。
これらは引数やローカル変数と区別する為。

910 :デフォルトの名無しさん:2007/02/24(土) 18:39:51
>>905
どう勘違いしたのか分からんけど、グローバルとか動詞とか関係無いから。

意味を元に接頭辞=アプリケーションハンガリアン。
例えば座標の変数の場合、絶対座標はabsを、相対座標はrelを頭に付けるとかの話。

911 :デフォルトの名無しさん:2007/02/24(土) 18:42:01
>>902
>std::moveも、言語のセマンティクスでサポートしてほしいかなと。
今 C++0x に向けて提案されている仕様では,return 文においては
move (右辺値参照への変換) を適用できることが自明なので
言語側が自動的に move を適用してくれるようになります.

一方で明示的に std::move が必要な文脈,
つまり他にオブジェクトのエイリアスが存在して破壊的なコピー (move) が
適用できるかどうかを構文からは判断しかねるような文脈では,
言語側が勝手に move を適用するのはまずいですし,言語サポートは無理があるかと.

というか, Java ほとんど関係なくてスレ違いですね.
Java を詳しく知ってる人から見ると move semantics がどう見えるのかは
聞いてみたいんですけれど.

912 :デフォルトの名無しさん:2007/02/24(土) 18:53:18
無駄な悪あがきにしか思われない気がする。
みんなポインタで扱えばmove  semanticsの出る幕はないだろうからね。

913 :デフォルトの名無しさん:2007/02/24(土) 18:58:22
>>911
Javaに詳しくなくてごめんねぇ。

returnがコピーではなくてmoveだというのは、std::moveが出てくる前から、
最適化の一種として行われていたと思うけど。

明示的にstd::moveが必要な部分でも、変数の初期化忘れをコンパイラが
チェックしてくれるのと同じくらいの厳密さ(いい加減さ)で、
中身がなくなってしまった変数をチェックしてくれるのはアリだと思います。


914 :デフォルトの名無しさん:2007/02/24(土) 19:01:43
悪あがきっていう意味が分からない。
時間的・空間的効率も重視されるC++では値型は重要だし。

>>911
javaはプリミティブ以外に値型が無いから&&演算子自体不要かと。

915 :デフォルトの名無しさん:2007/02/24(土) 19:04:03
>>908
数年前にPerl厨やPHP厨も同じこといってたけど、
Javaは未だになくならないねえ。

JavaとPerlやPHP, Rubyなどの言語とは、そもそも畑違いの世界だから。

世界が違うんだよ。銀行で使われる言語と、たんなるコミュニティサイトでしか
使われないような言語とを比べている時点で終わってる。




916 :デフォルトの名無しさん:2007/02/24(土) 19:04:49
>>909
だったら、グローバル変装のほうにだけg_とつけておいて
メンバのほうには一切付けなくてもいいとおもうんだけどなあ。

どうせなら、そんな名前よりも、名詞形にすればいいのに

917 :デフォルトの名無しさん:2007/02/24(土) 19:05:43
>>910
その表記もイマイチだねえ。
クラス名や名前空間で補った方がいいんじゃないかな


918 :デフォルトの名無しさん:2007/02/24(土) 19:11:26
それだとコードがかなり冗長になる気がするなぁ

919 :デフォルトの名無しさん:2007/02/24(土) 19:14:57
>>911
その変には技術的にすごく興味があるけど、C++でやることじゃない。実験をするなら影響の少ない
無人島でやってほしいものだ。


920 :デフォルトの名無しさん:2007/02/24(土) 19:16:27
>>915
そうかなあ。トレンドの振れ幅が大きいのは、
Javaにしかできない、という分野がないからじゃない?
http://www.tiobe.com/tpci.htm

921 :デフォルトの名無しさん:2007/02/24(土) 19:17:43
>>917
ちょっと感情的になってない?
File.getAbsoluteFileとかも普通クラスわけたりしないっしょ?

絶対座標と相対座標を足すことも普通にあるし。

あと別に積極的に使った方が良いとか言ってる訳じゃないよ。
「終わってる」と言う程のことじゃないと思ってるだけで。

922 :デフォルトの名無しさん:2007/02/24(土) 19:21:58
final
何だか終わってしまったような響き

923 :デフォルトの名無しさん:2007/02/24(土) 19:24:12
try
何だか挑戦的な響き

924 :デフォルトの名無しさん:2007/02/24(土) 19:25:06
>>911
デフォルトでオブジェクトが参照型になっており
clone()メソッドがあるJavaでは気にすることでもなさそうだな。

それに、無駄なコピーは
FlyWeightパターンやProxyパターンで解決できる。

よく使う値はFactory Methodパターンでキャッシュしておくという手もある。


925 :デフォルトの名無しさん:2007/02/24(土) 19:26:38
>>918
場合によりけりだね。
パッケージ名なら、import文で短縮できる。

無駄な接頭辞をつけるよりはまし。
変数宣言の前に、コメント欄に何か書いておくってのもいいと思うし。

926 :デフォルトの名無しさん:2007/02/24(土) 19:29:45
響きと言えばsuperかな。

927 :デフォルトの名無しさん:2007/02/24(土) 19:30:33
>>920
それはどうかね。
Javaにしかできないことはあるとは思うけど。

Javaにしかできないわけではないけど、
Java以外の言語でも扱える分野では
例えば基幹系ではCOBOLや.NET、
携帯電話ではBREWがあるけれど
Java以外の言語でもできるからといって
それがよいのかっていうと疑問だけどね。
とくにBREW開発現場の実情は悲惨なものだ。
あれは携帯Java開発よりもひどい。
基幹系ではCOBOLはもう時代遅れで
Javaの優位性には勝てないし。

PHPやPerl, Rubyで金融開発は
できなくもないけど、かなり不向きだと思うね。
そもそも、スクリプト言語は大規模開発には弱いし。






928 :デフォルトの名無しさん:2007/02/24(土) 19:32:03
>>922
それはターミナル

929 :デフォルトの名無しさん:2007/02/24(土) 19:33:04
>>921
それで、Javaでハンガリアン記法を
使って開発効率が上がったという話があるのなら
聞いてみたい。

930 :デフォルトの名無しさん:2007/02/24(土) 19:33:14
>>925
いまいちイメージが掴めない・・・。
座標とかで例をお願い。

931 :デフォルトの名無しさん:2007/02/24(土) 19:33:38
どちらが書きやすく、読みやすく、理解しやすいか、という話なんだが、
接頭辞を「無駄」と言い切ってそこまで排除したがる理由って何?
そこでコメントを持ち出すとか本末転倒じゃん。

932 :デフォルトの名無しさん:2007/02/24(土) 19:43:07
「これは絶対にJavaにしかできない」ってことはそう多くないよね。
割とオールマイティーにこなせるのが強いという話でさ。

933 :911:2007/02/24(土) 19:45:45
>>912
>みんなポインタで扱えばmove semanticsの出る幕はないだろうからね。
効率云々の話を置いておいたとしても,ポインタ (参照) だけを使うという発想には
GC の有無も深く関わってくると思うので,そう単純ではないように思います.

>>913
>中身がなくなってしまった変数をチェックしてくれるのはアリだと思います。
これは move の泣き所だとは思いますけれど…….
空の状態が有効なクラスとそうでないクラスがありえて,その区別は
最終的には意味レベルの話になると思うので
こういうチェックは難しいのではないかなと思います.

>>914
>javaはプリミティブ以外に値型が無いから&&演算子自体不要かと。
やはりそういうことになりますかね. move は,値型というか
値の深いコピーを基本とする言語 (C++) 特有の発想と言えるのかな.

934 :911:2007/02/24(土) 19:47:12
>>912
>みんなポインタで扱えばmove semanticsの出る幕はないだろうからね。
効率云々の話を置いておいたとしても,ポインタ (参照) だけを使うという発想には
GC の有無も深く関わってくると思うので,そう単純ではないように思います.

>>913
>中身がなくなってしまった変数をチェックしてくれるのはアリだと思います。
これは move の泣き所だとは思いますけれど…….
空の状態が有効なクラスとそうでないクラスがありえて,その区別は
最終的には意味レベルの話になると思うので
こういうチェックは難しいのではないかなと思います.

>>914
>javaはプリミティブ以外に値型が無いから&&演算子自体不要かと。
やはりそういうことになりますかね. move は,値型というか
値の深いコピーを基本とする言語 (C++) 特有の発想と言えるのかな.

935 :デフォルトの名無しさん:2007/02/24(土) 19:48:08
>>929
だから俺は勧めてる訳じゃ無いんだって・・・。俺も使ってないし。
ただ、ちょっとした補足代わりにabsとか付けてる人が居ても悪くは無いっしょ?

936 :911:2007/02/24(土) 19:48:14
>>912
>みんなポインタで扱えばmove semanticsの出る幕はないだろうからね。
効率云々の話を置いておいたとしても,ポインタ (参照) だけを使うという発想には
GC の有無も深く関わってくると思うので,そう単純ではないように思います.

>>913
>中身がなくなってしまった変数をチェックしてくれるのはアリだと思います。
確かに,中身のなくなったオブジェクトが晒されるというのは
move の最大の泣き所だとは思いますけれど…….
ただ,空の状態が意味を成すクラスとそうでないクラスがありえて,その区別は
最終的には意味レベルの話になると思うので
こういうチェックは難しいのではないかなと思います.

>>914
>javaはプリミティブ以外に値型が無いから&&演算子自体不要かと。
やはりそういうことになりますかね. move は,値型というか
値の深いコピーを基本とする言語 (C++) 特有の発想と言えるのかな.

937 :デフォルトの名無しさん:2007/02/24(土) 19:48:39
接頭辞全てが無駄とは思わないけど

Javaならthis.やsuper.があるのがいい。
this.という接頭辞をつけるだけでメンバ変数だとわかる。

時と場合にもよるけれども
省略した接頭辞はわかりにくい。
接頭辞を付けたければできる限りフルネームで。しかもキャメルケースで。

たんなるカウンタ変数ならiでもいい。

938 :デフォルトの名無しさん:2007/02/24(土) 19:48:45
ハンガリアンはなくてもいいけど接頭辞は広い意味であれば使ってるでしょ。
たとえばget接頭辞とset接頭辞
プッ!set接頭辞

939 :デフォルトの名無しさん:2007/02/24(土) 19:48:49
>>925
// 絶対値
int a;
// 相対値
int b;

ってので無いことを祈ります。

940 :デフォルトの名無しさん:2007/02/24(土) 19:49:01
接頭辞全てが無駄とは思わないけど

Javaならthis.やsuper.があるのがいい。
this.という接頭辞をつけるだけでメンバ変数だとわかる。

時と場合にもよるけれども
省略した接頭辞はわかりにくい。
接頭辞を付けたければできる限りフルネームで。しかもキャメルケースで。

たんなるカウンタ変数ならiでもいい。

値型と参照型との区別を曖昧にしなければ
ハンガリアン記法はいらない

941 :デフォルトの名無しさん:2007/02/24(土) 19:49:43
>>916
だからグローバル変数と区別する為じゃねぇって言ってんだろが。
つか、グローバル変装ってなんだよ?

942 :デフォルトの名無しさん:2007/02/24(土) 19:50:54
>>932
「しかできない」という視点では見ず、
「Javaで作った方が効率が良い」という視点でみないと
意味がないと思うね。

C++にしかできないことも、今じゃ狭められてきている。
D言語が勢力を拡大し、Javaがドライバ開発や家電方面にまですそ野を広げると
C++にしかできないことはもう本当にごく僅かと限られてくると思うね。



943 :デフォルトの名無しさん:2007/02/24(土) 19:51:41
pc10.2chが今重いのか

944 :デフォルトの名無しさん:2007/02/24(土) 19:52:01
>>942
おいおい、C++には絶対に譲れない、他の言語にできないことがあるぞ。

既存のコードの保守、だ。

945 :デフォルトの名無しさん:2007/02/24(土) 19:52:02
>>935
absというとアンチロックブレーキシステムや、ABS樹脂、
絶対値を求めるabs()しか思いつかないなあ


946 :デフォルトの名無しさん:2007/02/24(土) 19:52:22
>>942
そうなれば俺もJavaしなきゃいけなくなるわけだ

947 :デフォルトの名無しさん:2007/02/24(土) 19:52:42
>>938
Javaならアノテーションで解決できてしまうで。


948 :911:2007/02/24(土) 19:52:45
あ,書き込めないと思って四苦八苦してたら多重に書き込んでしまっていた.すいません.

949 :デフォルトの名無しさん:2007/02/24(土) 19:52:56
>>929
だから俺は勧めてる訳じゃ無いんだって・・・。俺も使ってないし。
ただ、ちょっとした補足代わりにabsとか付けてる人が居ても悪くは無いっしょ?

950 :デフォルトの名無しさん:2007/02/24(土) 19:53:06
>>939
それは無駄。
おれだったら

absolutedValueにする

951 :デフォルトの名無しさん:2007/02/24(土) 19:53:41
>>937
thisをつけるメリットって高いと思うけど、
つけたりつけなかったりするのは、混乱の元。

なんで、this必須にしなかったのだろう?

952 :デフォルトの名無しさん:2007/02/24(土) 19:54:37
>>941
やば。自分で書いてワラてしまた。
グローバルに世界規模に、世界中を回って変装することじゃね?

ローカル変数と区別するにしても
Javaならthis.をつければいいだけだしねえ。



953 :デフォルトの名無しさん:2007/02/24(土) 19:54:59
>>943
なんか、書込に失敗したとかでて、
重複投稿になってしもた

954 :デフォルトの名無しさん:2007/02/24(土) 19:55:12
superっていいね。

多重継承があるC++にはありえない。
多重継承は、使いようによっては面白い。特定の条件に限るけど。
もう一度書く。特定の条件に限るけど。


955 :デフォルトの名無しさん:2007/02/24(土) 19:55:23
>>944
負の遺産か

956 :デフォルトの名無しさん:2007/02/24(土) 19:55:41
>>946
大丈夫、D言語がある。

957 :デフォルトの名無しさん:2007/02/24(土) 19:56:28
>>945
それは決してイバって言うことじゃないだろ。
絶対値のabsも絶対座標のabsも同じabsoluteじゃん。
そこに考えが至らないのはプログラマーとしてどうかと思う。

>>950
absolutedなんて単語はない(少なくとも一般的ではない)

958 :デフォルトの名無しさん:2007/02/24(土) 19:57:29
>>951
つけなくても、IDEが自動的に判別して色分けしてくれる。

つけたほうがいいけどさ。
それも、CheckStyleやEclipseが警告してくれるから無問題。

必須にしなかった理由を言ったら、
なんでインスタンスフィールドのprivateを必須にしなかったんだろう
とか、とんでもない方向に話が進みそうだ。


959 :デフォルトの名無しさん:2007/02/24(土) 19:58:08
>>945
>絶対値を求めるabs
そのabsじゃん

960 :デフォルトの名無しさん:2007/02/24(土) 19:58:34
>>954
そういえば、super()やsuper.メソッド名()ないんだっけかC++には。

ついでにオーバーロードしたコンストラクタを呼び出せる
this()もないんかいな?



961 :デフォルトの名無しさん:2007/02/24(土) 19:58:51
次スレ立てました

http://pc10.2ch.net/test/read.cgi/tech/1172314713/

962 :デフォルトの名無しさん:2007/02/24(土) 20:00:15
>>957
absoluteValueな。

考えはいたっても、
間違っても、例えばアンチブロックブレーキシステム
に関するソフトウェアを開発したときには、
やたらめったらにabsなんて使って欲しくないな。


963 :デフォルトの名無しさん:2007/02/24(土) 20:02:31
>>961
スレタイがな。
趣旨はそういう目的じゃないし、用途が違うし。

JavaやるとC++の負の側面がみえる
JavaやるとC++のマイナス面がよく見えてくる


みたいな名前のほうがいいね



964 :デフォルトの名無しさん:2007/02/24(土) 20:02:53
>>954
特定の条件って
単一の基底クラス(Object)を必要としない、
ってやつだろ。それなら心配無用。

965 :デフォルトの名無しさん:2007/02/24(土) 20:05:53
>>962
じゃあ、アンチブロック(ryに関するソフトウェアを開発するときは
abs() は使用禁止にして getAbsoluteValue() って関数を再定義しなくちゃな。

966 :デフォルトの名無しさん:2007/02/24(土) 20:07:08
アプリケーションハンガリアンの本質的にはabsoluteって全部書いても良いんだけど・・・。
長いと見辛いから理解出来る程度に短くしてるだけで。
画像編集ライブラリでブレーキシステムは無いだろ。

あとシステムハンガリアンとは別物なんで、混同しないで下さい。

967 :デフォルトの名無しさん:2007/02/24(土) 20:08:03
俺はJavaを知らんが
クラス内のクラスに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は使えるよ。


968 :デフォルトの名無しさん:2007/02/24(土) 20:08:35
コレクション追加としてのaddと演算子としてのaddを勘違いするから駄目ってくらい荒唐無稽な気がするけど

969 :デフォルトの名無しさん:2007/02/24(土) 20:09:03
>>966
即アプリケーションハンガリアンがなんで
システムハンガリアンがなんだったか忘れてしまいそうな響き

970 :デフォルトの名無しさん:2007/02/24(土) 20:09:29
966は>>962宛です。

971 :デフォルトの名無しさん:2007/02/24(土) 20:09:41
>>966ほか
なんでパッケージとか名前空間とかを使おうよ、
って話にならないの?

972 :デフォルトの名無しさん:2007/02/24(土) 20:10:59
次スレ、マジであれで良いの?

973 :デフォルトの名無しさん:2007/02/24(土) 20:12:32
>>971
例出してよ。
アプリケーションハンガリアンが何かわかってレスしてる?

974 :デフォルトの名無しさん:2007/02/24(土) 20:14:10
>>972
スレの中身にこれ以上ないぐらい即してるだろw

975 :デフォルトの名無しさん:2007/02/24(土) 20:15:00
>>973
絶対値もとめるときはabs namespace
絶対名前空間
なんだがSFな響き

976 :デフォルトの名無しさん:2007/02/24(土) 20:18:42
>>973
例って、アンチロックブレーキシステムと、絶対値求める関数を区別する例?
Car.abs()、math::abs()。

977 :デフォルトの名無しさん:2007/02/24(土) 20:21:07
名前空間の話している人はg_とかm_の話をしていないか?
それ違うぞ。

978 :デフォルトの名無しさん:2007/02/24(土) 20:23:02
>>976
違うw

979 :デフォルトの名無しさん:2007/02/24(土) 20:23:57
>>965
まちがえた、アンチロックだった
アンチブロックじゃねえよw

980 :デフォルトの名無しさん:2007/02/24(土) 20:24:15
>>965
そこは名前空間で解決しようや


981 :デフォルトの名無しさん:2007/02/24(土) 20:27:34
>>976
相対座標と絶対座標の変数名の話。
相対なら、windowXとかじゃなくてrelWindowXという話で、
名前空間って何よ?ってこと。

982 :デフォルトの名無しさん:2007/02/24(土) 20:28:38
>>967
> 俺はJavaを知らんが
> クラス内のクラスにC++と同様に独立したクラスと
> 親クラスのメンバにアクセスできるのがあるね。

内部クラスならJavaにもある。

> C++的には子クラスのインスタンスをコンストラクトするときに
> 親クラスのインスタンスを渡すってな感じなのか。
> ってやると、
> (A)のところで、このthisはまだParentコンストラクタで
> 初期化してないって警告が出る。
> そもそも(B)や(C)じゃなくて(A)で初期化する仕様が気に入らない。
> Childではいちいちparent->〜ってしなきゃいけない。

Javaでも同じだし、そりゃ当たり前。そもそも、コンストラクタ
によって初めてthisができあがるんだから、初期化できなくて当然。
どうしてもやりたければ、Javaの場合は、内部クラスをstaticにするね。
んで、staticイニシャライザやprivate staticメソッドを使って初期化する。

983 :デフォルトの名無しさん:2007/02/24(土) 20:29:05
>>968
名前空間があるから駄目ってことはない。


984 :デフォルトの名無しさん:2007/02/24(土) 20:30:32
>>972
良いスレタイ案あるか?

ないなら俺が考える。


JavaやるとC++の暗黒面が見えてくる


とかでもいいか?


985 :デフォルトの名無しさん:2007/02/24(土) 20:31:51
JavaやるとC++がレトロに見えてくる


と書いておけば、C++屋も起こらないだろうと
思うが、どうよ?

986 :デフォルトの名無しさん:2007/02/24(土) 20:32:41
そんなスレタイで本当に住み分けできると思う?
どうせ同じ展開になるなら既に立ってるスレでいいじゃん。
真面目に語りたいならもう少し真っ当なスレタイにするべきだろ。

987 :デフォルトの名無しさん:2007/02/24(土) 20:32:53
で、別に流さはアプリケーションハンガリアンの本質じゃないから、
absをabsoluteと書くのは同じこと。
本質は同じ型・同じ単位で、混同してはいけない値の種類を変数名に付けること。

988 :デフォルトの名無しさん:2007/02/24(土) 20:34:42
いやだめだ、レトロだとC++を美化しすぎてJavaを悪く見せるかな。
レガシーも勘違いされるし。

Javaやると
C++がセピア色に見えてくる //まあまあ
JavaやるとC++=バブルと連想する //煽り?
JavaやるとC++が負の遺産に見えてくる //世界遺産でもそういうのあるので煽りではないとおもう


989 :デフォルトの名無しさん:2007/02/24(土) 20:35:09
>>986
こういう煽りがないと客がこんだろ。
Considered harmful
ってタイトルじゃなきゃ誰も読まなかったぜ。

990 :デフォルトの名無しさん:2007/02/24(土) 20:36:11
>>986
今までスレタイに厨がつくスレはろくな
使われカタしなかったことを思い出すよ。
本当に厨ややってスレが荒れるだけなんdなよな。
しかもJava嫌いな奴が集まってVBやDelphiやC#厨が
AAでスレを荒らす。
そういうのばかり。


991 :デフォルトの名無しさん:2007/02/24(土) 20:36:42
>>990
どうでもいいがもう少し落ち着いてレスしろよw

992 :デフォルトの名無しさん:2007/02/24(土) 20:37:04
>>988
java厨乙

993 :デフォルトの名無しさん:2007/02/24(土) 20:37:19
>>989
feel harmfulじゃないか


994 :デフォルトの名無しさん:2007/02/24(土) 20:38:06
厨は外した方が良い。人より言語をあおるべき。

995 :デフォルトの名無しさん:2007/02/24(土) 20:38:33
次スレ
JavaやるとC++はおほほほほほwwwwww
http://pc10.2ch.net/test/read.cgi/tech/1171237942/

996 :デフォルトの名無しさん:2007/02/24(土) 20:39:17
>>989はもう少し英語を真面目に勉強するべきだと思った。
高校受験レベルの受動態が理解できてない。

997 :デフォルトの名無しさん:2007/02/24(土) 20:39:19
ワラタ

998 :デフォルトの名無しさん:2007/02/24(土) 20:39:54
不覚にも吹いた

999 :デフォルトの名無しさん:2007/02/24(土) 20:40:12
999のついでに1000も貰う

1000 :デフォルトの名無しさん:2007/02/24(土) 20:40:25
というわけで、貰った

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

311 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)