「C++ vs. Java」

このエントリーをはてなブックマークに追加
1 ：デフォルトの名無しさん：
FIGHT!!!
2 ：デフォルトの名無しさん：03/10/04 00:14
>>1
Del厨はDelphiスレに帰れ。
3 ：デフォルトの名無しさん：03/10/04 00:14
(・∀・)ﾂﾚﾀ!
4 ：デフォルトの名無しさん：03/10/04 00:15
オヒョウが違う。
5 ：sage：03/10/04 00:22
このスレ(・∀・)ｲｲ!!
6 ：デフォルトの名無しさん：03/10/04 00:26
互換性をかんがえるとJavaの勝ち。
GUIを考えるとC++の勝ち。
7 ：デフォルトの名無しさん：03/10/04 00:27
C++にGUIのライブラリなんてねーよ。
8 ：デフォルトの名無しさん：03/10/04 00:36
無題に重複スレをたてるな>>1
削除依頼出して来い
9 ：デフォルトの名無しさん：03/10/04 09:48
>>6
＞互換性をかんがえるとJavaの勝ち。

STD C++の方がよっぽど互換性は高いが。
10 ：デフォルトの名無しさん：03/10/05 04:42
タイプ数の少なさでC++の勝ち。
カレー好きにはJavaの勝ち。
11 ：デフォルトの名無しさん：03/10/05 09:40
ここが秋の天気のよい日曜に　閉じこもり煽り屋軍団が集結するスレなわけですか？
12 ：デフォルトの名無しさん：03/10/05 13:55
統合開発環境の統一性と
解説書の多さと
マイクロソフトの御加護で
C++の勝利
13 ：デフォルトの名無しさん：03/10/05 15:05
>>12
それはVC++信者に当てはまることでUnix系でC++使っている人にとっては失礼だ。
14 ：唐辛子.net：03/10/07 23:06
C++避難所
http://www.ichigobbs.net/cgi/readres.cgi?bo=proglam&vi=0069&rm=50
15 ：デフォルトの名無しさん：03/10/08 21:48
C++の圧勝であります。
Javaの時代は終焉を迎えたのであります。
16 ：デフォルトの名無しさん：03/10/09 00:27
用途によって使い分けましょう。
以上。
17 ：デフォルトの名無しさん：03/10/09 00:57
C++だけで何でも出来る、Javaの出番は無し。
Javaまで手を回す余力があればC++の追求探求に力を注いだ方が絶対に良い。
18 ：デフォルトの名無しさん：03/10/09 01:00
遅ればせながらロボコード始めました。
Javaはお気楽でいいね。
19 ：デフォルトの名無しさん：03/10/09 01:01
>>17
なあ頼む、iアプリをC++で作ってくれ。
20 ：デフォルトの名無しさん：03/10/09 01:05
>>19
ドコモBREWを採用するように頼んでください
21 ：デフォルトの名無しさん：03/10/09 01:10
>>17
なあたのむC++だけでJavaと同じ開発速度でソフトを完成させてくれ。
22 ：デフォルトの名無しさん：03/10/09 01:11
>>20
なあたのむBREW用に作ったC++アプリをどの携帯電話でも再コンパイルせずに
動かせるようにしてくれ。
23 ：デフォルトの名無しさん：03/10/09 01:12
>>21
C++もJavaも開発期間は変わりませんね。
24 ：デフォルトの名無しさん：03/10/09 01:12
>>17
なな頼む、C++だけでJ2EEとおなじくらいの開発速度でJ2EE用システムをすべて
C++だけで開発してくれ。
25 ：デフォルトの名無しさん：03/10/09 01:13
>>22
バッチ処理でクロスコンパイルするだけだと思うんですが何か嫌ですか？
26 ：デフォルトの名無しさん：03/10/09 01:13
>>23
> >>21
> C++もJavaも開発期間は変わりませんね。
ﾌﾟ
27 ：デフォルトの名無しさん：03/10/09 01:13
>>25
> >>22
> バッチ処理でクロスコンパイルするだけだと思うんですが何か嫌ですか？
馬鹿丸出しw
28 ：デフォルトの名無しさん：03/10/09 01:15
>>24
そもそもJ2EE用システムってなんですか？
C++もライブラリでバックエンドとしてDBを使う事は簡単ですし、
セッション管理についてもFastCGI SAを使えば全く問題有りません。
また、その他ライブラリもC++なら豊富ですから問題有りませんね。
29 ：デフォルトの名無しさん：03/10/09 01:16
>>23
Javaを使うと開発速度がC++の５倍になったと発表した企業もいるのだが。
個人でも3倍は早くなったと発表しているが。
30 ：デフォルトの名無しさん：03/10/09 01:17
まあ好きでJavaやってるなら別にいいんですが、
みんな使ってるからとかやむを得ずJava使ってるなら考え直して欲しいですね。
31 ：デフォルトの名無しさん：03/10/09 01:17
>>28
C++だけで済ませろといったのにFastCGIときましたか。
32 ：デフォルトの名無しさん：03/10/09 01:17
>>29
単にC++の学習が十分じゃなかっただけでしょう
33 ：デフォルトの名無しさん：03/10/09 01:18
>>31
FastCGI SAもC++で書かれたApacheモジュールなんですが頭大丈夫ですか？
34 ：デフォルトの名無しさん：03/10/09 01:21
C++よりC#とくらべなはれ。
35 ：デフォルトの名無しさん：03/10/09 01:22
>>30
Javaを使い始めた多くの人々がJavaを使うきっかけを生んだのは
Javaがプラットフォーム非依存で
C++のようなスパゲティコードを生み出す危険性を減らすところにあったわけだが。

みんなが使ってるからやむを得ずJavaを使ってるとは失礼なことよ。
プログラミング言語はOSやOffice Suiteとは違い競争原理が働かないものなのだが。
36 ：デフォルトの名無しさん：03/10/09 01:23
>>32
もうそんな詭弁な言い訳はもはや通用しなくなっているのだが。
その一例としてJavaが難しいから.NETを選んだという企業も増えてきているわけだが。
37 ：デフォルトの名無しさん：03/10/09 01:25
>>34
ここはC++とJavaとを比較するスレであり
C#について語るスレではない。

C#と比較したければ該当スレまたは新規にそれ相応のスレをたてること。
38 ：デフォルトの名無しさん：03/10/09 01:25
>>35
Javaを使っているからと言ってスパゲティコードが減るとは思えませんが。
struts等のライブラリの拘束によってスパゲティが減るのだというのなら、
C++でも同じですよね。
39 ：デフォルトの名無しさん：03/10/09 01:25
>>25
そんなことを携帯電話もっている顧客にまで押し付けるのか。
終わってるな。
40 ：デフォルトの名無しさん：03/10/09 01:26
>>35
>プラットフォーム非依存
結局どこがプラットフォーム非依存なんでしょうか？
Javaの実効環境が無いと動かないのに。

>>36
それは頭悪い香具師が悪いだけです
41 ：デフォルトの名無しさん：03/10/09 01:26
>>38
C++はJavaと比べ低レベルな部分でスパゲティを生みやすいですが何か。
42 ：デフォルトの名無しさん：03/10/09 01:27
>>39
意味が分かりません。
願客がプログラム書くわけじゃないですよね。
43 ：デフォルトの名無しさん：03/10/09 01:28
>>41
boostやBoehmを使ってください。
44 ：デフォルトの名無しさん：03/10/09 01:28
>>40
> >>35
> >プラットフォーム非依存
> 結局どこがプラットフォーム非依存なんでしょうか？
> Javaの実効環境が無いと動かないのに。
オマエも頭が悪い。
プラットフォームにたいする依存性が減ったということがC++にはないJavaのうりなわけだが。
そんなことはすでに昔から語りつくされているだろうに、いまさらわめくな。

> >>36
> それは頭悪い香具師が悪いだけです
ニュースもみていないからそういうことしかいえないんだよ。頭が悪いのはオマエだよ。
45 ：デフォルトの名無しさん：03/10/09 01:30
>>43
boostなどがなくてもC++でコーディングできてしまうわけだが。
いちいちC++プログラマにそれらを使わせるように普及させない限り
Javaのようにはいかないぞ。
46 ：デフォルトの名無しさん：03/10/09 01:30
>>44
あなたあまりJavaの事も知らないみたいですね。

まあ日本の技術者の平均レベルが低いのは分かるんですが、
日本の技術者には向上心は無いんでしょうかね？
47 ：デフォルトの名無しさん：03/10/09 01:31
>>42
> >>39
> 意味が分かりません。
意味がわからない？　だとしたらオマエの頭が悪いとしか言いようが無い。

> 願客がプログラム書くわけじゃないですよね。
オマエの発言( >>25 )はそうともとれるわけだが。
48 ：デフォルトの名無しさん：03/10/09 01:32
>>45
Javaもstruts等の拘束が強いフレームワーク無しでは信じられないクラス構成のコードが簡単に作れてしまいますね。
まあstrutsを使っても馬鹿なクラス設計にする香具師は多いですが。
49 ：デフォルトの名無しさん：03/10/09 01:32
これはとうとうC++厨の誤魔化しが始まったか。

>>46
あなたあまり日本語の事も知らないみたいですね。
(こうとしかいいようがないな。)

まあ日本の技術者の平均レベルが低いのは分かるんですが、
日本の技術者には向上心は無いんでしょうかね？
50 ：デフォルトの名無しさん：03/10/09 01:33
>>47
相当頭悪いですね。
クロスコンパイルした後にそれぞれのバイナリを願客に配布するに決まってるでしょう。
51 ：デフォルトの名無しさん：03/10/09 01:33
>>48
チミ、strutsは何に使われるものか知ってる？
何かいってることが外れているんだよな。
52 ：デフォルトの名無しさん：03/10/09 01:34
>>51
MVC拘束型J2EEフレームワークです
53 ：デフォルトの名無しさん：03/10/09 01:34
>>50
相当頭悪いですね。
クロスコンパイルにかかるコストも無視していますね。
54 ：デフォルトの名無しさん：03/10/09 01:35
>>53
そんなコストは自動化で最小化できます。
さっきからバッチ処理って書いてるでしょ。
55 ：デフォルトの名無しさん：03/10/09 01:36
端的に言うとJavaは馬鹿が使う言語って事ですね。
56 ：デフォルトの名無しさん：03/10/09 01:37
>>54
では、それを使って新しいOSが登場したときのコストもお考えですか？
57 ：デフォルトの名無しさん：03/10/09 01:38
端的に言うとC++は古代の馬鹿が使う言語って事ですね。
58 ：デフォルトの名無しさん：03/10/09 01:38
>>54
バッチ処理プログラムを作るときのコストをお考えですか？
59 ：デフォルトの名無しさん：03/10/09 01:38
>>56
新しいOSが登場したときにJREが移植されるまでのコストと変わらないでしょう。
60 ：デフォルトの名無しさん：03/10/09 01:39
>>58
そんなもん一回作れば終わりだし半日もかからんだろ
61 ：デフォルトの名無しさん：03/10/09 01:40
>>54
OSやCPU,、ハードウエア固有の機能を駆使した複雑なプログラムにまでそんなことが
低コストでできるとお考えですか？
62 ：デフォルトの名無しさん：03/10/09 01:40
Javaで必死にパフォーマンスがとか嘆いてるのが目に浮かびます。
63 ：デフォルトの名無しさん：03/10/09 01:41
>>59
C++の場合は各プログラムひとつにつきそれ相応のコストがかかりますが
JREが移植されるときのコストはJREひとつだけですが何か。
64 ：デフォルトの名無しさん：03/10/09 01:42
>>61
新プラットフォームにコンパイラを自作するわけじゃないでしょう。
クロスコンパイル先のアーキテクチャのコマンドラインオプションを追加するだけです。
あなたは新プラットフォームが出るとJREを自作するんですか？
65 ：デフォルトの名無しさん：03/10/09 01:42
>>62
> Javaで必死にパフォーマンスがとか嘆いてるのが目に浮かびます。
ついに煽ることしかできなくなったかC++厨。
パフォーマンス？　コストパフォーマンスは君にいちいち言わなくても抜群だが。
66 ：デフォルトの名無しさん：03/10/09 01:43
>>63
どっちにしろ自動なんだから、人件費はほとんど必要ないでしょう。
67 ：デフォルトの名無しさん：03/10/09 01:43
>>64
どっちにしろC++はJavaよりも多大なコストがかかりますが何か
68 ：デフォルトの名無しさん：03/10/09 01:43
俺はJava派だが正直言おう。
日本の職業Javaプログラマの平均スキルはとてつもなく低い…。
69 ：デフォルトの名無しさん：03/10/09 01:44
Javaは適用できる案件の範囲から限られてる言語ですから最初から負け組言語ですね。
70 ：デフォルトの名無しさん：03/10/09 01:44
１．Javaは馬鹿が使う言語
２．開発者の９割は馬鹿

１および２からJavaは現実的な職業プログラマの仕事道具である。

残りの１割は、その１割の天才同士でC++やらlispやらで最高の効率で仕事する。
大規模な案件ならいくらでも補給の効くJavaが無難。
ま、言ってみればJavaコーダは使い捨てなわけですが。
71 ：デフォルトの名無しさん：03/10/09 01:44
>>66
どっちにしろC++はJavaよりもプログラマに負担をかけ徹夜付けにさせ病気にさせ頭がハゲますが何か
72 ：デフォルトの名無しさん：03/10/09 01:45
>>68
根拠は。
自分の周りがレベル低い香具師ばかりなんだろ。
73 ：デフォルトの名無しさん：03/10/09 01:46
>>71
Javaだと徹夜付けになったり病気にならないんですか。それは凄いですね。
C++の方がexcitingな言語ですからストレスは溜まりにくいと思いますが。
コーディング規約によりある程度束縛されたとしてもJavaよりはexcitingな言語ですからね。
74 ：デフォルトの名無しさん：03/10/09 01:46
>>69
> Javaは適用できる案件の範囲から限られてる言語ですから最初から負け組言語ですね。
Javaの案件はC++と食らえるととてつもなく多いが。
75 ：デフォルトの名無しさん：03/10/09 01:46
>>74
ご冗談を。Javaはサーバーサイドだけでしょう。
76 ：デフォルトの名無しさん：03/10/09 01:46
>>70
> １．Javaは馬鹿が使う言語
むかつくことをいいやがｔって。おまえこそJavaつかったことがあるから馬鹿なんだろ。
77 ：デフォルトの名無しさん：03/10/09 01:47
>>75
携帯電話を忘れてるぞー
78 ：デフォルトの名無しさん：03/10/09 01:48
ニューガンダムの連邦の機体で例えると

νガンダム ... C++ ニュータイプじゃないととても乗りこなせない
ジェガン ... Java 高性能な量産型。GM3(VB)やネモ(COBOL)とは格段の能力の差

ってところでしょうか？
79 ：デフォルトの名無しさん：03/10/09 01:48
>>77
まだゲーム程度にしか使われていませんが？
80 ：デフォルトの名無しさん：03/10/09 01:50
>>77
Javaは携帯電話に向いた言語だとは思えないんですよね。
そのうちBREWに統一されるでしょう。
81 ：デフォルトの名無しさん：03/10/09 01:51
>>70
> １．C++は利用者の大半が馬鹿が使う言語
> ２．C++開発者の９割は馬鹿
のほうが現実的だと思うが。
いつも腹立たしく思うことは、C++厨が「Javaは馬鹿が使う言語 」といっておきながら
C++はほんの少ししかできずほとんどC言語レベルしか使いこなせない奴だ。
Cしかできないことを隠すためにうわべだけ「C++やってるので馬鹿じゃありません」とかいう奴。
まったく殴りたくなってくる。
82 ：デフォルトの名無しさん：03/10/09 01:51
>>78
ガンヲタ消えろ。
83 ：デフォルトの名無しさん：03/10/09 01:52
>>81
そういう事を言う人に限ってJavaをCレベルでしか使ってないんですよね。
84 ：デフォルトの名無しさん：03/10/09 01:53
>>79
iアプリは新人研修と40くらいのおじさんの仕事。

いや大手になると若手がケータイ専門に駆り出されている所もあるみたいだけど、
普通の(中小)ゲーム屋ではバリバリの現役なんかiアプリに回さない。
85 ：デフォルトの名無しさん：03/10/09 01:53
>>73
> >>71
> Javaだと徹夜付けになったり病気にならないんですか。それは凄いですね。
> C++の方がexcitingな言語ですからストレスは溜まりにくいと思いますが。
それでexcitingと思うならおまえの作っているプログラムはだれもexcitingとは思わないだろうな、

> コーディング規約によりある程度束縛されたとしてもJavaよりはexcitingな言語ですからね。
Javaはバグだしまくりでそれのための無駄なことに時間を費やすC++よりはexcitingな言語だが。
86 ：デフォルトの名無しさん：03/10/09 01:55
>>85
C++ではXPが出来ないという事は無いですよ。
87 ：デフォルトの名無しさん：03/10/09 01:55
>>84
組み込みでいうと、
ハード屋のおじさんが片手間でやってる
PICアセンブラみたいなものなのかな？
88 ：デフォルトの名無しさん：03/10/09 01:56
>>83
そういうやつ(インスタンスメソッドにしたほうが効率が良いメソッドがすべてstaticになっているアホ)もいるが
おれさまをオマエのような貧相なことしかいえない奴と一緒にするな。
89 ：デフォルトの名無しさん：03/10/09 01:56
>>81
君(Javaコーダ)が日本語もうまく書けない馬鹿だという事が証明されてしまったわけですが感想は？
90 ：デフォルトの名無しさん：03/10/09 01:56
>>79
C++では携帯電話の実例はどうなんだ？
91 ：デフォルトの名無しさん：03/10/09 01:57
>>90
ファームはC/C++でしょう。
92 ：デフォルトの名無しさん：03/10/09 01:57
>>86
こいつ、いきなりXP言い出してるよ。話がいきなり飛躍してどうするよ。
93 ：デフォルトの名無しさん：03/10/09 01:58
>>90
BREWって既にこのスレで何度も出てきてるわけですが。
こういうスレに参加するなら双方の言語の最低限のの知識は身につけておいて欲しいですね。
94 ：デフォルトの名無しさん：03/10/09 01:58
>>91
中身がだろが。ゲームを作っているやしが(移植を除いて)C++でやっているとでもいうのかおい。
95 ：デフォルトの名無しさん：03/10/09 01:58
>>92
バグが出ない==テストファーストという事じゃないんですか？
Javaは普通に書いてもバグが出ない言語なんですか。それは素晴らしい事ですね。
96 ：デフォルトの名無しさん：03/10/09 02:00
>>93
知ったかぶりしおって。生意気そうな奴だな。
BREWはあるだけでは「ソフトがなければただの箱」同然だろが。
97 ：Lisp厨：03/10/09 02:00
>>70
天才はC++など使わない。
98 ：デフォルトの名無しさん：03/10/09 02:00
ゲーム屋的にはどうせならJavaじゃなくてC#がケータイ標準言語になってくれればよかったと思う。
99 ：デフォルトの名無しさん：03/10/09 02:00
バグが出ないのになんでJavaの案件で火の車になっている所があるのか不思議で仕方がないですね。
100 ：デフォルトの名無しさん：03/10/09 02:01
>>94
>>77 - >>79 - >>90 の流れをよく読んでくださいね。
101 ：デフォルトの名無しさん：03/10/09 02:01
>>97
Andrei Alexandrescu
は天才だとは思わない？
102 ：デフォルトの名無しさん：03/10/09 02:02
>>95
> >>92
> バグが出ない==テストファーストという事じゃないんですか？
お前がもしそう思っているならお前は会社やめたほうがいい。
そんなことを平気でいうとはお前も恥さらしだな。

> Javaは普通に書いてもバグが出ない言語なんですか。それは素晴らしい事ですね。
お前の脳内変換には呆れたよ。妄想も休み休みに言え。
103 ：デフォルトの名無しさん：03/10/09 02:02
>>98
DirectX Embedded 的なものがあればよかったのにね
104 ：デフォルトの名無しさん：03/10/09 02:02
>>101
イカレてると思う
105 ：デフォルトの名無しさん：03/10/09 02:02
>>98
それだったらC++のほうがいいって話になる。
106 ：デフォルトの名無しさん：03/10/09 02:03
C++厨の>>95が変なこと言い出したぞ。
107 ：デフォルトの名無しさん：03/10/09 02:04
Java厨は発言の一つ一つが必死に見えるんですが何故でしょうかね
108 ：デフォルトの名無しさん：03/10/09 02:04
>>98
大して変わらんよーな…
109 ：デフォルトの名無しさん：03/10/09 02:04
>>102
テストファーストして単体でバグが出たらテストファーストになってません。
110 ：デフォルトの名無しさん：03/10/09 02:04
>>93も馬鹿だな
111 ：Lisp厨：03/10/09 02:04
>>101
"God wrote in Lisp code"
ttp://www.gnu.org/fun/jokes/eternal-flame.html
ttp://www.gnu.org/fun/jokes/eternal-flame.ogg

112 ：デフォルトの名無しさん：03/10/09 02:05
>>103
いや描画APIはどーでもいいや。まだあと１０年は毎年激変するだろうから。

>>105
ケータイだとやっぱりVM系言語のほうがいいよ。
(作る側じゃなくて使う側として)
113 ：デフォルトの名無しさん：03/10/09 02:06
>>107
お前の妄想。お前は敬語つかっていれば必死に見えないと
思っているらしいがそうは見えないな。平静さを装っているかと思えば
そのような煽り。必死なのはどっちだ？
114 ：デフォルトの名無しさん：03/10/09 02:06
C#はクロスプラットフォームと言える状態にさえなってない。草の根でLinuxに移植されてるだけ。Java未満。
115 ：デフォルトの名無しさん：03/10/09 02:07
>>109
何か独り言いってるやつがいるぞ。だれかこいつを相手にしてやれよ。
116 ：デフォルトの名無しさん：03/10/09 02:07
>>113
サーバーサイドがASP.NETに呑まれたら終わりのJavaだからでしょうかね。
117 ：デフォルトの名無しさん：03/10/09 02:07
>>114
まあC#は別スレでも・・・・
118 ：デフォルトの名無しさん：03/10/09 02:08
>>115
「必死」の見本を見せてくれているのでしょうか。
119 ：デフォルトの名無しさん：03/10/09 02:09
>>116
>>113のレスと何の脈絡もないのになにいってんだこいつ、
120 ：デフォルトの名無しさん：03/10/09 02:10
>>119
高卒の方ですか。行間も読めないの？
121 ：デフォルトの名無しさん：03/10/09 02:10
>>116
呑まれない。今Javaはサーバサイドを飲んでないけど。
122 ：デフォルトの名無しさん：03/10/09 02:10
>>111
lisp信者ってついに本物の新興宗教がかってきましたね。
123 ：デフォルトの名無しさん：03/10/09 02:10
Java厨=高卒
124 ：デフォルトの名無しさん：03/10/09 02:10
>>118
主語を書いていない奴の意見はまったく意味不明。
125 ：デフォルトの名無しさん：03/10/09 02:11
>>120
必死な言い訳だなw
126 ：デフォルトの名無しさん：03/10/09 02:11
>>124
日本語は英語では無いのですよ。
127 ：デフォルトの名無しさん：03/10/09 02:11
>>123
煽ることしか脳が無くなったC++厨は中卒ですね。
128 ：デフォルトの名無しさん：03/10/09 02:14
まあ俺に言える事は
C++はスパゲッティとかいうJavaコーダは
本当はC++のソースなんぞ見たこともないだろうって事だけだ。
129 ：デフォルトの名無しさん：03/10/09 02:15
C++に比べてJavaのポテンシャルの低さと言ったら…
別にGoslingを責めてるわけではないですよ。
戦略として馬鹿向けに作った言語でしょうから。
130 ：デフォルトの名無しさん：03/10/09 02:16
C++のソースは美しいのですよ。
131 ：デフォルトの名無しさん：03/10/09 02:16
>>130
132 ：デフォルトの名無しさん：03/10/09 02:18
>>101
Andreiも相当頭が良い方ですが、
C++のようなポテンシャルの高い言語だからあのような事が出来るのですよ。
133 ：デフォルトの名無しさん：03/10/09 02:18
Javaはｵﾌﾞｼﾞｪｸﾄ指向言語なんかじゃない。

ﾏｰｹﾃｨﾝｸﾞ指向言語だ。
134 ：デフォルトの名無しさん：03/10/09 02:19
C++以外なら必要ないテクニックもあるけどな。
135 ：デフォルトの名無しさん：03/10/09 02:21
>>126
意味不明　
136 ：デフォルトの名無しさん：03/10/09 02:21
C++は確かにポテンシャルは高い。（賢い奴が使えば。）
↓
現実のプログラマは馬鹿の方が多い。
↓
デスマーチ
137 ：デフォルトの名無しさん：03/10/09 02:22
>>135
日本語は英語と違って主語必須の言語では無いのですよ。
と言えば分かりますか。もっと教養を身につけた方が良いのですよ。
138 ：デフォルトの名無しさん：03/10/09 02:23
>>133
正直、名言だと思う。

>>134
たしかに。でも低レベルと高レベルを両方扱う言語ならやっぱり必要な部分なんだよ。
Javaは低レベルはばっさり切っちゃったから、Javaしか知らない奴はC++のテクニックを
よくわからずに批判する。
139 ：デフォルトの名無しさん：03/10/09 02:25
>C++以外なら必要ないテクニックもあるけどな。
に対して
>Javaしか知らない奴はC++のテクニックを
>よくわからずに批判する。
はおかしいと思うのですよ。
140 ：デフォルトの名無しさん：03/10/09 02:26
>>136
C++でもJavaでもいいが、プログラマなりコーダなりの事情で
デスマってるてのはあんまりないだろ。

デスマと言語は本質的には関係ない。
141 ：俺の予想：03/10/09 02:29
C++以外なら必要ないテクニックをJavaしか知らない奴が見る

　　　　　　　　　　　　　　　↓

(僕の知ってる世界ではこういう事は許されないっ！！)

　　　　　　　　　　　　　　　↓

2chで「C++だとスパゲティ」とカキコ
142 ：デフォルトの名無しさん：03/10/09 02:29
JavaはC++よりもスタイルを強制される。
↓
普通のプログラマでもある程度の品質のコードがかける。
↓
C++よりも速く仕上がって(ﾟдﾟ)ｳﾏｰ
143 ：デフォルトの名無しさん：03/10/09 02:30
pimplは仕方が無いと思うのですよ。
144 ：デフォルトの名無しさん：03/10/09 02:30
>>141
許されないかどうかじゃなくて

必　　要　　な　　い　　。

んだよ。
145 ：デフォルトの名無しさん：03/10/09 02:30
>>142
だからライブラリに拘束されればどちらも同じなのですよ。
146 ：デフォルトの名無しさん：03/10/09 02:32
>>145
C++の場合はBetter Cとして低レベルなコードがかけてしまう。
Javaは低レベルな部分がなくてライブラリ使用を強制される。
147 ：デフォルトの名無しさん：03/10/09 02:32
てかJava厨がC++を目の仇にする理由がわからん。
適応分野が違いすぎる。
148 ：デフォルトの名無しさん：03/10/09 02:34
>>146
そんなものは、生のchar配列なんかは使わなければいいだけの話なのですよ。
フレームワークにクラスモデルを拘束されなければ、
スパゲティクラス構造作る馬鹿がいるのはJavaでも同じなのですよ。
これについては、何を使わなければいいとかいう簡単な問題じゃないのですよ。
149 ：デフォルトの名無しさん：03/10/09 02:35
>>136がいいこといった。
C++プログラマの大半は本当はC言語しかできましぇーんレベル。
現実ってそんなもんなんだよな。
150 ：デフォルトの名無しさん：03/10/09 02:37
>生のchar配列なんかは使わなければいいだけの話なのですよ。
まさにその通り。
↓
じゃ言語仕様からぬいちゃえ。
↓
Java(ﾟдﾟ)
151 ：デフォルトの名無しさん：03/10/09 02:38
>>150
Javaは抜きすぎなのですよ
152 ：デフォルトの名無しさん：03/10/09 02:38
>>146
まともなC++使いは相当パフォーマンスが気になる部分を除いてはC風の書き方はしないし、
好まないし、C使いがチームに混じりこんでC風のコードを書き散らすとむしろ嫌な顔をするのが普通。

C++をまともに使えるようになるまでの過程で「脱Cスタイル」という儀式があるC++使いは
本当にC風のコードは好まない。

