1 ：
デフォルトの名無しさん ：
03/10/04 00:12 FIGHT!!!
2 ：
デフォルトの名無しさん ：03/10/04 00:14
(・∀・)ﾂﾚﾀ!
オヒョウが違う。
このスレ(・∀・)ｲｲ!!
互換性をかんがえるとJavaの勝ち。
C++にGUIのライブラリなんてねーよ。
無題に重複スレをたてるな
>>1 削除依頼出して来い
>>6 ＞互換性をかんがえるとJavaの勝ち。
STD C++の方がよっぽど互換性は高いが。
10 ：
デフォルトの名無しさん ：03/10/05 04:42
タイプ数の少なさでC++の勝ち。
ここが秋の天気のよい日曜に 閉じこもり煽り屋軍団が集結するスレなわけですか？
12 ：
デフォルトの名無しさん ：03/10/05 13:55
統合開発環境の統一性と
>>12 それはVC++信者に当てはまることでUnix系でC++使っている人にとっては失礼だ。
15 ：
デフォルトの名無しさん ：03/10/08 21:48
C++の圧勝であります。
用途によって使い分けましょう。
17 ：
デフォルトの名無しさん ：03/10/09 00:57
C++だけで何でも出来る、Javaの出番は無し。
遅ればせながらロボコード始めました。
>>17 なあ頼む、iアプリをC++で作ってくれ。
>>19 ドコモBREWを採用するように頼んでください
>>17 なあたのむC++だけでJavaと同じ開発速度でソフトを完成させてくれ。
>>20 なあたのむBREW用に作ったC++アプリをどの携帯電話でも再コンパイルせずに
動かせるようにしてくれ。
>>21 C++もJavaも開発期間は変わりませんね。
>>17 なな頼む、C++だけでJ2EEとおなじくらいの開発速度でJ2EE用システムをすべて
C++だけで開発してくれ。
>>22 バッチ処理でクロスコンパイルするだけだと思うんですが何か嫌ですか？
27 ：
デフォルトの名無しさん ：03/10/09 01:13
>>25 >
>>22 > バッチ処理でクロスコンパイルするだけだと思うんですが何か嫌ですか？
馬鹿丸出しw
>>24 そもそもJ2EE用システムってなんですか？
C++もライブラリでバックエンドとしてDBを使う事は簡単ですし、
セッション管理についてもFastCGI SAを使えば全く問題有りません。
また、その他ライブラリもC++なら豊富ですから問題有りませんね。
>>23 Javaを使うと開発速度がC++の５倍になったと発表した企業もいるのだが。
個人でも3倍は早くなったと発表しているが。
まあ好きでJavaやってるなら別にいいんですが、
>>28 C++だけで済ませろといったのにFastCGIときましたか。
>>29 単にC++の学習が十分じゃなかっただけでしょう
>>31 FastCGI SAもC++で書かれたApacheモジュールなんですが頭大丈夫ですか？
34 ：
デフォルトの名無しさん ：03/10/09 01:21
C++よりC#とくらべなはれ。
>>30 Javaを使い始めた多くの人々がJavaを使うきっかけを生んだのは
Javaがプラットフォーム非依存で
C++のようなスパゲティコードを生み出す危険性を減らすところにあったわけだが。
みんなが使ってるからやむを得ずJavaを使ってるとは失礼なことよ。
プログラミング言語はOSやOffice Suiteとは違い競争原理が働かないものなのだが。
>>32 もうそんな詭弁な言い訳はもはや通用しなくなっているのだが。
その一例としてJavaが難しいから.NETを選んだという企業も増えてきているわけだが。
>>34 ここはC++とJavaとを比較するスレであり
C#について語るスレではない。
C#と比較したければ該当スレまたは新規にそれ相応のスレをたてること。
>>35 Javaを使っているからと言ってスパゲティコードが減るとは思えませんが。
struts等のライブラリの拘束によってスパゲティが減るのだというのなら、
C++でも同じですよね。
>>25 そんなことを携帯電話もっている顧客にまで押し付けるのか。
終わってるな。
>>35 >プラットフォーム非依存
結局どこがプラットフォーム非依存なんでしょうか？
Javaの実効環境が無いと動かないのに。
>>36 それは頭悪い香具師が悪いだけです
>>38 C++はJavaと比べ低レベルな部分でスパゲティを生みやすいですが何か。
>>39 意味が分かりません。
願客がプログラム書くわけじゃないですよね。
>>41 boostやBoehmを使ってください。
>>40 >
>>35 > >プラットフォーム非依存
> 結局どこがプラットフォーム非依存なんでしょうか？
> Javaの実効環境が無いと動かないのに。
オマエも頭が悪い。
プラットフォームにたいする依存性が減ったということがC++にはないJavaのうりなわけだが。
そんなことはすでに昔から語りつくされているだろうに、いまさらわめくな。
>
>>36 > それは頭悪い香具師が悪いだけです
ニュースもみていないからそういうことしかいえないんだよ。頭が悪いのはオマエだよ。
>>43 boostなどがなくてもC++でコーディングできてしまうわけだが。
いちいちC++プログラマにそれらを使わせるように普及させない限り
Javaのようにはいかないぞ。
>>44 あなたあまりJavaの事も知らないみたいですね。
まあ日本の技術者の平均レベルが低いのは分かるんですが、
日本の技術者には向上心は無いんでしょうかね？
>>42 >
>>39 > 意味が分かりません。
意味がわからない？ だとしたらオマエの頭が悪いとしか言いようが無い。
> 願客がプログラム書くわけじゃないですよね。
オマエの発言(
>>25 )はそうともとれるわけだが。
>>45 Javaもstruts等の拘束が強いフレームワーク無しでは信じられないクラス構成のコードが簡単に作れてしまいますね。
まあstrutsを使っても馬鹿なクラス設計にする香具師は多いですが。
これはとうとうC++厨の誤魔化しが始まったか。
>>46 あなたあまり日本語の事も知らないみたいですね。
(こうとしかいいようがないな。)
まあ日本の技術者の平均レベルが低いのは分かるんですが、
日本の技術者には向上心は無いんでしょうかね？
>>47 相当頭悪いですね。
クロスコンパイルした後にそれぞれのバイナリを願客に配布するに決まってるでしょう。
>>48 チミ、strutsは何に使われるものか知ってる？
何かいってることが外れているんだよな。
>>50 相当頭悪いですね。
クロスコンパイルにかかるコストも無視していますね。
>>53 そんなコストは自動化で最小化できます。
さっきからバッチ処理って書いてるでしょ。
端的に言うとJavaは馬鹿が使う言語って事ですね。
>>54 では、それを使って新しいOSが登場したときのコストもお考えですか？
端的に言うとC++は古代の馬鹿が使う言語って事ですね。
>>54 バッチ処理プログラムを作るときのコストをお考えですか？
>>56 新しいOSが登場したときにJREが移植されるまでのコストと変わらないでしょう。
>>58 そんなもん一回作れば終わりだし半日もかからんだろ
>>54 OSやCPU,、ハードウエア固有の機能を駆使した複雑なプログラムにまでそんなことが
低コストでできるとお考えですか？
Javaで必死にパフォーマンスがとか嘆いてるのが目に浮かびます。
>>59 C++の場合は各プログラムひとつにつきそれ相応のコストがかかりますが
JREが移植されるときのコストはJREひとつだけですが何か。
>>61 新プラットフォームにコンパイラを自作するわけじゃないでしょう。
クロスコンパイル先のアーキテクチャのコマンドラインオプションを追加するだけです。
あなたは新プラットフォームが出るとJREを自作するんですか？
>>62 > Javaで必死にパフォーマンスがとか嘆いてるのが目に浮かびます。
ついに煽ることしかできなくなったかC++厨。
パフォーマンス？ コストパフォーマンスは君にいちいち言わなくても抜群だが。
>>63 どっちにしろ自動なんだから、人件費はほとんど必要ないでしょう。
>>64 どっちにしろC++はJavaよりも多大なコストがかかりますが何か
俺はJava派だが正直言おう。
Javaは適用できる案件の範囲から限られてる言語ですから最初から負け組言語ですね。
１．Javaは馬鹿が使う言語
>>66 どっちにしろC++はJavaよりもプログラマに負担をかけ徹夜付けにさせ病気にさせ頭がハゲますが何か
>>68 根拠は。
自分の周りがレベル低い香具師ばかりなんだろ。
>>71 Javaだと徹夜付けになったり病気にならないんですか。それは凄いですね。
C++の方がexcitingな言語ですからストレスは溜まりにくいと思いますが。
コーディング規約によりある程度束縛されたとしてもJavaよりはexcitingな言語ですからね。
>>69 > Javaは適用できる案件の範囲から限られてる言語ですから最初から負け組言語ですね。
Javaの案件はC++と食らえるととてつもなく多いが。
>>74 ご冗談を。Javaはサーバーサイドだけでしょう。
>>70 > １．Javaは馬鹿が使う言語
むかつくことをいいやがｔって。おまえこそJavaつかったことがあるから馬鹿なんだろ。
ニューガンダムの連邦の機体で例えると
>>77 まだゲーム程度にしか使われていませんが？
>>77 Javaは携帯電話に向いた言語だとは思えないんですよね。
そのうちBREWに統一されるでしょう。
81 ：
デフォルトの名無しさん ：03/10/09 01:51
>>70 > １．C++は利用者の大半が馬鹿が使う言語
> ２．C++開発者の９割は馬鹿
のほうが現実的だと思うが。
いつも腹立たしく思うことは、C++厨が「Javaは馬鹿が使う言語 」といっておきながら
C++はほんの少ししかできずほとんどC言語レベルしか使いこなせない奴だ。
Cしかできないことを隠すためにうわべだけ「C++やってるので馬鹿じゃありません」とかいう奴。
まったく殴りたくなってくる。
>>81 そういう事を言う人に限ってJavaをCレベルでしか使ってないんですよね。
>>79 iアプリは新人研修と40くらいのおじさんの仕事。
いや大手になると若手がケータイ専門に駆り出されている所もあるみたいだけど、
普通の(中小)ゲーム屋ではバリバリの現役なんかiアプリに回さない。
>>73 >
>>71 > Javaだと徹夜付けになったり病気にならないんですか。それは凄いですね。
> C++の方がexcitingな言語ですからストレスは溜まりにくいと思いますが。
それでexcitingと思うならおまえの作っているプログラムはだれもexcitingとは思わないだろうな、
> コーディング規約によりある程度束縛されたとしてもJavaよりはexcitingな言語ですからね。
Javaはバグだしまくりでそれのための無駄なことに時間を費やすC++よりはexcitingな言語だが。
>>85 C++ではXPが出来ないという事は無いですよ。
>>84 組み込みでいうと、
ハード屋のおじさんが片手間でやってる
PICアセンブラみたいなものなのかな？
>>83 そういうやつ(インスタンスメソッドにしたほうが効率が良いメソッドがすべてstaticになっているアホ)もいるが
おれさまをオマエのような貧相なことしかいえない奴と一緒にするな。
>>81 君(Javaコーダ)が日本語もうまく書けない馬鹿だという事が証明されてしまったわけですが感想は？
>>86 こいつ、いきなりXP言い出してるよ。話がいきなり飛躍してどうするよ。
>>90 BREWって既にこのスレで何度も出てきてるわけですが。
こういうスレに参加するなら双方の言語の最低限のの知識は身につけておいて欲しいですね。
>>91 中身がだろが。ゲームを作っているやしが(移植を除いて)C++でやっているとでもいうのかおい。
>>92 バグが出ない==テストファーストという事じゃないんですか？
Javaは普通に書いてもバグが出ない言語なんですか。それは素晴らしい事ですね。
>>93 知ったかぶりしおって。生意気そうな奴だな。
BREWはあるだけでは「ソフトがなければただの箱」同然だろが。
ゲーム屋的にはどうせならJavaじゃなくてC#がケータイ標準言語になってくれればよかったと思う。
バグが出ないのになんでJavaの案件で火の車になっている所があるのか不思議で仕方がないですね。
>>97 Andrei Alexandrescu
は天才だとは思わない？
>>95 >
>>92 > バグが出ない==テストファーストという事じゃないんですか？
お前がもしそう思っているならお前は会社やめたほうがいい。
そんなことを平気でいうとはお前も恥さらしだな。
> Javaは普通に書いてもバグが出ない言語なんですか。それは素晴らしい事ですね。
お前の脳内変換には呆れたよ。妄想も休み休みに言え。
>>98 DirectX Embedded 的なものがあればよかったのにね
>>98 それだったらC++のほうがいいって話になる。
106 ：
デフォルトの名無しさん ：03/10/09 02:03
Java厨は発言の一つ一つが必死に見えるんですが何故でしょうかね
>>102 テストファーストして単体でバグが出たらテストファーストになってません。
>>103 いや描画APIはどーでもいいや。まだあと１０年は毎年激変するだろうから。
>>105 ケータイだとやっぱりVM系言語のほうがいいよ。
(作る側じゃなくて使う側として)
>>107 お前の妄想。お前は敬語つかっていれば必死に見えないと
思っているらしいがそうは見えないな。平静さを装っているかと思えば
そのような煽り。必死なのはどっちだ？
C#はクロスプラットフォームと言える状態にさえなってない。草の根でLinuxに移植されてるだけ。Java未満。
>>109 何か独り言いってるやつがいるぞ。だれかこいつを相手にしてやれよ。
>>113 サーバーサイドがASP.NETに呑まれたら終わりのJavaだからでしょうかね。
>>115 「必死」の見本を見せてくれているのでしょうか。
>>116 呑まれない。今Javaはサーバサイドを飲んでないけど。
>>111 lisp信者ってついに本物の新興宗教がかってきましたね。
Java厨=高卒
>>118 主語を書いていない奴の意見はまったく意味不明。
>>123 煽ることしか脳が無くなったC++厨は中卒ですね。
まあ俺に言える事は
C++に比べてJavaのポテンシャルの低さと言ったら…
C++のソースは美しいのですよ。
>>101 Andreiも相当頭が良い方ですが、
C++のようなポテンシャルの高い言語だからあのような事が出来るのですよ。
Javaはｵﾌﾞｼﾞｪｸﾄ指向言語なんかじゃない。
C++以外なら必要ないテクニックもあるけどな。
C++は確かにポテンシャルは高い。（賢い奴が使えば。）
>>135 日本語は英語と違って主語必須の言語では無いのですよ。
と言えば分かりますか。もっと教養を身につけた方が良いのですよ。
>>133 正直、名言だと思う。
>>134 たしかに。でも低レベルと高レベルを両方扱う言語ならやっぱり必要な部分なんだよ。
Javaは低レベルはばっさり切っちゃったから、Javaしか知らない奴はC++のテクニックを
よくわからずに批判する。
>C++以外なら必要ないテクニックもあるけどな。
>>136 C++でもJavaでもいいが、プログラマなりコーダなりの事情で
デスマってるてのはあんまりないだろ。
デスマと言語は本質的には関係ない。
C++以外なら必要ないテクニックをJavaしか知らない奴が見る
JavaはC++よりもスタイルを強制される。
pimplは仕方が無いと思うのですよ。
>>141 許されないかどうかじゃなくて
必 要 な い 。
んだよ。
>>142 だからライブラリに拘束されればどちらも同じなのですよ。
>>145 C++の場合はBetter Cとして低レベルなコードがかけてしまう。
Javaは低レベルな部分がなくてライブラリ使用を強制される。
てかJava厨がC++を目の仇にする理由がわからん。
>>146 そんなものは、生のchar配列なんかは使わなければいいだけの話なのですよ。
フレームワークにクラスモデルを拘束されなければ、
スパゲティクラス構造作る馬鹿がいるのはJavaでも同じなのですよ。
これについては、何を使わなければいいとかいう簡単な問題じゃないのですよ。
>>136 がいいこといった。
C++プログラマの大半は本当はC言語しかできましぇーんレベル。
現実ってそんなもんなんだよな。
>生のchar配列なんかは使わなければいいだけの話なのですよ。
>>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は抜きすぎじゃないと？
>>150 それにJavaにもChar配列あるのですよ。
JavaからC++への移植は簡単なのだが・・・。
Javaは馬鹿でもつかえる
>>154 動的型付けができる時点で無限の世界が広がるのですよ。
俺にとっての「脱Cスタイル」の機会を与えてくれたのは当時解説書が軒並みアプレットの解説しかしてなかった当時の
>>153 俺は何でもJavaを適用して失敗する青臭いJava房の方が目につくよ
>>155 つーかポインタも含めてC++の配列は取り扱い要注意だろ。
おのおのの長さが異なる配列変数を大量に宣言しておくと
爆発物を取り扱っているかのように感じる。
>>157 そのこぴぺをあちこちに容赦なく張りつけるんだろ。
>>153 じゃあ間違ってるじゃん。
C使いとC++使いは別人種。
責めるべきはC使いだろ？
>>163 いや、ちょっと言ってみただけだ。
馬鹿でも使えるJavaだとしても、Java使いが全て馬鹿なわけじゃないように
C++使えるつもりのC厨がたくさんいるからといって、全てのC++使いがそうなわけじゃない。
>>162 そんなに生配列をいくつも宣言する理由が分からないのですよ。
それじゃCなのですよ。
>>165 それが、クラス一個作ったくらいで俺様はC++プログラマだぜー、すごいだろー、
みたいな香具師がいるわけですわい。
>>171 いや珠玉混在
だから「何でもJavaを適用して」と書いたつもり
>>170 そんなやついねーよ。
というかいて欲しくない、マジで。
俺は
>>168 の発言がこの馬鹿な議論が行き着くべき終着駅だと思うな。
この馬鹿な議論が何の実も結ばないなんてそれこそ悲しすぎる。
みんなが
>>168 の結論に行き着くべき。
まぁここに居るJava信者は馬鹿だけどな。
JavaとC++を連携するときJavaをメインに使う場合はJNIやRunTimeクラスなどを使うわけだが
>>176 JavaからC++を使わないと出来ない事はたくさんあっても、
C++からJavaを使う必要性は感じないのですよ。
>>177 精度の低い認定してるあたりが馬鹿丸出しですね:)
>>176 正直、部下の会話についていけないものの、
なんとなくかじった知識を披露したかった部長さんの発言のような
謎な終わり方ですね＾＾；
>>172 ちっこいものやメディアプレーヤとかつくるとなるとネイティブ相当の魅力的なAPIが少ないJavaではねえ。
>>181 むしろ統一化されているJavaではその辺は有利だと思いますが、
結局重くてメモリ喰いなら誰も起動しないのですよ。
>>178 サーバ系ではそうもいかないときもあると覆うが。
>>181 いや、ちっこいもの作る時はJavaのが気楽でよい。
スクリプト感覚でさっくり作れるよ。
>>178 JNI で使ってるのは C++ っても template とか使わない C++ だからねぇ…
あとは殆ど C だし…
>>176 RunTime クラスなんてあったか？
>>184 よほどマイナーな新参DBでも無い限り大丈夫だと思うのですよ。
>>188 いや漏れはどっちかつーとC++側で参戦してるわけだが。
それにスクリプト=書き捨てとさりげなく貶したつもり。
3時なので寝るのですよ
俺のPCの時計はまだ2時ですた
正直、Javaでライブラリを書きたいとは思わない。
一番ムカつくのは、別言語から移ってきて、初心者質問スレで
俺が一番ムカつくのは、C系の構文でラップしたSmalltalkをありがたがって
007/007は二度死ぬ
>>197 Objective-C を悪く言わないで下ちい
それにObjective-Cの移植性は怪しいですよ。
>>197 JavaはSmalltalkなんかよりずっとC++に近いわけだが・・・。
>>199 いやobjcは好きですよ？
Chains of ResponsibilityはObjective-Cが一番自然だしね。
>C系の構文でラップしたSmalltalk
>>200 ﾊﾟｰﾌﾟﾙﾌﾞｯｸとInside the C++ Object Modelと
The Java Virtual Machine Specification読んでからまた来いや。
美しい → C++厨は言語仕様の汚さ(マイナス)よりもオートマティックな美しさ(プラス)に惹かれている人種です。
>>203 なぜにVMが関係ある？
VMがあったらSmalltalkと同じってか？
あほだな。
>>202 要するにﾏｰｹﾃｨﾝｸﾞ指向のSyntax Sugarなんだよ。Javaは。
>>205 object-model, object-systemの話ですよ。
>>206 またあほ発見。
JavaがSmalltalkの構文糖だって？
>>207 お前は Smalltalkに触ったことがないだろう？
>>208 C砂糖ふりかけただけだっつの。
使ってて感じないのか？
まったくもってSmalltalkに失礼だ。
>>210 君は「全部Virtual」がSmalltalkとでも思ってるんだろうね。
やれやれ。
Smalltalkには世界がある。
煽ってるC++厨房がこの程度ってことがよく分かったよ。
>>204 その通りなんだが改めて言われると果たしてそれでいいのかと思ってしまう・・・
>>214 ﾎﾞｸはC++使いじゃないんですけど。
病気ですか？
まぁpurple bookに誰もﾂｯｺﾐを入れなかった時点で
>>213 Javaは寄生虫だからこそ魅力がある。
神聖なる寄生虫はある世界(OS)が滅んでもほかの新しいOSにすぐ飛びつける。
C#も寄生虫と化そうとしているが真の寄生虫として撃退され気味。
あっちの世界では寄生虫でないC#、Monoが受け入れられようとしている
>>217 その言い訳もワンパターンで飽きてきたなあ
>>220 あいかわらず妄想激しいですね。
ﾌﾞﾙｰﾌﾞｯｸ読んでからまたおいで。
正直
>>203 はVMだから近いと逝ってるようにしか見えないんだが。
JavaとSmalltalkのMethod Dispatchまわりは全く違いますが。
>>224 確かにJavaとSmalltalk"だけ"を比較したらかなり違うよねぇ。
でもいくつかの言語を含めて比較してみたらどうよ。
・・・vtblを使うJavaとC++は近いよね・・・。
ｱﾎｸｾ
228 ：
デフォルトの名無しさん ：03/10/09 14:18
<丶｀∀´>ﾆﾀﾞﾘ
229 ：
デフォルトの名無しさん ：03/10/09 19:00
C…ポインタを操るのが面白い
Javaは安っぽい三つボタンスーツを着た茶髪のｵﾆｰﾁｬﾝって感じがするなぁ。
Javaの面白いところ
マクロがあればテンプレートなんかいらない。
C++…テンプレートメタプログラミングが面白い
Java...Interfaceを駆使するのが面白い
>>1 に踊らされるｱﾌｫどもを見られるｽﾚはここでつか?
>>234 Interface関連ならSmalltalkの方が面白いと思うが。
>>236 UIじゃないほうのInterfaceですが。
CQ出版？
>>229 > C++…テンプレートメタプログラミングかせ面白い
こいつはJavaでテンプレートを使え無いと思い込んでいたのか
なんて視野が狭すぎる厨房なんだ。
テンプレートとGenericsは別物じゃなかったっけ？
Javaで仮にテンプレートらしきものが使えたとしても、
242 ：
デフォルトの名無しさん ：03/11/05 22:36
Java使いの平均IQ…95
どっちも低いのかよ
>>241 面白い/つまらない とか言う奴のコードは独りよがりで読み難い事が多いのだが…
>>239 は確実にC++やってない厨ですね。やってても初心者どまり。
面白くも無い言語を使っているなら奴隷と変わりませんね
>>247 面白い/つまらない ってのは個人でも時々によって変わるし。
今は C++ は面白い、と感じていても
いつ C++ なんてつまらないと感じるようになるかもしれん。
>>247 作っているモノが面白いのならともかく、
使ってる言語が面白いってのは、それほど重要じゃないと思うが。
250 ：
デフォルトの名無しさん ：03/11/05 23:26
なんかJavaってそそられないのよね。なんか。
>>248 少なくとも現状のJavaはC++よりもつまらない事は同意してるのか？
Javaはまだ言語仕様ガリガリ変わるだろう(C#とタメ張りつづけるには変わらないとどーにもならん)から
わからないけどな。
AspectJとかは現状でもただのJavaよりは面白そうだし。
C++でフリーでGUIアプリ作れる環境あったら教えて～
253 ：
デフォルトの名無しさん ：03/11/05 23:50
フリーのコンパイラもフリーのGUIライブラリもあるがこのスレにはあまり関係無いな
>>242 > Java使いの平均IQ…95
> C++使いの平均IQ…110
C++とやらが実はC厨でC++厨の仮面を被っていることを
想定するなら
C++厨の平均IQは50以下だな。
Java厨とやらがJ2EEやネットワーキングなどを理解していなければ
同様かもしれないが。
>>251 現状のJavaは十分面白いぞ。
Java3Dで遊んでみるのもよし。
Beanで組み立てて遊んでみるのもよし。
さらにJakarta ProjectのJavaフレームワークを使い倒す楽しみがある。
サーバ構築するついでにJavaアプリケーションサーバも立ち上げて
DBアクセスを考慮してオリジナルな掲示板やWebメールを作ったりと
楽しみが満載だぞ。
>>254 平均 IQ が 50 以下って全然現実味ないんだけど。
まぁ
>>242 も根拠なんぞないだろうし。
IQ なんて何測ってるかもハッキリしないようなもんで勝負しても意味ないし。
>>251 >>248 は言語が面白い/つまらない、には意味は無いって話なので
> 少なくとも現状のJavaはC++よりもつまらない事は同意してるのか？
には同意も否定もしません。
Javaなんて必要ない。
なんだ、C++じゃないのか
>>254 >C++とやらが実はC厨でC++厨の仮面を被っていることを
>想定するなら
>C++厨の平均IQは50以下だな。
今、254がいいこと言った！
問題はC厨なんだよ。C++厨もJava厨も仲間。
しかし、C厨もいれて平均IQが110とすると、
純粋C++厨のIQは200くらいか？
>>260 えーと、IQ の標準偏差が 20 と仮定すると
(知能検査は標準偏差20ぐらいになるように構成するのが多いため)
IQ 200 以上の人間の確率は 0.00002867% 程度。
日本人が 1億2千万人として、IQ 200以上は 34人程度。
平均 IQ が 200ってことなので、IQ 200以下がIQ 200以上と同数いると考えると
純粋C++厨とやらは日本に70人程しか居ない、と。
>>260 ちなみに、IQ の標準偏差が 15 と仮定すると
日本には純粋C++厨とやらは 一人もいないだろうと思われる。
頭のいい奴が生まれるのって確率の問題なの？血筋ちゃうの？
>>263 IQが高い ≠ 頭がいい
っつか、「頭がいい」は数値化して評価できないと思うけど…
>>261 >純粋C++厨とやらは日本に70人程しか居ない、と。
そんなもんだろ。ｗ
俺はそのうちの一人ですが、なにか？
266 ：
デフォルトの名無しさん ：03/11/07 11:58
>>241 Javaでは実装しない多重継承ならできるが。
それとも実装多重継承に頼りたいのか？
実装多重継承などという愚かなことをするのはやめれ。
テンプレートのそんなことをするためにあるものじゃない。
>>263-264 そういえば
「EQ こころの知能指数」
という本があったなw
EQ Emotional Quotient
IQが高くても社会で成功するとは限らないという話。
もうひとつのEQの略として教育指数(educational quotient)というのもあったなw
>>265 >
>>261 > >純粋C++厨とやらは日本に70人程しか居ない、と。
> そんなもんだろ。ｗ
> 俺はそのうちの一人ですが、なにか？
では、その証拠を示してみてくれ。
>>265 >>261 のは間違い。標準偏差は高くても 15ぐらいのが多い。
IQ 200 以上は日本に一人もいない可能性が非常に高いため、
純粋C++厨は日本に一人もいないと考えるのが妥当。
ってのを考えれば、まぁそんなもんかなと思うね。
>>267 >実装多重継承などという愚かなことをするのはやめれ
できるけどやらない、っていうのは少なくとも賢そうに見えないこともないけど、
Java 厨の場合出来ないくせに、愚かだからやめれって人に指図するあたりが
（本当のところはどうであれ）バカそうに見えちゃうんだよなぁ。。。
>>269 必死に他人を馬鹿にしようという態度が(以下略)
>>267 「EQ こころの知能指数」は読んだか？
著者は EQ を IQ のように安易に数値化するのを厳しく戒めていたが。
オブジェクト指向的な情報隠蔽もろくに理解できていない奴が、
274 ：
デフォルトの名無しさん ：03/11/07 12:43
テンプレート語るのにオブジェクト指向は直接的な関係は無いもの
275 ：
デフォルトの名無しさん ：03/11/07 14:47
>>270 はてそれはどうかな。ポインタ演算と勘違いしていないかなw
C++厨の場合はスパゲティコードを書いてわざと暗号のように汚いコードを量産して
チームのことを考えずに独りよがりなコードかいて、
Facadeパターンのひとつでも簡単に覚えられることをやろうとせず
自分の得意分野が限られているくせに自分の立場を守ろうと保守的になって
わざと自分だけにわかるように書いてついでに無駄なイースターエッグまで埋め込み
パターンのひとつやその類似すら使わないのは
アージャイル開発では馬鹿そうに見えちゃんだよなな。。。
>>272 読んだよ。抽象的なものほど数値化したところで正確な答えは得られないことは
カオス理論に囲まれた自然界でも常識でしょ。
>>275 「はてそれはどうかな」と言われても困るけど、後半は同意。
でもなんとなくJava厨って、Java に実装継承があったらあったで嬉々として
実装継承を用いてこんなパターンが、とか語りだしそうなイメージあるんだよなぁ。。。
印象批判だけど。
まぁそれでも Java だと他人がきれいに整備したフレームワークに則ってちょっとだけ
ロジックを書くっていう仕事が大半だから、コードの可読性と保守性は高く保たれるとは思う。
･･････「実装の多重継承」ね
279 ：
デフォルトの名無しさん ：03/11/07 18:15
結局はこのスレで評判の悪い方が普及すると思われ。
280 ：
デフォルトの名無しさん ：03/11/07 23:53
まさかとは思うが、
>>277 はJavaに実装単一継承がないと思い込んでいたのだろうか？
おいおい！
それではテンプレートメソッドパターンですら実装できないではないか！
とツッコミ
このスレは誰もポリシーベーステンプレートメタプログラミング分かってないな。
言語のスレで何故に設計手法
Javaのswingラクでいいわ。ホント。
>>239 =266=275 か？
典型的なjava厨だな。
あとjava厨の言い訳にC++厨の大半はC厨みたいなこと
言う奴がいるが、それはjava厨がC++厨より劣ることを
認めているようなものだな。
正直C++で作られたJavaがC++より上である道理がない。
286 ：
デフォルトの名無しさん ：03/11/08 02:38
>>284 されどそんなJava厨に勝るC++厨はほとんどいないという現実。
君はC++をフルに使いこなせるか？
>>285 それは、「親から生まれた子供は親より上である道理がない」ってのと同じだね。
C++ 厨の頭が悪いというイメージを植えつけようという Java 厨の陰謀か？
Java厨ってさ、誰かが言った事を鵜呑みにしちゃうのが多いだろってのが最近の感想。
>>288-289 陰謀？ お前被害妄想でかすぎ。
Java厨の頭が悪いというイメージを植えつけようと必死になっているC++厨だってねえ・・・
そりゃあんた、死に物狂いで頑張ってきたCOBOLerやアセンブラ厨が
COBOLやアセンブラよりも新しい言語のC厨をむかつくといっているのと同じレベルだよ
>>289 > ・C++厨の大半はC厨
これ言ってるのは C++使いじゃないかと思ってたよ。
自分は C++使いの中でも特別だと思い込んで、自分は IQ 200 とか言ってた奴も居たし。
> まともなC++使いは少なくともOOPにおいてもJava厨よりも習熟度が高い。
(一般論としては)全く根拠の無い事を(一般論として)言われても…
「Java厨よりもOOPにおいて習熟度が低いC++使い」は「まともなC++使い」ではないって可能性もあるし…
結局宗教戦争だわな。
293 ：
デフォルトの名無しさん ：03/11/08 09:45
香ばしいアホアンチと宗教戦争なんてしても無駄。
294 ：
デフォルトの名無しさん ：03/11/08 09:52
ところでJavaの人が自分たちのものみたいにいうデザインパターン本に
C++スレでクラスをただの２次元配列として設計し、
296 ：
デフォルトの名無しさん ：03/11/08 09:59
>>295 どんなコード？
あと大勢いる中の低い部分だけをとりあげて全体を判断するのはおろかなことだな。
＞テンプレートを使うテクニックのいくつかは、
＞型付けの弱い言語では必要ないし、
これはひっくり返して言えば？
GoFのデザパタ本のサンプルはC++とSmalltalkで書かれているが、
>>295 なんとなくテンプレートメタプログラミングを誤解している悪寒
>>295 >オブジェクト指向の基礎的なことも理解できていない
>くせに「テンプレートメタプログラミング」が最新の
>テクニックだ、と勘違いして鼻高々なバカばかり。
テンプレートメタプログラミングの基礎的なことも理解できていない
くせに「オブジェクト指向」なんて関係無いものを勘違いして鼻高々なバカばかり。
テンプレートメタプログラミング厨の集うスレはここですか？
>>284 少なくとも文法は一通り知ってますが何か？
iostream、STL、boost等一通り使えますが何か？
まあ、それでも極めた気にならんような奥の深さが
魅力なのだが。
>>295 >オブジェクト指向の基礎的なことも理解できていない
なんて何で言い切れるん？
C++にとってクラスや継承なんかは所詮、言語が
持つ表現方法の一つに過ぎん。導入した目的が
オブジェクト指向サポートだったとしても、他の目的に
それを使用してはいけない道理はないだろう？
>>301 > C++にとってクラスや継承なんかは所詮、言語が
> 持つ表現方法の一つに過ぎん。
C++ は表現の幅が広い。Java は表現の幅が狭い。
複数人のプロジェクトの場合は
表現の統一ができた方が保守性が上がるので
表現の幅が狭い方が良い。
> 導入した目的がオブジェクト指向サポートだったとしても、
> 他の目的にそれを使用してはいけない道理はないだろう？
大多数の間でクラスや継承はオブジェクト指向サポートのために使う、
という合意ができている場合、それを他の目的に使用した場合
誤解の生じやすいコードになる可能性が非常に高い。
特別な理由でもない限り目的外の使用は止めた方が良いと思われ。
表現の幅が狭い方が良いならbasicでも使ってろ
C++しか知らなくて最近javaかじりはじめたんだけど、かなり新鮮だな。
とりあえず、ヘマしても落ちないjavaがｲｲ！
>>304 > 演算子オーバーロードがなくてInteger+Integerも計算できないとか､
C++ の iostream みたいに演算子のオーバーロード使われるよりは
演算子のオーバーロードなんぞ無い方がマシ、って考え方もあるので。
> そのくせStringは+演算子使えるし。よくワカンネ(´д｀)
頭が硬くなってきてるんじゃない？
ちなみに、String だと + 演算子が使えるんじゃなくて
+ 演算子の左右のオペランドの何れかが String だと
+ が文字列連結演算子と解釈される。
>>306 >C++ の iostream みたいに演算子のオーバーロード使われるよりは
>演算子のオーバーロードなんぞ無い方がマシ、って考え方もあるので。
頭が硬くなってきてるんじゃない？
>>307 個人が「 ** がワカンネ(´д｀)」って事なら個人の資質が問題になる。
演算子のオーバーロードはが要らんってのは
多人数での開発の際に起こりうる問題を未然に防ぐのが目的だから
個人の資質がどーこーという問題ではない。
309 ：
デフォルトの名無しさん ：03/11/08 23:18
>>294 > ところでJavaの人が自分たちのものみたいにいうデザインパターン本に
> Javaのコードって1行もでてこないよね
理解してJavaに適用するにはそれでもほとんど困らないんだけどなあ。
>>302 >
>>301 > > C++にとってクラスや継承なんかは所詮、言語が
> > 持つ表現方法の一つに過ぎん。
> C++ は表現の幅が広い。Java は表現の幅が狭い。
既存のクラスライブラリやフレームワークの整備によっては
表現の幅が狭いかどうかは微妙だな。
JavaのAPIはまさに増えてきている。
C++にはないさまざまなAPIが用意されオブジェクト指向レベルでは表現の幅は広い。
>>304 > C++しか知らなくて最近javaかじりはじめたんだけど、かなり新鮮だな。
> 演算子オーバーロードがなくてInteger+Integerも計算できないとか､
> 漏れからするとかなり(ﾟДﾟ)ﾊｧ?って感じなんだが。
そういうあなたにはC#がお似合い。
Javaの場合は危険性を最小限におさえようとしているわけで。
C#の場合は危険性や拡張性よりも即座に使えるという利便性を追求しているのが
C#とJavaとのアプローチの違い。
>>305 >>とりあえず、ヘマしても落ちないjavaがｲｲ！
ん～、それはどうだろう。
間違えたコードを書いてしまったのなら
とっととアプリが死んでくれた方がバグの早期発見に繋がると思うんだが。。。
>>302 そうか？無理やりオブジェクト指向の枠にはめるのも
どうかと思うが。なんか、その発想だと新しいこと（表現）
やろうとする度に、言語なりライブラリを拡張せにゃ
あかんような気がするが。
100の事をやるのに100の知識を覚えなきゃならん、みたいな。
314 ：
デフォルトの名無しさん ：03/11/08 23:34
まあどっちでもいいんだが、
>>310 C++のAPIはまさに増えてきている。
JavaにはないさまざまなAPIが用意されオブジェクト指向のみならず色々な表現の幅は広い。
C++の「API」は処理系依存が多いしー。
演算子オーバーロードのナニが危険なのかわかんねぇ
>>312 >>305 のいっている落ちないは大げさだということには同意。
だがそれだけJavaは堅牢なことも事実。
>>313 100のクラスがあるからといって100のクラスを覚えないといけないことはないぞ。
JavaのAPIには有名なデザインパターンを上手に使ったフレームワークが数多くあるなら
それらのパターンなどを知っていると把握しやすい。
しかも、あることをやるためにすべてのことを覚えないといけないというNRI症候群に
陥る必要も無い(むしろ全部お終えられたら神！というか人生の無駄っつーのもあるわけだし)。
そのためのオブジェクト指向なわけだから。
>>313 > 100の事をやるのに100の知識を覚えなきゃならん、みたいな。
そーじゃなくて、
10人が全員 10 の事を覚えるのよりは
10人が全員 5 の事を覚える方が簡単だし
ルールも徹底しやすいって事。
>>315 鸚鵡返しは見苦しいぞ。
C++の場合はAPIというかライブラリが膨大な聖書のように乱立しているようなもんだ。
Cから受け継がれたオブジェクト指向を無視したAPI群も多く酷い。
オブジェクト指向をなめとんのか、といえるものといえば
とくにVC++のWin32 API
あれはひどい。
次期VC++.NETはAPI以外でももっと酷い。あれはC++じゃない。
M$が独自拡張した有史以来の穢れたC++だ
>>317 iostream みたいに俺ルールで演算子のオーバーロードを使いまくると、
とあるクラスで演算子がどーゆー意味で使われてるのか即座に理解できなくなる。
>>317 > 演算子オーバーロードのナニが危険なのかわかんねぇ
コードの可読性というものを理解したことがあるかね？
使っている本人だけは使いやすくても他人にはソースコードをよみにくくしている結果をもたらす
ことが多いのだよ。
演算子のオーバーロードを行うとどのようにオーバロードされているかを
324 ：
デフォルトの名無しさん ：03/11/08 23:56
おまいらC++厨よ！
そんなコンパイラがあったらD言語もいらなくなりそう
>>320 オウム返しされるようなことを書くからそうなる
327 ：
デフォルトの名無しさん ：03/11/08 23:59
オブジェクト指向をしっかりと学び
>>326 反駁できないからオウム審理狂といわれる、
ここでも蛇罵統一教会が壷売りに来てるのか
2chのトップページに壷画像を貼り付けられ馬鹿にされているにもかかわらず
331 ：
デフォルトの名無しさん ：03/11/09 00:05
>演算子のオーバーロードを行うとどのようにオーバロードされているかを
C#には勝てそうにもないからC++叩きに来ますた
>>320 >Cから受け継がれたオブジェクト指向
ﾊｧ？
>>321 Stringはいいんだ？
>>322 a.add(1).sub(2) と a+1-2 どっちが読みやすい？
>>323 ﾊﾞｶ？普通のメソッドでもどう動作するかはソースを公開するかコメント付けるしかないだろ
>>320 はあんまり口をあけない方がいい。ﾊﾞｶが他人に移るから。
>>333 > Stringはいいんだ？
String で +演算子だけだし、
文字列を + で結合するって文法は他の言語でもよく使われている。
演算子のオーバーロードを禁止するのはあくまで乱用を防ぐためなので
String だけ、とか制限されていれば それほど問題はない。
ひとつ言うと String は演算子のオーバーロードしてない。
>>333 >
>>320 > >Cから受け継がれたオブジェクト指向
> ﾊｧ？
こうやって句読点を打とう
Cから受け継がれた、オブジェクト指向
>>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)
のほうが見やすいな。
>>333 >
>>323 > ﾊﾞｶ？普通のメソッドでもどう動作するかはソースを公開するかコメント付けるしかないだろ
ある程度の勝手な型変換や
配列のバッファーオーバーフローがおこるかどうかは言語仕様によっては
気にしなくてすむということがあるわけだ。
>>334 そんなオウム君なあなたには理解できないことだったのですね
>>333 > Stringはいいんだ？
JavaではStringの+演算子の自前での オレ様オーバーローディングはできないわけだが。
よってさほどの危険性はないわけだ。
精神病院にいる患者の言うことは理解出来ないし、理解出来なくても構わない。それと一緒。
演算子のオーバーロードって微妙だよね
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 ) )
などと書かれていた日には、式の整理困難間違いなし
適当にオーバーロードすると確かに問題を起こすけれども適切に使えば効果は上がる事は確か。
むやみには使えないが、これを否定するのは手が痒いといっているのに、ならば腕を切り落とせと言っているようにも思う。
>>338 >+, -演算子の定義をだれかが勝手に書き換えた疑いがあるなら
>a.add(1).sub(2)
>のほうが見やすいな。
ﾊｧ？a.addの定義を勝手に書き換えられる疑いは無いんか？
>>342 脳内変換で現実から逃げるC++厨(ﾌﾟ
技術的な話題ができず反論もできなくなるとこういう誹謗中傷しかできないのが
C++厨(本当はCしかできない間抜けなC厨)の特徴。
>>344 それはね、「どういう処理をしているか」と言う点について見通しがいいんだけれども
「何を意味しているのか」という点については見通しがとても悪いんですよ。
プログラムで重要なことは、「何を意味しているのか」という点も非常に大きなウエイトを持っていると思うんで。
>>344 定義が重複するならひとつで十分。
名前が違うだけで機能が同じ関数をつくるのは
eXtreme Programmingでは無駄とされるように、
名前が違うだけで機能が関数と同じ演算子を定義するのは無駄
になる可能性が大きいというリスクを背負う。
>>345 さっきから反論してんだけど？今時(ﾌﾟ ってナニ？精神病院では今頃はやってんの？
要はJAVA厨はポインタ分かりませんということか
>>347 >定義が重複するならひとつで十分。
じゃあa + bだけでいいよ
>>350 ポインタ理解できなくて馬鹿にされた事でもあるのか？
a + bがナニを意味してるかわかりにくいという奴は、小学生からやり直した方がいいよ
>>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)のようにメソッドを使った方が読みやすいことになる例が多々あるのだ。
>>350 ポインタがわからなかったらJavaすらできないわけだが。
Javaはポインタが無ければプログラミングすらできないことも知らないのか。
>>354 a.add(b)もどのように処理されるか一目瞭然ではないだろ。
>>355 二項演算は、その記号よりも中置することに意味があると思うのですが如何でしょうか。
ワザトa.add(b)で意味を分かりにくくしてギャップを埋めるとか言ったら馬鹿扱いしますよ
>>357 > a.add(b)もどのように処理されるか一目瞭然ではないだろ。
どのように処理されるか一目瞭然でないのが問題なのではなく、
意味はわかるが、どのように処理されるかはわからない、というギャップが大きいのが問題。
a.add(b) の方が a+b よりギャップが少ない。
>>355 spiritって精神とか魂という意味だよね？
なんでspiritなの？
>>359 馬鹿扱いしてくれて結構だけど、ギャップが大きいのは事実。
ギャップが大きければ危険性が高くなるのも事実。
じゃあa + bが意味どおりに実装されればOKでつね
>>363 「a+b」がどのように処理されるべき、と感じるかは個々人によって違うので
話はそう簡単ではない。
>>365 add の場合はよりギャップが少ないと、さっき書いたんだけど。
端から見てるとどっちも対して変わらないと思うよ
>>364 * なら、まあわからなくも無いが+を変な形で定義するのは、バグの時くらいな気もするが・・・
しかし、* にしても、数学屋かそれもどきの人がキテレツな定義を準備するときぐらいだと思うが。
メソッドを利用すれば、英数字が使えより適切な名前を付けることができるが、
Stringだって + で連結するのか、それとも個々の要素を足すのかわからんよね。
>>371 > Stringだって + で連結するのか、それとも個々の要素を足すのかわからんよね。
そーゆー解釈をする人は見たことがないけど。
Javaで言えば "ab" == "a" + "b" が true なのに
"ab" == new String("a") + "b" が false になるってところで躓く人はよくいる。
そーゆー話。
ぶっちゃけおまいらJavaが演算子オーバーロードをサポートしていたら、演算子オーバーロードできるのを非難しなかっただろ？
>>371 > でもそれを受け入れてる。それはなんでやって話ですよ。
結構な人が躓く。けど乗り越えてるだけの話。
演算子のオーバーロードができると、躓く箇所が増える。
>>372 >そーゆー解釈をする人は見たことがないけど。
そーゆー解釈をする人を危惧して、文字列連結演算子が .. とか & とかなってる言語を動思う？
>>371 > ぶっちゃけおまいらJavaが演算子オーバーロードをサポートしていたら、演算子オーバーロードできるのを非難しなかっただろ？
そんな妄想の話をされても…
> その証拠はStringには何も文句をいわないことだよ。
証拠にはならんね。
String は演算子のオーバーロードをしていないので。
>>375 > そーゆー解釈をする人を危惧して、文字列連結演算子が .. とか & とかなってる言語を動思う？
なるほど、と思う。
型のない言語で数値と見なして足すのか文字列を連結するのかはっきりさせるためでは
Stringの + も非難すべきだよね
演算子のオーバーロードが欲しいと思うこともたまにはある。
>>348 >
>>345 > さっきから反論してんだけど？今時(ﾌﾟ ってナニ？精神病院では今頃はやってんの？
こんなこと書いている香具師が技術的に反論？ ↓
>>342 > 精神病院にいる患者の言うことは理解出来ないし、理解出来なくても構わない。それと一緒。
C++厨はもはや誹謗中傷と人格攻撃しかできなくなったな。
これだからC++厨は過去の栄光におぼれてジジイCOBOLerと同格呼ばわりされるんだよ。
とりあえずさらしあげておこう。さらしあげられることで身の程をよく知ってもらおうか。
>>383 なんでその２れすだけだと思う？いいから引っ込んでろよ。
結局、どういう処理をしているかという問題が不明確になるリスクが
383のアホさが晒されてしまった
>>373 > ぶっちゃけおまいらJavaが演算子オーバーロードをサポートしていたら、演算子オーバーロードできるのを非難しなかっただろ？
していたよ。
> その証拠はStringには何も文句をいわないことだよ。
おい、まだ理解していないのか。C++やっているくせに脳足りんのか？
JavaのStringの演算子オーバーロードは自作できないんだが。
>>372 それは演算子のオーバーロードうんぬんより、
"a" + "b"をコンパイルすると自動的に"ab"に置き換えられるところに
問題があると言った方がいいと思うが。。。
インスタンスの過剰生成を抑えるためか知らんが漏れ的には欠陥かと思うがな
>>385 > 完全排除に踏み切ったJavaは神経質過ぎだろうね、得た物もあるが失った物も多い気がする。
それをいったらSmalltalkはどうなんだ？
なんか、このスレ見ているとC++厨の子供っぽさに失望する
>>385 > 結局、どういう処理をしているかという問題が不明確になるリスクが
> 何を意味しているのかがハッキリする見通しのよさを超えているかどうかの問題って感じだね。
それは問題の一つ。
iostream のようなオレ定義の演算子のオーバーロードが多用された場合
何を意味しているのかわからなくなる、という問題がある。
後者の方が大きな問題だろうね。
>>390 すもーるとーくはあれで良いんです、オブジェクト指向に対するあくなき追求がポリシーの仙人みたいな言語ですから。
394 ：
デフォルトの名無しさん ：03/11/09 01:39
>>388 ならばStringBuffer#append()や
String#concat()でも使っていなされ。
Stringの+はPrintStream#println(String)のためにあるようなものだよ。
>>391 そのC++厨とかJava厨とかひとくくりにする癖をやめたほうがいい。ガキっぽいからさ。
>>394 >定義が重複するならひとつで十分。
>名前が違うだけで機能が同じ関数をつくるのは
>eXtreme Programmingでは無駄とされるように、
>名前が違うだけで機能が関数と同じ演算子を定義するのは無駄
>になる可能性が大きいというリスクを背負う
反してるね。やはりStringは設計がおかしかった。
>>392 あれは惜しいと思ってるんですけどね、Loki boost が出てきた今、
再度そのノウハウを使って作り直せば、あのスタイルの演算子オーバーロードでも
かなりよいものになると思うので。
template どころか、まだ、class の概念・仕様すらまともに定まってなかった頃の物にしては悪くないと思うんですがね。
古いものにケチつけても仕方ないです。
そのうち誰かが新規に作って標準化してくれることを期待してます。
>>389 文字列連結演算子を非難する人も居るけど、
どっちかというと演算子のオーバーロードを排除するなら徹底しろ、という論調が強いような。
>>394 意味が通じていないようだ。
漏れが言いたいのは、
"ab" == new String("a") + "b" が false
"ab" == "a" + "b" は "ab" == "ab" となって true だが、
"ab" == "a" + "b" は "ab" = new String("a") + new String("b") と解釈されてほしいということ。
ちなみに、値と参照の区別はついてるよね？
"ab" == "a" + "b" は "ab" = new String("a") + new String("b") と解釈されてほしいということ。
>>399 Java のプリプロセッサ作るとか、新しい言語作るとかすれば？
"a" + "b" が "ab" でなく new String("a") + new String("b") と解釈されてほしい理由を教えてくれ
まあどうせ "a"+"b" が "ab" になるのなら
>>403 > String s="a" のとき "a" == s が常に真になる
個人的には 「==」 は参照値の比較だ、という規則に例外を作る事になるので要らない。
> (switch文とかも)
個人的にはあんま必要性感じないけど… あった方がいいのかな？
C# にはあったような…
Java において連続した文字列リテラルが
コンパイル時にひとつの文字列リテラルにまとめられるのは
仕様なのか？コンパイラの最適化なのか？
>>399 >ちなみに、値と参照の区別はついてるよね？
Java における文字列リテラル ("a" など) は
new String(new char[] { 'a', }).intern() の省略表現。
String#intern() はある意味値を参照に置き換える操作だ。
>>404 まあ "a"==s が真になるということを認めるということは
真面目に演算子のオーバーロードを認めるか
でも==と+のみってわけにもいかないだろうし
結局その演算子が何を比較・演算してるのかが
きちんとわからないと不安であるというのは
まあ既出の問題で、Javaはオーバーロードを
端から放棄してるからその問題も起こりえないという
いいんだかわるいんだか って漢字
不便を以って便を為すってところだ。
どう考えても "ab" == new String("a") + "b" と
1.7からは演算子のオーバーロードを取り入れるようだけど
やっぱ演算子のオーバーロードあったほうが便利だね、って気づいたんだね。テンプレートもまた然り。
C++で演算子のオーバーロードをするときって
C++の演算子オーバロードはあくまでオーバロードであって
>>406 まあ、判らなくは無いが、同時にその問題が起こるのは == 程度だとおもうけどね。
確かに等しいという事については、何についてっていうのは人それぞれになりがちなのは認める。
(Key,Value)のようなデータはその典型だと思う。比較演算子は難しい。
けれども、それ以外の演算子は、まあ大体見ての通りと思うけどね。
C#を使っていると、参照比較とインスタンス比較の演算子を別けて参照比較用に === 等にして欲しかったのは確か。
ちなみに C++ だと、ポインタ操作のため常に意識していていたり
&a == &b となって区別がつくケースが多く問題が出る事は殆どないですね。
>>412 俺もそう思う。演算子を自分で好きなように定義できる言語がうらやましい
415 ：
デフォルトの名無しさん ：03/11/09 02:49
>>414 演算子と関数やメソッドの区別があまりない言語も含めるといくらでもある。
>>405 > Java において連続した文字列リテラルが
より正確には定数式の値となる文字列、ね。
"pai=" + Math.PAI
とかも intern() される(はず)。
> 仕様なのか？コンパイラの最適化なのか？
仕様。
> new String(new char[] { 'a', }).intern() の省略表現。
intern() されるのはクラスファイルの読み込み時だから、
その説明はちょっと違うかと。
>>418 > "pai=" + Math.PAI
"pi=" + Math.PI だった…
(/o＼*)
422 ：
デフォルトの名無しさん ：03/11/09 03:22
>>400 ならば、
new String("ab") == new String("a") + new String("b")
"ab" == "a".clone() + "b".clone()
と解釈されて欲しいとでもいうのかおい。
424 ：
デフォルトの名無しさん ：03/11/09 03:24
>>403 > まあどうせ "a"+"b" が "ab" になるのなら
> String s="a" のとき "a" == s が常に真になる
> くらいまではやってほしかったとは思う。
それは絶対にだめだ。オブジェクト指向に反する。
equals()メソッドを使わなければならない。
どうしてもそうしたければSingletonクラスを作れ。
そうか、416と417の「414」は「415」の間違いだな。
>>404 > > (switch文とかも)
> 個人的にはあんま必要性感じないけど… あった方がいいのかな？
> C# にはあったような…
switch文の引数にオブジェクトを対応させるということか？
そういうオブジェクト指向破壊機能はいらないというよりもむしろ邪魔だ。
>>403 > String s="a" のとき "a" == s が常に真になる
現在の仕様でも常に真になりますね。
428 ：
デフォルトの名無しさん ：03/11/09 03:29
String#equals()メソッドを使えば済むものをお前らはなぜ==を使うことに拘る？
>>403 > (switch文とかも)
if文があればそんなもんはイラン
>>428 拘るわけじゃないけど
そこまで言うなら 、String s = "hoge"; とか s = "a" + "b";
という表現があるのは ちょっとおかしいと思うっすよ。
なんつーか、 == で比較したっていいじゃん
Stringだけでいいからさぁ
という話。普段はちゃんとequalsつかうし、このくらい許して
>>426 > switch文の引数にオブジェクトを対応させるということか？
そーじゃなくて、switch( Expression ) の Expression が String を受け入れるって事。
> そういうオブジェクト指向破壊機能はいらないというよりもむしろ邪魔だ。
オブジェクト指向は破壊しないと思うよ。
JDK1.5 では 列挙型で switch できるようになる(はずだ)し。
何でStringは特別扱いなのにIntegerはそうじゃないの？
>>431 同じ文字列の比較を何回も行う場合とかは
文字列全部 intern() して == で比較行うけど。
>>433 > 何でStringは特別扱いなのにIntegerはそうじゃないの？
言語設計者に聞いてくれ。
436 ：
デフォルトの名無しさん ：03/11/09 03:38
>>430 > なんつーか、 == で比較したっていいじゃん
> Stringだけでいいからさぁ
そんな糞機能使いたければオートオーバローディングに頼っているC#でもやれ。
Singletonパターンというものがなんなのかわかっとるか。
そんな糞機能ばかり使っているとオブジェクト内の文字列を変更したときの処理や
マルチスレッドで泣きをみるぞ。
>>409 > 1.7からは演算子のオーバーロードを取り入れるようだけど
JSRにそんなことかいてあんのか？
すぐに確定するとは思えない。
>>432 > > switch文の引数にオブジェクトを対応させるということか？
> そーじゃなくて、switch( Expression ) の Expression が String を受け入れるって事。
ｲﾗﾈ。ifや専用メソッドで十分。
>>431 そんなのは知ってますって。
ひとつ聞きたいんですけど
文字列を比較するときって、同じリテラルかどうかを見ることって
ほんとにあるんですか？
まずほとんどの場合、文字列の比較がしたいだけであって
同一の実体かどうか なんて検査は不要だと思うんですけど・・・
あ、継承していたら話は別か。
そのときは何の機能つけてるかわからないし
文字列の単純比較は出来ないのか
>>433 おまいはIntegerで何をしたいのか
>>440 マジでおまいはマルチスレッドをやったほうがいい
>>440 String は final で修飾されてるので継承できません。
>>436 なぜ、String a = "hoge"; や "a"+"b" だけに
シンタックスシュガーが認められているのでしょうか
紛れが起こることがほとんど無い上に便利だから ってこと？
>>443 じゃあ文字列の比較を==でしても問題ないじゃん
うーん設計者は何でこういう実装にしたんだろう・・・
>>440 > 文字列を比較するときって、同じリテラルかどうかを見ることって
> ほんとにあるんですか？
「リテラル」じゃなくて参照値だけど、
>>434 とか。
>>442 なぜ？
String#equals ってアトミックじゃないの？
>>445 言語設計者が何考えたかは知らんが、
個人的には 「==」 は参照値の比較で
equals() で同値かの比較を行う、
という規則があるからだと思う。
>>445 だからお前はマルチスレッドとシングルトンの意味を調べて来いや。
このオブジェクト指向も知らない恥さらしが
>>445 お前はオブジェクトのクローンについてもとんでもない誤解を生んでいそうだ。
C++ vs Java が
>>448 == は参照値の比較、プリミティブな値だけ比較できる ってことで
まあ納得はするんですが、 文字列の連結に + が使える事に関して
その実装のポリシーに疑問が沸きますよ、やっぱり。
なんつーか、いっそ + で連結なんて出来なかった方が
清清しくてよかったと思うんですけど。
>>449 マルチスレッドとシングルトンの意味はよく知ってますよ。
それとStringで == を使っちゃいけないこととの関連性が
イマイチ理解できないッス
>>448 ネタばかり流すなよ。
規則だったら==でも問題ないんだが。
Stringオブジェクトがメモリ上でどのように管理されているかがわかれば
==を使ってはならない理由は一目瞭然なのだが。
>>452 その姿勢は正しいね。
他のヤツラはStringが + で連結できることに何の疑問ももってないっぽいもの。
演算子オーバーロードを否定するならStringの + も同じ理由で否定できるのに。
Javaに演算子オーバーロードが最初からあったら否定しなかっただろう、ってのは当たってそう。
>>452 JavaではStringの扱いは特別なんだが。
String以外の型にStringオブジェクトを代入すると
暗黙のうちにtoString()メソッドが呼び出されるわけだが。
お前はそれすらも否定する気か？
>>454 「文字列を == を使って比較できない理由」 を論じてるんじゃないっすよ
それは百も承知の上で、あえて、シンタックスシュガーのひとつとして
== で「文字列」の比較ができるようにすればいいのに何故しなかったの
ということを言っているんですね。
それを言い出したら さっきから言ってるように
+ での連結を認めるのも何だか変ザマス
>>456 特別なら特別で、もういっそ == も特別に扱っちゃおうゼ！
次のバージョンあたりから！
と言いたいです。
>>455 >
>>452 > その姿勢は正しいね。
> 他のヤツラはStringが + で連結できることに何の疑問ももってないっぽいもの。
では聞こう。Stringに+を使うことでどんな困った問題があったのかね？
> 演算子オーバーロードを否定するならStringの + も同じ理由で否定できるのに。
ただの偏屈だな。Smalltalkには値型は一切無いのになんでJavaには値型あるのか？
Smalltalkではfor分野if文もおうじぇくとなのになんでJavaではそうなっていないのか？
JavaはOS非依存なのになんでOSによって挙動や見栄えが異なるのか？
と質問しているようなものだ。
> Javaに演算子オーバーロードが最初からあったら否定しなかっただろう、ってのは当たってそう。
なくてもあっても否定するんだが。たとえばJavaですでにあるもので否定したいものがある。
instanceofキーワードも気に入らん。否定する。
assertもいらん。JUnitで十分できることを無駄に付け加えて余計だ。
はやくGenericsによってサブクラスの型をいちいち調べる機能をなくして欲しい、と思うこともある。
>>457 >
>>454 > 「文字列を == を使って比較できない理由」 を論じてるんじゃないっすよ
>
> それは百も承知の上で、あえて、シンタックスシュガーのひとつとして
> == で「文字列」の比較ができるようにすればいいのに何故しなかったの
> ということを言っているんですね。
==とequals()を区別して使いたいからに決まっているだろ。
何度もいうが、マルチスレッドをやってみろ。
==とequals()を区別して使ってみたい理由が痛いほどよくわかる。
ついでにObject#clone()についても勉強しろ。
>>459 + で連結できること に困った場面はありません。便利だし。
で、逆に質問なんですが
== で文字列同士の比較ができるようになったとき、
それで怒りうる問題にはどんなのが考えられますか？
>>458 JCPに提案でもしてみなと。真っ先に否定されるぞ。
どうしてもやりたければC#を使うか自分でJavaを改造しろ。
>>461 > で、逆に質問なんですが
> == で文字列同士の比較ができるようになったとき、
> それで怒りうる問題にはどんなのが考えられますか？
オブジェクトの同値性が確認できないという困った問題が考えられるだろうが。
>>455 > 演算子オーバーロードを否定するならStringの + も同じ理由で否定できるのに。
演算子のオーバーロードは文字列連結演算子と同じようなものを いくらでも作り出すことができる。
基本的に同列の問題じゃない。
>>459 >では聞こう。Stringに+を使うことでどんな困った問題があったのかね？
俺は演算子オーバーロード容認派だから困ったことは無いけど。
オマエラ演算子否定派が色々な難癖つけて演算子オーバーロードを否定してんのに
なぜStringだけ容認するのかがわからんといってんの。矛盾してる。
なぜStringの+を容認するのか、理由はわかる。便利だからだ。
同様に便利だから演算子オーバーロードは容認されてもいいべきだ。
いやもう、とにかくJavaの鉄則や落とし穴を読めと。
>>456 > String以外の型にStringオブジェクトを代入すると
> 暗黙のうちにtoString()メソッドが呼び出されるわけだが。
ウソはいかんぞ。ウソは。
>>460 String s="hoge";
String t= Nanntoka.toString(); ← まあ結果的に "hoge"文字列が返る何か
このとき、 s==t が成立しない ということが重要な意味を持つ場面とか
思いつかないです。
単なる文字列を オブジェクトして捉えてその同一性を厳密に確認する
というのが果たして本当に必要なのか という問題 かな？
>>465 >
>>459 > >では聞こう。Stringに+を使うことでどんな困った問題があったのかね？
> オマエラ演算子否定派が色々な難癖つけて演算子オーバーロードを否定してんのに
> なぜStringだけ容認するのかがわからんといってんの。矛盾してる。
お前は日本語読めないのか？
> なぜStringの+を容認するのか、理由はわかる。便利だからだ。
> 同様に便利だから演算子オーバーロードは容認されてもいいべきだ。
屁理屈だけで実践もしてみない奴が何をいうかと。実際にやってみてどんな副作用が
生じるのか経験したことも無いから馬鹿げたことをいえる。
お前みたいな口だけのくだらん不満を持った奴がC#に飛びつくわけだが。
>>465 > 同様に便利だから演算子オーバーロードは容認されてもいいべきだ。
一つのクラスで演算子オーバーロードが許されたら全てのクラスで許されるべきってのは極論でしょ。
>>467 ああプリミティブ型だけは違ったな。
String以外のオブジェクトの型にといっておくべきだったな。
>>466 一応職業がプロのプログラマ兼SEなので
マルチスレッドはバンバン使ってますし、落とし穴も
それなりに理解しているつもりですけど・・・
具体的な例を挙げてもらいませんか？
>>468 とかへの反論でもいいので おねがいします
>>452 そーゆー事は言語仕様作った奴に言ってくれ。
474 ：
デフォルトの名無しさん ：03/11/09 04:24
>>465 Stringの+演算子オーバーライドは言語仕様レベルで仕様が確定
していて、他に影響ないからな。確かに仕様に統一感が無いとは
思うけど。
お前さんあるいはどこぞの半端バカが自作クラスで勝手にやった
演算子オーバーライドに振り回されたくはないな。
>>469 >お前は日本語読めないのか？
お前、自分自身の文が日本語のつもりか？
>屁理屈だけで実践もしてみない奴が何をいうかと。実際にやってみてどんな副作用が
>生じるのか経験したことも無いから馬鹿げたことをいえる。
じゃ、お前もその副作用とかいうのを具体的に言ってみろ。言えるか？
>>474 >お前さんあるいはどこぞの半端バカが自作クラスで勝手にやった
>演算子オーバーライドに振り回されたくはないな。
これが良く分からん。C++も使ってるが、演算子のオーバーロードに振り回された時なんか無いぞ
>>471 > > String以外の型にStringオブジェクトを代入すると
まず、この部分は逆っぽい
「String型の変数に String以外のオブジェクトを代入すると」だろね。
> > 暗黙のうちにtoString()メソッドが呼び出されるわけだが。
よびだされないよ。
String s = new Object(); はコンパイルエラーになる。
>>472 > 一応職業がプロのプログラマ兼SEなので
常識もしらないでおまえは本当にプロなのかと。
>>475 ポインタの意味わかってますよ。
現時点では Stringはインスタンスでcharの配列を持ってるオブジェクトで
"hoge"=="hoge"が成立するのは単に同じリテラルだから
左辺右辺とも同じオブジェクトを参照しているので
==ではそのポインタの比較だから真となるけど
違うオブジェクトの場合はその保証は全く無い ということですよね。
でも、今はその話ではないです。
常識を疑えずして本当にプロか？
>>476 とりあえずお前はマルチスレッドとクローニングについて勉強しろ。
>>480 > 違うオブジェクトの場合はその保証は全く無い ということですよね。
違うオブジェクトへの参照なら必ず偽になる と言う事です。
具体的にいえないんですね
486 ：
デフォルトの名無しさん ：03/11/09 04:33
equals()をつかわずに==だけで文字列を比較したいと言い出す奴は
>>486 そこまでは言いませんよ。
だいたい、他のオブジェクトでの演算子オーバーロードは
現時点では使いたいと思ってないです。
ただ、一番よく使われる（と思われる)単純な文字列比較は
あってもいいじゃん というのが趣旨でして。
>>468 に関する意見て無いスか？
>>468 > このとき、 s==t が成立しない ということが重要な意味を持つ
「==」 が参照値の比較だってゆーポリシーが崩れるという観点からみてダメだと何度言ったら…
文字列連結演算子が何故許されるのかは言語仕様決めた奴に聞け。
俺は知らん。
>>487 「==」による文字列比較では
>>434 のような小細工も使われているので
今更変えられても困りますぅ
なんで演算子のオーバーロードをそんな毛嫌いすんの？
492 ：
デフォルトの名無しさん ：03/11/09 04:41
equals():内部の値の比較。比較方法は各クラス毎の実装依存。
>>489 元々の出発点が 「＋許すんなら ==も許せよー もぅ！」 ってとこなので
それ言われたら元も子も無いでんがな
つーか、単にポリシーが崩れるだけですよね
他に機能面では問題ないと思うですよ
>>492 String以外のクラスに関しては全く同意です
>>492 >C++で==に変な演算子オーバーライド掛けられてこまった
>ことがあるので、尚更
これもJavaではequalsに比較じゃない動作を仕掛けられてしまった、のと何がちがうの？
>>490 == で「文字列」の比較をするようになっても
既存コードへの影響は極小だと思います。
そう思う理由は
>>468 なんですけど
>>487 どうやらお前は文字コードの違いというものを意識したことが無いようだ
>>493 > 元々の出発点が 「＋許すんなら ==も許せよー もぅ！」 ってとこなので
文字列連結演算子でいえば、他の参照値同士は「+」で演算できない。
文字列連結演算子だけが特例になっている。
対して「==」では他の参照値では以前と同じく参照値の比較で
文字列だけ「==」で同値かどうかの比較にしろってんでしょ？
同列に論じていい問題じゃない。
> つーか、単にポリシーが崩れるだけですよね
そうだよ。
まぁ、そんなに言うなら JCP なり BugParade なりで騒いでみるとか、
プリプロセッサ作るとかすれば？
文字列連結演算子だけが特例なのはポリシーが崩れないのか？
>>498 > 読んだ上で言ってる。おなじじゃん。
同じなら演算子のオーバーロードなんて要りませんね。
>>501 > 文字列連結演算子だけが特例なのはポリシーが崩れないのか？
それは言語仕様作った奴に言え。
「==」の仕様を変えろ、ってのは既に確立してるポリシーを崩す事になるので容認できないってだけ。
>>502 なんで？あったほうが便利ジャン。文字列の + は便利だと思ってんだろ？
>>499 それはequalsでも同じですよね
でも、そもそもJavaではUTF-8を使っているから
どのみちEUCなりSJISが出たり入ったりするときには
streamから読み書きするときに必要ならまずエンコードしますよね
だからこの件には影響ないよね
こいつはStringクラスのソースコードの一部だ。
>>504 > なんで？あったほうが便利ジャン。
なら同じではありませんね。
508 ：
デフォルトの名無しさん ：03/11/09 04:56
>>496 左辺値と右辺値が同じStringインスタンスを指し示していることを
確認したい場合はどうするんですか？
>>507 アンタとオレの言う同じが同じでないだけじゃん
>>505 おまえはjava.nio.charset.Charsetを知らんのか？
まったく影響があるんだが。
とにかくUTF-8以外のファイルの取り扱いについて考えてみろ
>>508 >>468 でも聞いたんですが、その必要性が本当にあるのか
String比較で本当に同一インスタンスであることが重要な場面は
いったいあるのでしょうか というのがわたしの疑問だったりします
まあ「あるといったらあるんだい！こまるんだい！」と言われれば
しょうがないですけど
「そんな用途は存在しない」というヒトがもしいるのなら、
>>506 すみません。これだけでは考えは変わりませんです。
どうでもいいけど具体例を出さない奴の言うことはほっとけ。妄想を語ってる場合が多いから。
>>509 >>491 を読めば演算子のオーバーロードと従来の関数は全く同じ、と言っていますが
>>504 では演算子のオーバーロードがあった方が便利、と言っています。
便利だと言う事はなんらかの違いがあると言う事です。
>>511 >
>>508 >
>>468 でも聞いたんですが、その必要性が本当にあるのか
> String比較で本当に同一インスタンスであることが重要な場面は
> いったいあるのでしょうか というのがわたしの疑問だったりします
スレッド
>>512 ですから、どんな場合に必要なのか具体例を教えて欲しかったです
わたしは使っています だけでは へぇボタン押せません
>>516 ですから、どんな場合に必要なのか具体例を教えて欲しかったです
スレッド使うときに困ります だけでは へぇボタン押せません
>>514 なるほど、自称プロSE C++厨の妄想か。
>>515 オレの言う同じは下の二行のことだったぢゃん
>>511 >String比較で本当に同一インスタンスであることが重要な場面は
あります。
>>434
>>517 私は例えば列挙値に表現上の理由でString使いますが。
わざわざstrcmpカマス必要が無いので==で比較しますが。
>>510 すみません。それに関しては勉強します。
でも、String$equalsにも影響あるんですか？
>>521 >>522 これらが 文字列の比較 と置き換わったときに
起こりうる問題ってなんでしょうか
あー速度が遅くなるか
文字列の同値判定はあんまり同一判定と速度かわらなさそうなんだけど
やはり、
>>511-512 のどちらの場合も
「文字列」の同一性について比較しているわけで
「Stringオブジェクト」の同一性について比較しているわけではないですね
>>523 いや、煽りたいのはわかるんですが
もうちっとこうヒントでもくださいな
>>513 private char value[];
private int count;
==だけで比較したいということはお前が比較したい対象はこれだけに絞り
こまれるわけだ。それ困ることだ。
private int offset
private int hash
この二つの変数を無視した比較ができないのはあとあとこまる。
とあるクラスは、String#hashcode()メソッドを使って探索を高速化している。
よって、hash値の比較は重要。==による比較が文字列のみの場合hashの比較までまとめてできないので
==の勝手なオーバーローディングは却下。
言語仕様なんて、結局「矛盾の少ない落しどころ」「許容可能な妥協」
C++厨も威張っているくせにこういうところだけ抜けている。
いまさら==の仕様を変えたら大変なことになるのはあきらかだわな。
>>528 違う。
「オブジェクト」が同じ物であることを==で比較していて、
その中身がタマタマStringだというだけ。
>>529 ==の比較が、まずhash同士が同じか調べてから文字列の比較をするという実装になってればいいんじゃ？
>>528 > 「文字列」の同一性について比較しているわけで
> 「Stringオブジェクト」の同一性について比較しているわけではないですね
最終的に判定したいのは「文字列の同一性」ですが、
「文字列の同一性」を判定するのは高くつく場合もありますね。
その場合は参照値の同一性に置き換えて比較する事によって高速化を試みるわけです。
なので参照値の同一性を比較できなくなると困ります。
見た目だけ便利にしてもしょうがないわけだが。
>>534 おいおい、すべてのクラスで==をそういう仕様にすればいいと思っているのか？
>>535 C#の仕様は、「高くついてもいい」という判断の結果ですか。
>>538 C# の仕様決めた人に聞いてください。
>>537 String同士の時だけでいいじゃん。なにいってんの？
>>529 Stringで同じ文字列なら同じHashになりませんか？
それと、hash値の比較で高速化するのと
文字列の==比較を禁止するとの関連性は希薄ですよね
>>535 そうですね
文字列の比較がオブジェクト(ポインタ)の比較と置き換えられる
というのは確かに高速化につながるので
高速動作を要求されるコードでは確かに困るですね
でもそのときにはボトルネック部分だけ何とかすれば
いい気もします
高速性を要求される部分では文字列比較しない、とか
>>高速性を要求される部分では文字列比較しない、とか
>>541 > でもそのときにはボトルネック部分だけ何とかすれば
> いい気もします
> 高速性を要求される部分では文字列比較しない、とか
いや、既存のコードで既に使われているので安易に変更されると困るって意味なんですが…
>>533 それであれば、Stringを使う必要がそもそも無いということになりますね
暴論ですが 現時点で便利だからそう使ってる というだけとも言えたり。
>>542 もちろんユーザ(プログラマ)です。
最初から 文字列比較はちょっと遅い ということがわかってれば
リファクタリングしてそれなりのコードが書けるはずです。
internして比較してるならなおさらかと。
>>543 大丈夫ッスよ 今のCPU速いし！ ハッハッハ
>>545 > 大丈夫ッスよ 今のCPU速いし！ ハッハッハ
おいおい…
>>スレ荒らしてる人
まあ 結論は
>>548 > 機能的には問題なし。
機能的に問題が無いかどーかは知らない。
+のシンタックスシュガーは、決めた奴にｱﾘｶﾞﾄｳを言いたいなあ。
え？Javaって
>>548 俺は
>>489 で
> 文字列連結演算子が何故許されるのかは言語仕様決めた奴に聞け。
とは言ったが、文句言えと言った覚えは無いぞ。
まぁ文句言いたいんなら 勝手に言えばいーんだけどさ。
なんだそりゃ。C,C++から派生した癖にコンパイルエラーになんのかよ。
派生じゃないよ。文法を拝借しただけ。
>>550 は利点じゃないな
"ほげほげ" "ほげほげ" が連結されるようなC/C++の仕様と同じならいい話なだけだ。
すごくスレが伸びたねぇ。
文字列の+は演算子オーバーロードとほとんど同じ欠点を持つ、なのに文字列の+にだけ利便性を遊船させるのはおかしいというはなていちい
>>558 再定義できないなら演算子オーバーロードとちっとも一緒じゃない。
ただの構文。
>>557 文字列オブジェクトの同一性チェックが必要ある場面
が思いつかないです
>>559 Stringの+が文字列連結に再定義されている
というのが問題だと思うんです
いまさら無理に==を文字列比較にも適用するくらいなら別に文字列比較演算子を作ったほうがいいと思うけど
562 ：
デフォルトの名無しさん ：03/11/09 09:31
>>561 ＞文字列比較演算子
それだ！
と、思ったけどswitch文でも使いたいのでちょっとアレか
>>560 オブジェクトの同一性が必要な場合が
>>557 に書いてあるじゃん。
その目は節穴か？
>>560 文字列連結に「再」定義されているのではない。
その証拠にユーザはそれを変更できないだろ？
強弁するのは見苦しいよ。
564 ：
デフォルトの名無しさん ：03/11/09 11:26
>>560 >
>>557 > 文字列オブジェクトの同一性チェックが必要ある場面
> が思いつかないです
だからマルチスレッドをやってみればわかるっていってるだろうが
じゃあ再定義、じゃなくて定義でいいよ。
>>540 おまいはhash関数が何のために存在するかわかってないようだ
まだ起きていたのか。
570 ：
デフォルトの名無しさん ：03/11/09 11:41
Stringクラスのみ==の仕様をString#equals()と同じにしたとき
==の仕様を変えたがっているｳﾞｧｶは
こうなったらStringも値型にしようぜ！！
+はいいのか？不公平だろ？
>>572 アフォ。Objectのサブクラスでなくなる以上、コレクション系で
値型をラッピングした別のクラスが必要になり結局参照型のStringが残る。
>>574 じゃあstringを値型でStringを参照型で
>>573 あれだけ親切に説明されてもまだわからなのか。
あれで理解できないなら
頭手術したほうがいいんじゃないのか？
>>575 そんなことをいうお前はBigIntegerやBigDecimalの値型も必要だとぬかすんだろうな。
そしてJavaにも構造体が必要だとかアフォなことを言い出す。まるでC#だな。
>>576 ﾊｧ？あれで他人に理解して貰えると思ってるのか？
>>577 なんでアホなの？Javaより良い回答だと思うけど？
結局、値と参照がよくわかってない馬鹿一人が
文字列に値型と同じように演算子が定義されるようにするんなら
やっっぱりわかってない。w
それはお前だ！
printメソッドなんかで変数をいろいろ出力したいときに
C++のiostreamも見やすくするための苦肉の策。見やすいほうがいいだろ。
結局オーバーローディングは読みやすくするためにある程度は必要だってことですね。
C++演算子オーバーロードは「俺定義」で醜くなる
オレ定義で見難くなる事なんかめったに無いし
で結局==の定義を変えたがってた奴は、この文脈で何がいいたかったんだ？？
>>581 お前はポインタがなんのためにあるかわかっていないようだ。
お前の脳細胞の配列の設計がミスっているわけだが。
>>587 そのとおりなんだが約一名Javaに噛み付いた馬鹿が粘着してるみたいだ。
ポインタは無い。参照はある。
>>588 > オレ定義で見難くなる事なんかめったに無いし
お前は一人でオナニーでもしていればいい。
チーム開発で乱用するとどんなリスクを背負うかまったく理解できないのは大恥。
>>589 C++厨としての面子を保ちたかっただけじゃねえか？
>>593 だから、機能があるからって乱用することは無いよ。
お前だってメソッドにめちゃくちゃな意味不明な名前をつけて、
チーム開発をめちゃくちゃにできる権利はあるけど、それをしないだろ？それと一緒。
結局Java使いtaiタンは、演算子オーバーロードの優位性を示したくて
>>594 それ言ってた奴はJava厨だろ。名前にJavaとかついてたし
Java厨房を装ったC++厨だろ。
演算子オーバーロードは適切に定義すれば、文字列の例からも見て取れるように、有用ってことでいいですか？
>>597 名前にJavaをつけている奴はどうもC++厨かC#厨臭い匂いがするのだが。
オブジェクト指向をなめている奴がJavaを否定しああいう機能をつけたがる。
C++厨やC#厨が欲しがるような機能ってもんはそんな程度
オブジェクト指向舐めてない奴は今のJavaの仕様に対して手放しで大絶賛なの？
>>601 オレは==は同一性の比較でいいと思ってるがそれが何か？
>>599 >文字列の例からも見て取れるように
どこに例があるの？
「==」厨房は引っ込んだ（もしくは何食わぬ顔で主張を撤回した）わけね。
==は同値性の比較、===は同一性の比較、とかだったら嬉しいかも
>>602 不満に決まってるだろ。
genericsをはやく導入して欲しいとおもうことや
instanceofやassertを廃止して欲しいと思うことがある。
>>607 混乱する。
String以外のクラスでもそんな仕様を実装するのかと。
>>608 お前C++厨か臭い匂いがプンプンするな。
オブジェクト指向をなめている奴がJavaを否定しgenericsなんてアホな機能をつけたがる。
C++厨が欲しがるような機能ってもんは所詮そんな程度なんだよ
>>609 お前もうJava以外の言語使えねーな。臆病すぎ。
>>605 >>587 そもそも適切な定義がなされるとは限らない、というところから
議論が始まったんじゃないの？
>>613 だから普通のメソッドだって名前とは反した機能をつけることだってできる。
メソッドの定義も禁止するか？
メソッド名は「適切に名付ける事で」回避できるな。
演算子オーバーロードは「適切な機能」を付けることで回避できる。
>>575 Stringが値型で*Stringが参照型のがええぞ。
ﾏｼﾞﾚｽ砂。
>>616 適切な機能が各個人で同じとは限らんな。
matrixの*は内積なのか外積なのか各要素の積なのかmatrixのポインタなのかw（冗談だけど。
>>615 適切に命名できれば良いのですが、isEqual はについては本質的に混乱しやすいと思う。
== のオペレータオーバーロードで混乱という話を上でみたけれども、
もし C++ で == のオーバーロードの混乱があるなら isEqual でも、名前が変わって
メソッド名が中置されたという文法上の微妙な違い以外は変わらないです、
本質的な問題である「何について等しいのか」と点が混乱しているなら
どのように書かれようが結局混乱という事態は避けられていなかったのではと思う。
参照が等しいのか、それとも中身が等しいのか、そもそも中身が等しいとは何をもってなのか、
たとえば、オブジェクトがデータとキーの組のときなどは
組オブジェクトの参照が等しい
組オブジェクトの中のデータとキーの参照が等しい
組オブジェクトの中のデータとキーのインスタンスが等しい
組オブジェクトのそのもののインスタンスが等しい
組オブジェクトのキーの参照が等しい
組オブジェクトのキーのインスタンスが等しい
どれも isEqual で正当だと思う。
十分に注意深く意識して付けられたものはあまりないと思う。
C++ の stl などではファンクタにして外に放り出して解決してしまいましたが・・・
命名での解決は難しいと思う。
>>620 現状のC++では特に理由がない限りポインタの使用は避け、
コンテナあるいは参照、イテレーターを使う。
Cと違って滅多にポインタが使われることはなく、
そういった混乱はない。
>>620 それを言うなら適切な命名とやらも個人で異なる。
それにStringだって各要素を足すという解釈も出来る。
またすさまじく伸びたな。
Javaの仕様は理想的で美しいと思っている信者ならばこそ
使いやすいから、便利だからというだけで例外を認めてしまったら
どうでも良いけどうせ他人が書いた物を使う時は
>>585 C++ の iostream は醜いし、見にくいよ。
>>625 > Javaの仕様は理想的で美しいと思っている信者ならばこそ
> 異分子であるStringの+は否定すべきだ
そーゆー人はいるよ。
==はオブジェクトの同一性比較、isEqualはそのオブジェクトの性質にふさわしい
>>630 まあ、参照についてはOOである以上最大重要要素なので分離しておく事に依存はないです。
Java ならば == でよいと思います。
しかし、オブジェクトの同一性についてはどうだろう。
これだけを取り出しても十分に混乱要因だと思いますが。
おお、別にファンクタなんぞ誇るつもりなどないです、あんなのもはただの関数ポインタでも十分です。
そうではなくて、何が問題で混乱が起こるのかという点を考えたいですね。
>あとファンクタとイテレータを誇っている時点
String a = "hoge";
>>632 ==とisEqualの話には直接関係ない話だと思ったから。
話がすり替わってるよね。
>>635 >>621 の
>C++ の stl などではファンクタにして外に放り出して解決してしまいましたが・・・
>命名での解決は難しいと思う。
ここに噛み付いてるの？・・・摩り替わってるかなぁ？それにイテレータはどこから出てきたんだ？
>>635 というか、話をすりかえたのはお前だろ！
ああ
>>622 でイテレータが出てきてるな。
まぁ
>>622 は何故か
>>620 の
>matrixのポインタなのかw（冗談だけど
の冗談に良く分からん突っ込みをしてる奴だから無視で
>>634 > String a = "hoge";
"hoge" は文字列リテラルで、
String型の変数に代入できるのは明らか。
> Integer b = 0;
0 は整数リテラルであって Integer のオブジェクトでは無いので、
Integer型の変数には代入できない。
とはいっても 1.5 で導入される Autoboxing では許されるかもしんない。
>>634 > プリミティブなintとかなんて作らなければよかったのに
確かにそーすれば、より一貫性がでるとは思う。
> もしくはStringもプリミティブにしとけばいいのに
それだと「汚い仕様」のまんまだと思うが…
つまりRuby最強と。。。
オブジェクトじゃないデータ型がある時点で
あら、なんか盛り上がってますね
>>643 > 「文字列を”プリミティブな値”として保持するStringクラスのようなもの」
> があったらそれで万事解決しますね
何が、どのように解決するのかサッパリわからん。
JavaとC++が死滅すればそれで万事解決
>>643 あぁ 「==」に関しては解決するのか。
でも String が Object のサブクラスでなくなるので
コレクションとかで String 使う時の使い勝手とかはメチャクチャ悪くなるね。
>>646 それは解決なのか？
>>643 値としての文字列が一致すればオブジェクトが異なっていても
それがわからなくなる。とても困ります。
>>647 > それは解決なのか？
java使いTai!氏にとっては「解決」するのです。
俺的に解釈すると
「String がプリミティブ型だ、と言い張ってしまえれば
参照値の違いなんぞ知った事ではない」
ので「解決」するわけですね。
>>648 俺はint型のように参照型をやめてしまうという風に受け取ったのだが。。。
>>647 うぇーい
Stringとは別に プリミティブな文字列としての
int に対する Integer のような、
たとえば string という型 ができたら
それで解決っすよね
（で、Stringはstringのラッパークラスになる！）
という話 なんですけど、なんかまずそうですかね
文字列がなぜ参照値として実装されているかつまり
>>640 に同意でプリミティブを増やすのは言語として汚くなるだけ。
>>649 Java の byte code には殆ど空きがないから
String のプリミティブ型バージョンは殆ど操作できないだろうね。
String が本体で、String のプリミティブ型バージョンはStringの機能を大幅に削った型って事になりそう。
イメージとしては、Integer で四則演算できるのに、int では四則演算できないとかそーゆーかんじ。
>>652 string という型をつくって文字列はそれで表現し
従来の String str = "hoge"; はそのまま残して、さらに
string s = "hoge";
String str = s; または String str = new String(s); を
表記できるようにちょっぴり仕様拡張して、
string型同士の比較は自由に出来るようにする というのなら
あまり波風立たないと思うんですけど・・・
プリミティブな型が増えるのを補って余りあるメリット（ていうか==）
があるような気がするんですけど、どでしょ。
コレがダメならまたなんか考えます
>>653 まあそれでもいいと思いますよ
もともとStringで四則演算できないですし
>>654 っつーか、String のプリミティブ型バージョンって
「==」で同値かどうかの比較ができる以外に何かあるの？
> あまり波風立たないと思うんですけど・・・
とか思うなら JCP とか BugParade で騒ぐなり
プリプロセッサ自作するなりすれば？
> もともとStringで四則演算できないですし
String には charAt() とか substring() とかメソッドいっぱいあるんだけど…
プリミティブ型にしたところでメリットがなく、性能も落ちるだろうね。
内部でflyweightできるかもしれないだろ
>プリミティブ型にしたところでメリットがなく、性能も落ちるだろうね。
>String には charAt() とか substring() とかメソッドいっぱいあるんだけど…
>>657 flyweight なら String でもやってますがな…
>>659 > >String には charAt() とか substring() とかメソッドいっぱいあるんだけど…
> 四則演算できないこととそのメソッドがあるのと何の関係が？
> > > イメージとしては、Integer で四則演算できるのに、int では四則演算できないとかそーゆーかんじ。
とは書いたけど…
別の言い方すれば「操作できない string」は「四則演算できない int 」と同じで役にたたんって事。
string型とやらは参照をもたない値型なんでしょ？
>>662 まあそぅなりますね・・・
でもそれはVM側でなんかうまいことやればいけそうな気がします。
>>661 string型なるものが出来たとして、
+ と == が出来ればまあいいかなぁと思うデスよ。
ちゃんと読んでないけどさ、
>>663 > + と == が出来ればまあいいかなぁと思うデスよ。
+ と == 以外は全然考慮に入ってないんじゃ？
コボラｷﾀｰ
>>663 > でもそれはVM側でなんかうまいことやればいけそうな気がします。
generics でも VM変更しなかったのに、
こんな役に立たんモンのために VM仕様を変更するとわけないだろ…
>>663 VMだろうがどこのレベルで対処しようが、文字列のコピーを行うか、
「参照を保持し、それを隠蔽する」という本末転倒な実装をするしかないでしょう。
やっぱり値型を増やすのは無駄ですね。
むしろVMの変更が難しい故、template をつけても役に立たないんだと思ふ
>>610 > オブジェクト指向をなめている奴がJavaを否定しgenericsなんてアホな機能をつけたがる。
Genericsは重要だ。だがC++のようなtemplate相当な余計な機能はいらない。
コレクション用のみに限定してtemplateを使えればいい
C++的な使い方をするとしっかりとコンパイルエラーがでるようにだ。
>>623 >
>>620 > それを言うなら適切な命名とやらも個人で異なる。
それも、どのクラスのオブジェクトかがわかるので問題なし
>>639 > とはいっても 1.5 で導入される Autoboxing では許されるかもしんない。
いや、あれはC#とちょっ微妙に異なる仕様なようだ。
C#のようになんでもあり的で危険なことはやりにくいようになっているようだ。
キャストで十分、おれは型安全程度使われ方なら、ソースコードをかき乱すだけだから無いほうがいいな。
>>652 >
>>640 に同意でプリミティブを増やすのは言語として汚くなるだけ。
>
汚くなった言語仕様として、C#がいい例だね。
そんなにプリミティブが嫌ならsmalltalkでも使ってなさい
値型Stringは作るだけ無駄だな。
結論として、equals()を==に置き換えるメリットはあまりないようだ。
equalsと==が混在する環境は最悪だね。
>>673 コレクション系で困ったことは無いのか？
>>678 どこが最悪なんだか。
たかがStringクラスひとつのためだけに==の仕様を変更するとはアフォ
演算子のオーバーロードって重要なんだね。
>>681 shift+ハット(への字)でチルダを入力できるぞ
結局演算子オーバーローディングは読みやすくするためにある程度は必要だってことですね。
>>677 いや真骨頂はswitch文ッスよ。多分。なんとなく。
ていうか仲良く行きましょうよ
>>688 String で switch するのと String をプリミティブ型にするとゆーのは全く別の問題だと思われ。
690 ：
デフォルトの名無しさん ：03/11/09 20:40
>>690 すでに語りつくされ興味のあるネタは殆どないのだが。
徐々に厨房の煽り合いになって言語仕様とは関係ない話題、
アンチオープンソースだアンチWindowsだなんだの方向にすすんで
いつものように話がおかしくなる。
しかもC#マンセーな厨はほとんどVB厨で言語仕様の話よりもGUIの話しか興味を
もたない奴が多すぎで言ってることがほとんどつまんね。
>>688 そもそもswitch文マンセーな奴はDQN
695 ：
デフォルトの名無しさん ：03/11/09 22:01
C++厨がクソスレ立ててるのか。わかりやすいね。
↑Java厨の自作自演の戯言
↑さっそく釣れました。（こいつがクソスレ立てた本人。）
↑Java厨の自作自演の戯言 。（こいつがクソスレ立てた本人。）
今時「釣れた」と抜かす奴はリア厨未満
>>695 またスレ立てたのかよ。
無駄にスレ立てんなよ
>>696 わざわざ vs. Java と名がつくスレを複数もたてる奴はこのスレで暴れていたc++厨くらいだな
>>689 ==使いたいだけなのでミーの心の中では等価ですよ
全然関係無いけどphpなんかは
文字列を==等で比較すると数値化して比較するのに対し
switch文で検査すると文字列として扱うんですよ
いや、ホントに関係なかったですね
>>703 だったら自作でSwitchクラスでも作れ！
>>703 > > String で switch するのと String をプリミティブ型にするとゆーのは全く別の問題だと思われ。
> ==使いたいだけなのでミーの心の中では等価ですよ
「==」つかえるのと、switch できるのはあなたの願望以外に共通点は無いですね。
>>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 で等価といってるのは？？？
やっぱりJavaの仕様は糞だな
完全に仕様を満たした処理系が存在しないC++は仕様が糞なのか処理系が糞なのか
いずれにしてもC#はもっと糞
Java がコケルときスタックトレースしてくれるのは良いなぁ～。
>>711 デバッグ環境じゃなくて実行時にも出るの？
Javaのはソースの行位置まで出るよ。
>>712 > Javaのはソースの行位置まで出るよ。
コンパイルオプションに -g:none とか入ってるとソースの行番号でないけどね。
>>712 その場ではみれないけど、デバッグ情報残しておけばVCならide立ち上げるからそこで見れるし。
gccなら例外時に生成される core ファイルから追えるよ。
ところでスタックトレースの概念はC++どころかCの頃からあるんだけど・・・
v――.､
／ ! ＼
/ ,ｲ ヽ
/ _,,,ﾉ !）ﾉﾘﾊ i
i jr三ミ__r;三ミ_ ヽ
l ,iヾ二ノ ヽ二 ハ ﾉ ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ､.l ,.r､_,っ､ !_, ＜
>>1 糞スレ立てんな、蛆虫、氏ね。
! rrrrrrrｧi! L. ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
ゝ､^'ｰ=~''"' ;,∧入
,r‐‐'"／ >､＿_,r‐ﾂ./ ヽ_
/ ／ i" i, ..: / / ヽ-､
./ ヽ＞ l ／ i ＼
なんか俺のせいで大荒れですか？
718 ：
java使いTai! ：03/11/11 19:25
>>704 Switchクラスはおもしろそうですね
こういう処理を実現するとき、やっぱif文の羅列はどうかなと思うんですよ
switch( s ) {
case "jackonly":
are();
break;
case "king":
kore();
break;
}
みなさんはどうしてるんですか？
>>717 > Stringと同じように、Integer等にも演算子使えるようにすればずっとすっきりすると思うんだがどうか。
四則演算とかでオーバーロードを認めると <、>、<=、>= 等のオーバーロードもしたい、
==、!= もオーバーロードしたい、と要求がエスカレートするのは目に見えている。
ところが、Java では == と != が、既に参照が同じかどうかの比較に使われているので、
参照型に == と != のオーバーロードを認めると面倒くさい事態になる。
演算子のオーバーロードの良し悪しにかかわらず、
Java に演算子のオーバーロードを追加した方が良いというのは、
極端にセンスが無いか、追加した後どーなるかを何も考えてないかのどちらか。
720 ：
デフォルトの名無しさん ：03/11/11 19:28
本物のプログラマは演算子の多重定義はしない
>>717 > コンテナに直接intを突っ込めないのはｷﾓｲ。
1.5 で、見かけとしては出来るようになる予定。
>>719 いや、演算子オーバーロードを使えるようにするわけじゃなくて、
Stringで＋が使えるようにInteger、Doubleといった特定の型で演算子を使えるようにするんだよ。
Java厨にはオーバーロードの利点すら理解できんか（ｗ
>>718 if 文の羅列かな？
String での switch って滅多に使わないし、問題無い。
Javaの言語仕様は完璧です。
> 四則演算とかでオーバーロードを認めると <、>、<=、>= 等のオーバーロードもしたい、
>>722 > Stringで＋が使えるようにInteger、Doubleといった特定の型で演算子を使えるようにするんだよ。
普通の Java プログラマなら Integer や Double に演算子が使えてもそれほど嬉しくない。
っつーか、無闇やたらと提案するよか、実際にプリプロセッサなり作ってみたら？
Integer や Double で演算できると便利になるか簡単にわかるでしょ。
>>724 コンパイラの文法解釈とか、htmlの解釈とか使う機会は
いくらでもあると思うが。
730 ：
デフォルトの名無しさん ：03/11/11 19:40
>>729 ネタならもう少しおもしろいことを言おう
> 普通の Java プログラマ
メチャクチャ臆病なんですなJavaというやつは。
ここでC++厨のふりをしてJava厨を煽っているのはC#厨ですので間違えないでくださいね。
>>728 文字列を数字に直して計算して計算結果を文字列に直すときとか
そのつどparseなんとかにつっこんだりとかするので
Integerでそのまま計算できたらやっぱり便利だと思いますよ。
intとIntegerの型変換が暗黙で行われるとか
なんかそんなのがあったりすると面白かもしれないですね
シンタックスシュガーとして実装するとか・・？
>>728 というか、intとかのｷﾓｲプリミティブ型をなくすのが目的。
プリミティブなんかOOに反してる！キモイ！差別！出て行け！
んでもって
>>735 の言うような暗黙の型変換機能をつければ互換性もバッチリ（たぶん
っていうか漏れはjavaなんて学校の実習で3回くらいいじっただけで無知そのものなんだけどな（ごめん
正直言ってメソッドがオブジェクトじゃない
ちょっと考えてみましたけど
>>735 > intとIntegerの型変換が暗黙で行われるとか
> なんかそんなのがあったりすると面白かもしれないですね
だから 1.5 から Autoboxing が追加されると何度も…
>>741 すみません
ついでにswitch文で文字列比較も出来るようになるといいですね
>>733 > トラブルは起こらないが進展も無い、自ら未来に進む事を辞めた言語ですね。
機能を追加すれば「進展」だ、とか能天気に思わなくなっただけですね。
generics とかちゃんと追加されるし。
そしてまたJavaの仕様が肥大し汚くなっていく
>>729 Java の構文のサブセットならパーサー書いたことあるけど、
String の switch なんて使える場所なんて無かったと思うが…
Java の構文解析で String の switch をどう使うか例示してみてくれる？
>>735 > 文字列を数字に直して計算して計算結果を文字列に直すときとか
> そのつどparseなんとかにつっこんだりとかするので
> Integerでそのまま計算できたらやっぱり便利だと思いますよ。
Integer で計算できても、
文字列から Integer に変換するのには明示的にメソッド呼ばなきゃいかんし、
Integer から文字列にするのには 暗黙の toString() もしくは明示的なメソッド呼び出しが必要になる。
っつーか、「文字列<->Integer の変換」と「Integer で計算できる事」は関係ないと思われ。
>>738 > というか、intとかのｷﾓｲプリミティブ型をなくすのが目的。
そんなら Smalltalk 使えば？
>>743 > 機能を追加すれば「進展」だ、とか能天気に思わなくなっただけですね。
意味わかりません。どういう状態が進展なんですか？
genericsが追加されることは進展じゃないんですか？
>>746 まあ最初の一発目のとっかかりのString→Integerは
手動でやんなきゃですね。そこはしょうがない・・・かな
正直言って、「java使いTai!」はアニヲタなわけだが。
>>750 それは偏見ですね
他の趣味を持っている人はいっぱいいますよ
私はたまたまそれがアレだっただけで
>>750 今までの話を見るに、「java使いTai!」は Java を使った事が(殆ど)ないようだが。
>>749 っつーか、現在の状態でも
文字列 -> int の parse を明示的にやれば、
あとは演算子で計算できるし 文字列への変換も
Integer の暗黙の toString() と同様に 暗黙の String.valueOf() で行われるのだが…
>>748 > 意味わかりません。どういう状態が進展なんですか？
generics が追加されるような状態は進展。
演算子のオーバーロードが無原則に許されるような状態は進展じゃない。
>>756 要するに自分の趣味じゃん。
もしくはJavaにしたがいます。
Javaが行うことはすべて進展です。
一生Javaに付いて逝きます。ですか？
>>757 > 要するに自分の趣味じゃん。
趣味だけじゃないんだけど･･･
例えば、演算子のオーバーロードが無原則に許されると
>>719 で書いたように
今現在存在する 参照型等価演算子と衝突するので、進展じゃない。
"a" + "b" == "ab";
>>759 > 文字列リテラルってStringのインスタンスじゃないんですね
違う。
「数字」と 「1」が違うように
「文字列リテラル」と「Stringのインスタンス」は別の概念。
>>759 > が等価にならないところがJavaは気持ち悪い
とか思うなら Java より自分の理想に近い言語を作るとかすれば良いわけで…
>>745 > Java の構文解析で String の switch をどう使うか例示してみてくれる？
あぁ、Statement の解析で Statement の先頭にくる "if" とか "switch" とか "try" とかの分岐で使おうと思えば使えるかも。
でも使えるのってそこだけだと思うけど…
Javaって構文解析にしかswitch使わないものなの?
>>763 String の switch は使い道が殆ど無いっていったら
構文解析に使うって話がでたので、
>>745 はその続き。
っつか、ちっとはスレ読んでから書けよ…
>>761 お前のような奴が沢山いたらJavaにgenericsが
採用されることも無かっただろうな。
「Javaにgenericsを搭載しよう。」
「却下。気に入らないのなら自分の理想に近い言語を作れ。」
お前迷惑。
>>765 > お前のような奴が沢山いたらJavaにgenericsが
それは逆。
実際に実物を提示された方が説得力あるし、議論もできる。
> 「Javaにgenericsを搭載しよう。」
>「却下。気に入らないのなら自分の理想に近い言語を作れ。」
「作ったよ。こーゆーふーに実装したら VM も変更しなくて良いし」
「んじゃ、それ採用」
(実際にはもっとイロイロあったらしいが)
>>766 却下。気に入らないのなら自分の理想に近い言語を作れ。
>>766 いーねー。オーバーロードは却下しといて
genericsだけ都合のいい話にする。
自己厨とはお前のこと。
> 「Javaにgenericsを搭載しよう。」
>>769 > ここで却下厨は。
>「却下。気に入らないのなら自分の理想に近い言語を作れ。」
> という。やはり迷惑。
そんな妄想の話されても困りますぅ
現に、気に入らないから自分の理想に近い言語を作れといっているわけで、
>>760 文字リテラルをあらわす型がほしくなりますよね、やっぱり
>>771 > 現に、気に入らないから自分の理想に近い言語を作れといっているわけで、
既存の言語に不満があるなら、不満点を改善した実装を作れと言ってるだけ。
>>772 > 文字リテラルをあらわす型がほしくなりますよね、やっぱり
文字列リテラルをあらわす型って？？？
775 ：
デフォルトの名無しさん ：03/11/11 22:05
言語仕様の決定なんてすべて惨の独断だろ？(ｹﾞﾗ
>>775 ならば$unが倒産したらJavaは死亡だね
>>775 > 言語仕様の決定なんてすべて惨の独断だろ？(ｹﾞﾗ
JCP とか知らんのかいな…
別に倒産しなくても現時点で死滅寸前だろ。派遣を除いて。www
>>773 自分で作ったわけでもないのに偉そうですな（ｗ
>>777 だらだらと話し合ってるフリしてる糞団体だろ？(ｹﾞﾗ
それで忘れかけた頃に惨が独断で決定。
Javaはバイトコードの仕様いじれないから改良はあっても進化はない
>>780 > だらだらと話し合ってるフリしてる糞団体だろ？(ｹﾞﾗ
えーと、「だらだらと話し合ってるフリ」の具体例とかｷﾎﾞﾝﾇ
>>780 > それで忘れかけた頃に惨が独断で決定。
ついでに、「忘れかけた頃に惨が独断で決定」の具体例とかｷﾎﾞﾝﾇ
JCPって日本共産党？
>>784 Java Community Process。www.jcp.org ね。
786 ：
デフォルトの名無しさん ：03/11/11 22:28
>>784 .or.jpじゃなくて.org
と釣られてみる
そっか。だからJava使いには左っぽいのが多いのか。
上層部独裁なのもそっくり
>>780 > だらだらと話し合ってるフリしてる糞団体だろ？(ｹﾞﾗ
えーと、「だらだらと話し合ってるフリ」の具体例とかｷﾎﾞﾝﾇ
>>780 > それで忘れかけた頃に惨が独断で決定。
ついでに、「忘れかけた頃に惨が独断で決定」の具体例とかｷﾎﾞﾝﾇ
なんかローカルあぼーんだらけになってきた
793 ：
デフォルトの名無しさん ：03/11/11 23:57
なんか知らんが、C++とJava両方をちゃんとわかってるやつらが、
勘定(´,_ゝ｀)ﾌﾟｯ行
どうでもいいがJavaで演算子オーバローディングを実現する実装は転がってるでよ
796 ：
デフォルトの名無しさん ：03/11/12 00:00
Javaの
797 ：
デフォルトの名無しさん ：03/11/12 00:05
>>796 継承だと多重継承が出来ない。困る。すごく困る。
だからインターフェイスのインプリメントを使う。
アブストラクトは空の関数を定義するときなどに使う。
それ単体でインスタンス化されるとヤバイため、
仮想であることを明示しないと危険だ。だからアブストラクトにする。
>それ単体でインスタンス化されるとヤバイため、
800 ：
デフォルトの名無しさん ：03/11/12 00:13
class abstract Hoge implements Fooable, Barable { // インスタンス化できない。
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; }
}
もう安心だ。
>>800 これぅて
class Huge extends Hoge {
↓
class Huga:public Fooable, public Barable{
と同義？C++で
Fooable foo = huga;
ってできるんだっけ？
>>801 ありがとうございます。勉強になります。
>>799 > なぜヤバイ、危険なのでしょうか？
仮に、C++ で純粋仮想関数を持ったクラスのインスタンスが生成できて、
そのインスタンスの純粋仮想関数を呼び出されたら危険じゃない？
>>717 > 上のほうで誰か書いてたけど、プリミティブ型はないほうがいいんじゃないか？
んなお前はSmalltalkでもやってろと。
>>729 >
>>724 > コンパイラの文法解釈とか、htmlの解釈とか使う機会は
> いくらでもあると思うが。
HTMLにswitchなんぞいまどき使わん。
XML Parserを使うのが常識。
807 ：
デフォルトの名無しさん ：03/11/12 00:28
全てのswitch文は、いずれポリモーフィズムに置き換えられるべきです。
>>807 全てとは言わんが、ポリモーフィズムを上手く使えば switch が必要なケースは減るね。
>>805 それ言われたの2回目だぞ
SmallTalkは確かに楽しそうだけどコメントが"こんな"なのは超ｷﾓｲ｡
やはり俺はC++を愛しているんだ！多重継承と演算子オーバーライドと暗黙の型変換とテンプレートがない言語なんか糞だ！！！！１
ﾌｧｯｸ
>>775 -
あたりから嘲笑激藁厨が現れたな。
馬鹿は死滅スレに帰れや。
>>810 同じこと書いている香具師がいることがあとから読んできがついた。
つーかお前、C++を愛しているくせに値型を嫌っているだと。
いっていることが矛盾してるぞw
>>812 C++はｷﾓｲのがいいんだよ。
なんだよjavaの中途半端さは。OO目指すならもっとストイックっつーかファナティックにやってほしいもんだ。
タダの愚痴か
815 ：
デフォルトの名無しさん ：03/11/12 01:43
C++は演算子オーバーロードが使えるところぐらいかな。
Javaに移行してもいいと思う。以下の二点さえ満たせばね。
>>818 Java に移行しなければ良いだけでは？
>>819 現状のC++言語とSTLには満足しているが、
MFCとかつかいずらくてswingみたいなラクチンなのが欲しい。
GUIとかのライブラリパッケージはJavaの方が好きなんだよね。
>>820 C++BuilderでVCL使えば？
JavaのライブラリはVCL参考にしてるわけだし。
>>821 VCLにレイアウト機能があればなぁってgtkみたいに。
GUIビルダー使わんプログラムの場合、VCL使いずらい。
(XHTMLのタグを読んで実行中に動的にフォームを生成なんて場合、
RADツールって何の役にも立たんです)。
あとAnsiStringとstd::stringの使い分けって統一感ないし。
>>822 「使いづらい」ね。つらいんだよ。
VCLの世界ならAnsiString使うようにしてるけど。
gcjからswt使うというのはどうよ？
>>822 > (XHTMLのタグを読んで実行中に動的にフォームを生成なんて場合、
RAD ツールを使うなら IE コンポーネントとかを使うのが作法では？
>>818 > Javaに移行してもいいと思う。以下の二点さえ満たせばね。
> １）ネイティブコードを吐くこと
> (アプリもサーバーもソース互換で充分だ)
JavaChipやJETコンパイラとかでも使えと。
> ２）テンプレートを中心にした標準ライブラリの構築
Java Genericsでもダウンロードして使え
> swingも基本設計だけ残してネイティブコードで実装しなおし。
ＳＷＴでも使え。
以上
>>826 > > ２）テンプレートを中心にした標準ライブラリの構築
> Java Genericsでもダウンロードして使え
Java の generics と C++ の template は全く別物だと思われ…
> > swingも基本設計だけ残してネイティブコードで実装しなおし。
> ＳＷＴでも使え。
SWT と Swing って設計思想から違うよーな。
>>818 > ２）テンプレートを中心にした標準ライブラリの構築
まぁ、コレクションを中心にした標準ライブラリって意味では既にあるよね。
C++のようなオブジェクト指向に反する使い方をできるtemplateは
Java厨ってJavaをさも最高のオブジェクト指向言語のように語ってC++,C#を貶すよな
オブジェクト指向らしさうんぬんとかがいいから
その機能を入れるとオブジェクト指向が汚れる！そればっか。
>拡張性を保ちつつ効率よく使えればいいってことだけだろ。
>>832 > その機能を入れるとオブジェクト指向が汚れる！そればっか。
> もうプリミティブ型入れてる時点で汚れてるっつーに
おまえのいっとる「穢れる」は実体験に基づいていないので信用できない。
実際に使ってみてソースが穢れメンテナンス性を悪くする
可能性があるのが「穢れる」だ。
ﾌﾟリミティブ型程度で穢れてコーディングに困ったのかお前は。
Smalltalkもやったことが無いくせにアホなことを言うな。
>>832 オブジェクト指向が汚れる、とは言ってないと思うが。
オペレーターオーバーロードなんかは、コードの信頼性が下がる、と言ってるだけじゃないの？
とりあえず、オブジェクト指向が汚れると言う理由で却下されてる機能キボンヌ。
>オペレーターオーバーロードなんかは、コードの信頼性が下がる、と言ってるだけじゃないの
Javaをオブジェクト指向どうこうでけなしてるやつって、結局Javaに限らずオブジェクト指向についてこれなかったヤツということでよろしいか？
840 ：
デフォルトの名無しさん ：03/11/12 14:31
JavaはC++などよりコード量が多いからequals()を==にかえたほうがいいとか
>>840 > JavaはC++などよりコード量が多いからequals()を==にかえたほうがいいとか
コード量を理由に equals() を == に変えろってのは聞いた事無いね。
コード量の話で言えばいつだったか C# vs Java vs C++ のベンチマークをやってた外人のコードだと、
C# と Java は殆ど同じで C++ はそれらより 1.3 倍ぐらい多かった(行数で数えて)気がする。
> C#やPerl, Delphiにあるforeachが無いのか糞だとか
1.5 で for が拡張されますね。
>>838 > オペレータオーバーロードは信頼性を上げる事もあれば下げる事もある。
どーゆー時に信頼性が上がって、どーゆー時に信頼性が下がるんすか？
>>839 アンチJava厨の自作自演じゃなかったの？
>>839 連中はオブジェクト指向と直接関係無い低レベルな部分で必死に貶そうとしているだけ。
もとからレベルが低く大規模開発に携わる器も無い奴なので
そういうことでよろしい。
いままで否定していた物が採用される。
>>848 いらない、とはいってないと思うのだが。
危険性が高い方法では要らない、とは言ってたと思うが。
Genericsなんて、昔から要るいると言われてたわけだが。
>>842 考えなしにオペレーターオーバーロードして、その演算子でなにをしてるかわかりにくくなったときに信頼性は下がる。
考えられた直感的なオペレーターオーバーロードの場合、コード記述の効率が上がる。結果、信頼性も間接的にあがる。
>>850 > 考えられた直感的なオペレーターオーバーロードの場合、コード記述の効率が上がる。結果、信頼性も間接的にあがる。
ここの「～。結果、～」の前後の因果関係は相当怪しいね。
>>848 > あれほど、いらない。ある奴はクソと言い続けていたのに。
具体的に、誰が、何を、いらない、とか クソ、と言い続けたんで？
個人的に enum (C/C++/C# みたいな int の enum じゃないやつ)は必要だといってたけど。
結局Javaはまだまだなんだよなぁ。
>>853 後だしジャンケンを誇られてもね。
そもそもC#はJavaのパクリなわけで。
1.5で取り入れられそうな、enumもC#と同じタイプセーフなenumだしね。
>>852 はなんか勘違いしているみたいだけど。
>>851 うん。あやしい。
だから、弊害が起こる可能性の方が高い。
でオペレーターオーバーロードは却下となるわけで。
>>854 そのJavaもC++やその他のパクリなわけだが。
んでも実際問題として、Smalltalk みたいな変数に型の無い言語は別としてC++ で
>>858 > オペレータのオーバーロードが関数より「なにしてるかわからん・
iostream が非常に良い例ですな。
>>858 > 代入演算子のオーバーロードもダメ？ a = b はダメで、 a.set(b) とかするべき？
例えば、Java だと単純代入演算子 = で参照型の代入式を記述したら
右辺の参照値が左辺に代入される。
これがオーバーロードされて別の意味になったら混乱する。
> 比較演算子もダメ？なーんか納得いかない。。。
比較演算子の話は
>>719 あたりで出てなかったか？
ところで、javaに #ifdef って実装されませんかね？
>>864 Sun の公式回答が
> 今は必要に応じてgccとかそのへんのプリプロセッサだけ使う
しろ、じゃなかったっけ？
もしくは if( 定数式 ) とすると既存のコンパイラが条件分岐を削除するのを利用するとか。
ところで、#ifdef で何したいの？
>>860 iostream が何してるかわからない人って、そもそも非常に低レベルな人材なわけで、
C++ なんか使うような開発に適正が無い、って気がするけど。。
（ちと自信ないけど）
>>861 それはどの well known なメソッドについてもいえることで、演算子オーバーロードに
限らないと思うけど。。。 size() や equals() や clone が別の意味になってたらやはり
混乱するわけで。。。less なんて名前で実は意味が反対、みたいな比較メソッドが書
けるから、メソッドに意味のありそうな名前をつけられる言語仕様はダメ、識別子は全
て無意味語にして設計書を読ませるのが安全、って。
>>865 もれは864じゃないけど SDK のバージョン違いを吸収するのに ifdef 使いたくなる
ことはある。。。
＞＞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 オーバーロード。 オーバーライド。 このインスタンスの値を、それと等価の文字列形式に変換します。
>>868 .NET では値型も System.Object も派生すんだからメソッド持ってても…
>>868 int val = 0;
Console.WriteLine(val.ToString());
Console.WriteLine(val.GetType());
とか出来るし。
メソッド持っている時点でタダの数値じゃないね。
>>866 > それはどの well known なメソッドについてもいえることで、演算子オーバーロードに
> 限らないと思うけど。。。
一般論としてはね。
ただし
>>861 は代入演算子をオーバーロードしない方が
良い理由を書いているので、その指摘は的外れ。
>>871 > メソッド持っている時点でタダの数値じゃないね。
C# にはタダの数値は存在しない、と。
>>866 > iostream が何してるかわからない人って、そもそも非常に低レベルな人材なわけで、
例えば、1文字しか入力が無かった場合、
char c1,c2;
cin >> c1 >> c2;
でどうなるの？ とか最初はマニュアル見なきゃわからんし。
まぁ慣れれば大丈夫、ってのはわかるけど、
慣れる前の状態も重要だと考えるので。
>>870 それゆーなら、C# では
Console.WriteLine(0.ToString());
Console.WriteLine(0.GetType());
もできるんだが…
>>867 > もれは864じゃないけど SDK のバージョン違いを吸収するのに ifdef 使いたくなる
具体的には？
>>875 C#の方がOOPLとしての完成度が高いですね
C#最強。
>>870 GetName というメソッドが使えることからもわかるように
列挙はただの数値じゃないってこった。
>>881 > GetName というメソッドが使えることからもわかるように
>>871 と言ってる事が変わってるぞ。
>>881 > GetName というメソッドが使えることからもわかるように
> 列挙はただの数値じゃないってこった。
列挙型がただの数値型でないだけ。enum と int で加減算できるし、
enum と enum でビット演算できるし、どこが typesafe なんだか…
>>874 エラー処理の方法がマニュアル見ないと判らないのは、これがメソッド変わろうが事情は同じだべ。
最低限のカルチャーはどんな言語だろうが、ライブラリーだろうが必要だっちゅーの。
>>842 ひねくれ者のあなたには判らないだけです、普通の人なら演算は見ての通りの書き方のほうが判りやすいのです。
判りやすい書き方は間違いが少ないのですよ。
間違いが少ないという事は信頼性も高いという事です。
そして、世の中にひねくれ者が少数居る事は承知していますよ(藁
>>884 > エラー処理の方法がマニュアル見ないと判らないのは、これがメソッド変わろうが事情は同じだべ。
istream::get() を使えば EOF が帰るのに
istream::operator >>(char&) では安易な記述の変わりに EOF チェックが面倒になってるよね。
こーゆーのも安易な演算子のオーバーロードの例って事で。
>>885 > ひねくれ者のあなたには判らないだけです、普通の人なら演算は見ての通りの書き方のほうが判りやすいのです。
「見ての通り」が何を意味するかは個々人によって違う事がある。
まぁ、個人の資質のせいにするのもいいけどさ。
それだけじゃあ複数人での開発は上手くいかないと思うけど？
>>885 > 判りやすい書き方は間違いが少ないのですよ。
判りやすい書き方とはいっても、マニュアル読まないと
「何やってるか」は分からない、と。
本当に判りやすいのか？
ダカラソレハ普通のメソッドでも同じだろうが。
a + b;
>>886 int ch;
ch=s.get();
if(ch==EOF)
char ch;
s>>ch;
if(s.eof())
面倒か？
>>889 演算子のオーバーロードは記述が容易になるのに、
根っこから理解するには普通のメソッドと同じだけの労力が必要。
熟練者にとってはガシガシ記述できて便利だけど、
初心者は読むのが大変だし、(他の言語の経験などの)先入観があると躓く事も多い。
それに、演算子のオーバーロードを数学的なものだけに限定するなら、
必要無い分野のプログラムしか書かない人もかなり多い。
>>887 少なくとも代数的なオブジェクトに対して、四則演算程度のオペレータごときを違う定義にする奴は奇特だと思うね。
複数人でも普通はいない、あなたは別ですか？
別だというなら、そんな状況下ではオペレータオーバーロードでなくても問題起こすと思うよ。
メソッドにしたところで状況は改善しないでしょう。
>>891 少し複雑になった、という意味で「面倒」という単語を使ってるので。
>>893 > 少なくとも代数的なオブジェクトに対して、四則演算程度のオペレータごときを違う定義にする奴は奇特だと思うね。
いつの間に こんな前提が？
それに、代数的なオブジェクトなら
必要無い分野のプログラムしか書かない人もかなり多い。
>>893 > 少なくとも代数的なオブジェクトに対して、四則演算程度のオペレータごときを違う定義にする奴は奇特だと思うね。
そうであっても、個々の値でオーバーフローとか発生した場合どうするのかとかで違いは出るね。
まぁ、演算子のオーバーロードでなくても同じ問題でるが、
そのような問題の発生を まるで考慮してないような
>>893 は
演算子のオーバーロードは使わないほうが良いかも。
>>895 普通はあるだろう、表計算程度の物だって加減乗除くらい使うと思うが。
>>892 >演算子のオーバーロードは記述が容易になるのに、
>根っこから理解するには普通のメソッドと同じだけの労力が必要。
記述が用意になって労力はメソッドと一緒ならすごいいいじゃん。
>初心者は読むのが大変だし
初心者はa.add(b.mul(c))みたいな形式よりa + b * cを好む。
>それに、演算子のオーバーロードを数学的なものだけに限定するなら、
>必要無い分野のプログラムしか書かない人もかなり多い。
必要のある分野の人は切捨てか？書く人はめちゃくちゃ書くと思うが？
>>894 複雑か？
>>895 メソッド名とまったく異なる処理にする奴はかなり奇特だろ？
>>896 例外でも投げたら？
>>896 考慮する必要が無い、ばかばかしいと判断したからC#では復活したんでしょうね。
散々議論されたがそんなものは杞憂だと
多分これからの言語はその傾向になると思うよ。
矛盾が発生しにくいようにちょっとだけ文法に工夫すればいいだけ。
>>897 > 初心者はa.add(b.mul(c))みたいな形式よりa + b * cを好む。
で、躓くと。
どう躓くのか言えよ
絶対a.add(b.mul(c))の方が躓くと思う気のせいか？
>>898 > 必要のある分野の人は切捨てか？書く人はめちゃくちゃ書くと思うが？
必要ある分野の人はプリプロセッサ使うか、
演算子のオーバーロードがある言語使えばよいだけ。
>先入観があると躓く事も多い。
>>903 ﾊｧｿｳﾃﾞｽｶ。語るに落ちたとはまさにこのことですね。
>>905 そりゃJavaの文字列処理の仕様が変だからだよ。
>>907 何かを変かと思うかどうかは個々人によって違う。
今となっては演算子オーバーローディングが無い言語の方が少なくなってきてるよ
911 ：
デフォルトの名無しさん ：03/11/12 23:51
中置演算子万歳！
>>910 > 今となっては演算子オーバーローディングが無い言語の方が少なくなってきてるよ
ローカルルールで、演算子オーバーローディング禁止してるとこも多いけどね。
>>912 あれのどこが演算子オーバーロードと関係あるの？
>>913 まぁ職場レベルの低いところはしょうがないよね
>>917 String の + を演算子のオーバーロードと見立てて、
演算子のオーバーロードで躓く例。
>>918 まぁそれでもええけどさぁ、あれはJavaの言語仕様ゆえの躓きだろ
==は同値かどうかの判定
===は同一かどうかの判定
にすれば混乱は起きなかったと思うが。
ちなみに↑の戦略をとってる言語は多い。Lisp Ruby ・・・もっと在ったけど思い打線
Lispは中間演算子の形をとってないけど
>>918 > ==は同値かどうかの判定
> ===は同一かどうかの判定
Javaでも
== は同一かどうかの判定
equals は同値かどうかの判定。
という戦略を取ってるね。
んで、==はオーバーロード可能にして===はオーバーロード不可能にすればOK
JavaのStringと文字リテラルが同じ性質もってないって糞仕様のせいでしょ
つーわけで躓く例、じゃなくなったので、他の躓く例を挙げてみてよ
>>922 > んで、==はオーバーロード可能にして===はオーバーロード不可能にすればOK
Java でも
同一かどうかの判定を行う == はオーバーロード不可能、
同値かどうかの判定を行う equals は上書き可能。
でも混乱は起こる。
>>923 > JavaのStringと文字リテラルが同じ性質もってないって糞仕様のせいでしょ
String と「文字リテラル」が同じ性質を持つって…
糞仕様と思うかは人次第。
もっと良い仕様が記述できなければ「糞」の部分に説得力ないし。
>>925 混乱は起こるから何？
どっちにしろ演算子のオーバーロードで躓く例じゃ無いから、他の例出してよ。
>>926 >糞仕様と思うかは人次第
ふーん。じゃあお前は演算子オーバーロードを糞仕様ということは出来ないね。言うなよ。
>>927 > 混乱は起こるから何？
演算子のオーバーロードでも同様の事が起こる。
> ふーん。じゃあお前は演算子オーバーロードを糞仕様ということは出来ないね。言うなよ。
糞とは言ってないけど。
便利な機能でも混乱の原因になるなら制限したり機能を削ったりするのも選択の一つと言ってるだけで。
>>929 お前さぁ、演算子のオーバーロード無くても混乱してんじゃん。プログラマ向いてないんじゃない？
今時Javaにこんなに熱入れてるなんて学生に決まってるじゃん
932 ：
デフォルトの名無しさん ：03/11/13 00:37
＞便利な機能でも混乱の原因になるなら制限したり機能を削ったりするのも選択の一つと
オーバーロードごときで混乱するのは
ある年齢に達すると、プログラマーは自分から使う言語を変えることはほとんどなくなる。
プログラマは自分の好みの言語を深く愛する質だし、私は誰も傷つけたくないので、
そして、仮想的な「ほげ」プログラマ氏は、Cobolも機械語も使わない。
このプログラマ氏がパワーのスペクトルを見下ろしている時、彼にはそうしているという自覚がある。
彼が目にするのは、変てこりんな言語ばかり。
で、そのLisp好きポール・グラハムさんは、
>>934 ただし、その「ある年齢」は人によって大きく違う。
>>938 なかなか興味深い。
自分が使ってる言語が「ぱわふる」であるかどーかで、
「ぱわふる」でない言語のユーザを見下ろしたりするのか…
C++とJavaの場合はどっちがパワフルというよりも
オブジェクト指向も限界なのかもな。
>>942 方向は適用分野？それともパラダイム？
言語ってそういったベクトルの組み合わせなわけであって、
有るベクトルに射影すると長かったり短かったりするわけで、
そういう意味でいえば向き不向きがあるわけだ。
要するに単一の方向だけで全てを賄おうとする言語は糞。
補足
C++厨はどうして「C++が最先端」と思い込みたがるのだろうか？
痛杉
可読性についてだけど、
949 ：
デフォルトの名無しさん ：03/11/13 15:02
>>943 プログラム言語のパラダイムという点では、つぎはアスペクト指向なのだろうが・・・。
ただ、多くの点でプログラム言語のパラダイムとしてはオブジェクト指向で充分であるようだ。
教育コストのバランスなどを考えてね。
ということで、視点としてはプログラム技術のパラダイムからプロセス技術のパラダイムに移行している。
CMMとかXPとかテストファーストとか、そういった話題が普通のプログラム技術誌をにぎわすようになってきた。
>>948 > ↑の場合適切なメソッド名は何になるんだろう。
・会社のルールに従う。
・使用している言語でより支持されたルールに従う。
・俺ルールでやる。
上のが優先順位は高い。
>>950 理想はこっち。
・使用している言語でより支持されたルールに従う。
・会社のルールに従う。
・俺ルールでやる。
いっその事演算子なんてなくしちまえ！
>>951 あぁ、給料もらえなくてもいいならそーかも。
っつか、会社レベルのルールも守れなければ
> ・使用している言語でより支持されたルールに従う。
とかいーつつ、それをちょっと改変した俺ルールとか使いそうだし。
会社のルールを押し付ける会社がDQNなんですよ。
まぁ職場レベルが低いところはしょうがないよね
>>950 一番上は
・プロジェクトのルールに従う
じゃ無いかと
>>954 職場のルールが守られない＝職場のレベルが低いって意味だよね？
・使用している言語でより支持されたルールに従う。
>>959 > ってのを採用しない職場のレベルはまず低いと思って間違いないだろう。
「使用している言語でより支持されたルール」は幅が広くて、
会社とかプロジェクトのルールは幅が狭いルールって意味。
> 会社のルールってのはDQN上司の俺ルールってパターンが非常に多いからだ。
そーゆー上司にはあたったことないしなぁ…
>そーゆー上司にはあたったことないしなぁ…
職場レベルが低くて苦労してる人間が集うスレはここですか？
>>948 > b.mul(c) ってかかれると b <- b*c みたいにも読めるし
> ↑の場合適切なメソッド名は何になるんだろう
破壊的なメソッドには語尾に！をつけるのはどうでしょう
kill!
次スレは立てないでC# vs JavaかDelphi vs Javaを使おうよ。
Javaは対決好きなんだな
非破壊
このスレオモロイ！
次スレってどこですかね
971 ：
デフォルトの名無しさん ：03/11/14 05:20
>>969 Java の String は + 以外でも特別扱いされてっからねぇ
973 ：
デフォルトの名無しさん ：03/11/14 07:23
Cのように文字列サポートが無い仕様のほうがよっぽどキモイぞ！
>>973 > Stringの+連結演算子はJavaのシンタックスシュガーなんだよ
シンタックスシュガーって否定的な意味で使われるんだと思ってた…
975 ：
デフォルトの名無しさん ：03/11/14 07:45
俺漏れも
>>973 > C++/SmallTalkのように文字列クラスごときのために、演算子オーバーロード
> 認めましたなんていうグロい実装をマンセーするつもりかボケが！
文字列以外でも使ってますが…
977 ：
デフォルトの名無しさん ：03/11/14 08:25
>976
978 ：
デフォルトの名無しさん ：03/11/14 09:12
多倍長整数、多倍長浮動小数点数、複素数、ベクトル数
>>978 > その他ユーザーによって定義される数値を現す型を使うとき
これは要らん
>>977 > Javaが演算子オーバーロードを仕様に含めなかった潔さについて言ってるんだと思う。
どのように読めばそのような解釈になるのでしょうな？
981 ：
デフォルトの名無しさん ：03/11/14 09:46
ぼくちん馬鹿だから
>ぼくちん馬鹿だから
>ぼくちん
984 ：
デフォルトの名無しさん ：03/11/14 10:47
ふふふ。Javaは地上のボクチンをターゲットに作られている。
>馬鹿どもにはちょうどいい目くらまし言語だ。
（COBOL 使えばいいのに。。⇒Java やってる人)
問題は業務業界に跳梁跋扈するＶＢ厨なのであった
>>973 そりゃC言語って元々アセンブラの変わりに使う予定だったものなんだし
高級言語が文字列を取り扱って、高級言語からCへトランスレートするのが元々Cの目的な訳で
色々な文字コードが今後出る事が確実と判っていて、特定文字コードに特化した文字列処理を追加するとすれば、それは問題な訳。
ところが、C言語の当時の構造化プログラムの記述能力が最も高い言語の一つで、それがマシン語並のスペックを出すと、
当時プログラマとしてはわずかな記述性の向上は捨ててCを取ってしまった。
それで、本来の高級言語が流行れなかったのだが、それはCが悪いのでは無く、当時の高級言語の記述能力があまりに不甲斐無かったのが悪いんだと思う。
991 ：
デフォルトの名無しさん ：03/11/14 21:57
1000get!!!
992 ：
デフォルトの名無しさん ：03/11/14 22:05
993
994
995
996
997
998
アホアンチ氏ね
1000 ：
デフォルトの名無しさん ：03/11/14 22:28
FIGHT!!!
1001 ：
１００１ ：
Over 1000 Thread このスレッドは１０００を超えました。