C++と称されたBetter CのソースをJavaに移植する事になった担当者だったら
ご冥福を申し上げるばかりだが。
153 ：デフォルトの名無しさん：03/10/09 02:38
>>147
答えはこれだ。
C++はすばらしい言語だ。だが、C++を使っているものすべてがすばらしい人間だとは限らない。
(Javaでもそうだが。)
世の中にはC++使えると威張っている香具師がいるが、
そいつの正体を暴くと、オブジェクト指向も知らないCしかできない厨房。
そんなC厨房がJavaは馬鹿でもつかえる言語と言い切ることに腹をたてる。
154 ：デフォルトの名無しさん：03/10/09 02:39
>>151
じゃ、Smalltalkは抜きすぎじゃないと？
155 ：デフォルトの名無しさん：03/10/09 02:39
>>150
それにJavaにもChar配列あるのですよ。
156 ：デフォルトの名無しさん：03/10/09 02:40
JavaからC++への移植は簡単なのだが・・・。
RMIなどのフレームワークを使った場合を除いて・・・・。
157 ：デフォルトの名無しさん：03/10/09 02:40
Javaは馬鹿でもつかえる
158 ：デフォルトの名無しさん：03/10/09 02:40
>>154
動的型付けができる時点で無限の世界が広がるのですよ。
159 ：152：03/10/09 02:40
俺にとっての「脱Cスタイル」の機会を与えてくれたのは当時解説書が軒並みアプレットの解説しかしてなかった当時の
Javaなので、最近のJava使いがC++を悪く言うのがとても辛い。
160 ：デフォルトの名無しさん：03/10/09 02:41
>>153
俺は何でもJavaを適用して失敗する青臭いJava房の方が目につくよ
161 ：デフォルトの名無しさん：03/10/09 02:41
>>159
あぁ、俺もだ。
162 ：デフォルトの名無しさん：03/10/09 02:42
>>155
つーかポインタも含めてC++の配列は取り扱い要注意だろ。
おのおのの長さが異なる配列変数を大量に宣言しておくと
爆発物を取り扱っているかのように感じる。
163 ：デフォルトの名無しさん：03/10/09 02:42
>>157
そのこぴぺをあちこちに容赦なく張りつけるんだろ。
164 ：デフォルトの名無しさん：03/10/09 02:43
>>155
逝ってくる。∧‖∧
165 ：デフォルトの名無しさん：03/10/09 02:43
>>153
じゃあ間違ってるじゃん。
C使いとC++使いは別人種。

責めるべきはC使いだろ？
166 ：デフォルトの名無しさん：03/10/09 02:43
>>160
どんな失敗か興味がある。
例を教えれ
167 ：デフォルトの名無しさん：03/10/09 02:45
>>166
主にreplaceの案件
168 ：デフォルトの名無しさん：03/10/09 02:45
>>163
いや、ちょっと言ってみただけだ。
馬鹿でも使えるJavaだとしても、Java使いが全て馬鹿なわけじゃないように
C++使えるつもりのC厨がたくさんいるからといって、全てのC++使いがそうなわけじゃない。
169 ：デフォルトの名無しさん：03/10/09 02:45
>>162
そんなに生配列をいくつも宣言する理由が分からないのですよ。
それじゃCなのですよ。
170 ：デフォルトの名無しさん：03/10/09 02:46
>>165
それが、クラス一個作ったくらいで俺様はC++プログラマだぜー、すごいだろー、
みたいな香具師がいるわけですわい。
171 ：デフォルトの名無しさん：03/10/09 02:47
>>167
C++からの？
だったら>>152のいうように「ご冥福」として躓くと思う。
172 ：デフォルトの名無しさん：03/10/09 02:47
>>171
いや珠玉混在

だから「何でもJavaを適用して」と書いたつもり
173 ：デフォルトの名無しさん：03/10/09 02:48
>>170
そんなやついねーよ。


というかいて欲しくない、マジで。
174 ：デフォルトの名無しさん：03/10/09 02:48
俺は>>168の発言がこの馬鹿な議論が行き着くべき終着駅だと思うな。

この馬鹿な議論が何の実も結ばないなんてそれこそ悲しすぎる。
みんなが>>168の結論に行き着くべき。
175 ：デフォルトの名無しさん：03/10/09 02:48
まぁここに居るJava信者は馬鹿だけどな。
176 ：デフォルトの名無しさん：03/10/09 02:49
JavaとC++を連携するときJavaをメインに使う場合はJNIやRunTimeクラスなどを使うわけだが
C++を使う場合は普通にRunTimeクラス相当であれか
177 ：デフォルトの名無しさん：03/10/09 02:51
>>174
>>175がまた蒸し返しているぞ。
>>168と>>175は多分同じだと思うが。それもどうでもいいが。
178 ：デフォルトの名無しさん：03/10/09 02:51
>>176
JavaからC++を使わないと出来ない事はたくさんあっても、
C++からJavaを使う必要性は感じないのですよ。
179 ：デフォルトの名無しさん：03/10/09 02:52
>>177
精度の低い認定してるあたりが馬鹿丸出しですね:)
180 ：デフォルトの名無しさん：03/10/09 02:52
>>176
正直、部下の会話についていけないものの、
なんとなくかじった知識を披露したかった部長さんの発言のような
謎な終わり方ですね＾＾；
181 ：デフォルトの名無しさん：03/10/09 02:52
>>172
ちっこいものやメディアプレーヤとかつくるとなるとネイティブ相当の魅力的なAPIが少ないJavaではねえ。
182 ：デフォルトの名無しさん：03/10/09 02:53
>>176
Javaしか使えないんですね？
183 ：デフォルトの名無しさん：03/10/09 02:54
>>181
むしろ統一化されているJavaではその辺は有利だと思いますが、
結局重くてメモリ喰いなら誰も起動しないのですよ。
184 ：デフォルトの名無しさん：03/10/09 02:55
>>178
サーバ系ではそうもいかないときもあると覆うが。
185 ：デフォルトの名無しさん：03/10/09 02:55
>>181
>>183みたいな調子で失敗犯すんですよ
もうね、ｱﾚかと
186 ：デフォルトの名無しさん：03/10/09 02:55
>>181
いや、ちっこいもの作る時はJavaのが気楽でよい。
スクリプト感覚でさっくり作れるよ。
187 ：デフォルトの名無しさん：03/10/09 02:56
>>178
JNI で使ってるのは C++ っても template とか使わない C++ だからねぇ…
あとは殆ど C だし…
188 ：デフォルトの名無しさん：03/10/09 02:56
>>181
>>186みたいな奴もね、Javaを持ち上げてね
Java言いたいだけちゃうんかと
189 ：デフォルトの名無しさん：03/10/09 02:58
>>176
RunTime クラスなんてあったか？
190 ：デフォルトの名無しさん：03/10/09 02:58
>>184
よほどマイナーな新参DBでも無い限り大丈夫だと思うのですよ。
191 ：186：03/10/09 02:58
>>188
いや漏れはどっちかつーとC++側で参戦してるわけだが。
それにスクリプト=書き捨てとさりげなく貶したつもり。
192 ：デフォルトの名無しさん：03/10/09 02:59
>>191
ｽﾏｿ失礼しました
193 ：デフォルトの名無しさん：03/10/09 03:00
3時なので寝るのですよ
194 ：デフォルトの名無しさん：03/10/09 03:00
俺のPCの時計はまだ2時ですた
195 ：186：03/10/09 03:03
正直、Javaでライブラリを書きたいとは思わない。
Javaで書いた物を再利用とか考えない。
C++はライブラリ書いてる時が一番楽しい。
C++で書くものは再利用が大前提。

だからどうしたっていう感じだが、あるC++厨房の井上トロ…もとい、心情吐露でした。
196 ：デフォルトの名無しさん：03/10/09 03:04
一番ムカつくのは、別言語から移ってきて、初心者質問スレで
（前の言語）では簡単に出来たのに（スレの言語）ではこんなことも出来ないんですか？

とか言うやつ。
言語にはそれぞれのスタイルがあるのにそれを学びもせずに前の言語と同じ機能が無いと許せないらしい。
197 ：デフォルトの名無しさん：03/10/09 03:08
俺が一番ムカつくのは、C系の構文でラップしたSmalltalkをありがたがって
美しいだの、移植性があるだの、真のオブジェクトだの言ってる奴。

君達が興奮してる其はもうずうっっっっっっと前に
大勢が体験済みだってことを知らないんだよ。常識なんだよ？
198 ：デフォルトの名無しさん：03/10/09 03:08
007/007は二度死ぬ

アホアンチは３時に寝る
199 ：デフォルトの名無しさん：03/10/09 03:10
>>197
Objective-C を悪く言わないで下ちい

それにObjective-Cの移植性は怪しいですよ。
200 ：デフォルトの名無しさん：03/10/09 03:12
>>197
JavaはSmalltalkなんかよりずっとC++に近いわけだが・・・。
201 ：デフォルトの名無しさん：03/10/09 03:13
>>199
いやobjcは好きですよ？

Chains of ResponsibilityはObjective-Cが一番自然だしね。
202 ：デフォルトの名無しさん：03/10/09 03:14
>C系の構文でラップしたSmalltalk
これがなにをさしているのやらさっぱり・・・。
203 ：デフォルトの名無しさん：03/10/09 03:15
>>200
ﾊﾟｰﾌﾟﾙﾌﾞｯｸとInside the C++ Object Modelと
The Java Virtual Machine Specification読んでからまた来いや。
204 ：デフォルトの名無しさん：03/10/09 03:16
美しい　　　　→ C++厨は言語仕様の汚さ(マイナス)よりもオートマティックな美しさ(プラス)に惹かれている人種です。
移植性がある　→ ライブラリ次第
真のオブジェクト → 言葉足らず？意味不明

どっちにしても本物のC++使いはOOPLとしてのC++が美しくない事はわかってる。
だけどlokiとかboostに魅せられちまったらもうOOだけの言語は主戦場ではないと感じてる。
205 ：デフォルトの名無しさん：03/10/09 03:17
>>203
なぜにVMが関係ある？
VMがあったらSmalltalkと同じってか？
あほだな。
206 ：デフォルトの名無しさん：03/10/09 03:18
>>202
要するにﾏｰｹﾃｨﾝｸﾞ指向のSyntax Sugarなんだよ。Javaは。
207 ：デフォルトの名無しさん：03/10/09 03:18
>>205
object-model, object-systemの話ですよ。
208 ：デフォルトの名無しさん：03/10/09 03:19
>>206
またあほ発見。
JavaがSmalltalkの構文糖だって？
209 ：デフォルトの名無しさん：03/10/09 03:20
>>207
お前は Smalltalkに触ったことがないだろう？
210 ：デフォルトの名無しさん：03/10/09 03:20
>>208
C砂糖ふりかけただけだっつの。
使ってて感じないのか？
211 ：デフォルトの名無しさん：03/10/09 03:21
まったくもってSmalltalkに失礼だ。
212 ：デフォルトの名無しさん：03/10/09 03:21
>>210
君は「全部Virtual」がSmalltalkとでも思ってるんだろうね。
やれやれ。
213 ：デフォルトの名無しさん：03/10/09 03:21
Smalltalkには世界がある。
Javaはどこかの世界に寄生する寄生虫。
214 ：デフォルトの名無しさん：03/10/09 03:22
煽ってるC++厨房がこの程度ってことがよく分かったよ。
おやすみ。
215 ：デフォルトの名無しさん：03/10/09 03:24
>>209
あるに決まってんだろ。

>>212
そんな例えしか出来ないのかよ。レベル低いね君。
216 ：デフォルトの名無しさん：03/10/09 03:25
>>204
その通りなんだが改めて言われると果たしてそれでいいのかと思ってしまう・・・
217 ：デフォルトの名無しさん：03/10/09 03:25
>>214
ﾎﾞｸはC++使いじゃないんですけど。
病気ですか？
218 ：デフォルトの名無しさん：03/10/09 03:49
まぁpurple bookに誰もﾂｯｺﾐを入れなかった時点で
ここに入る全員がSmalltalk童貞ばかりだということは
明々白々なわけだか。
219 ：デフォルトの名無しさん：03/10/09 03:55
>>213
Javaは寄生虫だからこそ魅力がある。
神聖なる寄生虫はある世界(OS)が滅んでもほかの新しいOSにすぐ飛びつける。

C#も寄生虫と化そうとしているが真の寄生虫として撃退され気味。
あっちの世界では寄生虫でないC#、Monoが受け入れられようとしている
220 ：デフォルトの名無しさん：03/10/09 03:55
>>217
その言い訳もワンパターンで飽きてきたなあ
221 ：デフォルトの名無しさん：03/10/09 03:57
>>220
あいかわらず妄想激しいですね。
ﾌﾞﾙｰﾌﾞｯｸ読んでからまたおいで。
222 ：デフォルトの名無しさん：03/10/09 04:00
正直>>203はVMだから近いと逝ってるようにしか見えないんだが。

223 ：デフォルトの名無しさん：03/10/09 04:02
>>222
>>203と>>207で理解してくれよ。
オブジェクトの内部表現辺りの話なんだけどな。
224 ：デフォルトの名無しさん：03/10/09 04:06
JavaとSmalltalkのMethod Dispatchまわりは全く違いますが。
225 ：デフォルトの名無しさん：03/10/09 04:10
>>224
確かにJavaとSmalltalk"だけ"を比較したらかなり違うよねぇ。
でもいくつかの言語を含めて比較してみたらどうよ。
226 ：デフォルトの名無しさん：03/10/09 04:23
・・・vtblを使うJavaとC++は近いよね・・・。
227 ：デフォルトの名無しさん：03/10/09 04:25
ｱﾎｸｾ

ﾂｷｱｯﾀ ﾓﾚｶﾞ ﾊﾞｶﾀﾞｯﾀ
228 ：デフォルトの名無しさん：03/10/09 14:18
<丶｀∀´>ﾆﾀﾞﾘ
229 ：デフォルトの名無しさん：03/10/09 19:00
C…ポインタを操るのが面白い
C++…テンプレートメタプログラミングかせ面白い
Smalltalk…OOが面白い
Lisp…リスト遊びが面白い
Prolog…ユニフィケーションが面白い
Java…何が面白いの？
230 ：デフォルトの名無しさん：03/10/09 19:03
Javaは安っぽい三つボタンスーツを着た茶髪のｵﾆｰﾁｬﾝって感じがするなぁ。
231 ：デフォルトの名無しさん：03/10/09 21:19
Javaの面白いところ

掃いて捨てるほどいるJavaコーダの中で
使い捨てられずに立身出世していくのが面白い。




というのだとしたら、Javaラーがこのスレで一番まともな社会人だった事になるな。
232 ：Lisp厨：03/10/09 23:43
マクロがあればテンプレートなんかいらない。
233 ：デフォルトの名無しさん：03/10/09 23:57
C++…テンプレートメタプログラミングが面白い
Smalltalk…OOが面白い
Lisp…リスト遊びが面白い
Prolog…ユニフィケーションが面白い
Java…金儲けが面白い

これで納得だろ>all
234 ：デフォルトの名無しさん：03/10/09 23:59
Java...Interfaceを駆使するのが面白い
235 ：デフォルトの名無しさん：03/10/10 00:35
>>1に踊らされるｱﾌｫどもを見られるｽﾚはここでつか?
236 ：デフォルトの名無しさん：03/10/10 00:52
>>234
Interface関連ならSmalltalkの方が面白いと思うが。
237 ：デフォルトの名無しさん：03/10/10 01:09
>>236
UIじゃないほうのInterfaceですが。
238 ：デフォルトの名無しさん：03/10/10 02:17
CQ出版？
239 ：デフォルトの名無しさん：03/11/05 11:06
>>229
> C++…テンプレートメタプログラミングかせ面白い
こいつはJavaでテンプレートを使え無いと思い込んでいたのか
なんて視野が狭すぎる厨房なんだ。

240 ：デフォルトの名無しさん：03/11/05 22:17
テンプレートとGenericsは別物じゃなかったっけ？
241 ：デフォルトの名無しさん：03/11/05 22:34
Javaで仮にテンプレートらしきものが使えたとしても、
多重継承が出来ないとポリシーベースのテンプレートメタプログラミングが出来ないので、
Javaはつまらない。
242 ：デフォルトの名無しさん：03/11/05 22:36
Java使いの平均IQ…95
C++使いの平均IQ…110
243 ：デフォルトの名無しさん：03/11/05 22:48
どっちも低いのかよ
244 ：デフォルトの名無しさん：03/11/05 22:49
>>241
面白い/つまらない とか言う奴のコードは独りよがりで読み難い事が多いのだが…
245 ：デフォルトの名無しさん：03/11/05 22:52
>>242
いまさら IQ 言われてもねぇ…
246 ：デフォルトの名無しさん：03/11/05 23:00
>>239　は確実にC++やってない厨ですね。やってても初心者どまり。
247 ：デフォルトの名無しさん：03/11/05 23:08
面白くも無い言語を使っているなら奴隷と変わりませんね
248 ：デフォルトの名無しさん：03/11/05 23:15
>>247
面白い/つまらない ってのは個人でも時々によって変わるし。

今は C++ は面白い、と感じていても
いつ C++ なんてつまらないと感じるようになるかもしれん。
249 ：デフォルトの名無しさん：03/11/05 23:18
>>247
作っているモノが面白いのならともかく、
使ってる言語が面白いってのは、それほど重要じゃないと思うが。
250 ：デフォルトの名無しさん：03/11/05 23:26
なんかJavaってそそられないのよね。なんか。
251 ：デフォルトの名無しさん：03/11/05 23:40
>>248
少なくとも現状のJavaはC++よりもつまらない事は同意してるのか？
Javaはまだ言語仕様ガリガリ変わるだろう(C#とタメ張りつづけるには変わらないとどーにもならん)から
わからないけどな。
AspectJとかは現状でもただのJavaよりは面白そうだし。
252 ：デフォルトの名無しさん：03/11/05 23:47
C++でフリーでGUIアプリ作れる環境あったら教えて〜
Javaは無料だからこれまで使ってきたが、C++も無料で色々出来るならやってみたい
253 ：デフォルトの名無しさん：03/11/05 23:50
フリーのコンパイラもフリーのGUIライブラリもあるがこのスレにはあまり関係無いな
254 ：デフォルトの名無しさん：03/11/06 00:47
>>242
> Java使いの平均IQ…95
> C++使いの平均IQ…110
C++とやらが実はC厨でC++厨の仮面を被っていることを
想定するなら
C++厨の平均IQは50以下だな。
Java厨とやらがJ2EEやネットワーキングなどを理解していなければ
同様かもしれないが。
255 ：デフォルトの名無しさん：03/11/06 00:51
>>251
現状のJavaは十分面白いぞ。
Java3Dで遊んでみるのもよし。
Beanで組み立てて遊んでみるのもよし。
さらにJakarta ProjectのJavaフレームワークを使い倒す楽しみがある。
サーバ構築するついでにJavaアプリケーションサーバも立ち上げて
DBアクセスを考慮してオリジナルな掲示板やWebメールを作ったりと
楽しみが満載だぞ。
256 ：デフォルトの名無しさん：03/11/06 02:01
>>254
平均 IQ が 50 以下って全然現実味ないんだけど。

まぁ >>242 も根拠なんぞないだろうし。
IQ なんて何測ってるかもハッキリしないようなもんで勝負しても意味ないし。
257 ：デフォルトの名無しさん：03/11/06 02:05
>>251
>>248 は言語が面白い/つまらない、には意味は無いって話なので

> 少なくとも現状のJavaはC++よりもつまらない事は同意してるのか？

には同意も否定もしません。
258 ：デフォルトの名無しさん：03/11/06 09:07
Javaなんて必要ない。
perlにしとけ。
259 ：デフォルトの名無しさん：03/11/06 12:56
なんだ、C++じゃないのか
よりにもよってまたマ板で暴れていたPerl厨がこんなスレにまできて暴れてるのか
260 ：デフォルトの名無しさん：03/11/06 20:16
>>254
>C++とやらが実はC厨でC++厨の仮面を被っていることを
>想定するなら
>C++厨の平均IQは50以下だな。

今、254がいいこと言った！
問題はC厨なんだよ。C++厨もJava厨も仲間。

しかし、C厨もいれて平均IQが110とすると、
純粋C++厨のIQは200くらいか？
261 ：デフォルトの名無しさん：03/11/06 22:29
>>260
えーと、IQ の標準偏差が 20 と仮定すると
(知能検査は標準偏差20ぐらいになるように構成するのが多いため)
IQ 200 以上の人間の確率は 0.00002867% 程度。
日本人が 1億2千万人として、IQ 200以上は 34人程度。
平均 IQ が 200ってことなので、IQ 200以下がIQ 200以上と同数いると考えると
純粋C++厨とやらは日本に70人程しか居ない、と。
262 ：デフォルトの名無しさん：03/11/06 22:34
>>260
ちなみに、IQ の標準偏差が 15 と仮定すると
日本には純粋C++厨とやらは 一人もいないだろうと思われる。
263 ：デフォルトの名無しさん：03/11/06 22:35
頭のいい奴が生まれるのって確率の問題なの？血筋ちゃうの？
264 ：デフォルトの名無しさん：03/11/06 22:40
>>263
IQが高い ≠ 頭がいい

っつか、「頭がいい」は数値化して評価できないと思うけど…
265 ：デフォルトの名無しさん：03/11/07 11:20
>>261
>純粋C++厨とやらは日本に70人程しか居ない、と。

そんなもんだろ。ｗ
俺はそのうちの一人ですが、なにか？
266 ：デフォルトの名無しさん：03/11/07 11:58
>>241
Javaでは実装しない多重継承ならできるが。
それとも実装多重継承に頼りたいのか？
実装多重継承などという愚かなことをするのはやめれ。
テンプレートのそんなことをするためにあるものじゃない。
267 ：デフォルトの名無しさん：03/11/07 12:02
>>263-264

そういえば
「EQ こころの知能指数」
という本があったなw
EQ Emotional Quotient
IQが高くても社会で成功するとは限らないという話。


もうひとつのEQの略として教育指数(educational quotient)というのもあったなw
268 ：デフォルトの名無しさん：03/11/07 12:02
>>265
> >>261
> >純粋C++厨とやらは日本に70人程しか居ない、と。
> そんなもんだろ。ｗ
> 俺はそのうちの一人ですが、なにか？
では、その証拠を示してみてくれ。
269 ：デフォルトの名無しさん：03/11/07 12:10
>>265
>>261 のは間違い。標準偏差は高くても 15ぐらいのが多い。
IQ 200 以上は日本に一人もいない可能性が非常に高いため、
純粋C++厨は日本に一人もいないと考えるのが妥当。

ってのを考えれば、まぁそんなもんかなと思うね。
270 ：デフォルトの名無しさん：03/11/07 12:16
>>267
>実装多重継承などという愚かなことをするのはやめれ

できるけどやらない、っていうのは少なくとも賢そうに見えないこともないけど、
Java 厨の場合出来ないくせに、愚かだからやめれって人に指図するあたりが
（本当のところはどうであれ）バカそうに見えちゃうんだよなぁ。。。
271 ：デフォルトの名無しさん：03/11/07 12:25
>>269
必死に他人を馬鹿にしようという態度が(以下略)
272 ：デフォルトの名無しさん：03/11/07 12:28
>>267
「EQ こころの知能指数」は読んだか？
著者は EQ を IQ のように安易に数値化するのを厳しく戒めていたが。
273 ：関係ないが：03/11/07 12:36
オブジェクト指向的な情報隠蔽もろくに理解できていない奴が、
「boostが」「lokiが」と得意満面でテンプレートについて語って
いることに気がついた秋の昼時。
274 ：デフォルトの名無しさん：03/11/07 12:43
テンプレート語るのにオブジェクト指向は直接的な関係は無いもの
275 ：デフォルトの名無しさん：03/11/07 14:47
>>270
はてそれはどうかな。ポインタ演算と勘違いしていないかなw

C++厨の場合はスパゲティコードを書いてわざと暗号のように汚いコードを量産して
チームのことを考えずに独りよがりなコードかいて、
Facadeパターンのひとつでも簡単に覚えられることをやろうとせず
自分の得意分野が限られているくせに自分の立場を守ろうと保守的になって
わざと自分だけにわかるように書いてついでに無駄なイースターエッグまで埋め込み
パターンのひとつやその類似すら使わないのは
アージャイル開発では馬鹿そうに見えちゃんだよなな。。。
276 ：デフォルトの名無しさん：03/11/07 14:48
>>272
読んだよ。抽象的なものほど数値化したところで正確な答えは得られないことは
カオス理論に囲まれた自然界でも常識でしょ。
277 ：270：03/11/07 14:56
>>275
「はてそれはどうかな」と言われても困るけど、後半は同意。
でもなんとなくJava厨って、Java に実装継承があったらあったで嬉々として
実装継承を用いてこんなパターンが、とか語りだしそうなイメージあるんだよなぁ。。。
印象批判だけど。

まぁそれでも Java だと他人がきれいに整備したフレームワークに則ってちょっとだけ
ロジックを書くっていう仕事が大半だから、コードの可読性と保守性は高く保たれるとは思う。
278 ：270：03/11/07 15:00
･･････「実装の多重継承」ね
279 ：デフォルトの名無しさん：03/11/07 18:15
結局はこのスレで評判の悪い方が普及すると思われ。
この辺の事情はi8086ｖｓMC68000の頃から変わっていない。
280 ：デフォルトの名無しさん：03/11/07 23:53
まさかとは思うが、>>277はJavaに実装単一継承がないと思い込んでいたのだろうか？
おいおい！

それではテンプレートメソッドパターンですら実装できないではないか！

とツッコミ
281 ：デフォルトの名無しさん：03/11/08 00:01
このスレは誰もポリシーベーステンプレートメタプログラミング分かってないな。
282 ：デフォルトの名無しさん：03/11/08 00:02
言語のスレで何故に設計手法
283 ：デフォルトの名無しさん：03/11/08 01:19
Javaのswingラクでいいわ。ホント。
テンプレートがないこととあのもっさりだけが問題。
あとIntegerクラスとアトムのintegerってのが不細工。
284 ：デフォルトの名無しさん：03/11/08 01:29
>>239=266=275 か？
典型的なjava厨だな。

あとjava厨の言い訳にC++厨の大半はC厨みたいなこと
言う奴がいるが、それはjava厨がC++厨より劣ることを
認めているようなものだな。
285 ：デフォルトの名無しさん：03/11/08 01:55
正直C++で作られたJavaがC++より上である道理がない。
286 ：デフォルトの名無しさん：03/11/08 02:38
>>284
されどそんなJava厨に勝るC++厨はほとんどいないという現実。
君はC++をフルに使いこなせるか？
287 ：デフォルトの名無しさん：03/11/08 02:38
>>285
そういうのを宗教戦争的発言という
288 ：デフォルトの名無しさん：03/11/08 02:46
>>285
それは、「親から生まれた子供は親より上である道理がない」ってのと同じだね。

C++ 厨の頭が悪いというイメージを植えつけようという Java 厨の陰謀か？
289 ：デフォルトの名無しさん：03/11/08 03:14
Java厨ってさ、誰かが言った事を鵜呑みにしちゃうのが多いだろってのが最近の感想。

・スパゲッティ
・C++厨の大半はC厨

最近どのスレみてもこればっか。
どれだけのJava厨が本当の↑に遭遇したの？
JavaとC++は適応分野が大分異なるから、そんなにC/C++と競合する仕事してるとは思えない。

大体本当にそうならば相手間違ってるって事にも気づいてない。
相手は * C++使えるふりをしているC厨 * だろうが。
パターン名とかを無駄に振りかざすレベルの奴にC++使いを馬鹿にされると正直ムカツク。

パターン名を無駄に振りかざすってのはもちろん過去の自分と照らし合わせてレベルを推し量っての事だ。
まともなC++使いは少なくともOOPにおいてもJava厨よりも習熟度が高い。
290 ：デフォルトの名無しさん：03/11/08 03:27
>>288-289
陰謀？　お前被害妄想でかすぎ。
Java厨の頭が悪いというイメージを植えつけようと必死になっているC++厨だってねえ・・・

そりゃあんた、死に物狂いで頑張ってきたCOBOLerやアセンブラ厨が
COBOLやアセンブラよりも新しい言語のC厨をむかつくといっているのと同じレベルだよ
291 ：デフォルトの名無しさん：03/11/08 03:28
>>289
> ・C++厨の大半はC厨
これ言ってるのは C++使いじゃないかと思ってたよ。
自分は C++使いの中でも特別だと思い込んで、自分は IQ 200 とか言ってた奴も居たし。

> まともなC++使いは少なくともOOPにおいてもJava厨よりも習熟度が高い。
(一般論としては)全く根拠の無い事を(一般論として)言われても…

「Java厨よりもOOPにおいて習熟度が低いC++使い」は「まともなC++使い」ではないって可能性もあるし…
292 ：デフォルトの名無しさん：03/11/08 03:37
結局宗教戦争だわな。

香ばしい>289が現れて今夜はここでお開きと。
さあて、寝るか。
293 ：デフォルトの名無しさん：03/11/08 09:45
香ばしいアホアンチと宗教戦争なんてしても無駄。
なにせこいつはPerlで挫折した男なんだから。
さらにCもほんのちょっとしか出来ない。
gccでコンパイルの仕方も知らない厨房だから真面目に相手しても無駄だよ。
宗教戦争に見せかけてるけど、実はコンプレックスの裏返しだよ。
294 ：デフォルトの名無しさん：03/11/08 09:52
ところでJavaの人が自分たちのものみたいにいうデザインパターン本に
Javaのコードって1行もでてこないよね
295 ：Java厨ではないが：03/11/08 09:55
C++スレでクラスをただの２次元配列として設計し、
アクセスを簡便にするためにテンプレートを使うという
C++厨を見た時にC++厨の実力を悟りました。
オブジェクト指向の基礎的なことも理解できていない
くせに「テンプレートメタプログラミング」が最新の
テクニックだ、と勘違いして鼻高々なバカばかり。
テンプレートを使うテクニックのいくつかは、
型付けの弱い言語では必要ないし、Lisperから
見れば、poor man's macroでpoor man's closureを
作っているだけにしか見えないようなテクをありがたがっている。
つまりC++だからこそ「無駄に」必要なテクニックであることを
知らないC++厨は視野が実に狭い。
馬鹿にされて当然だろう。
296 ：デフォルトの名無しさん：03/11/08 09:59
>>295
どんなコード？
あと大勢いる中の低い部分だけをとりあげて全体を判断するのはおろかなことだな。

＞テンプレートを使うテクニックのいくつかは、
＞型付けの弱い言語では必要ないし、

これはひっくり返して言えば？
297 ：デフォルトの名無しさん：03/11/08 10:01
GoFのデザパタ本のサンプルはC++とSmalltalkで書かれているが、
Smalltalkで簡単に解決できることをC++では手間がかかるという
ことがよくわかる内容だった記憶がありますが何か？
298 ：デフォルトの名無しさん：03/11/08 10:25
>>295
なんとなくテンプレートメタプログラミングを誤解している悪寒
299 ：デフォルトの名無しさん：03/11/08 11:20
>>295
>オブジェクト指向の基礎的なことも理解できていない
>くせに「テンプレートメタプログラミング」が最新の
>テクニックだ、と勘違いして鼻高々なバカばかり。

テンプレートメタプログラミングの基礎的なことも理解できていない
くせに「オブジェクト指向」なんて関係無いものを勘違いして鼻高々なバカばかり。
300 ：デフォルトの名無しさん：03/11/08 14:13
テンプレートメタプログラミング厨の集うスレはここですか？
301 ：デフォルトの名無しさん：03/11/08 18:58
>>284
少なくとも文法は一通り知ってますが何か？
iostream、STL、boost等一通り使えますが何か？
まあ、それでも極めた気にならんような奥の深さが
魅力なのだが。

>>295
>オブジェクト指向の基礎的なことも理解できていない
なんて何で言い切れるん？
C++にとってクラスや継承なんかは所詮、言語が
持つ表現方法の一つに過ぎん。導入した目的が
オブジェクト指向サポートだったとしても、他の目的に
それを使用してはいけない道理はないだろう？
302 ：デフォルトの名無しさん：03/11/08 20:21
>>301
> C++にとってクラスや継承なんかは所詮、言語が
> 持つ表現方法の一つに過ぎん。
C++ は表現の幅が広い。Java は表現の幅が狭い。

複数人のプロジェクトの場合は
表現の統一ができた方が保守性が上がるので
表現の幅が狭い方が良い。


> 導入した目的がオブジェクト指向サポートだったとしても、
> 他の目的にそれを使用してはいけない道理はないだろう？
大多数の間でクラスや継承はオブジェクト指向サポートのために使う、
という合意ができている場合、それを他の目的に使用した場合
誤解の生じやすいコードになる可能性が非常に高い。

特別な理由でもない限り目的外の使用は止めた方が良いと思われ。
303 ：デフォルトの名無しさん：03/11/08 20:37
表現の幅が狭い方が良いならbasicでも使ってろ
304 ：デフォルトの名無しさん：03/11/08 21:06
C++しか知らなくて最近javaかじりはじめたんだけど、かなり新鮮だな。
演算子オーバーロードがなくてInteger+Integerも計算できないとか､
漏れからするとかなり(ﾟДﾟ)ﾊｧ?って感じなんだが。
そのくせStringは+演算子使えるし。よくワカンネ(´д｀)
305 ：デフォルトの名無しさん：03/11/08 21:44
とりあえず、ヘマしても落ちないjavaがｲｲ！
306 ：デフォルトの名無しさん：03/11/08 21:53
>>304
> 演算子オーバーロードがなくてInteger+Integerも計算できないとか､
C++ の iostream みたいに演算子のオーバーロード使われるよりは
演算子のオーバーロードなんぞ無い方がマシ、って考え方もあるので。

> そのくせStringは+演算子使えるし。よくワカンネ(´д｀)
頭が硬くなってきてるんじゃない？
ちなみに、String だと + 演算子が使えるんじゃなくて
+ 演算子の左右のオペランドの何れかが String だと
+ が文字列連結演算子と解釈される。
307 ：デフォルトの名無しさん：03/11/08 22:12
>>306

>C++ の iostream みたいに演算子のオーバーロード使われるよりは
>演算子のオーバーロードなんぞ無い方がマシ、って考え方もあるので。

頭が硬くなってきてるんじゃない？

308 ：デフォルトの名無しさん：03/11/08 22:39
>>307
個人が「 ** がワカンネ(´д｀)」って事なら個人の資質が問題になる。

演算子のオーバーロードはが要らんってのは
多人数での開発の際に起こりうる問題を未然に防ぐのが目的だから
個人の資質がどーこーという問題ではない。
309 ：デフォルトの名無しさん：03/11/08 23:18
>>294
> ところでJavaの人が自分たちのものみたいにいうデザインパターン本に
> Javaのコードって1行もでてこないよね
理解してJavaに適用するにはそれでもほとんど困らないんだけどなあ。
310 ：デフォルトの名無しさん：03/11/08 23:20
>>302
> >>301
> > C++にとってクラスや継承なんかは所詮、言語が
> > 持つ表現方法の一つに過ぎん。
> C++ は表現の幅が広い。Java は表現の幅が狭い。
既存のクラスライブラリやフレームワークの整備によっては
表現の幅が狭いかどうかは微妙だな。
JavaのAPIはまさに増えてきている。
C++にはないさまざまなAPIが用意されオブジェクト指向レベルでは表現の幅は広い。

311 ：デフォルトの名無しさん：03/11/08 23:24
>>304
> C++しか知らなくて最近javaかじりはじめたんだけど、かなり新鮮だな。
> 演算子オーバーロードがなくてInteger+Integerも計算できないとか､
> 漏れからするとかなり(ﾟДﾟ)ﾊｧ?って感じなんだが。
そういうあなたにはC#がお似合い。
Javaの場合は危険性を最小限におさえようとしているわけで。
C#の場合は危険性や拡張性よりも即座に使えるという利便性を追求しているのが
C#とJavaとのアプローチの違い。
312 ：デフォルトの名無しさん ：03/11/08 23:32
>>305
>>とりあえず、ヘマしても落ちないjavaがｲｲ！
ん〜、それはどうだろう。
間違えたコードを書いてしまったのなら
とっととアプリが死んでくれた方がバグの早期発見に繋がると思うんだが。。。
313 ：デフォルトの名無しさん：03/11/08 23:33
>>302
そうか？無理やりオブジェクト指向の枠にはめるのも
どうかと思うが。なんか、その発想だと新しいこと（表現）
やろうとする度に、言語なりライブラリを拡張せにゃ
あかんような気がするが。

100の事をやるのに100の知識を覚えなきゃならん、みたいな。
314 ：デフォルトの名無しさん：03/11/08 23:34
まあどっちでもいいんだが、
C++だけ/Javaだけ しかわからない
ってのはどうもプログラマ失格だと思うよ
両方使えなきゃ
315 ：デフォルトの名無しさん：03/11/08 23:36
>>310
C++のAPIはまさに増えてきている。
JavaにはないさまざまなAPIが用意されオブジェクト指向のみならず色々な表現の幅は広い。
316 ：デフォルトの名無しさん：03/11/08 23:37
C++の「API」は処理系依存が多いしー。
標準ライブラリはJavaに比較するとショボイわけよ。
317 ：デフォルトの名無しさん：03/11/08 23:37
演算子オーバーロードのナニが危険なのかわかんねぇ
318 ：デフォルトの名無しさん：03/11/08 23:40
>>312
>>305のいっている落ちないは大げさだということには同意。
だがそれだけJavaは堅牢なことも事実。

>>313
100のクラスがあるからといって100のクラスを覚えないといけないことはないぞ。
JavaのAPIには有名なデザインパターンを上手に使ったフレームワークが数多くあるなら
それらのパターンなどを知っていると把握しやすい。

しかも、あることをやるためにすべてのことを覚えないといけないというNRI症候群に
陥る必要も無い(むしろ全部お終えられたら神！というか人生の無駄っつーのもあるわけだし)。

そのためのオブジェクト指向なわけだから。
319 ：デフォルトの名無しさん：03/11/08 23:41
>>313
> 100の事をやるのに100の知識を覚えなきゃならん、みたいな。
そーじゃなくて、
10人が全員 10 の事を覚えるのよりは
10人が全員 5 の事を覚える方が簡単だし
ルールも徹底しやすいって事。
320 ：デフォルトの名無しさん：03/11/08 23:44
>>315
鸚鵡返しは見苦しいぞ。
C++の場合はAPIというかライブラリが膨大な聖書のように乱立しているようなもんだ。
Cから受け継がれたオブジェクト指向を無視したAPI群も多く酷い。

オブジェクト指向をなめとんのか、といえるものといえば
とくにVC++のWin32 API
あれはひどい。
次期VC++.NETはAPI以外でももっと酷い。あれはC++じゃない。
M$が独自拡張した有史以来の穢れたC++だ

321 ：デフォルトの名無しさん：03/11/08 23:46
>>317
iostream みたいに俺ルールで演算子のオーバーロードを使いまくると、
とあるクラスで演算子がどーゆー意味で使われてるのか即座に理解できなくなる。
322 ：デフォルトの名無しさん：03/11/08 23:46
>>317
> 演算子オーバーロードのナニが危険なのかわかんねぇ
コードの可読性というものを理解したことがあるかね？
使っている本人だけは使いやすくても他人にはソースコードをよみにくくしている結果をもたらす
ことが多いのだよ。


323 ：デフォルトの名無しさん：03/11/08 23:53
演算子のオーバーロードを行うとどのようにオーバロードされているかを
理解させるためにソースコードを公開するか、
またはしっかりとしたコメントをかかないといけない。

しかしコメントにかいていることが本当にただしいことなのかを
人間が確認するのは限界がある。
ソースコードを公開すれば少しは信頼性も高まる。
またテストケースを作ったり、より多くの人につかってもらえば信頼性も高まる。

(話はそれるが)
だが、所詮人間は機械よりも信用できない。
人間よりもコンパイラのほうが信用できる。
信頼性という観点ではJavaのほうが有力。
324 ：デフォルトの名無しさん：03/11/08 23:56
おまいらC++厨よ！
Java厨に馬鹿にされたくなかったらJava的C++コンパイラを作れ！
グローバル関数を作ったらC++コンパイラがC++厨に
「おまいはC++厨の癖にアンチOO厨か？」と文句を言ってコンパイルを中止させる。

グローバル変数を作ったらC++コンパイラがC++厨に
「おまいはCOBOLerか？」と文句をいってコンパイルを中止させる。

実装多重継承をするとコンパイラが「おまいはチーム開発をなめとんのかｺﾞﾙｧ！　たとえ一人でも過去の自分は別人扱いだｺﾞﾙｧ！」とC++厨に文句をいってコンパイルを中止させる。

配列でサイズよりも大きいインデックスを参照するときも
コンパイラがC++厨に
「おまいはｽﾊﾟｹﾞﾃｨ屋かｺﾞﾙｧ！」
と文句を言ってコンパイルを中止させる。


この夢のコンパイラを作りこのJava的コンパイラを使ってC++を極めましたといえば
おまいらはJava厨に馬鹿にもされず誇り高き偉大なるC++厨として胸を張ってIT業界を歩けるぞ！

これでおまいらC++厨は過去の栄光を取り戻しC++帝國を復活させることができるぞ♪

おまいらC++厨よ、とにかくJavaライクなC++コンパイラを作れ。
325 ：デフォルトの名無しさん：03/11/08 23:57
そんなコンパイラがあったらD言語もいらなくなりそう
326 ：デフォルトの名無しさん：03/11/08 23:59
>>320
オウム返しされるようなことを書くからそうなる
327 ：デフォルトの名無しさん：03/11/08 23:59
オブジェクト指向をしっかりと学び
しっかりと安全に設計すればオブジェクト指向言語を避け
Cに逃げるということもないだろう。

しかしC++では限界かなw
Javaくらいだったら堅牢性が高く、コンパイラがいちいちうるさく文句をいうため
プログラマは真剣になる。

さらに多くのクラスライブラリがオブジェクト指向を知らないとどうにもならないため
積極的にオブジェクト指向を学ぼう必然的に必死になる。

さらに、クラスなどの名前が覚えやすいのもJavaの特徴。
クラス名が名詞、メソッド名が動詞になっているため覚えやすい。
それらの中には見覚えのあるデザインパターンが使われているものがあり、
デザインパターンのサンプルクラスとまったく同じ名前のクラス
(例 : Observer ,Iterator　など)がよくありそんなデザインパターンを駆使したJava Core APIに感動する。
よくできたつくりになっていると。そしてそれがさらにJavaを使いこなそうという気を起こさせる。
328 ：デフォルトの名無しさん：03/11/09 00:00
>>326
反駁できないからオウム審理狂といわれる、
329 ：デフォルトの名無しさん：03/11/09 00:02
ここでも蛇罵統一教会が壷売りに来てるのか
330 ：デフォルトの名無しさん：03/11/09 00:04
2chのトップページに壷画像を貼り付けられ馬鹿にされているにもかかわらず
VC++統一教会はまだ「ひろゆきは壷売り」だといっているのか。
331 ：デフォルトの名無しさん：03/11/09 00:05
>演算子のオーバーロードを行うとどのようにオーバロードされているかを
>理解させるためにソースコードを公開するか、
「プログラムの仕組みの分り易さ」に注目すればそうだろうけど、
「仕様の分り易さ」に注目するとどういう計算式を使ってるか見やすい
オーバーロードっで有効なんだよ。
この手の仕組みはソースから全体像を追いやすくなるんだよ。
ここで集合の積を取ってるなぁとか。
逆にプログラム的な仕掛けが見難くなるがそれはスキルの問題。
332 ：デフォルトの名無しさん：03/11/09 00:05
C#には勝てそうにもないからC++叩きに来ますた
333 ：デフォルトの名無しさん：03/11/09 00:06
>>320
>Cから受け継がれたオブジェクト指向
ﾊｧ？

>>321
Stringはいいんだ？

>>322
a.add(1).sub(2) と a+1-2　どっちが読みやすい？

>>323
ﾊﾞｶ？普通のメソッドでもどう動作するかはソースを公開するかコメント付けるしかないだろ




334 ：デフォルトの名無しさん：03/11/09 00:09
>>320はあんまり口をあけない方がいい。ﾊﾞｶが他人に移るから。
335 ：デフォルトの名無しさん：03/11/09 00:10
>>333
> Stringはいいんだ？
String で +演算子だけだし、
文字列を + で結合するって文法は他の言語でもよく使われている。
演算子のオーバーロードを禁止するのはあくまで乱用を防ぐためなので
String だけ、とか制限されていれば それほど問題はない。

ひとつ言うと String は演算子のオーバーロードしてない。
336 ：デフォルトの名無しさん：03/11/09 00:14
>>333
> >>320
> >Cから受け継がれたオブジェクト指向
> ﾊｧ？
こうやって句読点を打とう
Cから受け継がれた、オブジェクト指向
337 ：デフォルトの名無しさん：03/11/09 00:15
>>333
> a.add(1).sub(2) と a+1-2　どっちが読みやすい？
+ や - がどのような副作用を引き起こすのかによる。

「a+1-2」だと読みやすいけど、副作用があった時に気づくのが遅れる可能性が高くなる。
338 ：デフォルトの名無しさん：03/11/09 00:15
>>333
> >>320
> >Cから受け継がれたオブジェクト指向
> ﾊｧ？
>
> >>321
> Stringはいいんだ？
>
> >>322
> a.add(1).sub(2) と a+1-2　どっちが読みやすい？
勝手なオーバーロードがないことが明白なら後者のほうが見やすいが

+, -演算子の定義をだれかが勝手に書き換えた疑いがあるなら

a.add(1).sub(2)

のほうが見やすいな。
339 ：デフォルトの名無しさん：03/11/09 00:17
>>333
> >>323
> ﾊﾞｶ？普通のメソッドでもどう動作するかはソースを公開するかコメント付けるしかないだろ
ある程度の勝手な型変換や
配列のバッファーオーバーフローがおこるかどうかは言語仕様によっては
気にしなくてすむということがあるわけだ。
340 ：デフォルトの名無しさん：03/11/09 00:18
>>334
そんなオウム君なあなたには理解できないことだったのですね
341 ：デフォルトの名無しさん：03/11/09 00:19
>>333
> Stringはいいんだ？
JavaではStringの+演算子の自前での オレ様オーバーローディングはできないわけだが。
よってさほどの危険性はないわけだ。
342 ：デフォルトの名無しさん：03/11/09 00:20
精神病院にいる患者の言うことは理解出来ないし、理解出来なくても構わない。それと一緒。
343 ：デフォルトの名無しさん：03/11/09 00:22
演算子のオーバーロードって微妙だよね
boost::spirit (参考:http://boost.cppll.jp/HEAD/libs/spirit/index.html)とかを見ていると、これを演算子のオーバーロードなしで書くと
可読性が上がるどころか大幅低下を起こすし、他にもベクトル行列演算などにも言えるね
A * ( B + C ) == A * B + A * C
と、演算子のオーバーロードによって記述してあればすぐに気づくものだけれども
これが
matrix.mul( A , matrix.add( B , C ) )
などと書かれていた日には、式の整理困難間違いなし
適当にオーバーロードすると確かに問題を起こすけれども適切に使えば効果は上がる事は確か。
むやみには使えないが、これを否定するのは手が痒いといっているのに、ならば腕を切り落とせと言っているようにも思う。
344 ：デフォルトの名無しさん：03/11/09 00:24
>>338
>+, -演算子の定義をだれかが勝手に書き換えた疑いがあるなら
>a.add(1).sub(2)
>のほうが見やすいな。

ﾊｧ？a.addの定義を勝手に書き換えられる疑いは無いんか？
345 ：デフォルトの名無しさん：03/11/09 00:26
>>342
脳内変換で現実から逃げるC++厨(ﾌﾟ
技術的な話題ができず反論もできなくなるとこういう誹謗中傷しかできないのが
C++厨(本当はCしかできない間抜けなC厨)の特徴。
346 ：デフォルトの名無しさん：03/11/09 00:28
>>344
それはね、「どういう処理をしているか」と言う点について見通しがいいんだけれども
「何を意味しているのか」という点については見通しがとても悪いんですよ。
プログラムで重要なことは、「何を意味しているのか」という点も非常に大きなウエイトを持っていると思うんで。
347 ：デフォルトの名無しさん：03/11/09 00:29
>>344
定義が重複するならひとつで十分。
名前が違うだけで機能が同じ関数をつくるのは
eXtreme Programmingでは無駄とされるように、
名前が違うだけで機能が関数と同じ演算子を定義するのは無駄
になる可能性が大きいというリスクを背負う。
348 ：デフォルトの名無しさん：03/11/09 00:30
>>345
さっきから反論してんだけど？今時(ﾌﾟ ってナニ？精神病院では今頃はやってんの？
349 ：デフォルトの名無しさん：03/11/09 00:31
>>346
a + bはaとbを足してるという意味ですよ

>>347
話がかみ合ってない気がする
350 ：デフォルトの名無しさん：03/11/09 00:32
要はJAVA厨はポインタ分かりませんということか
351 ：デフォルトの名無しさん：03/11/09 00:34
>>347
>定義が重複するならひとつで十分。

じゃあa + bだけでいいよ
352 ：デフォルトの名無しさん：03/11/09 00:36
>>350
ポインタ理解できなくて馬鹿にされた事でもあるのか？
353 ：デフォルトの名無しさん：03/11/09 00:40
a + bがナニを意味してるかわかりにくいという奴は、小学生からやり直した方がいいよ
354 ：デフォルトの名無しさん：03/11/09 00:47
>>353
a + b は何を意味しているか一目瞭然だが、
a + b が どのように処理されるかは一目瞭然ではない。
このギャップが不注意な操作につながる危険性がある。
355 ：デフォルトの名無しさん：03/11/09 00:48
>>343
> 演算子のオーバーロードって微妙だよね
> boost::spirit (参考:http://boost.cppll.jp/HEAD/libs/spirit/index.html)とかを見ていると、これを演算子のオーバーロードなしで書くと
> 可読性が上がるどころか大幅低下を起こすし、他にもベクトル行列演算などにも言えるね
> A * ( B + C ) == A * B + A * C
> と、演算子のオーバーロードによって記述してあればすぐに気づくものだけれども
> これが
> matrix.mul( A , matrix.add( B , C ) )
> などと書かれていた日には、式の整理困難間違いなし
はてそれはどうだろうか。
オーバーロードしない利点もそれなりにある。

行列A, Bがあるとき
A×B とB×Aとはまったく違うことは知っておろう。
また、これが行列の個々の要素同士の積ではないことは知っておろう。
そこで*を行列同士の積とみなしてオーバーロードするか、
行列の個々の要素同士の積とみなしてオーバーロードするかの定義でもめる。
MATLABでは個々の要素を掛けるときは *の代わりに .*という演算子で区別している。
しかしC++では演算子のオーバーロードでは独自の演算子をつくることができないという欠点を抱えている。
苦肉の策をつかって限られた演算子を定義するのも混乱の元となるのである。

そうなると
(a*b)->times(c)とかくより
やはり
a.multiply(b).times(c)のようにメソッドを使った方が読みやすいことになる例が多々あるのだ。
356 ：デフォルトの名無しさん：03/11/09 00:49
>>350
ポインタがわからなかったらJavaすらできないわけだが。
Javaはポインタが無ければプログラミングすらできないことも知らないのか。
357 ：デフォルトの名無しさん：03/11/09 00:51
>>354
a.add(b)もどのように処理されるか一目瞭然ではないだろ。
358 ：デフォルトの名無しさん：03/11/09 00:51
>>355
二項演算は、その記号よりも中置することに意味があると思うのですが如何でしょうか。
359 ：デフォルトの名無しさん：03/11/09 00:52
ワザトa.add(b)で意味を分かりにくくしてギャップを埋めるとか言ったら馬鹿扱いしますよ
360 ：デフォルトの名無しさん：03/11/09 00:54
>>357
> a.add(b)もどのように処理されるか一目瞭然ではないだろ。
どのように処理されるか一目瞭然でないのが問題なのではなく、
意味はわかるが、どのように処理されるかはわからない、というギャップが大きいのが問題。

a.add(b) の方が a+b よりギャップが少ない。
361 ：デフォルトの名無しさん：03/11/09 00:56
>>355
spiritって精神とか魂という意味だよね？
なんでspiritなの？
362 ：デフォルトの名無しさん：03/11/09 00:57
>>359
馬鹿扱いしてくれて結構だけど、ギャップが大きいのは事実。
ギャップが大きければ危険性が高くなるのも事実。
363 ：デフォルトの名無しさん：03/11/09 00:59
じゃあa + bが意味どおりに実装されればOKでつね
364 ：デフォルトの名無しさん：03/11/09 01:01
>>363
「a+b」がどのように処理されるべき、と感じるかは個々人によって違うので
話はそう簡単ではない。
365 ：デフォルトの名無しさん：03/11/09 01:02
>>364
addがどのように(ry
366 ：デフォルトの名無しさん：03/11/09 01:03
>>365
add の場合はよりギャップが少ないと、さっき書いたんだけど。
367 ：デフォルトの名無しさん：03/11/09 01:03
>>366
俺はそうは思わないんだが
368 ：デフォルトの名無しさん：03/11/09 01:05
端から見てるとどっちも対して変わらないと思うよ
369 ：デフォルトの名無しさん：03/11/09 01:05
>>364
* なら、まあわからなくも無いが+を変な形で定義するのは、バグの時くらいな気もするが・・・
しかし、* にしても、数学屋かそれもどきの人がキテレツな定義を準備するときぐらいだと思うが。
370 ：デフォルトの名無しさん：03/11/09 01:10
メソッドを利用すれば、英数字が使えより適切な名前を付けることができるが、
演算子のオーバーロードではもちろん決められた演算子を使うことが強要される。
処理内容の誤解を招きにくいという点から言えば、
英数字で記述するほうに軍配があがるということだ。
371 ：デフォルトの名無しさん：03/11/09 01:10
Stringだって + で連結するのか、それとも個々の要素を足すのかわからんよね。
でもそれを受け入れてる。それはなんでやって話ですよ。
372 ：デフォルトの名無しさん：03/11/09 01:14
>>371
> Stringだって + で連結するのか、それとも個々の要素を足すのかわからんよね。
そーゆー解釈をする人は見たことがないけど。
Javaで言えば "ab" == "a" + "b" が true なのに
"ab" == new String("a") + "b" が false になるってところで躓く人はよくいる。
そーゆー話。
373 ：デフォルトの名無しさん：03/11/09 01:15
ぶっちゃけおまいらJavaが演算子オーバーロードをサポートしていたら、演算子オーバーロードできるのを非難しなかっただろ？

その証拠はStringには何も文句をいわないことだよ。
374 ：デフォルトの名無しさん：03/11/09 01:17
>>371
> でもそれを受け入れてる。それはなんでやって話ですよ。
結構な人が躓く。けど乗り越えてるだけの話。

演算子のオーバーロードができると、躓く箇所が増える。
375 ：デフォルトの名無しさん：03/11/09 01:17
>>372
>そーゆー解釈をする人は見たことがないけど。

そーゆー解釈をする人を危惧して、文字列連結演算子が　..　とか & とかなってる言語を動思う？
376 ：デフォルトの名無しさん：03/11/09 01:18
>>375
.じゃなくて？
377 ：デフォルトの名無しさん：03/11/09 01:18
>>371
> ぶっちゃけおまいらJavaが演算子オーバーロードをサポートしていたら、演算子オーバーロードできるのを非難しなかっただろ？
そんな妄想の話をされても…

> その証拠はStringには何も文句をいわないことだよ。
証拠にはならんね。
String は演算子のオーバーロードをしていないので。
378 ：デフォルトの名無しさん：03/11/09 01:22
>>375
> そーゆー解釈をする人を危惧して、文字列連結演算子が　..　とか & とかなってる言語を動思う？
なるほど、と思う。
379 ：デフォルトの名無しさん：03/11/09 01:23
型のない言語で数値と見なして足すのか文字列を連結するのかはっきりさせるためでは
380 ：デフォルトの名無しさん：03/11/09 01:25
Stringの +　も非難すべきだよね
381 ：デフォルトの名無しさん：03/11/09 01:27
演算子のオーバーロードが欲しいと思うこともたまにはある。
角度とか。
382 ：デフォルトの名無しさん：03/11/09 01:27
>>380
なんで？
383 ：デフォルトの名無しさん：03/11/09 01:29
>>348
> >>345
> さっきから反論してんだけど？今時(ﾌﾟ ってナニ？精神病院では今頃はやってんの？

こんなこと書いている香具師が技術的に反論？　↓

>>342
> 精神病院にいる患者の言うことは理解出来ないし、理解出来なくても構わない。それと一緒。

C++厨はもはや誹謗中傷と人格攻撃しかできなくなったな。
これだからC++厨は過去の栄光におぼれてジジイCOBOLerと同格呼ばわりされるんだよ。
とりあえずさらしあげておこう。さらしあげられることで身の程をよく知ってもらおうか。
384 ：デフォルトの名無しさん：03/11/09 01:31
>>383
なんでその２れすだけだと思う？いいから引っ込んでろよ。
385 ：デフォルトの名無しさん：03/11/09 01:31
結局、どういう処理をしているかという問題が不明確になるリスクが
何を意味しているのかがハッキリする見通しのよさを超えているかどうかの問題って感じだね。
超えていれば、その演算子は不適切で、超えていなければそんなあなたは神経質って事です。
完全排除に踏み切ったJavaは神経質過ぎだろうね、得た物もあるが失った物も多い気がする。
386 ：デフォルトの名無しさん：03/11/09 01:32
383のアホさが晒されてしまった
387 ：デフォルトの名無しさん：03/11/09 01:32
>>373
> ぶっちゃけおまいらJavaが演算子オーバーロードをサポートしていたら、演算子オーバーロードできるのを非難しなかっただろ？
していたよ。

> その証拠はStringには何も文句をいわないことだよ。
おい、まだ理解していないのか。C++やっているくせに脳足りんのか？
JavaのStringの演算子オーバーロードは自作できないんだが。
388 ：デフォルトの名無しさん：03/11/09 01:33
>>372
それは演算子のオーバーロードうんぬんより、
"a" + "b"をコンパイルすると自動的に"ab"に置き換えられるところに
問題があると言った方がいいと思うが。。。
インスタンスの過剰生成を抑えるためか知らんが漏れ的には欠陥かと思うがな
389 ：デフォルトの名無しさん：03/11/09 01:33
>>382

>>354
>>360
>>370
の理由から
390 ：デフォルトの名無しさん：03/11/09 01:34
>>385
> 完全排除に踏み切ったJavaは神経質過ぎだろうね、得た物もあるが失った物も多い気がする。
それをいったらSmalltalkはどうなんだ？
391 ：デフォルトの名無しさん：03/11/09 01:34
なんか、このスレ見ているとC++厨の子供っぽさに失望する
392 ：デフォルトの名無しさん：03/11/09 01:36
>>385
> 結局、どういう処理をしているかという問題が不明確になるリスクが
> 何を意味しているのかがハッキリする見通しのよさを超えているかどうかの問題って感じだね。
それは問題の一つ。

iostream のようなオレ定義の演算子のオーバーロードが多用された場合
何を意味しているのかわからなくなる、という問題がある。
後者の方が大きな問題だろうね。
393 ：デフォルトの名無しさん：03/11/09 01:36
>>390
すもーるとーくはあれで良いんです、オブジェクト指向に対するあくなき追求がポリシーの仙人みたいな言語ですから。
394 ：デフォルトの名無しさん：03/11/09 01:39
>>388
ならばStringBuffer#append()や
String#concat()でも使っていなされ。
Stringの+はPrintStream#println(String)のためにあるようなものだよ。
395 ：デフォルトの名無しさん：03/11/09 01:39
>>391
そのC++厨とかJava厨とかひとくくりにする癖をやめたほうがいい。ガキっぽいからさ。
396 ：デフォルトの名無しさん：03/11/09 01:42
>>394

>定義が重複するならひとつで十分。
>名前が違うだけで機能が同じ関数をつくるのは
>eXtreme Programmingでは無駄とされるように、
>名前が違うだけで機能が関数と同じ演算子を定義するのは無駄
>になる可能性が大きいというリスクを背負う


反してるね。やはりStringは設計がおかしかった。
397 ：デフォルトの名無しさん：03/11/09 01:43
>>392
あれは惜しいと思ってるんですけどね、Loki boost が出てきた今、
再度そのノウハウを使って作り直せば、あのスタイルの演算子オーバーロードでも
かなりよいものになると思うので。
template どころか、まだ、class の概念・仕様すらまともに定まってなかった頃の物にしては悪くないと思うんですがね。
古いものにケチつけても仕方ないです。
そのうち誰かが新規に作って標準化してくれることを期待してます。
398 ：デフォルトの名無しさん：03/11/09 01:45
>>389
文字列連結演算子を非難する人も居るけど、
どっちかというと演算子のオーバーロードを排除するなら徹底しろ、という論調が強いような。
399 ：デフォルトの名無しさん：03/11/09 01:51
>>394
意味が通じていないようだ。
漏れが言いたいのは、
"ab" == new String("a") + "b" が false
"ab" == "a" + "b" は "ab" == "ab" となって true だが、
"ab" == "a" + "b" は "ab" = new String("a") + new String("b") と解釈されてほしいということ。
ちなみに、値と参照の区別はついてるよね？
400 ：デフォルトの名無しさん：03/11/09 01:52
"ab" == "a" + "b" は "ab" = new String("a") + new String("b") と解釈されてほしいということ。
は
"ab" == "a" + "b" は "ab" == new String("a") + new String("b") で false と解釈されてほしいということ。
に読み替えてくれ。スマソ。
401 ：デフォルトの名無しさん：03/11/09 01:53
>>399
Java のプリプロセッサ作るとか、新しい言語作るとかすれば？
402 ：デフォルトの名無しさん：03/11/09 01:55
"a" + "b" が "ab" でなく new String("a") + new String("b") と解釈されてほしい理由を教えてくれ
403 ：java使いTai!：03/11/09 01:57
まあどうせ "a"+"b" が "ab" になるのなら
String s="a" のとき "a" == s が常に真になる
くらいまではやってほしかったとは思う。
(switch文とかも)

演算子のオーバーロード云々ではなく単なる使い勝手の問題だけど
404 ：デフォルトの名無しさん：03/11/09 02:00
>>403
> String s="a" のとき "a" == s が常に真になる
個人的には 「==」 は参照値の比較だ、という規則に例外を作る事になるので要らない。

> (switch文とかも)
個人的にはあんま必要性感じないけど… あった方がいいのかな？
C# にはあったような…
405 ：デフォルトの名無しさん：03/11/09 02:05
Java において連続した文字列リテラルが
コンパイル時にひとつの文字列リテラルにまとめられるのは
仕様なのか？コンパイラの最適化なのか？

>>399
>ちなみに、値と参照の区別はついてるよね？
Java における文字列リテラル ("a" など) は
new String(new char[] { 'a', }).intern() の省略表現。
String#intern() はある意味値を参照に置き換える操作だ。
406 ：java使いTai!：03/11/09 02:06
>>404
まあ "a"==s が真になるということを認めるということは
真面目に演算子のオーバーロードを認めるか
でも==と+のみってわけにもいかないだろうし
結局その演算子が何を比較・演算してるのかが
きちんとわからないと不安であるというのは
まあ既出の問題で、Javaはオーバーロードを
端から放棄してるからその問題も起こりえないという
いいんだかわるいんだか って漢字
407 ：java使いTai!：03/11/09 02:08
不便を以って便を為すってところだ。
408 ：デフォルトの名無しさん：03/11/09 02:09
どう考えても "ab" == new String("a") + "b" と
"ab" == "a" + "b" で結果が違うのが分かりにくいと思う。
"ab" == "a" + "b" の見た目も同じ参照のインスタンス(オブジェクトの内容が同じではない)
をさしているオブジェクトの比較に見えない。
実は "ab" に置換されるというトリックがあって、同じ文字列定数のインスタンスを比較するから、
"ab" == "a" + "b" は true になるんだけども。
409 ：デフォルトの名無しさん：03/11/09 02:10
1.7からは演算子のオーバーロードを取り入れるようだけど
410 ：デフォルトの名無しさん：03/11/09 02:12
やっぱ演算子のオーバーロードあったほうが便利だね、って気づいたんだね。テンプレートもまた然り。
411 ：デフォルトの名無しさん：03/11/09 02:24
C++で演算子のオーバーロードをするときって
演算の瞬間に例外起きたりする？
412 ：デフォルトの名無しさん：03/11/09 02:24
C++の演算子オーバロードはあくまでオーバロードであって
新たな演算子を定義できないところが非常に中途半端。
413 ：デフォルトの名無しさん：03/11/09 02:24
>>406
まあ、判らなくは無いが、同時にその問題が起こるのは == 程度だとおもうけどね。
確かに等しいという事については、何についてっていうのは人それぞれになりがちなのは認める。
(Key,Value)のようなデータはその典型だと思う。比較演算子は難しい。
けれども、それ以外の演算子は、まあ大体見ての通りと思うけどね。
C#を使っていると、参照比較とインスタンス比較の演算子を別けて参照比較用に === 等にして欲しかったのは確か。
ちなみに C++ だと、ポインタ操作のため常に意識していていたり
&a == &b となって区別がつくケースが多く問題が出る事は殆どないですね。
414 ：デフォルトの名無しさん：03/11/09 02:44
>>412
俺もそう思う。演算子を自分で好きなように定義できる言語がうらやましい
415 ：デフォルトの名無しさん：03/11/09 02:49
>>414
そんなのあるの？
416 ：デフォルトの名無しさん：03/11/09 03:13
>>414
演算子と関数やメソッドの区別があまりない言語も含めるといくらでもある。
417 ：414：03/11/09 03:14
>>416
ﾊｧ?
418 ：デフォルトの名無しさん：03/11/09 03:16
>>405
> Java において連続した文字列リテラルが
より正確には定数式の値となる文字列、ね。
"pai=" + Math.PAI
とかも intern() される(はず)。

> 仕様なのか？コンパイラの最適化なのか？
仕様。

> new String(new char[] { 'a', }).intern() の省略表現。
intern() されるのはクラスファイルの読み込み時だから、
その説明はちょっと違うかと。
419 ：デフォルトの名無しさん：03/11/09 03:19
>>418
> "pai=" + Math.PAI
"pi=" + Math.PI だった…
420 ：414：03/11/09 03:19
>>417
ｶﾀﾙﾅ

>>416
/ ＼　ｱ　？
421 ：デフォルトの名無しさん：03/11/09 03:22
(/o＼*)
422 ：デフォルトの名無しさん：03/11/09 03:22
>>400
ならば、
new String("ab") == new String("a") + new String("b")
"ab" == "a".clone() + "b".clone()
と解釈されて欲しいとでもいうのかおい。

423 ：デフォルトの名無しさん：03/11/09 03:23


---------------------------- 切り取り線 --------------------------------

424 ：デフォルトの名無しさん：03/11/09 03:24
>>403
> まあどうせ "a"+"b" が "ab" になるのなら
> String s="a" のとき "a" == s が常に真になる
> くらいまではやってほしかったとは思う。
それは絶対にだめだ。オブジェクト指向に反する。
equals()メソッドを使わなければならない。

どうしてもそうしたければSingletonクラスを作れ。
425 ：ヤボ：03/11/09 03:25
そうか、416と417の「414」は「415」の間違いだな。
426 ：デフォルトの名無しさん：03/11/09 03:27
>>404
> > (switch文とかも)
> 個人的にはあんま必要性感じないけど… あった方がいいのかな？
> C# にはあったような…
switch文の引数にオブジェクトを対応させるということか？
そういうオブジェクト指向破壊機能はいらないというよりもむしろ邪魔だ。
427 ：デフォルトの名無しさん：03/11/09 03:28
>>403
> String s="a" のとき "a" == s が常に真になる
現在の仕様でも常に真になりますね。
428 ：デフォルトの名無しさん：03/11/09 03:29
String#equals()メソッドを使えば済むものをお前らはなぜ==を使うことに拘る？
429 ：デフォルトの名無しさん：03/11/09 03:31
>>403
> (switch文とかも)
if文があればそんなもんはイラン
430 ：java使いTai!：03/11/09 03:34
>>428
拘るわけじゃないけど

そこまで言うなら 、String s = "hoge"; とか s = "a" + "b";
という表現があるのは ちょっとおかしいと思うっすよ。

なんつーか、 == で比較したっていいじゃん
Stringだけでいいからさぁ

という話。普段はちゃんとequalsつかうし、このくらい許して
431 ：デフォルトの名無しさん：03/11/09 03:35
お前らJavaのStringの取り扱いについては
http://www.gimlay.org/~javafaq/S008.html
を読むか、「Javaの鉄則」を読め

いまどき==で文字列比較してる奴はアフォ
432 ：デフォルトの名無しさん：03/11/09 03:35
>>426
> switch文の引数にオブジェクトを対応させるということか？
そーじゃなくて、switch( Expression ) の Expression が String を受け入れるって事。

> そういうオブジェクト指向破壊機能はいらないというよりもむしろ邪魔だ。
オブジェクト指向は破壊しないと思うよ。
JDK1.5 では 列挙型で switch できるようになる(はずだ)し。
433 ：デフォルトの名無しさん：03/11/09 03:37
何でStringは特別扱いなのにIntegerはそうじゃないの？
434 ：デフォルトの名無しさん：03/11/09 03:38
>>431
同じ文字列の比較を何回も行う場合とかは
文字列全部 intern() して == で比較行うけど。
435 ：デフォルトの名無しさん：03/11/09 03:38
>>433
> 何でStringは特別扱いなのにIntegerはそうじゃないの？

言語設計者に聞いてくれ。
436 ：デフォルトの名無しさん：03/11/09 03:38
>>430
> なんつーか、 == で比較したっていいじゃん
> Stringだけでいいからさぁ
そんな糞機能使いたければオートオーバローディングに頼っているC#でもやれ。

Singletonパターンというものがなんなのかわかっとるか。
そんな糞機能ばかり使っているとオブジェクト内の文字列を変更したときの処理や
マルチスレッドで泣きをみるぞ。
437 ：デフォルトの名無しさん：03/11/09 03:40
>>409
> 1.7からは演算子のオーバーロードを取り入れるようだけど
JSRにそんなことかいてあんのか？
すぐに確定するとは思えない。
438 ：デフォルトの名無しさん：03/11/09 03:41
>>432
> > switch文の引数にオブジェクトを対応させるということか？
> そーじゃなくて、switch( Expression ) の Expression が String を受け入れるって事。
ｲﾗﾈ。ifや専用メソッドで十分。
439 ：デフォルトの名無しさん：03/11/09 03:41
>>437
ネタのマジレス
440 ：java使いTai!：03/11/09 03:42
>>431
そんなのは知ってますって。

ひとつ聞きたいんですけど
文字列を比較するときって、同じリテラルかどうかを見ることって
ほんとにあるんですか？
まずほとんどの場合、文字列の比較がしたいだけであって
同一の実体かどうか なんて検査は不要だと思うんですけど・・・

あ、継承していたら話は別か。
そのときは何の機能つけてるかわからないし
文字列の単純比較は出来ないのか
441 ：デフォルトの名無しさん：03/11/09 03:42
>>433
おまいはIntegerで何をしたいのか
442 ：デフォルトの名無しさん：03/11/09 03:43
>>440
マジでおまいはマルチスレッドをやったほうがいい
443 ：デフォルトの名無しさん：03/11/09 03:44
>>440
String は final で修飾されてるので継承できません。
444 ：java使いTai!：03/11/09 03:44
>>436
なぜ、String a = "hoge"; や "a"+"b" だけに
シンタックスシュガーが認められているのでしょうか
紛れが起こることがほとんど無い上に便利だから ってこと？
445 ：デフォルトの名無しさん：03/11/09 03:45
>>443
じゃあ文字列の比較を==でしても問題ないじゃん

うーん設計者は何でこういう実装にしたんだろう・・・
446 ：デフォルトの名無しさん：03/11/09 03:46
>>440
> 文字列を比較するときって、同じリテラルかどうかを見ることって
> ほんとにあるんですか？

「リテラル」じゃなくて参照値だけど、>>434 とか。
447 ：java使いTai!：03/11/09 03:47
>>442
なぜ？
String#equals ってアトミックじゃないの？
448 ：デフォルトの名無しさん：03/11/09 03:49
>>445
言語設計者が何考えたかは知らんが、

個人的には 「==」 は参照値の比較で
equals() で同値かの比較を行う、
という規則があるからだと思う。
449 ：デフォルトの名無しさん：03/11/09 03:52
>>445
だからお前はマルチスレッドとシングルトンの意味を調べて来いや。
このオブジェクト指向も知らない恥さらしが
450 ：デフォルトの名無しさん：03/11/09 03:57
>>445
お前はオブジェクトのクローンについてもとんでもない誤解を生んでいそうだ。
451 ：デフォルトの名無しさん：03/11/09 03:57
C++ vs Java が

Java vs Javaになってきました。
452 ：java使いTai!：03/11/09 03:57
>>448
== は参照値の比較、プリミティブな値だけ比較できる ってことで
まあ納得はするんですが、 文字列の連結に + が使える事に関して
その実装のポリシーに疑問が沸きますよ、やっぱり。

なんつーか、いっそ + で連結なんて出来なかった方が
清清しくてよかったと思うんですけど。
453 ：java使いTai!：03/11/09 03:59
>>449
マルチスレッドとシングルトンの意味はよく知ってますよ。
それとStringで == を使っちゃいけないこととの関連性が
イマイチ理解できないッス
454 ：デフォルトの名無しさん：03/11/09 04:00
>>448
ネタばかり流すなよ。
規則だったら==でも問題ないんだが。

Stringオブジェクトがメモリ上でどのように管理されているかがわかれば
==を使ってはならない理由は一目瞭然なのだが。
455 ：デフォルトの名無しさん：03/11/09 04:02
>>452
その姿勢は正しいね。
他のヤツラはStringが + で連結できることに何の疑問ももってないっぽいもの。

演算子オーバーロードを否定するならStringの + も同じ理由で否定できるのに。

Javaに演算子オーバーロードが最初からあったら否定しなかっただろう、ってのは当たってそう。
456 ：デフォルトの名無しさん：03/11/09 04:03
>>452
JavaではStringの扱いは特別なんだが。
String以外の型にStringオブジェクトを代入すると
暗黙のうちにtoString()メソッドが呼び出されるわけだが。

お前はそれすらも否定する気か？
457 ：java使いTai!：03/11/09 04:03
>>454
「文字列を == を使って比較できない理由」 を論じてるんじゃないっすよ

それは百も承知の上で、あえて、シンタックスシュガーのひとつとして
== で「文字列」の比較ができるようにすればいいのに何故しなかったの
ということを言っているんですね。
それを言い出したら さっきから言ってるように
+ での連結を認めるのも何だか変ザマス
458 ：java使いTai!：03/11/09 04:05
>>456
特別なら特別で、もういっそ == も特別に扱っちゃおうゼ！
次のバージョンあたりから！

と言いたいです。
459 ：デフォルトの名無しさん：03/11/09 04:09
>>455
> >>452
> その姿勢は正しいね。
> 他のヤツラはStringが + で連結できることに何の疑問ももってないっぽいもの。
では聞こう。Stringに+を使うことでどんな困った問題があったのかね？

> 演算子オーバーロードを否定するならStringの + も同じ理由で否定できるのに。
ただの偏屈だな。Smalltalkには値型は一切無いのになんでJavaには値型あるのか？
Smalltalkではfor分野if文もおうじぇくとなのになんでJavaではそうなっていないのか？
JavaはOS非依存なのになんでOSによって挙動や見栄えが異なるのか？

と質問しているようなものだ。

> Javaに演算子オーバーロードが最初からあったら否定しなかっただろう、ってのは当たってそう。
なくてもあっても否定するんだが。たとえばJavaですでにあるもので否定したいものがある。
instanceofキーワードも気に入らん。否定する。
assertもいらん。JUnitで十分できることを無駄に付け加えて余計だ。
はやくGenericsによってサブクラスの型をいちいち調べる機能をなくして欲しい、と思うこともある。
460 ：デフォルトの名無しさん：03/11/09 04:10
>>457
> >>454
> 「文字列を == を使って比較できない理由」 を論じてるんじゃないっすよ
>
> それは百も承知の上で、あえて、シンタックスシュガーのひとつとして
> == で「文字列」の比較ができるようにすればいいのに何故しなかったの
> ということを言っているんですね。
==とequals()を区別して使いたいからに決まっているだろ。
何度もいうが、マルチスレッドをやってみろ。
==とequals()を区別して使ってみたい理由が痛いほどよくわかる。
ついでにObject#clone()についても勉強しろ。
461 ：java使いTai!：03/11/09 04:11
>>459
+ で連結できること に困った場面はありません。便利だし。

で、逆に質問なんですが
== で文字列同士の比較ができるようになったとき、
それで怒りうる問題にはどんなのが考えられますか？
462 ：デフォルトの名無しさん：03/11/09 04:12
>>458
JCPに提案でもしてみなと。真っ先に否定されるぞ。
どうしてもやりたければC#を使うか自分でJavaを改造しろ。
463 ：デフォルトの名無しさん：03/11/09 04:12
>>461
> で、逆に質問なんですが
> == で文字列同士の比較ができるようになったとき、
> それで怒りうる問題にはどんなのが考えられますか？
オブジェクトの同値性が確認できないという困った問題が考えられるだろうが。
464 ：デフォルトの名無しさん：03/11/09 04:14
>>455
> 演算子オーバーロードを否定するならStringの + も同じ理由で否定できるのに。
演算子のオーバーロードは文字列連結演算子と同じようなものを いくらでも作り出すことができる。
基本的に同列の問題じゃない。
465 ：デフォルトの名無しさん：03/11/09 04:14
>>459
>では聞こう。Stringに+を使うことでどんな困った問題があったのかね？

俺は演算子オーバーロード容認派だから困ったことは無いけど。

オマエラ演算子否定派が色々な難癖つけて演算子オーバーロードを否定してんのに
なぜStringだけ容認するのかがわからんといってんの。矛盾してる。

なぜStringの+を容認するのか、理由はわかる。便利だからだ。
同様に便利だから演算子オーバーロードは容認されてもいいべきだ。
466 ：デフォルトの名無しさん：03/11/09 04:15
いやもう、とにかくJavaの鉄則や落とし穴を読めと。
マルチスレッドをやってみろと。
467 ：デフォルトの名無しさん：03/11/09 04:18
>>456
> String以外の型にStringオブジェクトを代入すると
> 暗黙のうちにtoString()メソッドが呼び出されるわけだが。

ウソはいかんぞ。ウソは。
468 ：java使いTai!：03/11/09 04:19
>>460
String s="hoge";
String t= Nanntoka.toString(); ← まあ結果的に "hoge"文字列が返る何か

このとき、 s==t が成立しない ということが重要な意味を持つ場面とか
思いつかないです。

単なる文字列を オブジェクトして捉えてその同一性を厳密に確認する
というのが果たして本当に必要なのか という問題 かな？
469 ：デフォルトの名無しさん：03/11/09 04:21
>>465
> >>459
> >では聞こう。Stringに+を使うことでどんな困った問題があったのかね？
> オマエラ演算子否定派が色々な難癖つけて演算子オーバーロードを否定してんのに
> なぜStringだけ容認するのかがわからんといってんの。矛盾してる。
お前は日本語読めないのか？

> なぜStringの+を容認するのか、理由はわかる。便利だからだ。
> 同様に便利だから演算子オーバーロードは容認されてもいいべきだ。
屁理屈だけで実践もしてみない奴が何をいうかと。実際にやってみてどんな副作用が
生じるのか経験したことも無いから馬鹿げたことをいえる。

お前みたいな口だけのくだらん不満を持った奴がC#に飛びつくわけだが。
470 ：デフォルトの名無しさん：03/11/09 04:22
>>465
> 同様に便利だから演算子オーバーロードは容認されてもいいべきだ。
一つのクラスで演算子オーバーロードが許されたら全てのクラスで許されるべきってのは極論でしょ。
471 ：デフォルトの名無しさん：03/11/09 04:22
>>467
ああプリミティブ型だけは違ったな。
String以外のオブジェクトの型にといっておくべきだったな。
472 ：java使いTai!：03/11/09 04:22
>>466
一応職業がプロのプログラマ兼SEなので
マルチスレッドはバンバン使ってますし、落とし穴も
それなりに理解しているつもりですけど・・・

具体的な例を挙げてもらいませんか？
>>468とかへの反論でもいいので おねがいします
473 ：デフォルトの名無しさん：03/11/09 04:24
>>452
そーゆー事は言語仕様作った奴に言ってくれ。
474 ：デフォルトの名無しさん：03/11/09 04:24
>>465
Stringの+演算子オーバーライドは言語仕様レベルで仕様が確定
していて、他に影響ないからな。確かに仕様に統一感が無いとは
思うけど。

お前さんあるいはどこぞの半端バカが自作クラスで勝手にやった
演算子オーバーライドに振り回されたくはないな。
475 ：デフォルトの名無しさん：03/11/09 04:25
>>468
ポインタの意味わかってるか？
476 ：デフォルトの名無しさん：03/11/09 04:25
>>469
>お前は日本語読めないのか？

お前、自分自身の文が日本語のつもりか？

>屁理屈だけで実践もしてみない奴が何をいうかと。実際にやってみてどんな副作用が
>生じるのか経験したことも無いから馬鹿げたことをいえる。

じゃ、お前もその副作用とかいうのを具体的に言ってみろ。言えるか？
477 ：デフォルトの名無しさん：03/11/09 04:27
>>474
>お前さんあるいはどこぞの半端バカが自作クラスで勝手にやった
>演算子オーバーライドに振り回されたくはないな。

これが良く分からん。C++も使ってるが、演算子のオーバーロードに振り回された時なんか無いぞ
478 ：デフォルトの名無しさん：03/11/09 04:27
>>471
> > String以外の型にStringオブジェクトを代入すると
まず、この部分は逆っぽい
「String型の変数に String以外のオブジェクトを代入すると」だろね。

> > 暗黙のうちにtoString()メソッドが呼び出されるわけだが。
よびだされないよ。
String s = new Object(); はコンパイルエラーになる。
479 ：デフォルトの名無しさん：03/11/09 04:29
>>472
> 一応職業がプロのプログラマ兼SEなので
常識もしらないでおまえは本当にプロなのかと。
480 ：java使いTai!：03/11/09 04:29
>>475
ポインタの意味わかってますよ。
現時点では Stringはインスタンスでcharの配列を持ってるオブジェクトで
"hoge"=="hoge"が成立するのは単に同じリテラルだから
左辺右辺とも同じオブジェクトを参照しているので
==ではそのポインタの比較だから真となるけど
違うオブジェクトの場合はその保証は全く無い ということですよね。

でも、今はその話ではないです。
481 ：デフォルトの名無しさん：03/11/09 04:30
常識を疑えずして本当にプロか？
482 ：デフォルトの名無しさん：03/11/09 04:31
>>476
とりあえずお前はマルチスレッドとクローニングについて勉強しろ。
483 ：デフォルトの名無しさん：03/11/09 04:31
>>480
> 違うオブジェクトの場合はその保証は全く無い ということですよね。
違うオブジェクトへの参照なら必ず偽になる と言う事です。
484 ：デフォルトの名無しさん：03/11/09 04:32
具体的にいえないんですね
485 ：java使いTai!：03/11/09 04:32
>>483
ああそうでした。すみません。
486 ：デフォルトの名無しさん：03/11/09 04:33
equals()をつかわずに==だけで文字列を比較したいと言い出す奴は
こんどばStringBufferオブジェクトとStringオブジェクト内に収まっている
文字列まで==だけで比較したいといいそうだな。
StringBuffer内にあるバッファ領域はどうやって比較するんだｳﾞｫｹが
487 ：java使いTai!：03/11/09 04:36
>>486
そこまでは言いませんよ。
だいたい、他のオブジェクトでの演算子オーバーロードは
現時点では使いたいと思ってないです。
ただ、一番よく使われる（と思われる)単純な文字列比較は
あってもいいじゃん というのが趣旨でして。

>>468に関する意見て無いスか？
488 ：デフォルトの名無しさん：03/11/09 04:36
>>477
そりゃお前の運が良かったんだろうな
489 ：デフォルトの名無しさん：03/11/09 04:38
>>468
> このとき、 s==t が成立しない ということが重要な意味を持つ
「==」 が参照値の比較だってゆーポリシーが崩れるという観点からみてダメだと何度言ったら…

文字列連結演算子が何故許されるのかは言語仕様決めた奴に聞け。
俺は知らん。
490 ：デフォルトの名無しさん：03/11/09 04:40
>>487
「==」による文字列比較では >>434 のような小細工も使われているので
今更変えられても困りますぅ
491 ：デフォルトの名無しさん：03/11/09 04:40
なんで演算子のオーバーロードをそんな毛嫌いすんの？
演算子の格好をしたただの関数じゃん。

演算子名と違う機能を割り当ててるのと、関数名と違う機能を割り当ててる関数と何が違うの？
どっちも同じだけダメなだけだろ？
492 ：デフォルトの名無しさん：03/11/09 04:41
equals():内部の値の比較。比較方法は各クラス毎の実装依存。
==:参照自身の指し示す相手が同じインスタンスかどうか
を確かめる。

最近、比較に関してJavaのこのルールは「最もシンプルか
つ明快で合理的」なのではないかと思うようになった。

C++で==に変な演算子オーバーライド掛けられてこまった
ことがあるので、尚更。==で同値比較された日には、同一
インスタンスかどうかのチェックはどうすんのよ、と。
493 ：java使いTai!：03/11/09 04:41
>>489
元々の出発点が 「＋許すんなら ==も許せよー もぅ！」 ってとこなので
それ言われたら元も子も無いでんがな

つーか、単にポリシーが崩れるだけですよね
他に機能面では問題ないと思うですよ
494 ：java使いTai!：03/11/09 04:42
>>492
String以外のクラスに関しては全く同意です
495 ：デフォルトの名無しさん：03/11/09 04:43
>>492
>C++で==に変な演算子オーバーライド掛けられてこまった
>ことがあるので、尚更

これもJavaではequalsに比較じゃない動作を仕掛けられてしまった、のと何がちがうの？
496 ：java使いTai!：03/11/09 04:43
>>490
== で「文字列」の比較をするようになっても
既存コードへの影響は極小だと思います。
そう思う理由は>>468なんですけど
497 ：デフォルトの名無しさん：03/11/09 04:45
>>491
>>317-400 あたりを読んでくれ。同じ話をする気にはなれん。
498 ：デフォルトの名無しさん：03/11/09 04:46
>>497
読んだ上で言ってる。おなじじゃん。
499 ：デフォルトの名無しさん：03/11/09 04:47
>>487
どうやらお前は文字コードの違いというものを意識したことが無いようだ
500 ：デフォルトの名無しさん：03/11/09 04:50
>>493
> 元々の出発点が 「＋許すんなら ==も許せよー もぅ！」 ってとこなので
文字列連結演算子でいえば、他の参照値同士は「+」で演算できない。
文字列連結演算子だけが特例になっている。

対して「==」では他の参照値では以前と同じく参照値の比較で
文字列だけ「==」で同値かどうかの比較にしろってんでしょ？
同列に論じていい問題じゃない。

> つーか、単にポリシーが崩れるだけですよね
そうだよ。

まぁ、そんなに言うなら JCP なり BugParade なりで騒いでみるとか、
プリプロセッサ作るとかすれば？
501 ：デフォルトの名無しさん：03/11/09 04:52
文字列連結演算子だけが特例なのはポリシーが崩れないのか？
502 ：デフォルトの名無しさん：03/11/09 04:53
>>498
> 読んだ上で言ってる。おなじじゃん。
同じなら演算子のオーバーロードなんて要りませんね。
503 ：デフォルトの名無しさん：03/11/09 04:54
>>501
> 文字列連結演算子だけが特例なのはポリシーが崩れないのか？
それは言語仕様作った奴に言え。

「==」の仕様を変えろ、ってのは既に確立してるポリシーを崩す事になるので容認できないってだけ。
504 ：デフォルトの名無しさん：03/11/09 04:54
>>502
なんで？あったほうが便利ジャン。文字列の + は便利だと思ってんだろ？
505 ：java使いTai!：03/11/09 04:55
>>499
それはequalsでも同じですよね
でも、そもそもJavaではUTF-8を使っているから
どのみちEUCなりSJISが出たり入ったりするときには
streamから読み書きするときに必要ならまずエンコードしますよね
だからこの件には影響ないよね
506 ：デフォルトの名無しさん：03/11/09 04:55
こいつはStringクラスのソースコードの一部だ。
これを良く見て==だけで文字列比較をしたいと思っているう奴は考え直せ。
/** The value is used for character storage. */
private char value[];

/** The offset is the first index of the storage that is used. */
private int offset;

/** The count is the number of characters in the String. */
private int count;

/** Cache the hash code for the string */
private int hash = 0;
507 ：デフォルトの名無しさん：03/11/09 04:56
>>504
> なんで？あったほうが便利ジャン。
なら同じではありませんね。
508 ：デフォルトの名無しさん：03/11/09 04:56
>>496
左辺値と右辺値が同じStringインスタンスを指し示していることを
確認したい場合はどうするんですか？
509 ：デフォルトの名無しさん：03/11/09 04:57
>>507
アンタとオレの言う同じが同じでないだけじゃん
510 ：デフォルトの名無しさん：03/11/09 04:59
>>505
おまえはjava.nio.charset.Charsetを知らんのか？
まったく影響があるんだが。

とにかくUTF-8以外のファイルの取り扱いについて考えてみろ
511 ：java使いTai!：03/11/09 04:59
>>508
>>468でも聞いたんですが、その必要性が本当にあるのか
String比較で本当に同一インスタンスであることが重要な場面は
いったいあるのでしょうか というのがわたしの疑問だったりします

まあ「あるといったらあるんだい！こまるんだい！」と言われれば
しょうがないですけど
512 ：508：03/11/09 04:59
「そんな用途は存在しない」というヒトがもしいるのなら、
それは「視野狭すぎ」です。少なくとも私は頻繁に使います。
513 ：java使いTai!：03/11/09 05:00
>>506
すみません。これだけでは考えは変わりませんです。
514 ：デフォルトの名無しさん：03/11/09 05:01
どうでもいいけど具体例を出さない奴の言うことはほっとけ。妄想を語ってる場合が多いから。
515 ：デフォルトの名無しさん：03/11/09 05:01
>>509
>>491 を読めば演算子のオーバーロードと従来の関数は全く同じ、と言っていますが
>>504 では演算子のオーバーロードがあった方が便利、と言っています。
便利だと言う事はなんらかの違いがあると言う事です。
516 ：デフォルトの名無しさん：03/11/09 05:02
>>511
> >>508
> >>468でも聞いたんですが、その必要性が本当にあるのか
> String比較で本当に同一インスタンスであることが重要な場面は
> いったいあるのでしょうか というのがわたしの疑問だったりします
スレッド
517 ：java使いTai!：03/11/09 05:02
>>512
ですから、どんな場合に必要なのか具体例を教えて欲しかったです
わたしは使っています だけでは へぇボタン押せません
518 ：java使いTai!：03/11/09 05:02
>>516
ですから、どんな場合に必要なのか具体例を教えて欲しかったです
スレッド使うときに困ります だけでは へぇボタン押せません
519 ：デフォルトの名無しさん：03/11/09 05:03
>>514
なるほど、自称プロSE C++厨の妄想か。
520 ：デフォルトの名無しさん：03/11/09 05:03
>>515
オレの言う同じは下の二行のことだったぢゃん
521 ：デフォルトの名無しさん：03/11/09 05:03
>>511
>String比較で本当に同一インスタンスであることが重要な場面は
あります。>>434
522 ：デフォルトの名無しさん：03/11/09 05:04
>>517
私は例えば列挙値に表現上の理由でString使いますが。
わざわざstrcmpカマス必要が無いので==で比較しますが。
523 ：デフォルトの名無しさん：03/11/09 05:04
>>513
> >>506
> すみません。これだけでは考えは変わりませんです。
このド素人が
524 ：デフォルトの名無しさん：03/11/09 05:04
>>519
Java厨もだよ。
525 ：java使いTai!：03/11/09 05:05
>>510
すみません。それに関しては勉強します。
でも、String$equalsにも影響あるんですか？
526 ：java使いTai!：03/11/09 05:06
>>521 >>522
これらが 文字列の比較 と置き換わったときに
起こりうる問題ってなんでしょうか

あー速度が遅くなるか
527 ：デフォルトの名無しさん：03/11/09 05:07
文字列の同値判定はあんまり同一判定と速度かわらなさそうなんだけど
528 ：java使いTai!：03/11/09 05:10
やはり、>>511-512のどちらの場合も
「文字列」の同一性について比較しているわけで
「Stringオブジェクト」の同一性について比較しているわけではないですね

>>523
いや、煽りたいのはわかるんですが
もうちっとこうヒントでもくださいな
529 ：デフォルトの名無しさん：03/11/09 05:10
>>513
private char value[];
private int count;


==だけで比較したいということはお前が比較したい対象はこれだけに絞り
こまれるわけだ。それ困ることだ。

private int offset
private int hash
この二つの変数を無視した比較ができないのはあとあとこまる。

とあるクラスは、String#hashcode()メソッドを使って探索を高速化している。
よって、hash値の比較は重要。==による比較が文字列のみの場合hashの比較までまとめてできないので
==の勝手なオーバーローディングは却下。
530 ：デフォルトの名無しさん：03/11/09 05:11
言語仕様なんて、結局「矛盾の少ない落しどころ」「許容可能な妥協」
といった理由できまるものなので、あちらを立てればこちらがたたない
場所があるのは当たり前。

開発を行う人間の頭の中で誤解が発生しない仕組みにさえなっていれば
ど　ー　で　も　い　い　。
531 ：デフォルトの名無しさん：03/11/09 05:12
C++厨も威張っているくせにこういうところだけ抜けている。
532 ：デフォルトの名無しさん：03/11/09 05:13
いまさら==の仕様を変えたら大変なことになるのはあきらかだわな。
C#ではすでに==がJavaのequalsl()と同じように勝手に機能するらしいので
あとが大変そうだな。
533 ：デフォルトの名無しさん：03/11/09 05:14
>>528
違う。
「オブジェクト」が同じ物であることを==で比較していて、
その中身がタマタマStringだというだけ。
534 ：デフォルトの名無しさん：03/11/09 05:15
>>529
==の比較が、まずhash同士が同じか調べてから文字列の比較をするという実装になってればいいんじゃ？
535 ：デフォルトの名無しさん：03/11/09 05:15
>>528
> 「文字列」の同一性について比較しているわけで
> 「Stringオブジェクト」の同一性について比較しているわけではないですね
最終的に判定したいのは「文字列の同一性」ですが、
「文字列の同一性」を判定するのは高くつく場合もありますね。
その場合は参照値の同一性に置き換えて比較する事によって高速化を試みるわけです。
なので参照値の同一性を比較できなくなると困ります。
536 ：デフォルトの名無しさん：03/11/09 05:17
見た目だけ便利にしてもしょうがないわけだが。
537 ：デフォルトの名無しさん：03/11/09 05:19
>>534
おいおい、すべてのクラスで==をそういう仕様にすればいいと思っているのか？
538 ：デフォルトの名無しさん：03/11/09 05:20
>>535
C#の仕様は、「高くついてもいい」という判断の結果ですか。
539 ：デフォルトの名無しさん：03/11/09 05:20
>>538
C# の仕様決めた人に聞いてください。
540 ：デフォルトの名無しさん：03/11/09 05:20
>>537
String同士の時だけでいいじゃん。なにいってんの？
541 ：java使いTai!：03/11/09 05:24
>>529
Stringで同じ文字列なら同じHashになりませんか？
それと、hash値の比較で高速化するのと
文字列の==比較を禁止するとの関連性は希薄ですよね

>>535
そうですね
文字列の比較がオブジェクト(ポインタ)の比較と置き換えられる
というのは確かに高速化につながるので
高速動作を要求されるコードでは確かに困るですね

でもそのときにはボトルネック部分だけ何とかすれば
いい気もします
高速性を要求される部分では文字列比較しない、とか
542 ：デフォルトの名無しさん：03/11/09 05:26
>>高速性を要求される部分では文字列比較しない、とか

だれがその部分に高速性を要求するの？コンパイラやVMじゃないよね？
ソースにヒントでも書かせるのですか？薄汚い仕様ですな。
543 ：デフォルトの名無しさん：03/11/09 05:32
>>541
> でもそのときにはボトルネック部分だけ何とかすれば
> いい気もします
> 高速性を要求される部分では文字列比較しない、とか

いや、既存のコードで既に使われているので安易に変更されると困るって意味なんですが…
544 ：java使いTai!：03/11/09 05:33
>>533
それであれば、Stringを使う必要がそもそも無いということになりますね
暴論ですが 現時点で便利だからそう使ってる というだけとも言えたり。

>>542
もちろんユーザ(プログラマ)です。
最初から 文字列比較はちょっと遅い ということがわかってれば
リファクタリングしてそれなりのコードが書けるはずです。
internして比較してるならなおさらかと。
545 ：java使いTai!：03/11/09 05:34
>>543
大丈夫ッスよ 今のCPU速いし！ ハッハッハ
546 ：デフォルトの名無しさん：03/11/09 05:37
>>545
> 大丈夫ッスよ 今のCPU速いし！ ハッハッハ
おいおい…
547 ：デフォルトの名無しさん：03/11/09 05:39
>>スレ荒らしてる人
言語仕様決めた人が、
>大丈夫ッスよ 今のCPU速いし！ ハッハッハ
とは判断しなかったということで。
548 ：java使いTai!：03/11/09 05:41
まあ 結論は

== での文字列比較はポリシー的・速度的にイヤ

ってとこですね。機能的には問題なし。
でもって、 + のｼﾝﾀｯｸｽｼｭｶﾞｰは仕様決めた奴に文句言えと。
そんなファイナルアンサーですか。
549 ：デフォルトの名無しさん：03/11/09 05:46
>>548
> 機能的には問題なし。
機能的に問題が無いかどーかは知らない。
550 ：デフォルトの名無しさん：03/11/09 05:48
+のシンタックスシュガーは、決めた奴にｱﾘｶﾞﾄｳを言いたいなあ。
String hoge=
　"ほげほげ"+
　"ほげほげ"+
　"ほげほげ";

で、コンパイル時に"ほげほげほげほげほげほげ"と評価してくれるのは
いいことだと思うけど。長い文字列をコード内に書くときに、見やすく
てよい。でもって、==のようなトレードオフないし。
551 ：デフォルトの名無しさん：03/11/09 05:52
え？Javaって

String hoge=
　"ほげほげ"
　"ほげほげ"
　"ほげほげ";

これダメなの？
552 ：デフォルトの名無しさん：03/11/09 05:54
>>551
コンパイルエラー
553 ：デフォルトの名無しさん：03/11/09 05:56
>>548
俺は >>489 で
> 文字列連結演算子が何故許されるのかは言語仕様決めた奴に聞け。
とは言ったが、文句言えと言った覚えは無いぞ。

まぁ文句言いたいんなら 勝手に言えばいーんだけどさ。
554 ：デフォルトの名無しさん：03/11/09 05:56
なんだそりゃ。C,C++から派生した癖にコンパイルエラーになんのかよ。
555 ：デフォルトの名無しさん：03/11/09 06:00
派生じゃないよ。文法を拝借しただけ。
556 ：デフォルトの名無しさん：03/11/09 06:01
>>550は利点じゃないな
"ほげほげ" "ほげほげ" が連結されるようなC/C++の仕様と同じならいい話なだけだ。
557 ：デフォルトの名無しさん：03/11/09 06:51
すごくスレが伸びたねぇ。
文字列オブジェクトの同一性チェックと文字列の同一性チェックは
両方ないと困るんじゃないの？あるコレクションが同じオブジェクトを
複数参照していないか確認したい時とか。
あとはそのどちらを「==」にあてるかという問題だけでしょ。
文字列オブジェクトの同一性チェックは必要ない、っていうのは
馬鹿の妄言としか思えない。
つか、文字列の+は演算子オーバーロードと何の関係もないだろ。
558 ：デフォルトの名無しさん：03/11/09 06:57
文字列の+は演算子オーバーロードとほとんど同じ欠点を持つ、なのに文字列の+にだけ利便性を遊船させるのはおかしいというはなていちい
559 ：デフォルトの名無しさん：03/11/09 07:04
>>558
再定義できないなら演算子オーバーロードとちっとも一緒じゃない。
ただの構文。
560 ：デフォルトの名無しさん：03/11/09 07:26
>>557
文字列オブジェクトの同一性チェックが必要ある場面
が思いつかないです

>>559
Stringの+が文字列連結に再定義されている
というのが問題だと思うんです
561 ：デフォルトの名無しさん：03/11/09 08:21
いまさら無理に==を文字列比較にも適用するくらいなら別に文字列比較演算子を作ったほうがいいと思うけど

あとStringで+を特別扱いしたのは変数や文字列リテラルをたくさんつないでも見やすくするためでは
(C++のiostreamを意識したのかも)

"a=" + a + ", b=" + b + ", c=" + c;
みたいなのを+なしてやったらかなり見にくくなりそうだし
562 ：デフォルトの名無しさん：03/11/09 09:31
>>561
＞文字列比較演算子
それだ！

と、思ったけどswitch文でも使いたいのでちょっとアレか
563 ：デフォルトの名無しさん：03/11/09 10:49
>>560
オブジェクトの同一性が必要な場合が>>557に書いてあるじゃん。
その目は節穴か？

>>560
文字列連結に「再」定義されているのではない。
その証拠にユーザはそれを変更できないだろ？

強弁するのは見苦しいよ。

564 ：デフォルトの名無しさん：03/11/09 11:26
>>548
> まあ 結論は
>
> == での文字列比較はポリシー的・速度的にイヤ
>
> ってとこですね。機能的には問題なし。
馬鹿いえ
http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#101083
565 ：デフォルトの名無しさん：03/11/09 11:29
>>560
> >>557
> 文字列オブジェクトの同一性チェックが必要ある場面
> が思いつかないです
だからマルチスレッドをやってみればわかるっていってるだろうが
566 ：デフォルトの名無しさん：03/11/09 11:29
じゃあ再定義、じゃなくて定義でいいよ。

で、ユーザーが変更できないってのに何か意味が？

C++だって既に定義されてる演算や、プリミティブな型同士の再定義は禁止されてるけど
567 ：デフォルトの名無しさん：03/11/09 11:31
>>540
おまいはhash関数が何のために存在するかわかってないようだ
568 ：デフォルトの名無しさん：03/11/09 11:31
>>565
ﾊﾞｶ?
569 ：デフォルトの名無しさん：03/11/09 11:33
まだ起きていたのか。
まるで参照型と値型との区別もできない馬鹿が==の仕様をかえたがっているみたいだな。
570 ：デフォルトの名無しさん：03/11/09 11:41
Stringクラスのみ==の仕様をString#equals()と同じにしたとき
Stringクラスラップ↓特殊な文字列操作クラスを作った香具師が
Stringクラスの==だけString#equals()相当のことができるのは不公平だといって
演算子のオーバーロディング機能をJavaに追加しろという馬鹿があらわれる
それこそ矛盾するので禁止だな。
571 ：デフォルトの名無しさん：03/11/09 11:46
==の仕様を変えたがっているｳﾞｧｶは
片方のStringオブジェクトがObject型にアップキャストされても==だけで比較したいと抜かすんだろうな。

どうしても==で比較したいなら素直にintern()つかばすむことや。
intern()もメモリ節約をしたい香具師のためにある機能なのだが。
572 ：デフォルトの名無しさん：03/11/09 11:46
こうなったらStringも値型にしようぜ！！


・・・なんてこと言ってみるテスト

573 ：デフォルトの名無しさん：03/11/09 11:48
+はいいのか？不公平だろ？
574 ：デフォルトの名無しさん：03/11/09 11:48
>>572
アフォ。Objectのサブクラスでなくなる以上、コレクション系で
値型をラッピングした別のクラスが必要になり結局参照型のStringが残る。
575 ：デフォルトの名無しさん：03/11/09 11:49
>>574
じゃあstringを値型でStringを参照型で
576 ：デフォルトの名無しさん：03/11/09 11:49
>>573
あれだけ親切に説明されてもまだわからなのか。
あれで理解できないなら
頭手術したほうがいいんじゃないのか？
577 ：デフォルトの名無しさん：03/11/09 11:50
>>575
そんなことをいうお前はBigIntegerやBigDecimalの値型も必要だとぬかすんだろうな。
そしてJavaにも構造体が必要だとかアフォなことを言い出す。まるでC#だな。
578 ：デフォルトの名無しさん：03/11/09 11:51
>>576
ﾊｧ？あれで他人に理解して貰えると思ってるのか？
579 ：デフォルトの名無しさん：03/11/09 11:51
>>577
なんでアホなの？Javaより良い回答だと思うけど？
580 ：デフォルトの名無しさん：03/11/09 11:55
結局、値と参照がよくわかってない馬鹿一人が
「思いつかない」と理解を拒否しているだけだな。
581 ：デフォルトの名無しさん：03/11/09 11:55
文字列に値型と同じように演算子が定義されるようにするんなら
文字列も値型と同じ扱いにすればよかったのに。
Javaの設計ミスですね。
582 ：デフォルトの名無しさん：03/11/09 11:57
やっっぱりわかってない。w
583 ：デフォルトの名無しさん：03/11/09 11:58
それはお前だ！
584 ：デフォルトの名無しさん：03/11/09 11:58
printメソッドなんかで変数をいろいろ出力したいときに
もし文字列が+で連結できない仕様だったらと考えてみると・・・

変数が出てくるたびにいちいちprintメソッドを呼び出すことになるし
無理やりprintメソッド1回で収めようとすれば文字列を結合するメソッドを
何重にも呼び出して括弧だらけになり見た目最悪になるわけだが

そういう事態を避けるための苦肉の策だったんだろうなと漏れは思ってるんだけど違う？
585 ：デフォルトの名無しさん：03/11/09 12:00
C++のiostreamも見やすくするための苦肉の策。見やすいほうがいいだろ。
586 ：デフォルトの名無しさん：03/11/09 12:02
結局オーバーローディングは読みやすくするためにある程度は必要だってことですね。
587 ：デフォルトの名無しさん：03/11/09 12:03
C++演算子オーバーロードは「俺定義」で醜くなる
という話が元だったんだろう？
Javaの文字列演算子は、「元々そーゆー構文」と思えば問題ナシでないか？
588 ：デフォルトの名無しさん：03/11/09 12:05
オレ定義で見難くなる事なんかめったに無いし
589 ：デフォルトの名無しさん：03/11/09 12:06
で結局==の定義を変えたがってた奴は、この文脈で何がいいたかったんだ？？
590 ：デフォルトの名無しさん：03/11/09 12:06
>>581
お前はポインタがなんのためにあるかわかっていないようだ。
お前の脳細胞の配列の設計がミスっているわけだが。
591 ：デフォルトの名無しさん：03/11/09 12:07
>>587
そのとおりなんだが約一名Javaに噛み付いた馬鹿が粘着してるみたいだ。
592 ：デフォルトの名無しさん：03/11/09 12:08
ポインタは無い。参照はある。
593 ：デフォルトの名無しさん：03/11/09 12:09
>>588
> オレ定義で見難くなる事なんかめったに無いし
お前は一人でオナニーでもしていればいい。
チーム開発で乱用するとどんなリスクを背負うかまったく理解できないのは大恥。
594 ：デフォルトの名無しさん：03/11/09 12:10
>>589
C++厨としての面子を保ちたかっただけじゃねえか？
595 ：デフォルトの名無しさん：03/11/09 12:11
>>593
だから、機能があるからって乱用することは無いよ。

お前だってメソッドにめちゃくちゃな意味不明な名前をつけて、
チーム開発をめちゃくちゃにできる権利はあるけど、それをしないだろ？それと一緒。
596 ：デフォルトの名無しさん：03/11/09 12:11
結局Java使いtaiタンは、演算子オーバーロードの優位性を示したくて
文字列の==比較に難癖をつけてみたけれど、==ではオブジェクトの
同一性が比較されるという大原則を壊す事になり、まさに「俺定義」
の余計な複雑性を増すだけだということを指摘されているんじゃないの？
どうよ？
597 ：デフォルトの名無しさん：03/11/09 12:11
>>594
それ言ってた奴はJava厨だろ。名前にJavaとかついてたし
598 ：デフォルトの名無しさん：03/11/09 12:13
Java厨房を装ったC++厨だろ。
599 ：デフォルトの名無しさん：03/11/09 12:16
演算子オーバーロードは適切に定義すれば、文字列の例からも見て取れるように、有用ってことでいいですか？
600 ：デフォルトの名無しさん：03/11/09 12:20
>>597
名前にJavaをつけている奴はどうもC++厨かC#厨臭い匂いがするのだが。
オブジェクト指向をなめている奴がJavaを否定しああいう機能をつけたがる。
C++厨やC#厨が欲しがるような機能ってもんはそんな程度
601 ：デフォルトの名無しさん：03/11/09 12:21
>>599
馬鹿は>>571をもう一度読み返せ
602 ：デフォルトの名無しさん：03/11/09 12:23
オブジェクト指向舐めてない奴は今のJavaの仕様に対して手放しで大絶賛なの？

C++厨かC#厨に負けず劣らず厨だね
603 ：デフォルトの名無しさん：03/11/09 12:24
>>601
オレは==は同一性の比較でいいと思ってるがそれが何か？
604 ：デフォルトの名無しさん：03/11/09 12:24
>>599
>文字列の例からも見て取れるように

どこに例があるの？
605 ：デフォルトの名無しさん：03/11/09 12:25
>>604
+
606 ：デフォルトの名無しさん：03/11/09 12:26
「==」厨房は引っ込んだ（もしくは何食わぬ顔で主張を撤回した）わけね。
607 ：デフォルトの名無しさん：03/11/09 12:27
==は同値性の比較、===は同一性の比較、とかだったら嬉しいかも
608 ：デフォルトの名無しさん：03/11/09 12:28
>>602
不満に決まってるだろ。
genericsをはやく導入して欲しいとおもうことや　

instanceofやassertを廃止して欲しいと思うことがある。
609 ：デフォルトの名無しさん：03/11/09 12:29
>>607
混乱する。
String以外のクラスでもそんな仕様を実装するのかと。
610 ：デフォルトの名無しさん：03/11/09 12:30
>>608
お前C++厨か臭い匂いがプンプンするな。

オブジェクト指向をなめている奴がJavaを否定しgenericsなんてアホな機能をつけたがる。

C++厨が欲しがるような機能ってもんは所詮そんな程度なんだよ
611 ：デフォルトの名無しさん：03/11/09 12:31
>>609
お前もうJava以外の言語使えねーな。臆病すぎ。
612 ：デフォルトの名無しさん：03/11/09 12:31
>>610演技派だね。
613 ：デフォルトの名無しさん：03/11/09 12:34
>>605
>>587
そもそも適切な定義がなされるとは限らない、というところから
議論が始まったんじゃないの？
614 ：デフォルトの名無しさん：03/11/09 12:35
>>613
だから普通のメソッドだって名前とは反した機能をつけることだってできる。
メソッドの定義も禁止するか？
615 ：デフォルトの名無しさん：03/11/09 12:39
メソッド名は「適切に名付ける事で」回避できるな。
演算子はオーバーロードだけだと定義を見ないとわからないだろう。
JavaはC++の余計な混乱を招く機能を割愛した。
ただそれだけのことだろう？
616 ：デフォルトの名無しさん：03/11/09 12:44
演算子オーバーロードは「適切な機能」を付けることで回避できる。

なのにバッサリとカットするのはやりすぎちゃうんかと。
例えばPythonと同じようなルールを採用すれば効果的だったんじゃないかなぁと。
617 ：デフォルトの名無しさん：03/11/09 12:46
>>575
Stringが値型で*Stringが参照型のがええぞ。
618 ：デフォルトの名無しさん：03/11/09 12:49
>>617
なんで？
619 ：デフォルトの名無しさん：03/11/09 12:55
ﾏｼﾞﾚｽ砂。
620 ：デフォルトの名無しさん：03/11/09 13:03
>>616
適切な機能が各個人で同じとは限らんな。
matrixの*は内積なのか外積なのか各要素の積なのかmatrixのポインタなのかw（冗談だけど。
621 ：デフォルトの名無しさん：03/11/09 13:12
>>615
適切に命名できれば良いのですが、isEqual はについては本質的に混乱しやすいと思う。
== のオペレータオーバーロードで混乱という話を上でみたけれども、
もし C++ で == のオーバーロードの混乱があるなら isEqual でも、名前が変わって
メソッド名が中置されたという文法上の微妙な違い以外は変わらないです、
本質的な問題である「何について等しいのか」と点が混乱しているなら
どのように書かれようが結局混乱という事態は避けられていなかったのではと思う。

参照が等しいのか、それとも中身が等しいのか、そもそも中身が等しいとは何をもってなのか、
たとえば、オブジェクトがデータとキーの組のときなどは

組オブジェクトの参照が等しい
組オブジェクトの中のデータとキーの参照が等しい
組オブジェクトの中のデータとキーのインスタンスが等しい
組オブジェクトのそのもののインスタンスが等しい
組オブジェクトのキーの参照が等しい
組オブジェクトのキーのインスタンスが等しい

どれも isEqual で正当だと思う。

十分に注意深く意識して付けられたものはあまりないと思う。
C++ の stl などではファンクタにして外に放り出して解決してしまいましたが・・・
命名での解決は難しいと思う。
622 ：デフォルトの名無しさん：03/11/09 13:12
>>620
現状のC++では特に理由がない限りポインタの使用は避け、
コンテナあるいは参照、イテレーターを使う。
Cと違って滅多にポインタが使われることはなく、
そういった混乱はない。
623 ：デフォルトの名無しさん：03/11/09 13:17
>>620
それを言うなら適切な命名とやらも個人で異なる。

それにStringだって各要素を足すという解釈も出来る。
624 ：　：03/11/09 13:18
またすさまじく伸びたな。
625 ：デフォルトの名無しさん：03/11/09 13:22
Javaの仕様は理想的で美しいと思っている信者ならばこそ
異分子であるStringの+は否定すべきだ
626 ：デフォルトの名無しさん：03/11/09 13:24
使いやすいから、便利だからというだけで例外を認めてしまったら
M$となんら変わりがなくなる
627 ：デフォルトの名無しさん：03/11/09 13:29
どうでも良いけどうせ他人が書いた物を使う時は
資料無しじゃわからねーんだから。
演算子オーバーロードも資料かいときゃ良いだけじゃん。
628 ：デフォルトの名無しさん：03/11/09 13:30
>>585
C++ の iostream は醜いし、見にくいよ。
629 ：デフォルトの名無しさん：03/11/09 13:32
>>625
> Javaの仕様は理想的で美しいと思っている信者ならばこそ
> 異分子であるStringの+は否定すべきだ
そーゆー人はいるよ。
630 ：デフォルトの名無しさん：03/11/09 13:35
==はオブジェクトの同一性比較、isEqualはそのオブジェクトの性質にふさわしい
「中身」の比較、という切り分けにどんな混乱があるのかわからない。
あとファンクタとイテレータを誇っている時点でC++厨の視野の狭さが知れる。
Javaでも無名インナークラスとイテレータで同じ事が出来る。
631 ：デフォルトの名無しさん：03/11/09 13:40
>>630
まあ、参照についてはOOである以上最大重要要素なので分離しておく事に依存はないです。
Java ならば == でよいと思います。
しかし、オブジェクトの同一性についてはどうだろう。
これだけを取り出しても十分に混乱要因だと思いますが。

おお、別にファンクタなんぞ誇るつもりなどないです、あんなのもはただの関数ポインタでも十分です。
そうではなくて、何が問題で混乱が起こるのかという点を考えたいですね。
632 ：デフォルトの名無しさん：03/11/09 13:43
>あとファンクタとイテレータを誇っている時点

どこで誇ってると思ったんだ？お前の視野はあらぬ方向を向いてるな。
633 ：デフォルトの名無しさん：03/11/09 13:44

>しかし、オブジェクトの同一性についてはどうだろう。

オブジェクトの同一性比較は必要ないって言いたい訳ですか？
634 ：デフォルトの名無しさん：03/11/09 13:44
String a = "hoge";
は許されて
Integer b = 0;
が許されないのは統一性がないな
プリミティブなintとかなんて作らなければよかったのに
もしくはStringもプリミティブにしとけばいいのに
汚い仕様だな
635 ：デフォルトの名無しさん：03/11/09 13:48
>>632
==とisEqualの話には直接関係ない話だと思ったから。
話がすり替わってるよね。
636 ：デフォルトの名無しさん：03/11/09 13:53
>>635

>>621の

>C++ の stl などではファンクタにして外に放り出して解決してしまいましたが・・・
>命名での解決は難しいと思う。

ここに噛み付いてるの？・・・摩り替わってるかなぁ？それにイテレータはどこから出てきたんだ？
637 ：デフォルトの名無しさん：03/11/09 13:54
>>635
というか、話をすりかえたのはお前だろ！
638 ：デフォルトの名無しさん：03/11/09 13:56
ああ>>622でイテレータが出てきてるな。

まぁ>>622は何故か>>620の
>matrixのポインタなのかw（冗談だけど
の冗談に良く分からん突っ込みをしてる奴だから無視で
639 ：デフォルトの名無しさん：03/11/09 13:56
>>634
> String a = "hoge";
"hoge" は文字列リテラルで、
String型の変数に代入できるのは明らか。

> Integer b = 0;
0 は整数リテラルであって Integer のオブジェクトでは無いので、
Integer型の変数には代入できない。

とはいっても 1.5 で導入される Autoboxing では許されるかもしんない。
640 ：デフォルトの名無しさん：03/11/09 13:59
>>634
> プリミティブなintとかなんて作らなければよかったのに
確かにそーすれば、より一貫性がでるとは思う。

> もしくはStringもプリミティブにしとけばいいのに
それだと「汚い仕様」のまんまだと思うが…
641 ：デフォルトの名無しさん：03/11/09 14:00
つまりRuby最強と。。。
642 ：デフォルトの名無しさん：03/11/09 14:19
オブジェクトじゃないデータ型がある時点で
C++もJavaもOOPLとしてはどちらも三流なんだから
けんかしないで仲良くしとけ
643 ：java使いTai!：03/11/09 15:28
あら、なんか盛り上がってますね
・・・と思ったら全然関係無い方向に伸びてますね〜

で、思ったんですけど
「文字列を”プリミティブな値”として保持するStringクラスのようなもの」
があったらそれで万事解決しますね
644 ：デフォルトの名無しさん：03/11/09 15:43
>>643
> 「文字列を”プリミティブな値”として保持するStringクラスのようなもの」
> があったらそれで万事解決しますね
何が、どのように解決するのかサッパリわからん。
645 ：デフォルトの名無しさん：03/11/09 15:48
JavaとC++が死滅すればそれで万事解決
646 ：デフォルトの名無しさん：03/11/09 15:53
>>643
あぁ 「==」に関しては解決するのか。

でも String が Object のサブクラスでなくなるので
コレクションとかで String 使う時の使い勝手とかはメチャクチャ悪くなるね。
647 ：デフォルトの名無しさん：03/11/09 16:03
>>646
それは解決なのか？
>>643
値としての文字列が一致すればオブジェクトが異なっていても
それがわからなくなる。とても困ります。

648 ：デフォルトの名無しさん：03/11/09 16:06
>>647
> それは解決なのか？
java使いTai!氏にとっては「解決」するのです。

俺的に解釈すると
「String がプリミティブ型だ、と言い張ってしまえれば
　参照値の違いなんぞ知った事ではない」
ので「解決」するわけですね。
649 ：デフォルトの名無しさん：03/11/09 16:10
>>648
俺はint型のように参照型をやめてしまうという風に受け取ったのだが。。。
650 ：java使いTai!：03/11/09 16:11
>>647
うぇーい

Stringとは別に プリミティブな文字列としての
int に対する Integer のような、
たとえば string という型 ができたら
それで解決っすよね
（で、Stringはstringのラッパークラスになる！）

という話 なんですけど、なんかまずそうですかね
651 ：デフォルトの名無しさん：03/11/09 16:12
文字列がなぜ参照値として実装されているかつまり
理解できないということでつか？
652 ：デフォルトの名無しさん：03/11/09 16:16
>>640に同意でプリミティブを増やすのは言語として汚くなるだけ。
653 ：デフォルトの名無しさん：03/11/09 16:19
>>649
Java の byte code には殆ど空きがないから
String のプリミティブ型バージョンは殆ど操作できないだろうね。

String が本体で、String のプリミティブ型バージョンはStringの機能を大幅に削った型って事になりそう。
イメージとしては、Integer で四則演算できるのに、int では四則演算できないとかそーゆーかんじ。
654 ：java使いTai!：03/11/09 16:20
>>652
string という型をつくって文字列はそれで表現し
従来の String str = "hoge"; はそのまま残して、さらに
string s = "hoge";
String str = s; または String str = new String(s); を
表記できるようにちょっぴり仕様拡張して、
string型同士の比較は自由に出来るようにする というのなら
あまり波風立たないと思うんですけど・・・

プリミティブな型が増えるのを補って余りあるメリット（ていうか==）
があるような気がするんですけど、どでしょ。
コレがダメならまたなんか考えます

>>653
まあそれでもいいと思いますよ
もともとStringで四則演算できないですし
655 ：デフォルトの名無しさん：03/11/09 16:37
>>654
っつーか、String のプリミティブ型バージョンって
「==」で同値かどうかの比較ができる以外に何かあるの？

> あまり波風立たないと思うんですけど・・・
とか思うなら JCP とか BugParade で騒ぐなり
プリプロセッサ自作するなりすれば？

> もともとStringで四則演算できないですし
String には charAt() とか substring() とかメソッドいっぱいあるんだけど…
656 ：デフォルトの名無しさん：03/11/09 16:58
プリミティブ型にしたところでメリットがなく、性能も落ちるだろうね。
string型変数への代入は文字全体のコピーしか手段がないわけで。
そんなのオブジェクト指向じゃないよ。
657 ：デフォルトの名無しさん：03/11/09 17:05
内部でflyweightできるかもしれないだろ
658 ：デフォルトの名無しさん：03/11/09 17:06
>プリミティブ型にしたところでメリットがなく、性能も落ちるだろうね。
>string型変数への代入は文字全体のコピーしか手段がないわけで。

↑これから↓これ？

>そんなのオブジェクト指向じゃないよ。

ﾊｧ？お前にとってオブジェクト指向ってなんだよ。
659 ：デフォルトの名無しさん：03/11/09 17:07
>String には charAt() とか substring() とかメソッドいっぱいあるんだけど…

四則演算できないこととそのメソッドがあるのと何の関係が？
660 ：デフォルトの名無しさん：03/11/09 17:11
>>657
flyweight なら String でもやってますがな…
661 ：デフォルトの名無しさん：03/11/09 17:15
>>659
> >String には charAt() とか substring() とかメソッドいっぱいあるんだけど…
> 四則演算できないこととそのメソッドがあるのと何の関係が？

> > > イメージとしては、Integer で四則演算できるのに、int では四則演算できないとかそーゆーかんじ。
とは書いたけど…
別の言い方すれば「操作できない string」は「四則演算できない int 」と同じで役にたたんって事。
662 ：デフォルトの名無しさん：03/11/09 17:21
string型とやらは参照をもたない値型なんでしょ？
flyweightに出来るのは文字列中に含まれる文字オブジェクト
などのコストを軽減できるだけで、値型としての文字列には
関数の引数にするにも変数に代入するにも値のコピーが必要に
なる。そうじゃない？

663 ：java使いTai!：03/11/09 17:55
>>662
まあそぅなりますね・・・
でもそれはVM側でなんかうまいことやればいけそうな気がします。

>>661
string型なるものが出来たとして、
+ と == が出来ればまあいいかなぁと思うデスよ。
664 ：デフォルトの名無しさん：03/11/09 18:01
ちゃんと読んでないけどさ、
値型にできるとか言ってる香具師は固定長でいいのか？
string hoge PIC X(20)ってか？

C++だって文字列は普通は参照型にするんだぞ。
665 ：デフォルトの名無しさん：03/11/09 18:34
>>663
> + と == が出来ればまあいいかなぁと思うデスよ。
+ と == 以外は全然考慮に入ってないんじゃ？
666 ：デフォルトの名無しさん：03/11/09 18:35
コボラｷﾀｰ
667 ：デフォルトの名無しさん：03/11/09 18:35
>>663
> でもそれはVM側でなんかうまいことやればいけそうな気がします。
generics でも VM変更しなかったのに、
こんな役に立たんモンのために VM仕様を変更するとわけないだろ…
668 ：デフォルトの名無しさん：03/11/09 18:38
>>663
VMだろうがどこのレベルで対処しようが、文字列のコピーを行うか、
「参照を保持し、それを隠蔽する」という本末転倒な実装をするしかないでしょう。
やっぱり値型を増やすのは無駄ですね。
669 ：デフォルトの名無しさん：03/11/09 18:40
むしろVMの変更が難しい故、template をつけても役に立たないんだと思ふ
670 ：デフォルトの名無しさん：03/11/09 19:09
>>610
> オブジェクト指向をなめている奴がJavaを否定しgenericsなんてアホな機能をつけたがる。
Genericsは重要だ。だがC++のようなtemplate相当な余計な機能はいらない。
コレクション用のみに限定してtemplateを使えればいい
C++的な使い方をするとしっかりとコンパイルエラーがでるようにだ。
671 ：デフォルトの名無しさん：03/11/09 19:12
>>623
> >>620
> それを言うなら適切な命名とやらも個人で異なる。
それも、どのクラスのオブジェクトかがわかるので問題なし
672 ：デフォルトの名無しさん：03/11/09 19:15
>>639
> とはいっても 1.5 で導入される Autoboxing では許されるかもしんない。
いや、あれはC#とちょっ微妙に異なる仕様なようだ。
C#のようになんでもあり的で危険なことはやりにくいようになっているようだ。
673 ：デフォルトの名無しさん：03/11/09 19:20
キャストで十分、おれは型安全程度使われ方なら、ソースコードをかき乱すだけだから無いほうがいいな。
674 ：デフォルトの名無しさん：03/11/09 19:23
>>652
> >>640に同意でプリミティブを増やすのは言語として汚くなるだけ。
>
汚くなった言語仕様として、C#がいい例だね。
675 ：デフォルトの名無しさん：03/11/09 19:25
そんなにプリミティブが嫌ならsmalltalkでも使ってなさい
676 ：デフォルトの名無しさん：03/11/09 19:27
値型Stringは作るだけ無駄だな。
Stringクラスにあるすべてのメソッドを演算子だけで使えるか？
メソッドを使うときは結局String型にもどさなければならない。無駄無駄。

677 ：デフォルトの名無しさん：03/11/09 19:29
結論として、equals()を==に置き換えるメリットはあまりないようだ。
文字数がへったからそれでいいって？
アフォですか。
678 ：デフォルトの名無しさん：03/11/09 19:30
equalsと==が混在する環境は最悪だね。
679 ：デフォルトの名無しさん：03/11/09 19:30
>>673
コレクション系で困ったことは無いのか？
680 ：デフォルトの名無しさん：03/11/09 19:31
>>678
どこが最悪なんだか。
たかがStringクラスひとつのためだけに==の仕様を変更するとはアフォ
681 ：Rubyマンセー：03/11/09 19:35
>>678は参照の理解でつまずいたらしいな。

http://www.rubyist.net/〜matz/?date=20030730#p01

これでも嫁。
682 ：デフォルトの名無しさん：03/11/09 19:35
>>679
ない。
683 ：デフォルトの名無しさん：03/11/09 19:37
演算子のオーバーロードって重要なんだね。
684 ：デフォルトの名無しさん：03/11/09 19:38
>>681の途中の〜はチルダにかえてくれ。

685 ：デフォルトの名無しさん：03/11/09 19:47
>>681
shift+ハット(への字)でチルダを入力できるぞ
686 ：デフォルトの名無しさん：03/11/09 20:04
結局演算子オーバーローディングは読みやすくするためにある程度は必要だってことですね。
687 ：デフォルトの名無しさん：03/11/09 20:06
>>671
演算子オーバローディングでも分かるよ
688 ：java使いTai!：03/11/09 20:09
>>677
いや真骨頂はswitch文ッスよ。多分。なんとなく。

ていうか仲良く行きましょうよ
689 ：デフォルトの名無しさん：03/11/09 20:18
>>688
String で switch するのと String をプリミティブ型にするとゆーのは全く別の問題だと思われ。
690 ：デフォルトの名無しさん：03/11/09 20:40
「C＃ vs Java」
http://pc2.2ch.net/test/read.cgi/tech/1068377418/

新しい対戦相手の入場です。
691 ：デフォルトの名無しさん：03/11/09 21:02
>>690
すでに語りつくされ興味のあるネタは殆どないのだが。
徐々に厨房の煽り合いになって言語仕様とは関係ない話題、
アンチオープンソースだアンチWindowsだなんだの方向にすすんで
いつものように話がおかしくなる。
しかもC#マンセーな厨はほとんどVB厨で言語仕様の話よりもGUIの話しか興味を
もたない奴が多すぎで言ってることがほとんどつまんね。

692 ：デフォルトの名無しさん：03/11/09 21:03
>>688
そもそもswitch文マンセーな奴はDQN
693 ：java使いTai!：03/11/09 21:42
>>692
ハッハッハ
ソンナコトナイヨ
694 ：デフォルトの名無しさん：03/11/09 21:46
>>691
ならそもそもここにも来るなよ
695 ：デフォルトの名無しさん：03/11/09 22:01
「Delphi vs. Java」
http://pc2.2ch.net/test/read.cgi/tech/1068381137/

新しい対戦相手の入場です。
696 ：デフォルトの名無しさん：03/11/09 22:05
C++厨がクソスレ立ててるのか。わかりやすいね。
Java厨も少しは手加減してやれよ。
697 ：デフォルトの名無しさん：03/11/09 22:07
↑Java厨の自作自演の戯言
698 ：デフォルトの名無しさん：03/11/09 22:08
↑さっそく釣れました。（こいつがクソスレ立てた本人。）
699 ：デフォルトの名無しさん：03/11/09 22:29
↑Java厨の自作自演の戯言 。（こいつがクソスレ立てた本人。）
700 ：デフォルトの名無しさん：03/11/09 22:34
今時「釣れた」と抜かす奴はリア厨未満
701 ：デフォルトの名無しさん：03/11/09 23:16
>>695
またスレ立てたのかよ。
無駄にスレ立てんなよ
702 ：デフォルトの名無しさん：03/11/09 23:21
>>696
わざわざ vs. Java　と名がつくスレを複数もたてる奴はこのスレで暴れていたc++厨くらいだな
703 ：java使いTai!：03/11/09 23:34
>>689
==使いたいだけなのでミーの心の中では等価ですよ

全然関係無いけどphpなんかは
文字列を==等で比較すると数値化して比較するのに対し
switch文で検査すると文字列として扱うんですよ

いや、ホントに関係なかったですね
704 ：デフォルトの名無しさん：03/11/09 23:43
>>703
だったら自作でSwitchクラスでも作れ！
705 ：デフォルトの名無しさん：03/11/10 00:09
>>703
> > String で switch するのと String をプリミティブ型にするとゆーのは全く別の問題だと思われ。
> ==使いたいだけなのでミーの心の中では等価ですよ
「==」つかえるのと、switch できるのはあなたの願望以外に共通点は無いですね。
706 ：デフォルトの名無しさん：03/11/10 00:34
>>703
Java で、プリミティブ型は byte short char int long float double boolean の8種あるが、
switch で使えるのは byte short char int の4種だけ。
プリミティブ型になっても switch に使えるわけじゃない。
1.5 で追加される enum は Object のサブクラスだが、switch に使えるようになる(はず)。

とゆー事をみるに、switch できるかどうかに プリミティブ型であるかどうかは関係ない。
じゃ >>703 で等価といってるのは？？？
707 ：デフォルトの名無しさん：03/11/10 01:09
やっぱりJavaの仕様は糞だな
708 ：デフォルトの名無しさん：03/11/10 02:07
完全に仕様を満たした処理系が存在しないC++は仕様が糞なのか処理系が糞なのか
709 ：デフォルトの名無しさん：03/11/10 09:01
いずれにしてもC#はもっと糞
710 ：デフォルトの名無しさん：03/11/10 19:36
Java がコケルときスタックトレースしてくれるのは良いなぁ〜。
C++ にもホスイぞな。
711 ：デフォルトの名無しさん：03/11/10 21:49
>>710
そこそこのデバッガなら大概ついてるよ
712 ：デフォルトの名無しさん：03/11/10 22:07
>>711
デバッグ環境じゃなくて実行時にも出るの？
Javaのはソースの行位置まで出るよ。
713 ：デフォルトの名無しさん：03/11/10 22:58
>>712
> Javaのはソースの行位置まで出るよ。
コンパイルオプションに -g:none とか入ってるとソースの行番号でないけどね。
714 ：デフォルトの名無しさん：03/11/10 23:14
>>710
>>324
715 ：デフォルトの名無しさん：03/11/10 23:14
>>712
その場ではみれないけど、デバッグ情報残しておけばVCならide立ち上げるからそこで見れるし。
gccなら例外時に生成される core ファイルから追えるよ。
ところでスタックトレースの概念はC++どころかCの頃からあるんだけど・・・
716 ：デフォルトの名無しさん：03/11/11 07:15

　　　　　　　　　v――.､
　　　　　　／　　!　　　　 ＼
　　 　 　 /　　 ,ｲ　　　　　　ヽ
　　　　 /　 _,,,ﾉ !）ﾉﾘﾊ　　　　i 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　i　　jr三ミ__r;三ミ_　　 ヽ 　　　　
　　　　l　 ,iヾ二ノ ヽ二 ハ　　 ﾉ　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　ヽ､.l　　,.r､_,っ､　　!_, 　　　＜　 >>1 糞スレ立てんな、蛆虫、氏ね。
　　　　　　 !　 rrrrrrrｧi!　L.　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　 ゝ､^'ｰ=~''"' ;,∧入
　　　,r‐‐'"／ >､＿_,r‐ﾂ./ 　 ヽ_
　　/　　／　 i"　i,　..:　 /　　/　 ヽ-､ 　　
　./　　ヽ＞　l　　　　／　　 i　　　　　＼
717 ：304：03/11/11 19:02
なんか俺のせいで大荒れですか？
javaのタブーに触れてしまったんだろうか。

上のほうで誰か書いてたけど、プリミティブ型はないほうがいいんじゃないか？
全部Objectのサブクラスなほうがすっきりするし。
コンテナに直接intを突っ込めないのはｷﾓｲ。
Stringと同じように、Integer等にも演算子使えるようにすればずっとすっきりすると思うんだがどうか。
718 ：java使いTai!：03/11/11 19:25
>>704
Switchクラスはおもしろそうですね
こういう処理を実現するとき、やっぱif文の羅列はどうかなと思うんですよ
　　switch( s ) {
　　　case "jackonly":
　　　　are();
　　　　break;
　　　case "king":
　　　　kore();
　　　　break;
　　}
みなさんはどうしてるんですか？
719 ：デフォルトの名無しさん：03/11/11 19:25
>>717
> Stringと同じように、Integer等にも演算子使えるようにすればずっとすっきりすると思うんだがどうか。
四則演算とかでオーバーロードを認めると <、>、<=、>= 等のオーバーロードもしたい、
==、!= もオーバーロードしたい、と要求がエスカレートするのは目に見えている。
ところが、Java では == と != が、既に参照が同じかどうかの比較に使われているので、
参照型に == と != のオーバーロードを認めると面倒くさい事態になる。

演算子のオーバーロードの良し悪しにかかわらず、
Java に演算子のオーバーロードを追加した方が良いというのは、
極端にセンスが無いか、追加した後どーなるかを何も考えてないかのどちらか。
720 ：デフォルトの名無しさん：03/11/11 19:28
本物のプログラマは演算子の多重定義はしない
721 ：デフォルトの名無しさん：03/11/11 19:30
>>717
> コンテナに直接intを突っ込めないのはｷﾓｲ。
1.5 で、見かけとしては出来るようになる予定。
722 ：717：03/11/11 19:31
>>719
いや、演算子オーバーロードを使えるようにするわけじゃなくて、
Stringで＋が使えるようにInteger、Doubleといった特定の型で演算子を使えるようにするんだよ。
723 ：デフォルトの名無しさん：03/11/11 19:32
Java厨にはオーバーロードの利点すら理解できんか（ｗ
724 ：デフォルトの名無しさん：03/11/11 19:33
>>718
if 文の羅列かな？
String での switch って滅多に使わないし、問題無い。
725 ：デフォルトの名無しさん：03/11/11 19:34
Javaの言語仕様は完璧です。
何かを増やしても
何かを減らしても
その言語はクソでしかありません。
726 ：717：03/11/11 19:34
> 四則演算とかでオーバーロードを認めると <、>、<=、>= 等のオーバーロードもしたい、
> ==、!= もオーバーロードしたい、と要求がエスカレートするのは目に見えている。
あー、そういうことか。
でもこれってもしかしてプリミティブ型とクラスでは==の動作が違うって事？
727 ：デフォルトの名無しさん：03/11/11 19:34
>>724
ダセッ。
728 ：デフォルトの名無しさん：03/11/11 19:37
>>722
> Stringで＋が使えるようにInteger、Doubleといった特定の型で演算子を使えるようにするんだよ。
普通の Java プログラマなら Integer や Double に演算子が使えてもそれほど嬉しくない。

っつーか、無闇やたらと提案するよか、実際にプリプロセッサなり作ってみたら？
Integer や Double で演算できると便利になるか簡単にわかるでしょ。
729 ：デフォルトの名無しさん：03/11/11 19:38
>>724
コンパイラの文法解釈とか、htmlの解釈とか使う機会は
いくらでもあると思うが。
730 ：デフォルトの名無しさん：03/11/11 19:40
>>729
ネタならもう少しおもしろいことを言おう
731 ：デフォルトの名無しさん：03/11/11 19:41
> 普通の Java プログラマ
便利な言葉だな。
使えて嬉しいと思えば、それは普通のJavaプログラマじゃないで
終わらせるわけか。普通のJavaプログラマってなんだよ。
732 ：デフォルトの名無しさん：03/11/11 19:41
>>730
一人脱落（ｗ
733 ：デフォルトの名無しさん：03/11/11 19:43
メチャクチャ臆病なんですなJavaというやつは。
トラブルは起こらないが進展も無い、自ら未来に進む事を辞めた言語ですね。
もっとも、ここで進展したりなどすると利点を全て失って自爆しそうな状況でもあるという事情もありそうですが。
734 ：デフォルトの名無しさん：03/11/11 19:44
ここでC++厨のふりをしてJava厨を煽っているのはC#厨ですので間違えないでくださいね。
735 ：java使いTai!：03/11/11 19:55
>>728
文字列を数字に直して計算して計算結果を文字列に直すときとか
そのつどparseなんとかにつっこんだりとかするので
Integerでそのまま計算できたらやっぱり便利だと思いますよ。

intとIntegerの型変換が暗黙で行われるとか
なんかそんなのがあったりすると面白かもしれないですね
シンタックスシュガーとして実装するとか・・？
736 ：デフォルトの名無しさん：03/11/11 19:59
>>734
なんで？（ｗ
737 ：デフォルトの名無しさん：03/11/11 20:00
>>735
C#で実現済み。
738 ：717：03/11/11 20:07
>>728
というか、intとかのｷﾓｲプリミティブ型をなくすのが目的。
プリミティブなんかOOに反してる！キモイ！差別！出て行け！
んでもって>>735の言うような暗黙の型変換機能をつければ互換性もバッチリ（たぶん

っていうか漏れはjavaなんて学校の実習で3回くらいいじっただけで無知そのものなんだけどな（ごめん
739 ：デフォルトの名無しさん：03/11/11 20:10
正直言ってメソッドがオブジェクトじゃない
Javaなんて全然オブジェクト指向じゃない。
740 ：java使いTai!：03/11/11 20:13
ちょっと考えてみましたけど
Integerの暗黙の型変換 は副作用がなさそうですね
Javaでも実装されるといいなぁ
もうあるのかな
741 ：デフォルトの名無しさん：03/11/11 20:16
>>735
> intとIntegerの型変換が暗黙で行われるとか
> なんかそんなのがあったりすると面白かもしれないですね
だから 1.5 から Autoboxing が追加されると何度も…
742 ：java使いTai!：03/11/11 20:19
>>741
すみません

ついでにswitch文で文字列比較も出来るようになるといいですね
743 ：デフォルトの名無しさん：03/11/11 20:20
>>733
> トラブルは起こらないが進展も無い、自ら未来に進む事を辞めた言語ですね。
機能を追加すれば「進展」だ、とか能天気に思わなくなっただけですね。

generics とかちゃんと追加されるし。
744 ：デフォルトの名無しさん：03/11/11 20:22
そしてまたJavaの仕様が肥大し汚くなっていく
745 ：デフォルトの名無しさん：03/11/11 20:23
>>729
Java の構文のサブセットならパーサー書いたことあるけど、
String の switch なんて使える場所なんて無かったと思うが…

Java の構文解析で String の switch をどう使うか例示してみてくれる？
746 ：デフォルトの名無しさん：03/11/11 20:27
>>735
> 文字列を数字に直して計算して計算結果を文字列に直すときとか
> そのつどparseなんとかにつっこんだりとかするので
> Integerでそのまま計算できたらやっぱり便利だと思いますよ。
Integer で計算できても、
文字列から Integer に変換するのには明示的にメソッド呼ばなきゃいかんし、
Integer から文字列にするのには 暗黙の toString() もしくは明示的なメソッド呼び出しが必要になる。

っつーか、「文字列<->Integer の変換」と「Integer で計算できる事」は関係ないと思われ。
747 ：デフォルトの名無しさん：03/11/11 20:29
>>738
> というか、intとかのｷﾓｲプリミティブ型をなくすのが目的。
そんなら Smalltalk 使えば？
748 ：デフォルトの名無しさん：03/11/11 20:29
>>743
> 機能を追加すれば「進展」だ、とか能天気に思わなくなっただけですね。
意味わかりません。どういう状態が進展なんですか？
genericsが追加されることは進展じゃないんですか？
749 ：java使いTai!：03/11/11 20:29
>>746
まあ最初の一発目のとっかかりのString→Integerは
手動でやんなきゃですね。そこはしょうがない・・・かな
750 ：デフォルトの名無しさん：03/11/11 20:31
正直言って、「java使いTai!」はアニヲタなわけだが。
Java厨＝アニヲタ。
751 ：デフォルトの名無しさん：03/11/11 20:32
>>748
>>733 が「進展」だ、と思うような状態。
752 ：java使いTai!：03/11/11 20:33
>>750
それは偏見ですね
他の趣味を持っている人はいっぱいいますよ
私はたまたまそれがアレだっただけで
753 ：デフォルトの名無しさん：03/11/11 20:33
>>750
今までの話を見るに、「java使いTai!」は Java を使った事が(殆ど)ないようだが。
754 ：デフォルトの名無しさん：03/11/11 20:33
>>751
お前は>>733なのか？ なんで他人の思っている状態が分かるんだ？
自分の言葉で言え。
755 ：デフォルトの名無しさん：03/11/11 20:36
>>749
っつーか、現在の状態でも
文字列 -> int の parse を明示的にやれば、
あとは演算子で計算できるし 文字列への変換も
Integer の暗黙の toString() と同様に 暗黙の String.valueOf() で行われるのだが…
756 ：デフォルトの名無しさん：03/11/11 20:38
>>748
> 意味わかりません。どういう状態が進展なんですか？
generics が追加されるような状態は進展。

演算子のオーバーロードが無原則に許されるような状態は進展じゃない。
757 ：デフォルトの名無しさん：03/11/11 20:41
>>756
要するに自分の趣味じゃん。
もしくはJavaにしたがいます。
Javaが行うことはすべて進展です。
一生Javaに付いて逝きます。ですか？
758 ：デフォルトの名無しさん：03/11/11 20:44
>>757
> 要するに自分の趣味じゃん。
趣味だけじゃないんだけど･･･

例えば、演算子のオーバーロードが無原則に許されると >>719 で書いたように
今現在存在する 参照型等価演算子と衝突するので、進展じゃない。
759 ：デフォルトの名無しさん：03/11/11 20:46
"a" + "b" == "ab";
と
String a = "a", b = "b", ab = "ab";
a + b == ab;
が等価にならないところがJavaは気持ち悪い
文字列リテラルってStringのインスタンスじゃないんですね
760 ：デフォルトの名無しさん：03/11/11 20:49
>>759
> 文字列リテラルってStringのインスタンスじゃないんですね
違う。

「数字」と 「1」が違うように
「文字列リテラル」と「Stringのインスタンス」は別の概念。
761 ：デフォルトの名無しさん：03/11/11 20:51
>>759
> が等価にならないところがJavaは気持ち悪い
とか思うなら Java より自分の理想に近い言語を作るとかすれば良いわけで…
762 ：デフォルトの名無しさん：03/11/11 20:57
>>745
> Java の構文解析で String の switch をどう使うか例示してみてくれる？
あぁ、Statement の解析で Statement の先頭にくる "if" とか "switch" とか "try" とかの分岐で使おうと思えば使えるかも。
でも使えるのってそこだけだと思うけど…
763 ：デフォルトの名無しさん：03/11/11 21:00
Javaって構文解析にしかswitch使わないものなの?
764 ：デフォルトの名無しさん：03/11/11 21:02
>>763
String の switch は使い道が殆ど無いっていったら
構文解析に使うって話がでたので、>>745 はその続き。

っつか、ちっとはスレ読んでから書けよ…
765 ：デフォルトの名無しさん：03/11/11 21:36
>>761
お前のような奴が沢山いたらJavaにgenericsが
採用されることも無かっただろうな。

「Javaにgenericsを搭載しよう。」
「却下。気に入らないのなら自分の理想に近い言語を作れ。」

お前迷惑。
766 ：デフォルトの名無しさん：03/11/11 21:40
>>765
> お前のような奴が沢山いたらJavaにgenericsが
それは逆。
実際に実物を提示された方が説得力あるし、議論もできる。

> 「Javaにgenericsを搭載しよう。」
>「却下。気に入らないのなら自分の理想に近い言語を作れ。」
「作ったよ。こーゆーふーに実装したら VM も変更しなくて良いし」
「んじゃ、それ採用」
(実際にはもっとイロイロあったらしいが)
767 ：デフォルトの名無しさん：03/11/11 21:48
>>766
却下。気に入らないのなら自分の理想に近い言語を作れ。
768 ：デフォルトの名無しさん：03/11/11 21:50
>>766
いーねー。オーバーロードは却下しといて
genericsだけ都合のいい話にする。
自己厨とはお前のこと。
769 ：デフォルトの名無しさん：03/11/11 21:52
> 「Javaにgenericsを搭載しよう。」
>「却下。気に入らないのなら自分の理想に近い言語を作れ。」
「作ったよ。こーゆーふーに実装したら VM も変更しなくて良いし」

ここで却下厨は。
「却下。気に入らないのなら自分の理想に近い言語を作れ。」
という。やはり迷惑。
770 ：デフォルトの名無しさん：03/11/11 21:54
>>769
> ここで却下厨は。
>「却下。気に入らないのなら自分の理想に近い言語を作れ。」
> という。やはり迷惑。

そんな妄想の話されても困りますぅ
771 ：デフォルトの名無しさん：03/11/11 21:57
現に、気に入らないから自分の理想に近い言語を作れといっているわけで、
全然説得力無い。
772 ：java使いTai!：03/11/11 21:58
>>760
文字リテラルをあらわす型がほしくなりますよね、やっぱり
773 ：デフォルトの名無しさん：03/11/11 22:00
>>771
> 現に、気に入らないから自分の理想に近い言語を作れといっているわけで、
既存の言語に不満があるなら、不満点を改善した実装を作れと言ってるだけ。
774 ：デフォルトの名無しさん：03/11/11 22:01
>>772
> 文字リテラルをあらわす型がほしくなりますよね、やっぱり
文字列リテラルをあらわす型って？？？
775 ：デフォルトの名無しさん：03/11/11 22:05
言語仕様の決定なんてすべて惨の独断だろ？(ｹﾞﾗ
話し合いも糞もない。なぜならJavaは惨の独占私有物だから。(大爆笑
776 ：デフォルトの名無しさん：03/11/11 22:06
>>775
ならば$unが倒産したらJavaは死亡だね
777 ：デフォルトの名無しさん：03/11/11 22:09
>>775
> 言語仕様の決定なんてすべて惨の独断だろ？(ｹﾞﾗ
JCP とか知らんのかいな…
778 ：デフォルトの名無しさん：03/11/11 22:09
別に倒産しなくても現時点で死滅寸前だろ。派遣を除いて。www
779 ：デフォルトの名無しさん：03/11/11 22:10
>>773
自分で作ったわけでもないのに偉そうですな（ｗ
780 ：デフォルトの名無しさん：03/11/11 22:12
>>777
だらだらと話し合ってるフリしてる糞団体だろ？(ｹﾞﾗ
それで忘れかけた頃に惨が独断で決定。
781 ：デフォルトの名無しさん：03/11/11 22:12
Javaはバイトコードの仕様いじれないから改良はあっても進化はない
782 ：デフォルトの名無しさん：03/11/11 22:16
>>780
> だらだらと話し合ってるフリしてる糞団体だろ？(ｹﾞﾗ
えーと、「だらだらと話し合ってるフリ」の具体例とかｷﾎﾞﾝﾇ
783 ：デフォルトの名無しさん：03/11/11 22:23
>>780
> それで忘れかけた頃に惨が独断で決定。
ついでに、「忘れかけた頃に惨が独断で決定」の具体例とかｷﾎﾞﾝﾇ
784 ：デフォルトの名無しさん：03/11/11 22:25
JCPって日本共産党？
785 ：デフォルトの名無しさん：03/11/11 22:27
>>784
Java Community Process。www.jcp.org ね。
786 ：デフォルトの名無しさん：03/11/11 22:28
>>784
.or.jpじゃなくて.org
と釣られてみる
787 ：デフォルトの名無しさん：03/11/11 22:35
そっか。だからJava使いには左っぽいのが多いのか。
788 ：デフォルトの名無しさん：03/11/11 22:35
>>784
まさに話し合いで解決だな。(ｹﾞﾗ
789 ：デフォルトの名無しさん：03/11/11 22:42
上層部独裁なのもそっくり
790 ：デフォルトの名無しさん：03/11/11 22:46
>>780
> だらだらと話し合ってるフリしてる糞団体だろ？(ｹﾞﾗ
えーと、「だらだらと話し合ってるフリ」の具体例とかｷﾎﾞﾝﾇ
791 ：デフォルトの名無しさん：03/11/11 22:46
>>780
> それで忘れかけた頃に惨が独断で決定。
ついでに、「忘れかけた頃に惨が独断で決定」の具体例とかｷﾎﾞﾝﾇ
792 ：　：03/11/11 23:07
なんかローカルあぼーんだらけになってきた
793 ：デフォルトの名無しさん：03/11/11 23:57
なんか知らんが、C++とJava両方をちゃんとわかってるやつらが、
自分の好みだけで議論してね？
そんだけわかってるんなら、普通に、両方使えばいいじゃんよ？
794 ：デフォルトの名無しさん：03/11/11 23:59
勘定(´,_ゝ｀)ﾌﾟｯ行
795 ：デフォルトの名無しさん：03/11/11 23:59
どうでもいいがJavaで演算子オーバローディングを実現する実装は転がってるでよ
796 ：デフォルトの名無しさん：03/11/12 00:00
Javaの

アブストラクタ
インプリメント

がわからねー。　
継承だけでいいじゃん。
797 ：デフォルトの名無しさん：03/11/12 00:05
>>796
継承だと多重継承が出来ない。困る。すごく困る。
だからインターフェイスのインプリメントを使う。
アブストラクトは空の関数を定義するときなどに使う。
それ単体でインスタンス化されるとヤバイため、
仮想であることを明示しないと危険だ。だからアブストラクトにする。
798 ：デフォルトの名無しさん：03/11/12 00:06
>>796
> アブストラクタ
アブストラクタ？
799 ：796：03/11/12 00:13
>それ単体でインスタンス化されるとヤバイため、
>仮想であることを明示しないと危険だ。だからアブストラクトにする。

なぜヤバイ、危険なのでしょうか？
800 ：デフォルトの名無しさん：03/11/12 00:13
class abstract Hoge implements Fooable, Barable { // インスタンス化できない。
　public abstract void hoge();
　public void foo() { System.out.println("Huga#foo"); }
　public void bar() { System.out.println("Huga#bar"); }
}
class Huga extends Hoge {
　public void hoge() { System.out.println("Huga#hoge"); }
}

Huga huga = new Huga();
huga.hoge(); // Hugaはhogeメソッドを実装している
Fooable foo = huga;
foo.foo(); // FooableインターフェイスはHogeクラスで実装されている
Fooable bar = huga;
foo.bar(); // BarableインターフェイスはHogeクラスで実装されている

801 ：デフォルトの名無しさん：03/11/12 00:21
>>799
危険の理由は様々だ。
例えば、nullを返すメソッドが定義されたAbstractクラスがあったとする。
public class AbstractSample { // インスタンス化できる
　public String hoge() { String result = null; return result; }
}
もしインスタンス化が自由に行えたら、このクラスを生成して、
NullPointerExceptionを出すクラス利用者が現れるかもしれない。

そこで、継承しないとインスタンス化できないようにしてしまう。
public abstract class AbstractSample { // インスタンス化できる
　public String hoge() { String result = null; return result; }
}
もう安心だ。
802 ：796：03/11/12 00:22
>>800

これぅて
class Huge extends Hoge {
↓
class Huga:public Fooable, public Barable{

と同義？C++で
Fooable foo = huga;　
ってできるんだっけ？
803 ：796：03/11/12 00:23
>>801
ありがとうございます。勉強になります。
804 ：デフォルトの名無しさん：03/11/12 00:23
>>799
> なぜヤバイ、危険なのでしょうか？
仮に、C++ で純粋仮想関数を持ったクラスのインスタンスが生成できて、
そのインスタンスの純粋仮想関数を呼び出されたら危険じゃない？
805 ：デフォルトの名無しさん：03/11/12 00:24
>>717
> 上のほうで誰か書いてたけど、プリミティブ型はないほうがいいんじゃないか？
んなお前はSmalltalkでもやってろと。
806 ：デフォルトの名無しさん：03/11/12 00:26
>>729
> >>724
> コンパイラの文法解釈とか、htmlの解釈とか使う機会は
> いくらでもあると思うが。
HTMLにswitchなんぞいまどき使わん。
XML Parserを使うのが常識。
807 ：デフォルトの名無しさん：03/11/12 00:28
全てのswitch文は、いずれポリモーフィズムに置き換えられるべきです。
808 ：デフォルトの名無しさん：03/11/12 00:30
>>807
全てとは言わんが、ポリモーフィズムを上手く使えば switch が必要なケースは減るね。
809 ：デフォルトの名無しさん：03/11/12 00:31
>>805
>>747
810 ：717：03/11/12 00:31
>>805
それ言われたの2回目だぞ
SmallTalkは確かに楽しそうだけどコメントが"こんな"なのは超ｷﾓｲ｡
やはり俺はC++を愛しているんだ！多重継承と演算子オーバーライドと暗黙の型変換とテンプレートがない言語なんか糞だ！！！！１
ﾌｧｯｸ
811 ：デフォルトの名無しさん：03/11/12 00:35
>>775-
あたりから嘲笑激藁厨が現れたな。
馬鹿は死滅スレに帰れや。
812 ：デフォルトの名無しさん：03/11/12 00:36
>>810
同じこと書いている香具師がいることがあとから読んできがついた。
つーかお前、C++を愛しているくせに値型を嫌っているだと。
いっていることが矛盾してるぞw
813 ：717：03/11/12 00:42
>>812
C++はｷﾓｲのがいいんだよ。
なんだよjavaの中途半端さは。OO目指すならもっとストイックっつーかファナティックにやってほしいもんだ。
814 ：デフォルトの名無しさん：03/11/12 00:55
タダの愚痴か
C++のどこがOOを目指しているんだか。
C++のほうが十分中途半端なのだが。
とにかく矛盾だらけだな
815 ：デフォルトの名無しさん：03/11/12 01:43
C++は演算子オーバーロードが使えるところぐらいかな。
そのうちJSRでもあがってくるだろうよ。
816 ：デフォルトの名無しさん：03/11/12 01:43
>>815
あがっちゃぁ消え、あがっちゃあ消え。
817 ：デフォルトの名無しさん：03/11/12 01:44
>>815
> そのうちJSRでもあがってくるだろうよ。

>>719 でも読んでください。
818 ：デフォルトの名無しさん：03/11/12 02:46
Javaに移行してもいいと思う。以下の二点さえ満たせばね。
１）ネイティブコードを吐くこと
　(アプリもサーバーもソース互換で充分だ)
２）テンプレートを中心にした標準ライブラリの構築
コンパイラはSUNの奴は捨ててexeを吐くgcjを標準にする。
swingも基本設計だけ残してネイティブコードで実装しなおし。
Javaはもっさりしすぎ。
819 ：デフォルトの名無しさん：03/11/12 02:48
>>818
Java に移行しなければ良いだけでは？
820 ：デフォルトの名無しさん：03/11/12 02:56
>>819
現状のC++言語とSTLには満足しているが、
MFCとかつかいずらくてswingみたいなラクチンなのが欲しい。
GUIとかのライブラリパッケージはJavaの方が好きなんだよね。
821 ：デフォルトの名無しさん：03/11/12 03:24
>>820
C++BuilderでVCL使えば？
JavaのライブラリはVCL参考にしてるわけだし。
822 ：デフォルトの名無しさん：03/11/12 03:56
>>821
VCLにレイアウト機能があればなぁってgtkみたいに。
GUIビルダー使わんプログラムの場合、VCL使いずらい。
(XHTMLのタグを読んで実行中に動的にフォームを生成なんて場合、
RADツールって何の役にも立たんです)。
あとAnsiStringとstd::stringの使い分けって統一感ないし。
823 ：デフォルトの名無しさん：03/11/12 04:05
>>822
「使いづらい」ね。つらいんだよ。

VCLの世界ならAnsiString使うようにしてるけど。
824 ：デフォルトの名無しさん：03/11/12 05:33
gcjからswt使うというのはどうよ？
825 ：デフォルトの名無しさん：03/11/12 07:06
>>822
> (XHTMLのタグを読んで実行中に動的にフォームを生成なんて場合、
RAD ツールを使うなら IE コンポーネントとかを使うのが作法では？
826 ：デフォルトの名無しさん：03/11/12 07:40
>>818
> Javaに移行してもいいと思う。以下の二点さえ満たせばね。
> １）ネイティブコードを吐くこと
> 　(アプリもサーバーもソース互換で充分だ)
JavaChipやJETコンパイラとかでも使えと。

> ２）テンプレートを中心にした標準ライブラリの構築
Java Genericsでもダウンロードして使え

> swingも基本設計だけ残してネイティブコードで実装しなおし。
ＳＷＴでも使え。

以上
827 ：デフォルトの名無しさん：03/11/12 08:01
>>826
> > ２）テンプレートを中心にした標準ライブラリの構築
> Java Genericsでもダウンロードして使え
Java の generics と C++ の template は全く別物だと思われ…

> > swingも基本設計だけ残してネイティブコードで実装しなおし。
> ＳＷＴでも使え。
SWT と Swing って設計思想から違うよーな。
828 ：デフォルトの名無しさん：03/11/12 08:05
>>818
> ２）テンプレートを中心にした標準ライブラリの構築
まぁ、コレクションを中心にした標準ライブラリって意味では既にあるよね。
829 ：デフォルトの名無しさん：03/11/12 08:20
C++のようなオブジェクト指向に反する使い方をできるtemplateは
Javaにとってチンカスのゴミ以下であrりJavaを汚す。
そんな糞機能はJavaには必要が無い。
830 ：デフォルトの名無しさん：03/11/12 08:32
Java厨ってJavaをさも最高のオブジェクト指向言語のように語ってC++,C#を貶すよな
完全なオブジェクト指向言語じゃ無いくせに。
831 ：デフォルトの名無しさん：03/11/12 08:36
オブジェクト指向らしさうんぬんとかがいいから
Javaがいいとかではないだろ。
拡張性を保ちつつ効率よく使えればいいってことだけだろ。
その点ではC++,C#ではJavaには勝てない、それだけのこと。
ただの宗教戦争のように
最高のオブジェクト指向だからなんたらとかの問題ではないということ。

832 ：デフォルトの名無しさん：03/11/12 08:37
その機能を入れるとオブジェクト指向が汚れる！そればっか。
もうプリミティブ型入れてる時点で汚れてるっつーに
833 ：デフォルトの名無しさん：03/11/12 08:39
>拡張性を保ちつつ効率よく使えればいいってことだけだろ。
>その点ではC++,C#ではJavaには勝てない、それだけのこと。

えーと、「拡張性を保ちつつ効率よく使える点ではC++,C#ではJavaには勝てない」の具体例とかｷﾎﾞﾝﾇ
834 ：デフォルトの名無しさん：03/11/12 08:47
>>829-833
自作自演？
835 ：デフォルトの名無しさん：03/11/12 10:01
>>832
> その機能を入れるとオブジェクト指向が汚れる！そればっか。
> もうプリミティブ型入れてる時点で汚れてるっつーに
おまえのいっとる「穢れる」は実体験に基づいていないので信用できない。
実際に使ってみてソースが穢れメンテナンス性を悪くする
可能性があるのが「穢れる」だ。
ﾌﾟリミティブ型程度で穢れてコーディングに困ったのかお前は。
Smalltalkもやったことが無いくせにアホなことを言うな。
836 ：デフォルトの名無しさん：03/11/12 10:03
>>830
C#にはtemplateはまだないぞ
837 ：デフォルトの名無しさん：03/11/12 11:03
>>832
オブジェクト指向が汚れる、とは言ってないと思うが。
オペレーターオーバーロードなんかは、コードの信頼性が下がる、と言ってるだけじゃないの？
とりあえず、オブジェクト指向が汚れると言う理由で却下されてる機能キボンヌ。
838 ：デフォルトの名無しさん：03/11/12 13:53
>オペレーターオーバーロードなんかは、コードの信頼性が下がる、と言ってるだけじゃないの
オペレータオーバーロードは信頼性を上げる事もあれば下げる事もある。
オペレーターオーバーロードがあれば上げる事はできる。
オペレーターオーバーロードがなければ下がる事はないが上げる事はできない。
それだけの事。
839 ：デフォルトの名無しさん：03/11/12 14:22
Javaをオブジェクト指向どうこうでけなしてるやつって、結局Javaに限らずオブジェクト指向についてこれなかったヤツということでよろしいか？
840 ：デフォルトの名無しさん：03/11/12 14:31
JavaはC++などよりコード量が多いからequals()を==にかえたほうがいいとか
C#やPerl, Delphiにあるforeachが無いのか糞だとか

ほざく馬鹿はJakarta Velocityを使って目を覚ませ。
841 ：デフォルトの名無しさん：03/11/12 14:37
>>840
> JavaはC++などよりコード量が多いからequals()を==にかえたほうがいいとか
コード量を理由に equals() を == に変えろってのは聞いた事無いね。

コード量の話で言えばいつだったか C# vs Java vs C++ のベンチマークをやってた外人のコードだと、
C# と Java は殆ど同じで C++ はそれらより 1.3 倍ぐらい多かった(行数で数えて)気がする。

> C#やPerl, Delphiにあるforeachが無いのか糞だとか
1.5 で for が拡張されますね。
842 ：デフォルトの名無しさん：03/11/12 14:41
>>838
> オペレータオーバーロードは信頼性を上げる事もあれば下げる事もある。
どーゆー時に信頼性が上がって、どーゆー時に信頼性が下がるんすか？
843 ：デフォルトの名無しさん：03/11/12 14:42
>>839
アンチJava厨の自作自演じゃなかったの？
844 ：デフォルトの名無しさん：03/11/12 14:46
>>839
連中はオブジェクト指向と直接関係無い低レベルな部分で必死に貶そうとしているだけ。
もとからレベルが低く大規模開発に携わる器も無い奴なので
そういうことでよろしい。　
845 ：デフォルトの名無しさん：03/11/12 14:48
>>844
いつもながら妄想だらけだな（ｗ
846 ：デフォルトの名無しさん：03/11/12 14:51
>>841
foreachの追加がもう確実？
847 ：デフォルトの名無しさん：03/11/12 15:07
>>846
> foreachの追加がもう確実？
もう確実って…
http://www.jcp.org/en/jsr/detail?id=201
去年の暮れだったかにでた JSR-201 で
enum、enhanced for、autoboxing、static import の導入が提案されてる。

enhanced for は構文とかで問題ないみたいだから提案されてるやつがそのまんま採用されんじゃないか？
848 ：デフォルトの名無しさん：03/11/12 15:09
いままで否定していた物が採用される。
あれほど、いらない。ある奴はクソと言い続けていたのに。
Java使いの信念が否定されたようだ。
849 ：デフォルトの名無しさん：03/11/12 15:15
>>848
いらない、とはいってないと思うのだが。
危険性が高い方法では要らない、とは言ってたと思うが。
Genericsなんて、昔から要るいると言われてたわけだが。
850 ：デフォルトの名無しさん：03/11/12 15:17
>>842
考えなしにオペレーターオーバーロードして、その演算子でなにをしてるかわかりにくくなったときに信頼性は下がる。
考えられた直感的なオペレーターオーバーロードの場合、コード記述の効率が上がる。結果、信頼性も間接的にあがる。
851 ：デフォルトの名無しさん：03/11/12 16:07
>>850
> 考えられた直感的なオペレーターオーバーロードの場合、コード記述の効率が上がる。結果、信頼性も間接的にあがる。
ここの「〜。結果、〜」の前後の因果関係は相当怪しいね。
852 ：デフォルトの名無しさん：03/11/12 16:11
>>848
> あれほど、いらない。ある奴はクソと言い続けていたのに。
具体的に、誰が、何を、いらない、とか クソ、と言い続けたんで？

個人的に enum (C/C++/C# みたいな int の enum じゃないやつ)は必要だといってたけど。
853 ：デフォルトの名無しさん：03/11/12 16:54
結局Javaはまだまだなんだよなぁ。
進化するたびにC#に近づいていく。
854 ：デフォルトの名無しさん：03/11/12 17:05
>>853
後だしジャンケンを誇られてもね。
そもそもC#はJavaのパクリなわけで。
855 ：デフォルトの名無しさん：03/11/12 17:10
1.5で取り入れられそうな、enumもC#と同じタイプセーフなenumだしね。

>>852はなんか勘違いしているみたいだけど。
856 ：850：03/11/12 17:11
>>851
うん。あやしい。
だから、弊害が起こる可能性の方が高い。
でオペレーターオーバーロードは却下となるわけで。
857 ：デフォルトの名無しさん：03/11/12 17:12
>>854
そのJavaもC++やその他のパクリなわけだが。
858 ：デフォルトの名無しさん：03/11/12 17:35
んでも実際問題として、Smalltalk みたいな変数に型の無い言語は別としてC++ で
加減乗除なんかのオペレータのオーバーロードが関数より「なにしてるかわからん・
間違いやすい」なんてことある？

代入演算子のオーバーロードもダメ？ a = b はダメで、 a.set(b) とかするべき？
比較演算子もダメ？なーんか納得いかない。。。
859 ：デフォルトの名無しさん：03/11/12 17:45
>>855
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/csref/html/vcreftheenumerationtypes.asp
> [attributes] [modifiers] enum identifier [:base-type] {enumerator-list} [;]
> base-type (省略可能)
> 　基になる型。列挙子ごとのストレージの割り当てを指定します。char 以外の任意の整数型を指定できます。既定値は int です。

何を勘違いしてるのか知らんが、C# の enum は int、もしくは整数型だ。
860 ：デフォルトの名無しさん：03/11/12 17:48
>>858
> オペレータのオーバーロードが関数より「なにしてるかわからん・
iostream が非常に良い例ですな。
861 ：デフォルトの名無しさん：03/11/12 17:54
>>858
> 代入演算子のオーバーロードもダメ？ a = b はダメで、 a.set(b) とかするべき？
例えば、Java だと単純代入演算子 = で参照型の代入式を記述したら
右辺の参照値が左辺に代入される。
これがオーバーロードされて別の意味になったら混乱する。

> 比較演算子もダメ？なーんか納得いかない。。。
比較演算子の話は >>719 あたりで出てなかったか？
862 ：デフォルトの名無しさん：03/11/12 18:08
>>859
ここらへん見ると君の認識不足が分かるよ。
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpref/html/frlrfsystemenumclasstopic.asp
Enum クラス
列挙体の基本クラスを提供します。
863 ：デフォルトの名無しさん：03/11/12 18:12
>>862
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/csref/html/vcreftheenumerationtypes.asp
> 例 1
> ここでは、列挙 Days の宣言例を示します。2 つの列挙子は明示的に int に変換され、int 変数に代入されます。
>
> // keyword_enum.cs
> // enum initialization:
> using System;
> public class EnumTest
> {
> enum Days {Sat=1, Sun, Mon, Tue, Wed, Thu, Fri};
>
> public static void Main()
> {
> int x = (int) Days.Sun;
> int y = (int) Days.Fri;
> Console.WriteLine("Sun = {0}", x);
> Console.WriteLine("Fri = {0}", y);
> }
> }
864 ：java使いTai!：03/11/12 18:12
ところで、javaに #ifdef って実装されませんかね？
今は必要に応じてgccとかそのへんのプリプロセッサだけ使う
なんて方法があるらしいですけど、ちょっとヤですよね。
865 ：デフォルトの名無しさん：03/11/12 18:18
>>864
Sun の公式回答が
> 今は必要に応じてgccとかそのへんのプリプロセッサだけ使う
しろ、じゃなかったっけ？
もしくは if( 定数式 ) とすると既存のコンパイラが条件分岐を削除するのを利用するとか。

ところで、#ifdef で何したいの？
866 ：デフォルトの名無しさん：03/11/12 18:36
>>860
iostream が何してるかわからない人って、そもそも非常に低レベルな人材なわけで、
C++ なんか使うような開発に適正が無い、って気がするけど。。
（ちと自信ないけど）

>>861
それはどの well known なメソッドについてもいえることで、演算子オーバーロードに
限らないと思うけど。。。 size() や equals() や clone が別の意味になってたらやはり
混乱するわけで。。。less なんて名前で実は意味が反対、みたいな比較メソッドが書
けるから、メソッドに意味のありそうな名前をつけられる言語仕様はダメ、識別子は全
て無意味語にして設計書を読ませるのが安全、って。
867 ：デフォルトの名無しさん：03/11/12 18:37
>>865
もれは864じゃないけど SDK のバージョン違いを吸収するのに ifdef 使いたくなる
ことはある。。。
868 ：デフォルトの名無しさん：03/11/12 18:37
＞＞863
ふぅ。やれやれだな。ここまでださんといかんのか。
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/cpref/html/frlrfsystemenummemberstopic.asp
Enum メンバ
Enum 概要

パブリック メソッド
CompareTo 指定したオブジェクトとこのインスタンスを比較し、これらの相対値を示す値を返します。
Equals オーバーライド。 対象のインスタンスが、指定したオブジェクトに等しいかどうかを示す値を返します。
Format 指定した形式に従って、指定した列挙型の指定した値をそれと等価の文字列形式に変換します。
GetHashCode オーバーライド。 このインスタンスのハッシュ コードを返します。
GetName 指定した値を持つ指定した列挙体にある定数の名前を取得します。
GetNames 指定した列挙体に含まれている定数の名前の配列を取得します。
GetType (Object から継承されます) 現在のインスタンスの Type を取得します。
GetTypeCode このインスタンスの基になる TypeCode を返します。
GetUnderlyingType 指定した列挙体の基になる型を返します。
GetValues 指定した列挙体内の定数の値の配列を取得します。
IsDefined 指定した値を持つ定数が指定した列挙体に存在するかどうかを示す値を返します。
Parse オーバーロード。 文字列形式での 1 つ以上の列挙定数の名前または数値を、等価の列挙オブジェクトに変換します。
ToObject オーバーロード。 指定した値に設定された、指定の列挙型のインスタンスを返します。
ToString オーバーロード。 オーバーライド。 このインスタンスの値を、それと等価の文字列形式に変換します。
869 ：デフォルトの名無しさん：03/11/12 18:51
>>868
.NET では値型も System.Object も派生すんだからメソッド持ってても…
870 ：デフォルトの名無しさん：03/11/12 18:55
>>868
int val = 0;
Console.WriteLine(val.ToString());
Console.WriteLine(val.GetType());

とか出来るし。
871 ：デフォルトの名無しさん：03/11/12 18:56
メソッド持っている時点でタダの数値じゃないね。
キャストしないとintに代入できない＝型チェックが存在するし、
enumの値からenum名が取得できるし。
872 ：デフォルトの名無しさん：03/11/12 18:58
>>866
> それはどの well known なメソッドについてもいえることで、演算子オーバーロードに
> 限らないと思うけど。。。
一般論としてはね。

ただし >>861 は代入演算子をオーバーロードしない方が
良い理由を書いているので、その指摘は的外れ。
873 ：デフォルトの名無しさん：03/11/12 18:59
>>871
> メソッド持っている時点でタダの数値じゃないね。
C# にはタダの数値は存在しない、と。
874 ：デフォルトの名無しさん：03/11/12 19:12
>>866
> iostream が何してるかわからない人って、そもそも非常に低レベルな人材なわけで、

例えば、1文字しか入力が無かった場合、
char c1,c2;
cin >> c1 >> c2;
でどうなるの？ とか最初はマニュアル見なきゃわからんし。

まぁ慣れれば大丈夫、ってのはわかるけど、
慣れる前の状態も重要だと考えるので。
875 ：デフォルトの名無しさん：03/11/12 19:19
>>870
それゆーなら、C# では
Console.WriteLine(0.ToString());
Console.WriteLine(0.GetType());
もできるんだが…
876 ：java使いTai!：03/11/12 19:26
>>867
わたしもそうです
877 ：デフォルトの名無しさん：03/11/12 19:33
>>867
> もれは864じゃないけど SDK のバージョン違いを吸収するのに ifdef 使いたくなる
具体的には？
878 ：デフォルトの名無しさん：03/11/12 19:35
>>875
C#の方がOOPLとしての完成度が高いですね
879 ：デフォルトの名無しさん：03/11/12 19:38
>>878
言語としては、そうかもしれん。
880 ：デフォルトの名無しさん：03/11/12 19:40
C#最強。
881 ：デフォルトの名無しさん：03/11/12 20:07
>>870
GetName というメソッドが使えることからもわかるように
列挙はただの数値じゃないってこった。
882 ：デフォルトの名無しさん：03/11/12 20:48
>>881
> GetName というメソッドが使えることからもわかるように
>>871 と言ってる事が変わってるぞ。
883 ：デフォルトの名無しさん：03/11/12 21:13
>>881
> GetName というメソッドが使えることからもわかるように
> 列挙はただの数値じゃないってこった。
列挙型がただの数値型でないだけ。enum と int で加減算できるし、
enum と enum でビット演算できるし、どこが typesafe なんだか…
884 ：デフォルトの名無しさん：03/11/12 21:41
>>874
エラー処理の方法がマニュアル見ないと判らないのは、これがメソッド変わろうが事情は同じだべ。
最低限のカルチャーはどんな言語だろうが、ライブラリーだろうが必要だっちゅーの。
885 ：デフォルトの名無しさん：03/11/12 21:48
>>842
ひねくれ者のあなたには判らないだけです、普通の人なら演算は見ての通りの書き方のほうが判りやすいのです。
判りやすい書き方は間違いが少ないのですよ。
間違いが少ないという事は信頼性も高いという事です。
そして、世の中にひねくれ者が少数居る事は承知していますよ(藁
886 ：デフォルトの名無しさん：03/11/12 22:11
>>884
> エラー処理の方法がマニュアル見ないと判らないのは、これがメソッド変わろうが事情は同じだべ。
istream::get() を使えば EOF が帰るのに
istream::operator >>(char&) では安易な記述の変わりに EOF チェックが面倒になってるよね。

こーゆーのも安易な演算子のオーバーロードの例って事で。
887 ：デフォルトの名無しさん：03/11/12 22:15
>>885
> ひねくれ者のあなたには判らないだけです、普通の人なら演算は見ての通りの書き方のほうが判りやすいのです。
「見ての通り」が何を意味するかは個々人によって違う事がある。

まぁ、個人の資質のせいにするのもいいけどさ。
それだけじゃあ複数人での開発は上手くいかないと思うけど？
888 ：デフォルトの名無しさん：03/11/12 22:17
>>885
> 判りやすい書き方は間違いが少ないのですよ。
判りやすい書き方とはいっても、マニュアル読まないと
「何やってるか」は分からない、と。

本当に判りやすいのか？
889 ：デフォルトの名無しさん：03/11/12 22:44
ダカラソレハ普通のメソッドでも同じだろうが。
890 ：デフォルトの名無しさん：03/11/12 22:47
a + b;
が何やってるのかわからん人ばかりですか？

stream >> a;
だって新しいストリーム出力演算子がC++になって一つ追加されただけじゃん。
891 ：デフォルトの名無しさん：03/11/12 22:51
>>886
int ch;
ch=s.get();
if(ch==EOF)

char ch;
s>>ch;
if(s.eof())

面倒か？
892 ：デフォルトの名無しさん：03/11/12 23:04
>>889
演算子のオーバーロードは記述が容易になるのに、
根っこから理解するには普通のメソッドと同じだけの労力が必要。

熟練者にとってはガシガシ記述できて便利だけど、
初心者は読むのが大変だし、(他の言語の経験などの)先入観があると躓く事も多い。

それに、演算子のオーバーロードを数学的なものだけに限定するなら、
必要無い分野のプログラムしか書かない人もかなり多い。
893 ：デフォルトの名無しさん：03/11/12 23:06
>>887
少なくとも代数的なオブジェクトに対して、四則演算程度のオペレータごときを違う定義にする奴は奇特だと思うね。
複数人でも普通はいない、あなたは別ですか？
別だというなら、そんな状況下ではオペレータオーバーロードでなくても問題起こすと思うよ。
メソッドにしたところで状況は改善しないでしょう。
894 ：デフォルトの名無しさん：03/11/12 23:06
>>891
少し複雑になった、という意味で「面倒」という単語を使ってるので。
895 ：デフォルトの名無しさん：03/11/12 23:10
>>893
> 少なくとも代数的なオブジェクトに対して、四則演算程度のオペレータごときを違う定義にする奴は奇特だと思うね。
いつの間に こんな前提が？
それに、代数的なオブジェクトなら
必要無い分野のプログラムしか書かない人もかなり多い。
896 ：デフォルトの名無しさん：03/11/12 23:13
>>893
> 少なくとも代数的なオブジェクトに対して、四則演算程度のオペレータごときを違う定義にする奴は奇特だと思うね。
そうであっても、個々の値でオーバーフローとか発生した場合どうするのかとかで違いは出るね。

まぁ、演算子のオーバーロードでなくても同じ問題でるが、
そのような問題の発生を まるで考慮してないような >>893 は
演算子のオーバーロードは使わないほうが良いかも。
897 ：デフォルトの名無しさん：03/11/12 23:21
>>895
普通はあるだろう、表計算程度の物だって加減乗除くらい使うと思うが。
898 ：デフォルトの名無しさん：03/11/12 23:24
>>892
>演算子のオーバーロードは記述が容易になるのに、
>根っこから理解するには普通のメソッドと同じだけの労力が必要。
記述が用意になって労力はメソッドと一緒ならすごいいいじゃん。

>初心者は読むのが大変だし
初心者はa.add(b.mul(c))みたいな形式よりa + b * cを好む。

>それに、演算子のオーバーロードを数学的なものだけに限定するなら、
>必要無い分野のプログラムしか書かない人もかなり多い。
必要のある分野の人は切捨てか？書く人はめちゃくちゃ書くと思うが？


>>894
複雑か？


>>895
メソッド名とまったく異なる処理にする奴はかなり奇特だろ？


>>896
例外でも投げたら？
899 ：デフォルトの名無しさん：03/11/12 23:27
>>896
考慮する必要が無い、ばかばかしいと判断したからC#では復活したんでしょうね。
散々議論されたがそんなものは杞憂だと
多分これからの言語はその傾向になると思うよ。
矛盾が発生しにくいようにちょっとだけ文法に工夫すればいいだけ。
900 ：デフォルトの名無しさん：03/11/12 23:28
>>897
> 初心者はa.add(b.mul(c))みたいな形式よりa + b * cを好む。
で、躓くと。
901 ：デフォルトの名無しさん：03/11/12 23:29
どう躓くのか言えよ
902 ：デフォルトの名無しさん：03/11/12 23:31
絶対a.add(b.mul(c))の方が躓くと思う気のせいか？
オレいま少し考えたよ、この処理の内容。(笑
903 ：デフォルトの名無しさん：03/11/12 23:31
>>898
> 必要のある分野の人は切捨てか？書く人はめちゃくちゃ書くと思うが？
必要ある分野の人はプリプロセッサ使うか、
演算子のオーバーロードがある言語使えばよいだけ。
904 ：デフォルトの名無しさん：03/11/12 23:31
>先入観があると躓く事も多い。

先入観からの躓きの具体例をお願いします
905 ：デフォルトの名無しさん：03/11/12 23:36
>>901
代数 + 四則演算じゃないけど >>372
906 ：デフォルトの名無しさん：03/11/12 23:36
>>903
ﾊｧｿｳﾃﾞｽｶ。語るに落ちたとはまさにこのことですね。
907 ：デフォルトの名無しさん：03/11/12 23:38
>>905
そりゃJavaの文字列処理の仕様が変だからだよ。
908 ：デフォルトの名無しさん：03/11/12 23:39
>>907
何かを変かと思うかどうかは個々人によって違う。
909 ：デフォルトの名無しさん：03/11/12 23:42
つーか、>>372は関係無いだろ
910 ：デフォルトの名無しさん：03/11/12 23:48
今となっては演算子オーバーローディングが無い言語の方が少なくなってきてるよ

あんまり意固地だと、Java以外の言語使えなくなるよ
911 ：デフォルトの名無しさん：03/11/12 23:51
中置演算子万歳！
912 ：デフォルトの名無しさん：03/11/12 23:52
>>909
どこが？
913 ：デフォルトの名無しさん：03/11/12 23:54
>>910
> 今となっては演算子オーバーローディングが無い言語の方が少なくなってきてるよ
ローカルルールで、演算子オーバーローディング禁止してるとこも多いけどね。
914 ：デフォルトの名無しさん：03/11/12 23:56
>>912
あれのどこが演算子オーバーロードと関係あるの？
915 ：デフォルトの名無しさん：03/11/12 23:57
>>913
まぁ職場レベルの低いところはしょうがないよね
916 ：デフォルトの名無しさん：03/11/12 23:58
>>914
>>901 からのレスでも読んでくれ。
917 ：デフォルトの名無しさん：03/11/13 00:01
>>916
読んだ。で、>>372は演算子オーバーロードと何の関係があんのよ。そもそも>>372は演算子オーバーロードの無いJavaの話だろ。
918 ：デフォルトの名無しさん：03/11/13 00:03
>>917
String の + を演算子のオーバーロードと見立てて、
演算子のオーバーロードで躓く例。
919 ：デフォルトの名無しさん：03/11/13 00:06
>>918
まぁそれでもええけどさぁ、あれはJavaの言語仕様ゆえの躓きだろ

==は同値かどうかの判定
===は同一かどうかの判定

にすれば混乱は起きなかったと思うが。
ちなみに↑の戦略をとってる言語は多い。Lisp Ruby ・・・もっと在ったけど思い打線
920 ：デフォルトの名無しさん：03/11/13 00:06
Lispは中間演算子の形をとってないけど
921 ：デフォルトの名無しさん：03/11/13 00:08
>>918
> ==は同値かどうかの判定
> ===は同一かどうかの判定
Javaでも
　== は同一かどうかの判定
　equals は同値かどうかの判定。
という戦略を取ってるね。
922 ：デフォルトの名無しさん：03/11/13 00:08
んで、==はオーバーロード可能にして===はオーバーロード不可能にすればOK
923 ：デフォルトの名無しさん：03/11/13 00:10
JavaのStringと文字リテラルが同じ性質もってないって糞仕様のせいでしょ
924 ：デフォルトの名無しさん：03/11/13 00:11
つーわけで躓く例、じゃなくなったので、他の躓く例を挙げてみてよ
925 ：デフォルトの名無しさん：03/11/13 00:12
>>922
> んで、==はオーバーロード可能にして===はオーバーロード不可能にすればOK
Java でも
　同一かどうかの判定を行う == はオーバーロード不可能、
　同値かどうかの判定を行う equals は上書き可能。

でも混乱は起こる。
926 ：デフォルトの名無しさん：03/11/13 00:15
>>923
> JavaのStringと文字リテラルが同じ性質もってないって糞仕様のせいでしょ
String と「文字リテラル」が同じ性質を持つって…

糞仕様と思うかは人次第。
もっと良い仕様が記述できなければ「糞」の部分に説得力ないし。
927 ：デフォルトの名無しさん：03/11/13 00:18
>>925
混乱は起こるから何？
どっちにしろ演算子のオーバーロードで躓く例じゃ無いから、他の例出してよ。

>>926
>糞仕様と思うかは人次第
ふーん。じゃあお前は演算子オーバーロードを糞仕様ということは出来ないね。言うなよ。
928 ：デフォルトの名無しさん：03/11/13 00:19
>>926
もっと良い仕様＝C#
929 ：デフォルトの名無しさん：03/11/13 00:23
>>927
> 混乱は起こるから何？
演算子のオーバーロードでも同様の事が起こる。

> ふーん。じゃあお前は演算子オーバーロードを糞仕様ということは出来ないね。言うなよ。
糞とは言ってないけど。
便利な機能でも混乱の原因になるなら制限したり機能を削ったりするのも選択の一つと言ってるだけで。
930 ：デフォルトの名無しさん：03/11/13 00:25
>>929
お前さぁ、演算子のオーバーロード無くても混乱してんじゃん。プログラマ向いてないんじゃない？
931 ：デフォルトの名無しさん：03/11/13 00:30
今時Javaにこんなに熱入れてるなんて学生に決まってるじゃん
932 ：デフォルトの名無しさん：03/11/13 00:37
＞便利な機能でも混乱の原因になるなら制限したり機能を削ったりするのも選択の一つと

↑こういう考えは正しいと思う



933 ：デフォルトの名無しさん：03/11/13 00:39
オーバーロードごときで混乱するのは
自分が未熟なせいだろ。

未熟な奴はクラスでさえ混乱する。
934 ：デフォルトの名無しさん：03/11/13 00:41
ある年齢に達すると、プログラマーは自分から使う言語を変えることはほとんどなくなる。
何の言語を使っていようと、これで十分だと思ってしまうのだ。

935 ：デフォルトの名無しさん：03/11/13 00:41
プログラマは自分の好みの言語を深く愛する質だし、私は誰も傷つけたくないので、
ここで仮想的なプログラミング言語「ほげ」を使って私のポイントを説明しよう。
「ほげ」は抽象度のスペクトルのちょうど真中に位置するものとする。
最もパワフルな言語ではないけれど、Cobolや機械語よりはパワフルだ。
936 ：デフォルトの名無しさん：03/11/13 00:43
そして、仮想的な「ほげ」プログラマ氏は、Cobolも機械語も使わない。
もちろん機械語なんて使わない。あれはコンパイラのためのもんだ。
それにCobolだって、あれで何かをきちんと動かしたことがあるって人を知らないよ。
結局のところ、「ほげ」にある機能xが無いもんな。
937 ：デフォルトの名無しさん：03/11/13 00:44
このプログラマ氏がパワーのスペクトルを見下ろしている時、彼にはそうしているという自覚がある。
「ほげ」よりも力の弱い言語は、明らかに力が弱い。
彼が慣れ親しんだ機能が無いからだ。
しかし、このプログラマ氏が反対の方向に目を転じた時、彼は自分が見上げているのだということに気付かないのだ。
938 ：デフォルトの名無しさん：03/11/13 00:44
彼が目にするのは、変てこりんな言語ばかり。
多分、それらは「ほげ」と同じくらいパワフルなんだろうけど、どういうわけかふわふわしたおまけがいろいろついているんだ、と思うだろう。
彼にとっては「ほげ」で十分なのだ。何故なら彼は「ほげ」で考えているから。
でも、これよりもう一段階パワフルな言語を使っているプログラマを考えてみると、多分彼は「ほげ」を見下ろす位置にいる。
いったい「ほげ」で何ができるっていうんだい。あれには機能yさえ無いじゃないか。
939 ：デフォルトの名無しさん：03/11/13 01:12
で、そのLisp好きポール・グラハムさんは、
Haskellerに見下されているワケだ。
940 ：デフォルトの名無しさん：03/11/13 01:34
>>934
ただし、その「ある年齢」は人によって大きく違う。
941 ：デフォルトの名無しさん：03/11/13 02:12
>>938
なかなか興味深い。

自分が使ってる言語が「ぱわふる」であるかどーかで、
「ぱわふる」でない言語のユーザを見下ろしたりするのか…
942 ：デフォルトの名無しさん：03/11/13 09:03
C++とJavaの場合はどっちがパワフルというよりも
違うベクトルに向かっていってるわけだが。

Java厨がC++厨に喧嘩を売っている理由は別ベクトルの方向がある事をしらないから。
C++厨がJava厨に喧嘩を売っている理由はベクトル長の長さ(事実これは言語の歴史の長さに比例して徐々に伸びていく)の問題。

Java厨はわざわざ心配しなくてもC++はどんどん遠くへ行っちゃってるよ。
C++厨はわざわざ心配しなくてもJavaもあと10年すれば膨大で複雑怪奇な言語仕様の糞言語になってるよ。
943 ：デフォルトの名無しさん：03/11/13 09:57
オブジェクト指向も限界なのかもな。
次のパラダイムは何だ
944 ：デフォルトの名無しさん：03/11/13 10:02
>>942
方向は適用分野？それともパラダイム？
言語ってそういったベクトルの組み合わせなわけであって、
有るベクトルに射影すると長かったり短かったりするわけで、
そういう意味でいえば向き不向きがあるわけだ。

要するに単一の方向だけで全てを賄おうとする言語は糞。
945 ：デフォルトの名無しさん：03/11/13 10:20
補足
単一の方向で単一の分野を賄おうとする言語は糞ではない
946 ：デフォルトの名無しさん：03/11/13 11:34
C++厨はどうして「C++が最先端」と思い込みたがるのだろうか？
C++がありがたがる言語機能のほとんどがほかの言語からアイデアを
借りてきたものなのに。
947 ：デフォルトの名無しさん：03/11/13 11:57
痛杉
948 ：デフォルトの名無しさん：03/11/13 14:46
可読性についてだけど、

代数演算をメソッドにした場合非破壊的に演算結果を返すもの(+, -, *, / ) と
破壊的操作 (+=, -=, *=, /=) の区別がしにくくなると思うんだけど。

a = Math.mul(b, c); なら非破壊だな、ってわかるけど、インスタンスメソッドで
b.mul(c) ってかかれると b <- b*c みたいにも読めるし。。
↑の場合適切なメソッド名は何になるんだろう。
949 ：デフォルトの名無しさん：03/11/13 15:02
>>943
プログラム言語のパラダイムという点では、つぎはアスペクト指向なのだろうが・・・。
ただ、多くの点でプログラム言語のパラダイムとしてはオブジェクト指向で充分であるようだ。
教育コストのバランスなどを考えてね。

ということで、視点としてはプログラム技術のパラダイムからプロセス技術のパラダイムに移行している。
CMMとかXPとかテストファーストとか、そういった話題が普通のプログラム技術誌をにぎわすようになってきた。
950 ：デフォルトの名無しさん：03/11/13 15:29
>>948
> ↑の場合適切なメソッド名は何になるんだろう。
・会社のルールに従う。
・使用している言語でより支持されたルールに従う。
・俺ルールでやる。

上のが優先順位は高い。
951 ：デフォルトの名無しさん：03/11/13 17:49
>>950
理想はこっち。

・使用している言語でより支持されたルールに従う。
・会社のルールに従う。
・俺ルールでやる。
952 ：デフォルトの名無しさん：03/11/13 17:58
いっその事演算子なんてなくしちまえ！
953 ：デフォルトの名無しさん：03/11/13 18:16
>>951
あぁ、給料もらえなくてもいいならそーかも。

っつか、会社レベルのルールも守れなければ
> ・使用している言語でより支持されたルールに従う。
とかいーつつ、それをちょっと改変した俺ルールとか使いそうだし。
954 ：デフォルトの名無しさん：03/11/13 20:05
会社のルールを押し付ける会社がDQNなんですよ。
955 ：デフォルトの名無しさん：03/11/13 20:15
まぁ職場レベルが低いところはしょうがないよね
956 ：デフォルトの名無しさん：03/11/13 20:23
>>950
一番上は
・プロジェクトのルールに従う
じゃ無いかと
957 ：デフォルトの名無しさん：03/11/13 20:24
>>954
職場のルールが守られない＝職場のレベルが低いって意味だよね？
958 ：957：03/11/13 20:25
s/>>954/>>955/
959 ：デフォルトの名無しさん：03/11/13 20:36
・使用している言語でより支持されたルールに従う。

ってのを採用しない職場のレベルはまず低いと思って間違いないだろう。

会社のルールってのはDQN上司の俺ルールってパターンが非常に多いからだ。
960 ：デフォルトの名無しさん：03/11/13 20:41
>>959
> ってのを採用しない職場のレベルはまず低いと思って間違いないだろう。
「使用している言語でより支持されたルール」は幅が広くて、
会社とかプロジェクトのルールは幅が狭いルールって意味。

> 会社のルールってのはDQN上司の俺ルールってパターンが非常に多いからだ。
そーゆー上司にはあたったことないしなぁ…
961 ：デフォルトの名無しさん：03/11/13 21:41
>そーゆー上司にはあたったことないしなぁ…
関数名はロット番号にして管理、F012035とか
素晴らしいアイディア無限に出す人いるよね。
962 ：デフォルトの名無しさん：03/11/13 21:51
職場レベルが低くて苦労してる人間が集うスレはここですか？
963 ：デフォルトの名無しさん：03/11/13 23:03
>>948
> b.mul(c) ってかかれると b <- b*c みたいにも読めるし
> ↑の場合適切なメソッド名は何になるんだろう
破壊的なメソッドには語尾に！をつけるのはどうでしょう
964 ：デフォルトの名無しさん：03/11/13 23:08
kill!
965 ：デフォルトの名無しさん：03/11/14 01:11
次スレは立てないでC# vs JavaかDelphi vs Javaを使おうよ。
どうせどこでやっても同じだし。
966 ：デフォルトの名無しさん：03/11/14 01:35
Javaは対決好きなんだな
967 ：デフォルトの名無しさん：03/11/14 01:37
非破壊
b.getMuledValue(c);

破壊
b.setMuledValue(c);
968 ：デフォルトの名無しさん：03/11/14 01:49
>>965
まだ続けんのか？ 続けるネタあんの？
969 ：デフォルトの名無しさん：03/11/14 02:26
このスレオモロイ！
業務命令で嫌々Javaを触りはじめたC厨の俺だけど、
1時間で1からここまで読んじゃった。テヘッ。
Stringの+連結演算子だけ特別扱いなのがキモイってのは同感で〜す。
970 ：java使いTai!：03/11/14 04:46
次スレってどこですかね
971 ：デフォルトの名無しさん：03/11/14 05:20
ここかな？
http://pc2.2ch.net/test/read.cgi/tech/1068377418/
972 ：デフォルトの名無しさん：03/11/14 07:03
>>969
Java の String は + 以外でも特別扱いされてっからねぇ
973 ：デフォルトの名無しさん：03/11/14 07:23
Cのように文字列サポートが無い仕様のほうがよっぽどキモイぞ！
C++/SmallTalkのように文字列クラスごときのために、演算子オーバーロード
認めましたなんていうグロい実装をマンセーするつもりかボケが！
Stringの+連結演算子はJavaのシンタックスシュガーなんだよ
構文糖なんだよそれさえ否定するつもりかこのアンポンタンどもッ！！！
Javaのプリミティブ型とクラスの橋渡しをする中間管理職的な
位置につつましく収まってくれているStringクラスなんだぞ！
StringBufferクラスに汚れた仕事は任せて、インミュータブルに生きてる
ナイスガイなんだぞ！ それを……それを……

！　！　！　特　別　視　し　て　何　が　悪　い　！　！　！
974 ：デフォルトの名無しさん：03/11/14 07:39
>>973
> Stringの+連結演算子はJavaのシンタックスシュガーなんだよ

シンタックスシュガーって否定的な意味で使われるんだと思ってた…
975 ：デフォルトの名無しさん：03/11/14 07:45
俺漏れも

でも、Stringの連結を演算子で行うために演算子オーバーロードの仕様を組み入れるのが反対なのには同意。
976 ：デフォルトの名無しさん：03/11/14 07:52
>>973
> C++/SmallTalkのように文字列クラスごときのために、演算子オーバーロード
> 認めましたなんていうグロい実装をマンセーするつもりかボケが！

文字列以外でも使ってますが…
977 ：デフォルトの名無しさん：03/11/14 08:25
>976
Javaが演算子オーバーロードを仕様に含めなかった潔さについて言ってるんだと思う。
Javaは話のわかるやつだ。
978 ：デフォルトの名無しさん：03/11/14 09:12
多倍長整数、多倍長浮動小数点数、複素数、ベクトル数
その他ユーザーによって定義される数値を現す型を使うとき
演算子オーバーロードのできない言語は腐れ言語。
979 ：デフォルトの名無しさん：03/11/14 09:15
>>978
> その他ユーザーによって定義される数値を現す型を使うとき
これは要らん
980 ：デフォルトの名無しさん：03/11/14 09:23
>>977
> Javaが演算子オーバーロードを仕様に含めなかった潔さについて言ってるんだと思う。
どのように読めばそのような解釈になるのでしょうな？
981 ：デフォルトの名無しさん：03/11/14 09:46
ぼくちん馬鹿だから
ユーザー定義数値型なんて使わな〜い
計算とかしないし
982 ：デフォルトの名無しさん：03/11/14 10:02
>ぼくちん馬鹿だから
そのようですな
983 ：デフォルトの名無しさん：03/11/14 10:40
>ぼくちん
ですな
984 ：デフォルトの名無しさん：03/11/14 10:47
ふふふ。Javaは地上のボクチンをターゲットに作られている。
馬鹿どもにはちょうどいい目くらまし言語だ。
985 ：デフォルトの名無しさん：03/11/14 11:10
>>982
禿同
986 ：デフォルトの名無しさん：03/11/14 11:12
>馬鹿どもにはちょうどいい目くらまし言語だ。
お前にピッタリの言語だな
987 ：デフォルトの名無しさん：03/11/14 13:24
（COBOL 使えばいいのに。。⇒Java やってる人)
988 ：デフォルトの名無しさん：03/11/14 19:00
次スレ
http://pc2.2ch.net/test/read.cgi/tech/1046851381/l50
989 ：デフォルトの名無しさん：03/11/14 20:10
問題は業務業界に跳梁跋扈するＶＢ厨なのであった
　　　　　（完）
990 ：デフォルトの名無しさん：03/11/14 20:30
>>973
そりゃC言語って元々アセンブラの変わりに使う予定だったものなんだし
高級言語が文字列を取り扱って、高級言語からCへトランスレートするのが元々Cの目的な訳で
色々な文字コードが今後出る事が確実と判っていて、特定文字コードに特化した文字列処理を追加するとすれば、それは問題な訳。
ところが、C言語の当時の構造化プログラムの記述能力が最も高い言語の一つで、それがマシン語並のスペックを出すと、
当時プログラマとしてはわずかな記述性の向上は捨ててCを取ってしまった。
それで、本来の高級言語が流行れなかったのだが、それはCが悪いのでは無く、当時の高級言語の記述能力があまりに不甲斐無かったのが悪いんだと思う。
991 ：デフォルトの名無しさん：03/11/14 21:57
1000get!!!
992 ：デフォルトの名無しさん：03/11/14 22:05
>>991
まぁ、もてぃつけ
993 ：デフォルトの名無しさん：03/11/14 22:16
993
994 ：デフォルトの名無しさん：03/11/14 22:17
994
995 ：デフォルトの名無しさん：03/11/14 22:18
995
996 ：デフォルトの名無しさん：03/11/14 22:18
996
997 ：デフォルトの名無しさん：03/11/14 22:19
997
998 ：デフォルトの名無しさん：03/11/14 22:19
998
999 ：デフォルトの名無しさん：03/11/14 22:26
アホアンチ氏ね
1000 ：デフォルトの名無しさん：03/11/14 22:28
FIGHT!!!
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。