06/04/29 23:31:10
Cは難しすぎるんだよ。
良くも悪くも
263:仕様書無しさん
06/04/29 23:38:08
日本屈指のプログラマーですら
バッファオーバーフロー脆弱性だなんて・・・ねぇ
264:仕様書無しさん
06/04/30 00:12:59
>>257
> オブジェクト指向を入れたことで
> 短期納入はほぼ不可能となり、それなりの教育/コストがかかるようになった
再利用、移植、拡張、という長期的な視点で見れば
オブジェクト指向によってうける恩恵は大きいぞ。
それなりに経験とノウハウが必要だが、
オブジェクト指向を一切使わない方がいいというのは今どきの
開発ではもっと痛い。
おまえが儲けが減ったというのはオブジェクト指向の制ではない、
おまえんところの開発チームのオブジェクト指向スキルが低いことが
儲けが減った原因だろう。
265:仕様書無しさん
06/04/30 00:14:08
>>262
しかし、JavaはCよりも難しい。
オブジェクト指向が理解できず>>257のように躓いている
会社ではとくに難しいだろう。
266:仕様書無しさん
06/04/30 00:14:39
>>263
そこでJavaですよ
と言う話が出たりする。
267:仕様書無しさん
06/04/30 00:19:14
そのクラスとやらを再利用したことあるわけ？
268:仕様書無しさん
06/04/30 00:20:45
んなことたっぷりあるじゃん。
再利用経験が浅いってことはお前の設計に問題があるんじゃない？
269:仕様書無しさん
06/04/30 00:42:53
それが成功だったといえるか？
たとえば言ってみ？
保守効率はどう？
270:仕様書無しさん
06/04/30 01:02:03
まず>>267がいったいどんな障壁にぶつかったのか説明しないことにはねえ
271:仕様書無しさん
06/04/30 01:22:28
成功事例がないなら成功してないってことだな
272:仕様書無しさん
06/04/30 01:25:55
だからJavaは商品でも製品でもなく実験言語だと言っただろう。
実験なので仕様変更しまくっても当たり前。
実験といえばTHE INTERNET自体も未だに実験段階。
バグがあったら客にも「実験ですから」と言えばいい。
できれば最初に言っておけ。
お前のところはそんなもんを売るのかと言われたら「じゃあインターネットやTCP/IPを使いたいというあんたもどうかしてる」と切り返せ。
273:仕様書無しさん
06/04/30 01:32:30
10年後にオブジェクト指向はってのは、「なかったこと」になってるよｗ
いまだに言ってる場かは時代遅れｗｗｗ
274:仕様書無しさん
06/04/30 01:56:11
はぁ？
Javaでこんなボコボコシステム作ったら保守だけでも１０年程度で仕事が無くなるわけないだろ。
仕事したことあるのか？お前。
働いてからレスしろよ。学生。
275:仕様書無しさん
06/04/30 01:59:20
現在のオブジェクト指向の立場は10年前のニュ－ラルネットの立場だな。
まだ国を挙げて取り組んでないだけマシだけど。
オブジェクト指向の体現＝Java周辺技術
ニューラルネットの体現＝ニューロマシン
276:仕様書無しさん
06/04/30 02:03:26
保守期間が長いのはウォーターフォールの延長だから。
スパイラルやアジャイルが加速すればリプレース時期も早まる。
>>274の件はJavaが今のCOBOLの地位にすっぽり納まった場合のみ実現する。
しかし時代は変わっている。ていうか変わったからJavaが出てきた。
277:仕様書無しさん
06/04/30 08:23:39
おJava様があほなこといってるからインド人とかマレーシア人が大量に入ってきて日本で子供育ててるわけだが・・・・。
278:仕様書無しさん
06/04/30 08:51:05
>>272
Javaがそんなに実験言語だったら
今Javaの仕事なんてこんなにないはずだが
279:仕様書無しさん
06/04/30 08:53:13
>>273
オブジェクト指向は20年も前から存在しているわけだが
日本はオブジェクト指向技術の浸透が20年近くも遅れているわけだが。
それからオブジェクト指向よりも新しい技術が登場したときは
オブジェクト指向が対前提となってその上で新しい技術が
導入されるケースが大いに考えられるわけだが。
アスペクト指向技術もオブジェクト指向が大前提となっているように。
今のオブジェクト指向だって、構造化手法が大前提で
その上でオブジェクト指向が成り立っている。
280:仕様書無しさん
06/04/30 08:54:09
>>275
ニューラルネットワークによってエージェント指向技術が
完成し実用化されるのは一体どれくらい先だろうか。
281:仕様書無しさん
06/04/30 11:19:02
ニューラルネットなんてめちゃくちゃ古いんだけど
ちょっと前のトレンドはカーネルマシン
これだね
282:仕様書無しさん
06/04/30 12:08:05
VBより遅いしわかりにくいしメンテしずらい最悪の言語＝JAVA
蛇腹とともに消え去ってくれよ
283:仕様書無しさん
06/04/30 12:13:00
そりゃﾌﾞﾋﾞ脳じゃ理解できねえだろう。
284:仕様書無しさん
06/04/30 12:16:31
記述は面倒だと俺もおもうけど、メンテしづらいとは思ったことないなぁ。
クソコード書くやつはVBでもjavaでもいわるわな。
285:仕様書無しさん
06/04/30 12:26:28
>>277
意味不明。
Javaと外国人の子育てとの間にどんな相関があるのか
根拠を持って説明してみてくれ
286:仕様書無しさん
06/04/30 12:27:27
>>282
本当にVBより遅いなら
ベンチマークとってから言ってくれ
JavaはC/C++より高速化するケースだってありうるんだが。
287:仕様書無しさん
06/04/30 12:28:34
>>284
Javaの記述の面倒くささを解消するには
XDocletやVelocityのようなツールを使ってコード自動生成を
行う、EclipseなどのIDEを使う、ということも考えられるのだが。
288:仕様書無しさん
06/04/30 12:30:38
おJavaのご降臨じゃ
289:仕様書無しさん
06/04/30 12:33:24
本家sun謹製のnetBeansを使えよ。
どこの馬の骨かわからない奴が作ったツールなんかよく使う気がするな。
290:仕様書無しさん
06/04/30 12:34:43
>>286
馬 鹿
291:仕様書無しさん
06/04/30 12:37:10
sunのtoolはどれをとっても激重で話にならない。
292:仕様書無しさん
06/04/30 12:38:24
>JavaはC/C++より高速化するケースだってありうるんだが。
具体的にどのような場合か教えてください。100万回処理を
実行する場合とか除外して、現実的な具体例を提示して
いただけないでしょうか。何分JAVAという領域をまだ勉強中
なので解らないで解りやすく書けよ
293:仕様書無しさん
06/04/30 12:39:15
>>291
それはパソコンヲタクのPCで実行するからだ。マニアの玩具、自作PCとかショップブランドじゃ
話にならない。sparc機を使え。
294:仕様書無しさん
06/04/30 12:43:18
UltraSparkでも遅いぞ本気で使いたくないぐらい遅い
HP-UXのhotspotのほうが速いぞ安定してるし
295:仕様書無しさん
06/04/30 12:44:02
ニート糞Java厨は連休だというのに自宅のｾｺｲPCから2chかｗ
モデルの彼女と海沿いの高級ホテルより書き込み
296:仕様書無しさん
06/04/30 12:46:26
>>293
いや、普通に組み方がまずいと思うんだがな。
ＣＰＵを占有してしまうような処理が多いだけのような希ガス。
ＣＰＵやメモリを２倍に増やしてもこのへんのいらいらは全く解消されなかったし
軽減すらされなかったところからいって、組み方がまずいと思うんだよね。
必要なデータを読んでくるにしてもタイミング悪かったり、
使っててすげー癇に障る待ち処理が多いのも遅く感じる理由につながってる希ガス。
全体の仕上がりが「ふにゃふにゃしたアプリ」ってのが俺のsunのtoolのイメージ。
ちょっとセンス悪いなぁ・・・って思う。
297:仕様書無しさん
06/04/30 12:46:31
企業システムで求められる性能を備えているsun micro systemsのsparc機はマニアに縁の無いものだよ。
金の掛け方が全然違うからね？触ったことある？ｗ
298:69式フリーPG ◆hND3Lufios
06/04/30 12:51:21
sunのソフトはセンスないよね。どうもシンプルであることの重要性がごっそり抜けてると思う。
solarisにしたってlinuxに比べると重いしね。（SMP関連の実装が大違いなんだろうけど）
299:仕様書無しさん
06/04/30 12:51:59
>>290
馬鹿に馬鹿と言われたくないんだが
300:仕様書無しさん
06/04/30 12:52:17
>>291
下気重だと主張するならNetBeansを使ってから言ってみてくれ
301:仕様書無しさん
06/04/30 12:53:03
>>292
バブルソートに-serverオプションを使うあのサンプルがあるいぞ。
「JavaはCより速い」でググレw
302:仕様書無しさん
06/04/30 12:54:26
リアルNEETの糞C言語厨たる>>295が出会い系サイトで脳内モデル彼女と脳内デート中か
「高級ホテル」という言葉がいかにも貧乏人臭いがなw
303:仕様書無しさん
06/04/30 12:55:03
>>298
ふんぞり返る前にお前もNetBeansを使ってからセンスのあるなしを判断しろ。
304:仕様書無しさん
06/04/30 12:55:51
Javaの仕事を拒否して仕事がなくなって無職状態になったC言語厨は
NEETとしてレスしているのか
305:仕様書無しさん
06/04/30 12:56:46
>>303
NetBeansだって十分重いじゃん。
あれを軽いっていう奴はなかなかいないよ。
306:仕様書無しさん
06/04/30 13:00:38
キモヲタＣ言語厨はGW中も引き篭もって玩具PCから2ちゃんねるですか。
307:仕様書無しさん
06/04/30 13:01:17
なんか目くそIDEが鼻くそIDEをけなしている展開だなｗ
308:仕様書無しさん
06/04/30 13:02:55
sparcがいつからインテルより速くなったの？
バカの妄想って果てしないな
309:仕様書無しさん
06/04/30 13:04:55
また朝鮮工作員の分断工作か
310:仕様書無しさん
06/04/30 13:05:23
鼻毛Java厨と尻毛Java厨の戦いかおもろい
やれやれ
311:仕様書無しさん
06/04/30 13:07:49
Javaの生まれしsun micro systems謹製のnetBeansこそJava純正IDEであり標準IDEにふさわしい。
ゴミをかき集めたEclipseをﾏﾝｾｰしている奴は、秋葉原でジャンクパーツをかき集めてPC組み立てて
喜んでいるキモヲタだろう。
312:仕様書無しさん
06/04/30 13:08:40
鼻毛Java厨 Eclipse
尻毛Java厨 NetBeans
313:仕様書無しさん
06/04/30 13:10:04
Eclipseプラグイン==ジャンク
なるほど。>>311の言う事はある意味正しい。
314:仕様書無しさん
06/04/30 13:12:18
して鼻毛軍勢の逆襲は？
315:仕様書無しさん
06/04/30 13:13:33
jakarta == ジャンクパーツ市場
つまり、Java案件こそがキモヲタPC
316:仕様書無しさん
06/04/30 13:15:02
おおっと乱闘に持ち込んできたC厨=ﾃｨﾝ毛がきたぞ！
317:仕様書無しさん
06/04/30 13:30:00
C言語厨はﾁﾝ毛
318:仕様書無しさん
06/04/30 13:44:14
javaはパイパンだぞ！
319:仕様書無しさん
06/04/30 14:02:19
>>305
何いっとる
Eclipseより軽いんだが
320:仕様書無しさん
06/04/30 14:04:11
鼻毛C言語厨 Micro$ostの力を借りないと何もできないVisualC++厨
尻毛C言語厨 オブジェクト指向を知らないUnix厨
ワキガC言語厨 BREW開発しかできない超貧乏C言語厨
こういう組み合わせもあるがなw
321:仕様書無しさん
06/04/30 14:05:08
>>313
VS.NETなんてM$厨御用達製品でしこしこ
開発やってる奴はさらにオタクの領域に
322:仕様書無しさん
06/04/30 14:09:17
おもしれえ
こういうのはどうだwww
鼻毛C言語厨 Micro$ostの力を借りないと何もできないVisualC++厨 ←VB厨並みの最下層レベルC言語厨(嘲笑
尻毛C言語厨 オブジェクト指向を知らないUnix厨 ← そこそこレベルだがジジ臭い時代遅れなC言語厨
ワキガC言語厨 BREW開発しかできない超貧乏C言語厨 ← 職安でまさに悪臭漂うC言語ドカタw
珍毛C言語厨 ファームウェア開発しかできないC言語厨 ← このスレで暴れてる最凶のドカタC厨
323:仕様書無しさん
06/04/30 14:13:56
Java厨房って
馬鹿なんだね
あわれすぎる
みつお
324:仕様書無しさん
06/04/30 14:31:18
うむ。ネタを継承してセンス悪くするところなんざ
リアルなJavaコードと同じなのが哀しいな。
325:仕様書無しさん
06/04/30 14:31:40
蛇腹はソフトウェア業界発展のために消え失せろ
326:69式フリーPG ◆hND3Lufios
06/04/30 14:33:24
>>322
ﾜﾗﾀ
おもしろいｗｗｗ
327:仕様書無しさん
06/04/30 14:36:55
最強のプロセッサはalphaだろ。sparcなんざx86以下のゴミ
328:仕様書無しさん
06/04/30 14:45:13
Java厨かわいそうだな。今日は天気が良く風がさわやかだぞ。
モデルの彼女と海沿いのカフェテラスより
傍らには愛車のBenz SLCの屋根がフルオープンで佇む
329:仕様書無しさん
06/04/30 14:48:44
>>323-325
自演必死だなＣ言語厨wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
330:仕様書無しさん
06/04/30 14:50:02
今モデルの彼女からコメントが入ったから伝えるな。
彼女「Java厨さんこんにちわ、Java厨さんの着ているスーツって
コナカか青山製ではないでしょうか？」
331:仕様書無しさん
06/04/30 14:50:07
>>328
おい、さっきからモデルと楽しんでいるなら
2chなんかやってる暇は無いはずだぞ妄想爆発C言語厨www
おめえは恋愛ドラマの見過ぎじゃねえねのかw
332:仕様書無しさん
06/04/30 14:51:12
今モデルの彼女からコメントが入ったから伝えるな。
彼女「C言語厨さんこんにちわ、C言語厨さんの着ているスーツって
KDDIかクアルコム製ではないでしょうか？」
wwwww
333:仕様書無しさん
06/04/30 14:52:35
>>330
お前はワキガC言語厨だから流石にそういう脳内彼女でオナニーするしかないよなw
334:仕様書無しさん
06/04/30 14:53:36
彼女に伝えとくね
こいつらはスーツすら持ってなくて
チェックのシャツとディパックでアキバをうろついているデブヲタ
ばかりだと。ジーンズのウエストはゴムだってとね。
ｗｗｗｗｗ
335:仕様書無しさん
06/04/30 14:54:00
>>322
寺ﾜﾛｽ
336:仕様書無しさん
06/04/30 14:54:45
>>325
ジャバ羅漢を無くしたら直角の管パイプを使えというのかw
337:仕様書無しさん
06/04/30 14:56:15
>>334
ゴムだって？ そりゃおまえだろw
C言語厨のほうが秋葉系が多いぞw
Java One Tokyoとデブサミ言ったときの差を見たら
Java Oneのほうがイケメンが多くデブサミはお前が想像するようなキモヲタ
多かったよ。
その格差は歴然w
338:仕様書無しさん
06/04/30 14:57:00
バイト先でワンセグＢＲＥＷ開発してるC言語厨を見ていたら、
まさにドカタだった。しかも秋葉系アニヲタガンヲタが多かった
339:仕様書無しさん
06/04/30 14:58:09
>>334
貧乏無くせに消費者金融に借金して何十万もするスーツを
買ったとはC言語厨ご愁傷様w
340:仕様書無しさん
06/04/30 14:58:53
そんな何十万もするスーツを着てもお前のワキガ臭と脳内彼女妄想癖と貧乏性は直らないぞ。
341:仕様書無しさん
06/04/30 14:59:10
ワキガC言語厨どうしたw
342:仕様書無しさん
06/04/30 14:59:47
ワキガじゃC言語厨にはリアルで女は寄って来ないだろうw
343:仕様書無しさん
06/04/30 15:02:05
あはは。かわいそうにな。
彼女「Java厨さんたちって女性と付き合った事ないようね」
だってさｗ
344:仕様書無しさん
06/04/30 15:07:50
泣くなよJava厨
Javaやめればすこしはもてるようになるかもよｗ
なっ
345:仕様書無しさん
06/04/30 15:10:29
30歳独身童貞C言語厨がGWの最中にﾃﾞﾑﾊﾟ飛ばしていると聞いて飛んできました。
346:仕様書無しさん
06/04/30 15:28:42
>>278
実際インターネットはそんなに実験段階なのに普及してるだろ？商売にも使われている。
実験でも何でも客に使えるものであると納得させれば商売できるんだよ。
正確にはコンサル屋とかが担げばNoProblemなんだよ。
で、実験であるが故に新しい機能や試みも多く出てくる。
そういうところが好まれる時代になってきたんだよ。
好んでるのはコンサル屋なんだけどな。
347:仕様書無しさん
06/04/30 15:57:38
>>345
みたいだね。
というかこいつは30歳じゃんくて30代だろw
せいぜい脳内彼女と遊ばせてやれよw
348:仕様書無しさん
06/04/30 16:03:00
ここまで俺のｼﾞｻｸｼﾞｴﾝ
349:仕様書無しさん
06/04/30 16:06:12
がんばったな。
もうらくにしていいぞ。
さ、それじゃホスピスに行こうか。
Java厨房よ。
350:仕様書無しさん
06/04/30 16:28:23
まぁ実際問題、エンタープライズ領域でのシェアの差はもう歴然たるものなのですた。
351:仕様書無しさん
06/04/30 16:35:33
最近だとネットワークの基盤系のプロジェクトもＪＡＶＡなんだな
開発マシンに8Wayマシンとか渡されてびびったよなぁ。
Ｃなら２あればできそうなことずいぶんごついのでやるんだなと
思ったよ
352:仕様書無しさん
06/04/30 16:59:41
このみちーはぁ、いつかきたみち～♪
あーあーそうだよぉ～♪
こぼらーさんがぁ てまねきしている～♪
353:仕様書無しさん
06/04/30 18:18:56
Java自体もう終わってるよ・・
さんざん企業でテストしつくされ、結果「使えない」という結論に・・・
ああ、必死でJavaを覚えた奴ってBakaみたいｗ
354:仕様書無しさん
06/04/30 18:23:20
え～、、、、いま社内研修で必死で勉強してるのに。
355:仕様書無しさん
06/04/30 18:24:57
ﾌﾞﾋﾞしか出来ない通称「ｸﾞﾗﾏｸﾝ」が大暴れ
JavaやCが出来ないことをｺﾝﾌﾟﾚｯｸｽにJava、Cを叩きまくり
ｽﾚﾘﾝｸ(prog板)
ｽﾚﾘﾝｸ(prog板)
ｽﾚﾘﾝｸ(prog板)
356:仕様書無しさん
06/04/30 18:44:21
VisualStudio>>>>>>>>>>>>>>アルプス山脈＞＞＞＞＞＞＞＞＞＞＞＞太陽>>>月＞＞＞＞
357:仕様書無しさん
06/04/30 20:33:49
＞＞＞＞＞＞亀
358:仕様書無しさん
06/05/01 23:36:35
>>331
結構長い付き合いだから、君みたいにﾊｱﾊｱしてｱｾｱｾしてないんだよ。
359:仕様書無しさん
06/05/02 00:51:17
>>353
どっかでみたコピペだな。
マルチウザ
360:仕様書無しさん
06/05/02 00:52:45
>>358
つまりモデル経験ありのよぼよぼのオバサンと付き合ってるのかw
モデルというよりただの駄目AV女優か駄目ヤンキー女と
付き合ってるだけじゃねえのかw
361:仕様書無しさん
06/05/02 07:17:54
>>359
Javaを稚拙に叩いてるのはｸﾞﾗﾏｸﾝってVB6信者の池沼だよ
ｽﾚﾘﾝｸ(prog板)
ｽﾚﾘﾝｸ(prog板)
362:仕様書無しさん
06/05/02 11:00:52
ﾀﾞｻｯ
VB厨ごとこがJavaに喧嘩売ってるのかw
しかもC厨のフリをしていれば
高度なスキルがあると思ってくれると勘違い
しているところが実にイタイなw
363:仕様書無しさん
06/05/02 11:01:06
ＶＢ厨ごとき
364:仕様書無しさん
06/05/02 11:12:53
信頼性
VB＞＞＞Java
速度
VB＞＞＞＞＞＞＞＞Java
作りやすさ
VB>>>>>>>>>＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞じゃヴぁ
365:仕様書無しさん
06/05/02 11:38:08
>>360
現役ぴちぴちのﾌﾟﾘﾌﾟﾘのｼｬｷｼｬｷなデルモﾀﾝなんだよ。
漏れの周りはお嬢様しかいないからヤンキーとは縁が無い。
君は逆にヤンキーしか縁がないのかな。
Javaやめれば世界が変わるかもよ
なっ
366:仕様書無しさん
06/05/02 19:47:46
>>365
そんなかわいそうな事言うなよ。
Javaやめれば世界が変わるかもよ ・・・じゃなくて世界が終わるよ！
の可能性が高いんだから。
367:仕様書無しさん
06/05/03 00:14:04
JVM無くなったら食っていけない奴らだしな。
368:仕様書無しさん
06/05/03 00:26:34
ハードがどんどん進化してく中で、JVMのような概念はなくならないと思うけどね。
369:仕様書無しさん
06/05/03 00:35:34
いらんもんは無くなる
370:仕様書無しさん
06/05/03 02:04:51
なんつのかな、「プログラミング言語」としての優劣なら賛否あると思うけど
その言語を使ってプログラムを組む「中の人」の優劣なら明らかにJava有利じゃないか？
ﾌﾞﾋﾞ厨はｸﾞﾗﾏｸﾝみたいな理論のかけらのない奴多いし
371:仕様書無しさん
06/05/03 02:22:18
中の人の多くは同一の人間だから別に有利ということはないだろ
中が腐ってるのはどこも一緒、言語が違えば用語も違うだけで養護が必要なのはいつの時代も変わらんさ
372:仕様書無しさん
06/05/03 06:37:52
おじゃばさまの優位性ねえ・・・。
中身がなくてラッパみたいにお題目吹いてくれるからSUNにとっては・・・。
害しかないじゃんよｗｗｗ
373:仕様書無しさん
06/05/03 11:58:53
>>370
ＶＢは論外です。
374:仕様書無しさん
06/05/03 12:01:09
>>368
学会の常連が好んで言いそうな言葉だな。
それはエンジニアリングではなく研究だ。
375:仕様書無しさん
06/05/03 14:39:29
>>365はどこまで妄想をふくらませるのでしょうかw
376:仕様書無しさん
06/05/03 14:40:25
>>367
JVMはコピーをとっておいてあるからなくならないよw
というかサードパーティ各社が独自にJVMを
作っているから困りませんがw
377:仕様書無しさん
06/05/03 14:41:19
>>374
エンジニアリング(工学)という分野で研究している学者もいるんだが。
378:仕様書無しさん
06/05/03 14:59:01
>>377
残念ながら、現在のエンジニアリングはまだ学問とは呼べない。
理論を学べば誰でもできるものではない。
379:仕様書無しさん
06/05/03 15:19:24
誰でもできるって馬鹿でもできればいいってもんじゃないだろ。
380:仕様書無しさん
06/05/04 12:30:07
定義的には馬鹿でも努力すればできるのが学問だがな。
381:仕様書無しさん
06/05/06 20:05:59
VB以下のJavaなんていまどきｗｗｗｗ
382:仕様書無しさん
06/05/06 20:06:57
あ！ｸﾞﾗﾏｸﾝが湧いた
383:仕様書無しさん
06/05/06 21:19:51
ﾌﾞﾋﾞｸﾞﾗﾏｸﾝ必死だねw
384:仕様書無しさん
06/05/06 21:25:04
ｸﾞﾗﾏｸﾝてコテやトリップ使わず、書き込みの内容も
あたかも他人のフリして書いてるけど、書き込みの内容に理論性のかけらも無いから
すぐｸﾞﾗﾏｸﾝて解るよねｗ
385:仕様書無しさん
06/05/06 21:29:59
ﾜﾛｯﾀw
386:仕様書無しさん
06/05/07 15:34:12
JavaのCollectionってなぜか遅いんだよな。
Javaが早いと言う根拠も、みんなCollection使ってない
サンプルばかり。
387:仕様書無しさん
06/05/07 17:36:46
>>382
>>383
>>384
蛇腹が偉そうなクチ叩くなよ
388:仕様書無しさん
06/05/07 17:43:10
Collection使うと頻繁にヒープを確保しにいってると思うよ
まぁJAKARTAのcommonsにあるやつは標準よりも速いけど
それはやっぱり糞JAVA文化内でのどんぐりの背比べだな
389:仕様書無しさん
06/05/07 17:52:05
ｸﾞﾗﾏｸﾝ意気消沈気味？
390:仕様書無しさん
06/05/08 00:23:33
>>386
LinkListとArrayListとの使い分けを間違えて
遅いというコードもあったりするが、
具体的にそのベンチマークのデータを見せてくれないかな。
391:仕様書無しさん
06/05/08 00:24:57
あと、ハッシュを使うとき、
ただHashMapやLinkedHashMapを使った場合とTreeMap, SortedMap
を使った場合とでは速度がそれぞれ異なる。
その辺りも理解しているだろうか。
挿入、削除は速いがアクセスは遅い、
またはその逆になっているクラスもあるということだ。
392:仕様書無しさん
06/05/08 00:49:42
>>390
ほれw
Collections.sort(list);
393:仕様書無しさん
06/05/08 01:08:06
安定性
VB＞＞＞Java
速度
VB＞＞＞＞＞＞＞＞＞＞＞＞＞Java
作りやすさ
VB>>>>>>>>>>>>>>>>>＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞じゃｖ
394:仕様書無しさん
06/05/08 01:09:45
>>393
１つ忘れてるぞ
給料（年俸）
JAVA >>>>> VB
それでいいのかVBさん？
395:仕様書無しさん
06/05/08 04:03:37
>>392
Collections.sortのソースを追いかけてみたが、一旦全体を配列にコピーした後、
Arrays.sortを使った後、リストに戻してるのな。
しかもArrays.sortの中でmergesortを使うためにまた全体をコピーしてるしｗ
こりゃ遅いわ。
Javaコンパイラは速いかも知らんが、その前のJavaのソースが糞だわｗｗｗ
396:仕様書無しさん
06/05/08 15:54:56
糞Javaソースをデコンパイル後解析してまで叩くのが最近の主流ですか？
397:仕様書無しさん
06/05/09 01:24:09
Ｊａｖａのバイトコード解析って何使ってやってる？
俺、バイトコードの仕様見つつ覚えながら脳内解析なんで
時間かかってしゃあない誰かいいツール教えて
398:仕様書無しさん
06/05/09 03:12:59
マージソートのせいで遅いというのもあるんじゃないのか。
これは速さを取るよりも安定なソートをやりたいってことだろ。
しかし、問題はやたらメモリ使ってるところだな。
399:仕様書無しさん
06/05/09 12:07:07
>>392
ベンチマークに使ったソースコードとセットでデータが欲しいんだが。
それにArrayListとLinkListとではソートにかかる時間も異なるぞ。
ソートでなくてもデータ量が多いときと少ないときでもアクセス、データ追加削除更新速度に差が出る。
挿入ソートを用いているTreeMapやTreeSetとも比較してくれ。
ただし挿入する時点でソート済みなので挿入速度と含めて比較してみてくれ。
400:仕様書無しさん
06/05/10 00:36:40
自分で試してみれば。
401:仕様書無しさん
06/05/10 01:36:58
ここは言い出しっぺの>>392に試させるのが
筋ってもんだが。
402:仕様書無しさん
06/05/10 03:10:25
クレクレ君乙。
403:仕様書無しさん
06/05/10 04:09:14
List<Integer> list = new ArrayList<Integer>();
Random r = new Random();
final int N = 1000000;
for (int i = 0; i < N; ++i) {
list.add(r.nextInt());
}
long start = System.currentTimeMillis();
Collections.sort(list);
long end = System.currentTimeMillis();
System.out.println("Java : " + (end - start) + "ms");
Java : 1532ms
C++ : 120ms
404:仕様書無しさん
06/05/10 08:04:14
マジか。
マージソートとかコピーしてるという次元の違いじゃない気がするぞ。
405:仕様書無しさん
06/05/10 11:39:40
>>397 デコンパイルツール
ｽﾚﾘﾝｸ(prog板:285-290番)
406:仕様書無しさん
06/05/10 13:17:39
Jakarta Commons Collectionsにsort関連のメソッド
があったと思うが
407:仕様書無しさん
06/05/10 13:20:25
Javaの場合、sort関数なんて使わずに
データを追加する時点でソートするTreeMap, TreeSetタイプを
使うことを推奨しているんじゃないのか？
データを作る時点ですでにソート済みにしておけば
わざわざsortなんてする必要無いからな
408:仕様書無しさん
06/05/10 13:24:05
データの並びやデータ量によってはクイックソートが必ずしも速いとは
限らないのでArrays.sort()やTreeMapが必ずしも遅いとは言い切れぬ
409:仕様書無しさん
06/05/10 14:18:07
それにしても10倍遅いってのはどうなの。
410:仕様書無しさん
06/05/10 16:06:56
遅いという結果を示すソースコードと測定方法を見せてくれないことには
どうにも検討しようがないのだが。
411:仕様書無しさん
06/05/10 16:08:22
>>409
いろんな意味で設計がまちがってるんだろね
まあ、競輪場でMTBとロードの戦いを見ても勝負は見えてると思うぞ
412:仕様書無しさん
06/05/10 17:55:32
>>410
>>403を見ろ。
413:仕様書無しさん
06/05/10 18:17:19
コードレビューが始まったと聞いて駆けつけました
414:仕様書無しさん
06/05/10 18:46:05
>>412
C++のソースコードが無いぞ
415:仕様書無しさん
06/05/10 18:50:49
vector<int> v;
clock_t t;
for (int i = 0; i < N; ++i) {
v.push_back(rand());
}
t = clock();
stable_sort(v.begin(), v.end());
cout << "C++ :" << (double) (clock() - t) * 1000 / CLOCKS_PER_SEC << "ms\n";
416:仕様書無しさん
06/05/10 18:54:30
うむ。C++のソースはカコイイな。糞Javaとは違う！！
417:仕様書無しさん
06/05/10 18:56:14
C++最強
418:仕様書無しさん
06/05/10 18:56:42
ただソートしてるだけでそんなに差が出るものなのかな。
何行にもわたる計算をしてるわけじゃなくて、一行で専用関数に処理を任せる
場合だろ。原理的に、この場合に遅くなるはずはないんだが。
ソートだけ特別遅いんじゃないの？
419:仕様書無しさん
06/05/10 19:00:02
>>416
clock_t ← これを見た時点で恰好悪いと思ったなあ
このアンダースコア(_) 使わなくてもいいのにダサいぜ。
420:仕様書無しさん
06/05/10 19:00:14
>>418
JavaのCollections.sortは、ソートの本体(Arrays.sort)の前後に、配列に入れたり戻したりする処理を行っていて、
そこがJavaで書かれている。
421:仕様書無しさん
06/05/10 19:01:22
>>419
push_back()とかもダサいな。
422:仕様書無しさん
06/05/10 19:01:37
>>415
Ｎのサイズがいくつなのか
Ｎのサイズ毎に速度を計算してみてくれ。
Nのサイズ、というかデータのを変えると速度差に
変化が現れるはずだ。
できれば横軸にサイズ、縦軸に速度をとった
グラフとしてデータが欲しいところだな。
423:仕様書無しさん
06/05/10 19:03:29
いや、Arrays.sort自体も全部Javaで書かれてるな。
やっぱりJavaが遅いんだろ。
424:仕様書無しさん
06/05/10 19:04:01
古いサイトだが、
JavaとC++とで配列やリストの速度比較してるサイトがあったが
配列長、リスト長が長ければ長いほどJavaとC++との速度差は
縮まっていくようになっていたね。
とくに1万件を越えたあたりでJavaとC++とでは速度差が気にならなく
なるほどどころか、Javaのほうが速くなっていたような。二つの色違いの
折れ線グラフが1万件のところで交差していたような記憶がある。
しかし良く覚えていない。
425:仕様書無しさん
06/05/10 19:04:44
>>422 >>424
Nの値については、>>403を見ろ。
426:仕様書無しさん
06/05/10 19:05:59
>>423
だからデータサイズを出せといいたい。
それから測定に使用したマシンんの
メモリ容量、Java起動オプション、Javaのバージョン、
コンパイルされたファイルのバージョン、JVMのバージョン、
マシンのスペックも示せ。
でないとどれだけJavaの速度差が実際の仕事でネックになるのか
よくわからん。
427:仕様書無しさん
06/05/10 19:06:31
>>419
アンダースコアをダサいと言う Java厨
カコイイと言うC/C++厨
相容れない世界なのであった
それは
【Java厨はブラインドタッチが出来ないから】
428:仕様書無しさん
06/05/10 19:07:20
>>426
そこまで枝番しらべなきゃならないのかｗ
429:仕様書無しさん
06/05/10 19:09:15
>>425
本当にC++のNと同じサイズになっていればの話だが。
ついでだが、各々のコンパイラは何を使ったのか説明が足りないな。
430:仕様書無しさん
06/05/10 19:10:10
>>427
C言語厨はいつもこういう根拠のない発言しかできない。
Javaでも定数を宣言するときにアンダースコアを使うんだが。
C言語しかできない馬鹿は死んでいいよ
431:仕様書無しさん
06/05/10 19:10:28
>>428
1.3と1.5では速度が劇的に違うからな
432:仕様書無しさん
06/05/10 19:10:52
なぜか必死なJava厨ｗ
433:仕様書無しさん
06/05/10 19:11:39
>>423
-serverオプション、ヒープメモリサイズの設定などによっても
Javaのパフォーマンスは変わる。
そもそもsort()なんて滅多に使わない。
TreeSetやTreeMapをよく使う俺には一切必要ない。
データを追加する時点でソートされているからな
434:仕様書無しさん
06/05/10 19:11:56
自分が必死だと気づいていないC言語厨w
435:仕様書無しさん
06/05/10 19:12:42
Collections,sort()は一度も使ったことがないね
436:仕様書無しさん
06/05/10 19:12:54
>>424
Javaの方が速くなってたそのサイトってもうないの～？
シンジラレマセーン
437:仕様書無しさん
06/05/10 19:13:12
getJavatyuUnkonaBakadayon();
なんて長々アンダースコアがつかないでくどくどしいより良い。
438:仕様書無しさん
06/05/10 19:13:36
-serverオプションやヒープメモリサイズを変えた場合の
ベンチやマシンのスペックをださないC厨は事実を必死に誤魔化
してんじゃねえの？
439:仕様書無しさん
06/05/10 19:14:08
>>436
情報が古いから今だったらもっとJavaは速くなってるからねえ。
どこかの大学の研究室のサイトにあるらしい
440:仕様書無しさん
06/05/10 19:14:57
>>437
その長さはネーミングに問題有りだな。
クラス設計からやりなおしたほうがいい。
クラスの親子関係、メソッド引数などを考慮すると
ネーミングを短くする術が見つかる
441:仕様書無しさん
06/05/10 19:15:55
とりあえずC厨は古いからこっちのスレでも読んで
自分が今置かれている立場を理解汁
【あちら側】ウェブ進化論【Web2.0】
ｽﾚﾘﾝｸ(prog板)
442:仕様書無しさん
06/05/10 19:17:49
Axisは結構長いの使ってるけどねえｗ
URLﾘﾝｸ(ws.apache.org)
443:仕様書無しさん
06/05/10 19:19:05
とりあえずJava厨はJavaやめたほうがいいぞｗ
444:仕様書無しさん
06/05/10 19:21:05
ほれっ長いぞ
URLﾘﾝｸ(ws.apache.org)
445:仕様書無しさん
06/05/10 19:21:29
Javaは嫌いだけど使わざるおえないんだよぉ～？
446:仕様書無しさん
06/05/10 19:24:49
>>415のマシンのスペック情報ﾏﾀﾞｰ？
447:仕様書無しさん
06/05/10 19:25:42
>>442
冗長性もとくになく短いだろw
文字区切りも少ないしな
448:仕様書無しさん
06/05/10 19:25:58
getJavatyuUnkonaBakadayon
configureResponseFromAxisFault
漏れのサンプルのが短かったよ＞レスくれJava厨
449:仕様書無しさん
06/05/10 19:26:25
>>415のマシンは500MHz程度と見た
そりゃ遅くなる罠
450:仕様書無しさん
06/05/10 19:27:43
>>448
前者は意味が通じないし冗長だし
後者のほうが意味がわかる。
getCgenngochu(Attribute.UnkodaBakadayon)
のほうがいいな
451:仕様書無しさん
06/05/10 19:28:35
そもそもBakadayonというネーミングがC言語厨のセンスの無さを
伺わせる。
452:仕様書無しさん
06/05/10 19:29:20
しかもC言語厨はUnkodaなんてネーミング。
小学生かお前はw
453:仕様書無しさん
06/05/10 19:30:38
長さで負けたので悔しくてネーミングを叩きだしましたｗ
454:仕様書無しさん
06/05/10 19:32:43
喪前の設計センスはいいなｗ
apacheに言ってやれよｗ
クラス設計を見直したほうが良いってさｗ
455:仕様書無しさん
06/05/10 20:42:03
>>431
お前らさ、>>403のコードが1.5だということすらわからないの？ｗ
-serverオプションとかさあ、つけて自分のマシンで試してみりゃいいじゃねぇか
ソースも出てることだし。
まあ、Javaは遅いよ。何が原因かは知らんが。
456:仕様書無しさん
06/05/10 20:48:30
> 長さで負けたので悔しくてネーミングを叩きだしましたｗ
またC言語厨の言い訳だw
名前のセンスのもんだいなんだがw
457:仕様書無しさん
06/05/10 20:49:29
>>455
10倍速くしたというのが信用できないから
まずは言い出しっぺのあんたからスペックを提示してみたほうが
いいんじゃないか
458:仕様書無しさん
06/05/10 20:50:32
別に信用しなくてもいいんじゃね？そんなに信用できないなら実行してみれば？ｗ
459:仕様書無しさん
06/05/10 20:57:45
まあでもネタみたいに見える。俺はめんどくさいからやらないけど。誰かが追試してくれればいい。
460:仕様書無しさん
06/05/10 21:05:14
クレクレ君に真面目に付き合うとこうなるという例。
461:仕様書無しさん
06/05/10 21:15:37
面白いことを発見した。
コードを以下のように書き換えたら
List<Integer> list = new ArrayList<Integer>();
Set<Integer> set = new TreeSet<Integer>(list);
Random r = new Random();
final int N = 1000000;
for (int i = 0; i < N; ++i) {
set.add(r.nextInt());
}
long start = System.currentTimeMillis();
Collections.sort(list);
long end = System.currentTimeMillis();
System.out.println("Java : " + (end - start) + "ms"); //$NON-NLS-1$ //$NON-NLS-2$
こういう結果になった。
Java : 0ms
462:仕様書無しさん
06/05/10 21:18:06
Javaのほうが速くなってるのはどうして？
463:仕様書無しさん
06/05/10 21:21:02
それに何の意味があるの？
464:仕様書無しさん
06/05/10 21:21:52
>>462
Set.addのときにソートしてるから。
くだらないから無視しときなさい。
465:仕様書無しさん
06/05/10 21:31:31
set.addもうちの環境だとC++と比べて2倍ぐらい遅いなあ。
やっぱりJavaは遅いのかな。遜色ないと聞いていたのに。
466:仕様書無しさん
06/05/10 21:42:26
おそらく、C++のSTLとJavaのコレクションを比べるから2～10倍遅くなってしまうだけで、
よく言われる遜色ないというのは、細かいルーチンを自分で手で書いて
比べれば遜色ないという意味だろう。
おそらくSTLのチューンが進んでいるのではないだろうか。
467:仕様書無しさん
06/05/10 22:21:38
>>464
つまり、Set.addでソートしておけば速いってことじゃないのかな？
468:仕様書無しさん
06/05/10 22:21:52
>>465
ソースコード公開きぼん
469:仕様書無しさん
06/05/10 22:22:46
>>466
2～10倍になるちゃんとしたデータが欲しい。
sortは差はかなりでているけど
ほかのコレクション系についてはどうだろうか。
470:仕様書無しさん
06/05/10 22:43:31
>>467
それはJavaとC++を比べてどうこういうのとは問題が違うだろう。
471:仕様書無しさん
06/05/10 23:04:45
コードレビューや技術的な話になるとすっかりなりを潜めるｸﾞﾗﾏｸﾝ
472:仕様書無しさん
06/05/10 23:08:28
ﾌﾝﾌﾝ
JAVA厨藁
473:仕様書無しさん
06/05/10 23:14:11
つかVBは蚊帳の外
474:仕様書無しさん
06/05/10 23:14:56
コードレビューはeclipseがやってくれるから大丈夫、
変数が変でもあとでリファクタリングすれば大丈夫
て思ってるんじゃね？
475:仕様書無しさん
06/05/11 00:28:15
そんなＶＢ厨やC言語厨みたいな甘い思考じゃあるまいし
476:仕様書無しさん
06/05/11 00:29:04
データ無いのか。
TreeSet使った場合のC++版のソースコードは見せないのか。
つまりJavaでやってもC++でやっても大差ないってことかな
477:仕様書無しさん
06/05/11 02:46:37
その程度のこと自分で書けよｗ
何も出来ない奴は情報を得る資格もないし、これから苦労するぞ。
478:仕様書無しさん
06/05/11 08:11:29
書けないからクレクレしてパクリたいのがJava厨ですから
479:仕様書無しさん
06/05/11 13:32:58
どうせC厨も何もかけないだろ
オブジェクト指向も何もわかってないんだからな
480:仕様書無しさん
06/05/11 16:16:09
で、単純にソートしたのが早いのは分かったけどその後はどうするの？
項目のinsertしたあと毎回ソートするの？
481:仕様書無しさん
06/05/11 16:18:25
クタたんは解体されます。
482:仕様書無しさん
06/05/11 21:30:10
んだな。insertするたびにsortするのはアホらしいな。
だからJava標準関数には凝ったsortのアルゴリズムが
用意されていないんだろうな。
だから挿入ソートで挿入した時点で即座に
順序が決まるSortedSet, SortedMapのサブクラスのコレクションクラス
であるTreeSetやTreeMapなどのほうが
使い勝手がいいな
483:仕様書無しさん
06/05/11 21:33:25
だから何？そんなこと言ってみたってJavaが遅いことには変わりないんだけど。
484:仕様書無しさん
06/05/11 21:38:47
sortの使い道がわかってないな。
insertするたびにsortする馬鹿なんか、もともとどこにもいねぇよｗ
それでもsortって関数は存在し、使われてるわけだ。
人間一人にsortの使い道を全て想像できるわけないだろ。
485:仕様書無しさん
06/05/11 22:36:29
>>483
それこそだから何？
遅いからどうしたって話なんだけど。
仕事もたくさんあるしC++にリプレースする必要が
あるほど遅くは無いんだけど。
486:仕様書無しさん
06/05/11 22:37:10
>>484
> sortの使い道がわかってないな。
> insertするたびにsortする馬鹿なんか、もともとどこにもいねぇよｗ
sortに拘るC言語厨がいるから突っ込んでやったんだろ
487:仕様書無しさん
06/05/11 22:39:14
>>486
だから、それがめちゃくちゃ的外れな突込みだがな。
488:仕様書無しさん
06/05/11 22:40:30
>>485
スレタイ見てみろ。遅さを議論するスレです。
sortの使い方を議論するスレでも仕事にどちらが使えるかを
議論するスレでもない。
489:仕様書無しさん
06/05/11 22:50:42
sortにこだわってるのはむしろJava厨。
とっくにset.addも2倍遅いという結論が出てる。
俺も試してみたけど、そのぐらい遅かった。
490:仕様書無しさん
06/05/12 00:04:06
>>488
え？ Javaが遅い遅いと愚痴をこぼしてばかりいる
バブル世代の愚かさを嘲笑うスレじゃなかったっけ
491:仕様書無しさん
06/05/12 00:04:24
>>489
sortが遅いと言い出しっぺしたのはC言語厨だろ
492:仕様書無しさん
06/05/12 01:10:27
口が軽く仕事の厚みもペラペラの
JAVAさんのネタでした。
チャンチャン
493:仕様書無しさん
06/05/12 02:39:52
>>491
sortを最初に言ったのはJava厨じゃなかったかもしれないが(C言語厨？w)
それにこだわってクレクレ言いまくった挙句、的外れな指摘をスルーされても
繰り返しまくったのはJava厨だろ。
まあJavaの知識すら初歩レベルっぽいからJava厨とは呼べないかもしれないけど。
494:仕様書無しさん
06/05/12 02:42:25
C#って最近きてるよね。くさってもMicrosoftですよ。Javaはピンチですよ。
495:仕様書無しさん
06/05/12 02:44:49
いや、まだ全然大丈夫だろ。
496:仕様書無しさん
06/05/12 02:45:36
M$の人いってたけど、来年はC#の年になるみたいだね
C#の開発の方が来年は多くなるみたい。そのせいで
単価ちょっとずつ上がってるってさ
497:仕様書無しさん
06/05/12 02:46:46
いくらM$でもそこまでは言わないだろｗ
ソースあるのか？
498:仕様書無しさん
06/05/12 08:18:58
実際.aspxでぐぐってみろよ
JR東日本も.net C#その他多数公開されている
今後どんどん増える。
JavaはJAL,ANA,GET-Uしかない、2chで遅いと有名になってしまって今後増えそうもない。
499:仕様書無しさん
06/05/12 08:27:36
カブドットコムのチャートもJAVAなんだけど
いちいち再描画するのが遅い
500:仕様書無しさん
06/05/12 09:01:46
>クレクレ言いまくった挙句
ﾜﾗﾀ
501:仕様書無しさん
06/05/12 09:44:16
正解を言うと、Javaのコレクションが遅いのは、Object単位で
操作してるから。
これはJavaの構造上どうしようもない。
どうあがいてもコレクションがSTLを上回ることはないよ。
502:仕様書無しさん
06/05/12 10:12:18
JavaがC++と同等に速いというのは、
・基本データ型にコレクションを使わない
・描画は除外
・起動時間は除外
という条件を満たしてはじめて成り立つ。
世の中、たいていのうまい宣伝文句にはこうやって条件が
省かれてるんだよ。
503:仕様書無しさん
06/05/12 18:36:20
>・起動時間は除外
詐欺
504:仕様書無しさん
06/05/12 22:51:26
C#もそんなに速いとも思えんけどね
505:仕様書無しさん
06/05/12 23:29:55
ネィティブ以外は糞。
506:仕様書無しさん
06/05/12 23:45:36
VMのつくりは、C#のほうがすっきりしているし
遅いというなら、メモリ管理全部アンマネージで管理してみろ
507:仕様書無しさん
06/05/13 04:32:01
ていうか、なんだかんだいってSunのソフトって、質に関してはMSのほうが遥かに上だな。
まあ、かけた金額からいっても比べるのは可哀想かもしれないけど。
508:仕様書無しさん
06/05/13 20:33:22
Javaの貧弱さとMSの技術力（資金力）の高さはしかたない
509:仕様書無しさん
06/05/13 21:26:20
なんか最近のJavaとJava厨押されっぱなしだな
510:アホアホうんこ
06/05/13 22:06:14
JAVA使いってのは小僧が多いし、
経験もない頭でっかちが命削ってコード書いてきたベテランに口喧嘩してもかなうはずがない
JAVA厨が押されて当たり前でしょう
511:アホアホうんこ
06/05/13 22:11:01
JAVAだ、Ｃ＃だ、.NETだ、言語 言語 と騒いでいるが、一番重要な言語を忘れてないかい？
そんな賞味期限つきの言語なんかよりよっぽど大切な言語、それは
ストラクチャークエリー言語でしょ
512:仕様書無しさん
06/05/13 22:20:28
SQLっていっても複数あるわけだが・・・
そのなかで騒いでいるのと同じでしょ・・・
513:アホアホうんこ
06/05/13 22:27:30
ＳＱＬ９９だけ知ってれば問題ないでしょ、
５１２は知ったかぶり
514:512
06/05/13 22:38:48
すまん。やっぱり無理な突込みだったな
515:アホアホうんこ
06/05/13 22:48:10
実を言うと俺（アホアホうんこ）はギリギリＪＡＶＡ世代で
仕事でＪＡＶＡのアプリ、ＪＳＰ、サーブレットやった事あるけど
開発するとき、デバッグとか重くて毎回イライラしてた
イクリプスやフォルテ（ワンスタジオの先祖）は重くてダメポンだけど、ちょっと前のＡＰワークスなんて
重すぎてデバッグかけるとＰＣがフリーズだったぞ（ペン３、メモリ５１２だったけど）、スーパーダメダメ
といろいろやったけど、ＰＧ的にはＭＳ製品がイイヨ。サクサクとデバッグできるし
設計側の目で見た場合はJAVAでも何でも、どーでもいいよ
516:仕様書無しさん
06/05/13 23:28:40
携帯アプリ開発の俺が一番アホアホうんこだから心配しなくていいよ。
517:仕様書無しさん
06/05/14 04:54:33
＞ＳＱＬ９９だけ知ってれば問題ないでしょ、
ほんまかよ。
518:仕様書無しさん
06/05/14 09:13:42
SQL99 て言いたいだけだろ。
あれに完全準拠した DBMS などなく、
しかもチューニングの手法もバラバラな状況で
「SQL99 だけ知ってれば」
など笑止。
519:仕様書無しさん
06/05/14 20:08:24
>>502
> JavaがC++と同等に速いというのは、
> ・基本データ型にコレクションを使わない
> ・描画は除外
> ・起動時間は除外
> という条件を満たしてはじめて成り立つ。
今のマシンパワーならそれらの条件を
満たさなくても十分速いよ
520:仕様書無しさん
06/05/14 20:09:09
とりあえずやねうらおを撲滅させて
次はネカマのryokoを撲滅させるか。
奴はC++をマンセーしていたよな。
痛い目に遭わせてやる
521:仕様書無しさん
06/05/14 20:15:09
>>519
そのマシンパワーがあればC++はもっと速いよ
つまりどんな環境であっても
C++＞＞＞Java
この構図はかわらないわけだ
522:仕様書無しさん
06/05/14 20:49:15
Java支持派の受け答えはどっかの学会の答弁みたいだな。
523:仕様書無しさん
06/05/14 20:54:23
そりゃそうじゃね。やり込められないように逃げて
突っつき返して逃げるしかないし
524:仕様書無しさん
06/05/14 20:55:00
稚内のおっさんの影響か？
525:仕様書無しさん
06/05/14 23:11:54
>>521
> >>519
> そのマシンパワーがあればC++はもっと速いよ
> つまりどんな環境であっても
> C++＞＞＞Java
> この構図はかわらないわけだ
絶対的な微々たる速度差でC++がJavaに勝っているからといって
今更Javaで作られた製品をすべてC++に移行するのは
まったく採算に合わないわけだが。
各OSやCPU毎にまた作り直すのは
アプリが大規模で有ればあるほど無駄というものだよ。
526:仕様書無しさん
06/05/14 23:12:38
ryokoのブログが消えて
やねうらおが会社を畳む。
次はどこのC言語厨を攻撃するか
527:仕様書無しさん
06/05/14 23:15:09
今のマシンでもJavaの起動は遅いよ。
528:仕様書無しさん
06/05/14 23:28:19
>>527
バカだなお前
一度起動したら二度と起動し直さなくても良いように作れば良いんだよ。
529:仕様書無しさん
06/05/14 23:39:07
>>528
奇才現る
530:仕様書無しさん
06/05/14 23:57:05
バカだなお前
起動しないようにすれば良いんだよ。
531:仕様書無しさん
06/05/15 00:59:34
どれだけパソコンが進化しても、クリティカルな処理が2倍になったりすると、
2倍にならない場合と比べて不便だろ。
クリティカルな処理にコレクションを使えないというのは結構きつい。
532:仕様書無しさん
06/05/15 01:16:10
＞＞５１９
十分遅くて、メモリ馬鹿食いです、、、
533:仕様書無しさん
06/05/15 01:17:09
＞＞５２５
全てのOSで動作させないものほど、機種依存を高めて安定させるべき
534:仕様書無しさん
06/05/15 01:17:48
十分遅いし、そのくせメモリ馬鹿食い
だからSはノード増やせとかDQNな事を
平気で言ってくる
535:仕様書無しさん
06/05/15 01:37:00
>>531
どんなときでも同じプログラムの速度差が2倍の比例関係にあるとは
限らないんだが。そんな単細胞みたいなワンパターンな
考え方しかできないからいつまでたってもJavaに飛び込むことができないんだよ。
Javaはレスポンス性能ではC++には劣るが、
スループット性能ではC++をはるかに上回る。
536:仕様書無しさん
06/05/15 01:37:47
>>532
CPU3GHz, メモリ2GBだが、Javaは十分速いぞ。
わざわざC++にリプレースする必要もない。
これがサーバアプリだったらなおさらC++に
リプレースするメリットなんて全くない。
537:仕様書無しさん
06/05/15 01:38:24
>>533
> ＞＞５２５
> 全てのOSで動作させないものほど、機種依存を高めて安定させるべき
全てのOSに対応させてどうする。
使いもしない古臭いOSにまでいちいち対応するニーズがどこにある。
538:仕様書無しさん
06/05/15 01:41:34
JavaのGUIは負荷が応答がなくなるのを何とかして欲しいんだが
539:仕様書無しさん
06/05/15 01:42:48
>>538
×負荷が
○負荷が高くなると
540:仕様書無しさん
06/05/15 01:58:59
たとえばどんなアプリ？
541:仕様書無しさん
06/05/15 02:24:58
＞Javaはレスポンス性能ではC++には劣るが、
＞スループット性能ではC++をはるかに上回る。
分かりやすく説明しておくれ。
542:仕様書無しさん
06/05/15 02:48:28
聞くまでも無くハッタリｗ
543:仕様書無しさん
06/05/15 06:56:33
ApacheがなぜJavaで出来てないのか考えたらわかりそうなものなのになｗ
544:仕様書無しさん
06/05/15 07:09:20
Javaで作られたサーバーって結構あるんだが。
545:仕様書無しさん
06/05/15 07:28:32
そして結構失敗してるな。
546:仕様書無しさん
06/05/15 07:42:33
YahooのサーバーがJavaなわけだが。
もとはLispだが。
547:仕様書無しさん
06/05/15 07:52:52
＞＞５３６
あ り え な い
548:仕様書無しさん
06/05/15 11:58:27
>>543
「開発が始まった当初、Java など存在していなかったから」以外の理由が？
549:仕様書無しさん
06/05/15 19:43:48
>>538
AWT-Thread以外からのデータ投入は、
キューイングしてかつ適当なインターバル開けてかつAWT-Threadに移譲してる。
それでも極まれに数十秒AWT-Threadが戻ってこないときがある。
awt と swing 整理して綺麗に書き直して欲しい。
550:仕様書無しさん
06/05/15 20:12:11
>>547
ありえない根拠は？
Javaの仕事とC++の仕事、どっちが
多いと思っているんだ？
551:仕様書無しさん
06/05/15 21:46:35
>>550
まぁC++使いこなせる奴がそういないからね。
552:仕様書無しさん
06/05/15 21:53:41
いや、そういう理由だけでC++の仕事が少ない分けじゃあないハズなんだが。
ヘッダファイルの扱い欠陥が管理のしづらさと言語としての使いにくさを決定的に
してC++の人気が減ったのではないかと思う。
553:仕様書無しさん
06/05/15 22:15:42
ヘッダファイルの扱い欠陥？何を言ってるんだ？池沼か
原因はそんな事じゃないだろ。 もっと単純な事だ
使いこなせる奴がいない
これだけだ
554:仕様書無しさん
06/05/15 22:20:43
マが低レベル化したからね。
昔は中高生が趣味でアセンブラ使ってたわけで。
555:仕様書無しさん
06/05/15 22:22:24
今日も元気に沸いてるお
556:仕様書無しさん
06/05/15 22:22:58
Javaの仕事が多いなら理由はJavaコンサルが大風呂敷広げてホラ吹きまくってそれが客にウケたからだ。
少なくとも技術的に良かったからではない。
557:仕様書無しさん
06/05/15 22:29:13
つーか、お前らJava嫌いなC言語厨の
コミュニケーション能力が弱いから顧客を
説得できないだけじゃねえのか？
そうとしか思えないのだが。
558:仕様書無しさん
06/05/15 22:38:27
いやプログラマの質の劣化が進んでるから（特に若年層） 抽象的でメモリリークなどの責任を他の要素に負わせやすく
また、開発環境もタダで出回っていて業務外で自習させられることも手伝って、Javaが伝搬してるってことだな。
伝染病末期の日和見感染みたいなもんだよ
559:仕様書無しさん
06/05/15 23:01:15
>>558の発言のどこに真実が隠されているのだろう・・・・・・・・・・
560:仕様書無しさん
06/05/15 23:25:31
この世にプログラム言語がJavaしかなかったとしよう。
この世の終りだ。
561:仕様書無しさん
06/05/15 23:56:06
そんだけ客が馬鹿になったというか、客が技術の移り変わりについていけなくなっている。
まぁいらん技術ばかりだったとしてもだ。
そんな世界でのコンサルってのは、説得力とかいらん。
技術者的善意があっては勤まらないものになってきている。
いや、中には素で自分は素晴らしいソリューションを提供しているのだと勘違いしているのもいるけど。
562:仕様書無しさん
06/05/15 23:58:36
JAVANUMAとか考えるとおぞましくて死にそう
563:仕様書無しさん
06/05/16 00:01:55
元々Windowsプログラミングができない人向けにSunが社内ツールとしてつくったのがJavaのはじまりだからね
564:仕様書無しさん
06/05/16 00:04:06
あのSUNの糞爺がお救い言語を開発しなければ世の中
間違ったほうにはいかなかった。
でもそろそろSUNは無くなる来期も赤字なら確実に消える
これはつまり暗く腐った臭気を漂わせていたJAVAから
我々が解放されることを意味している
565:仕様書無しさん
06/05/16 00:17:10
>564
大罪を犯したSunには消えて欲しいが、そうなるとM$の対抗馬が完全に消える
やりたい放題になるよ。。。
566:仕様書無しさん
06/05/16 00:19:07
みんなうそばっかしだね
567:仕様書無しさん
06/05/16 00:23:12
まぁノベルとか赤帽潰れたらWindowsでいくからそれはそれでいいよ
SUNは邪魔業界のゴミでしかない。
JAVAのコミュニティでVMが糞とかいうと凄い非難浴びるしな
会社でも同じ事言うがすげー顰蹙買う
568:仕様書無しさん
06/05/16 03:39:33
>>549
なるほど、勉強になった。
ありがとう。
569:仕様書無しさん
06/05/16 03:46:32
>>568
それでいいのか？
570:仕様書無しさん
06/05/16 05:56:53
Javaが人気出たのはEclipseが便利すぎるから。
571:仕様書無しさん
06/05/16 07:59:40
import java.awt.*;
import java.awt.event.*;
class baka1 extends WindowAdapter {
public static void main(String args[]) {
new baka1().start();
}
private void start() {
Dialog alert = new Dialog(new Frame() , "うるさい>>1は死ね");
alert.add(new Label("嘘つくな>>570も死ね"));
alert.setSize(300 , 150);
alert.setVisible(true);
alert.addWindowListener(this);
}
public void windowClosing(WindowEvent e) {
System.exit(0);
}
}
572:Mb
06/05/16 08:24:04
>>570
年寄りはeclipse 使わんほうがいい。
あれだけ楽だと早くボケが来る。
最近はeclipse 使わんとスペルミスばっかりで
コンパイルさえ通らん。
573:仕様書無しさん
06/05/16 09:03:02
>>569
今はJava系開発から離れてるからとりあえずいいよ
574:仕様書無しさん
06/05/16 14:09:12
>>535
正解
JavaでC以上のスピードを出すのはサーバーVMのときだけ
サーバーVMは強度の最適化のためにメモリとコンパイル速度が
通常のhotspotクライアントよりかかるためにレスポンスは悪い
上で出てたC++のコードとあわせるならプリミティブを登録するListにかえるべき
Javaのパフォーマンスチューニングは無料で使えるプロファイラで簡単にできるんだから
馬鹿でも最適化は容易だよ
575:仕様書無しさん
06/05/16 14:12:10
>>573
こんなのがJavaの技術者の平均レベルを下げている例
実際はできるやつはCだろうがJavaだろうが自分で勉強してなんでもこなす
すぐに調べれば分かるようなことをまったく理解しないまま進めるやつもいるからな
576:仕様書無しさん
06/05/16 14:27:02
>>575
だから開発してないっていってるじゃん
Java製アプリ使ってるだけだっつに
下二行は常識だろ
それこそ何の意味もない書き込みだ
577:仕様書無しさん
06/05/16 16:47:11
URLﾘﾝｸ(www.google.com)
578:仕様書無しさん
06/05/16 17:21:02
C++/CLI の登場、によるJavaの衰退はもう止まらないだろうね、、、
ECMA 標準に、そして ISO もまもなく、、、。
Standard ECMA-372 C++/CLI Language Specification
URLﾘﾝｸ(www.ecma-international.org)
URLﾘﾝｸ(signe.japan.webmatrixhosting.net)
Java房も下のコードを見れば、、
int main() {
System::Console::WriteLine("hello, world");
}
C++でネイティブ、.Net、他言語連携、、、、
全てが行え、かつ統一的なコーディングが可能である。
JavaもCLI配下になって生き残るのか。。。。？
579:仕様書無しさん
06/05/16 19:12:14
日本語でおけ
580:仕様書無しさん
06/05/16 19:25:58
MS-GW か。
581:仕様書無しさん
06/05/16 19:26:23
GW じゃねーよ GK だろ阿呆＞俺
582:仕様書無しさん
06/05/16 20:47:50
>>561
そう顔真っ赤になってまで必死になるな。
そんなに客が馬鹿だと思うなら
客を説得すればいいのにw
それすらできないからJavaのせいにして
「Javaは馬鹿でもできる言語だから仕事が多いんだ！」と
ファビョっているんだろC言語厨は。
C言語厨は実に商売が下手だなあw
583:仕様書無しさん
06/05/16 20:51:06
>>577
Javaのトレンドが圧倒的だね。
C#はちょっと伸びようとしているけど全然のびが悪い。
C++は全くグラフ上から姿を現さない。
584:仕様書無しさん
06/05/16 22:55:12
トレンドも何も・・・
585:仕様書無しさん
06/05/16 23:02:55
今Javaは上昇トレンドです
586:仕様書無しさん
06/05/16 23:18:24
>>574
アホか？
そもそもC++じゃそういうコード書くときにはvectorなんてちんたらしたもんは使わんだろ。
587:仕様書無しさん
06/05/16 23:21:26
>>586
それならJavaだって自前でかくわけだし同じだろ
そうなるとバブルソートじゃないけどCのほうが遅くなるかもね
>>583
Cだとかなりの数が出るからC++だとちと問題だと予想する
それでもTOPはJavaだが
588:仕様書無しさん
06/05/16 23:35:35
Javaは乱立していたUnix系OS上での共通基盤という意味があったのだが、残念ながら
Linuxの一人勝ちでその意味も薄れてしまった。
SolalisやAIX機はx86PCよりパフォーマンスがずっと優れており、VMに足を引っ張られても
問題ないってのがそもそもJavaの前提なんだな。
ところがx86の進化は留まるところをしらず、sparcはおろかalphaすら抜き去って最速になり
しかも低コスト。
対応すべきOSが集約してきたらC/C++で組めばいいだけのこと。
今やSolarisやAIXなんかは無視しても全然無問題で、LinuxとWin32でC/C++使えばそれでOKなのだ。
589:仕様書無しさん
06/05/16 23:37:51
こらこら死刑宣告をコピペするな。
590:仕様書無しさん
06/05/16 23:59:52
>>588
> Javaは乱立していたUnix系OS上での共通基盤という意味があったのだが、残念ながら
> Linuxの一人勝ちでその意味も薄れてしまった。
それでもJavaを使わないと。Windowsの各バージョンとLinuxの各バージョン毎にコンパイラやバイナリを
変える必要が出てくるんだがな。
> 対応すべきOSが集約してきたらC/C++で組めばいいだけのこと。
> 今やSolarisやAIXなんかは無視しても全然無問題で、LinuxとWin32でC/C++使えばそれでOKなのだ。
LinuxやWindowsでもバージョンやカーネルが異なる、APIが異なることで
コンパイラやバイナリを変えないと動かないものがあるのでJavaの必要性がないとは
まだまだ言い切れないぞ。
甘く見ていると、こういう結末が待っているぞ。
お前がC++で、あるソフトを作ったとする。10年経過した。
その間にOSは変わった。古いコンパイラでコンパイルしたバイナリが動かなくなった。
591:仕様書無しさん
06/05/17 00:00:39
Javaが速いとか言ってるやつはJavaしかやったこと無い奴なのかね？
そうだ、そうに違いない。
592:仕様書無しさん
06/05/17 00:01:06
新しいコンパイラを導入した。
10年前のソースコードをコンパイルできなくなった。
593:仕様書無しさん
06/05/17 00:02:21
そもそも10年たったらそんなソフト使わない。
企業も見切りをつける。
というかその間何度も新しいソフトを開発してるわなぁ。
594:仕様書無しさん
06/05/17 00:02:32
OSが乱立していた時代に別ﾌﾟﾗｯﾄﾎｰﾑ上で同じｱﾌﾟﾘを動かそうとしていて一応完成
したのがWindows。まあ結局ﾌﾟﾗｯﾄﾎｰﾑ自体同じになったわけだが。
あの頃屋根(マシン)の上に屋根(OS)乗っけるのは無駄だとおもったものだ。
OSなんぞメモリ管理さえしてりゃいいんだよと思ったものだ・・・。
で、そのメモリ管理さえ明け渡して、屋根の上の上に乗っけるようなJavaって
何だと当時思った。今でもそうだが。
Javaって結局だめだと思ったのは、所詮Javaはエミュでエミュはマシン環境に
依存しない位ガチガチにしなきゃいけなくて(クロック速度レベルまで)で、
ある程度あきらめないといけない。
Javaはそういった出来の良いエミュの定義踏み外しているのでだめぽ。
595:仕様書無しさん
06/05/17 00:03:07
さらに10年経過した。新たなOSが生まれた。
それどころか、新たなCPUが生まれた。
20年前のC++ソースコードは使い物にならなくなり、
現在の環境に対応させるために何100兆円もの予算
をかけなければならなくなった。
(これは、都庁を修理するのに一から立て直すのと同じくらい
コストがかかってしまう問題に似ているな。実に。)
596:仕様書無しさん
06/05/17 00:04:33
20年前に作ったchar*の文字列操作俺様ライブラリを今でも使っていますが。
597:仕様書無しさん
06/05/17 00:05:59
新世代VMを導入した。
１年前のバイトコードが動かなくなった。
598:仕様書無しさん
06/05/17 00:08:56
50年後、量子コンピュータが実用化された。
今までのソースコードはすべて役に立たなくなった。
C++で記述されたソースコードの量子コンピュータに
対応させるためのリプレースは莫大なコストがかることがわかった。
一方、Javaで記述されたソースコードはJVMを
量子コンピュータに対応させるだけでJavaソースコード全般を
修正する必要はなかった。そのためコストはC++よりもかからず、
C++しかできなかった者達はマスケット銃が発明されて衰退していった
騎士達のように悲惨な運命を辿っていった。
>>593
訂正コストというものを解っていないな。
世の中には何百年経っても難なく利用されている建造物が
いくつも存在する。
ところが、あの都庁のザマは一体なんだ？ まさにC++だけで作った建造物だ。
もうあの建物も持たないぞ。あの建物は短命で、早い時期に死ぬ。
あれだけ無駄にお金をかけておきながら。
599:仕様書無しさん
06/05/17 00:10:02
やねうらおの匂いがする。
600:仕様書無しさん
06/05/17 00:17:11
そんな例出していいのか？
＞JVMを量子コンピュータに対応させるだけで
ここの部分はJavaじゃ書けないぞ？
601:仕様書無しさん
06/05/17 00:19:47
考えて見りゃJVMがC++のバイナリである以上、Javaも共崩れだな。
602:仕様書無しさん
06/05/17 00:20:15
んな早いコンピュータできたらJVMじゃなくてx86VMつくればいいだけだっぺよ。
603:仕様書無しさん
06/05/17 00:20:41
>>597
ﾌﾛﾇ
604:仕様書無しさん
06/05/17 00:23:58
>>598
現時点で10年以上前からあり一度も手直しされていない今でも現役なソフトを教えてください。
骨董品や建造物のような概念持ち込まれてもね。
605:仕様書無しさん
06/05/17 00:26:25
SesserではPojoとJunitのみがJavaの資産であるといってたからな、、、
いまはCが最も汎用的な言語であり、C++/CLIが今後の主流だろうね
JavaですらCLIあれば吸収できるし
606:仕様書無しさん
06/05/17 00:29:48
おじゃばさまは自分らだけじゃ生きていけない事を肝に銘じとかなければいけない
607:仕様書無しさん
06/05/17 01:04:22
>>598
お前なかななセンスあるな
608:仕様書無しさん
06/05/17 01:07:09
自作自演ｷﾀｰ
609:仕様書無しさん
06/05/17 01:27:51
50年後、量子コンピュータが実用化された。
今までのソースコードはすべて役に立たなくなった。
C++で記述されたソースコードの量子コンピュータに
対応させるためのリプレースは莫大なコストがかることがわかった。
一方、Javaで記述されたソースコードはJVMを
量子コンピュータに対応させるだけでJavaソースコード全般を
修正する必要はなかった。そのためコストはC++よりもかからず、
C++しかできなかった者達はマスケット銃が発明されて衰退していった
騎士達のように悲惨な運命を辿っていった。
その後・・・ソースコードを修正する必要がないので、
牢獄につながれていたJava奴隷も晴れて捨てられた。
一部は結合テスト要員としてその姿を見かけたが、
殆どが悲惨な運命を辿っていったと言う。
610:仕様書無しさん
06/05/17 03:01:25
いい加減飽きた
611:仕様書無しさん
06/05/17 03:31:19
>>604
URLﾘﾝｸ(www.vector.co.jp)
612:仕様書無しさん
06/05/17 03:33:06
>>609
だれにも指示されないネガティブキャンペーン乙
やねうらお信者の馬鹿共が書いたおとぎ話ですかw
613:仕様書無しさん
06/05/17 07:48:13
おじゃばさま乙
614:仕様書無しさん
06/05/17 10:21:24
おじゃばさまはJVMの中の人の苦労は完全に計算外なんだな。
615:仕様書無しさん
06/05/17 12:20:35
JVMの開発のことは計算に入れているだろ。
だが、Javaで書いても問題が無いものをわざわざC++で書こうと
する馬鹿の言うことなどもちろん計算外だがなw
616:仕様書無しさん
06/05/17 13:52:06
>>615
そうか？
＞Javaで記述されたソースコードはJVMを量子コンピュータに対応させるだけで
一言で片付けてるけど、これは誰がやるんだ？
617:仕様書無しさん
06/05/17 13:54:57
ジェバンニ
618:仕様書無しさん
06/05/17 14:02:06
量子コンピュータにJVMを対応しても、量子コンピュータは得意な
計算領域が違うんだからそれにあわせた言語設計をして、
その言語を用いて一から組んだほうが良いんじゃないのか？
じゃないと、以前のバイトコードを量子コンピュータで実行できたからって、
VMがもの凄いボトルネックになりそうなんだが。
まぁ、量子コンピュータも言語の知識もあまり無い俺の妄想だが。
619:仕様書無しさん
06/05/17 15:08:06
>>616
C++をスコップ、
JVMをある高機能なクレーンだとしよう。
このクレーンを使わずC++スコップだけで超高層ビルを
建設することはできなくもないかもしれないがw、
非常にコストと時間がかかる。
そこでJVMクレーンを導入すると超高層ビルを
建設することは容易になるというわけだ。
武器や炎(JVM)を持ったサル(Javaソフトウェア)と武器を持たない、
火興しもできないサル(C++ソフトウェア)、
どちらが強いと思う？
武器を持てば、確かに重たくなって動きは鈍る。
だが敵を容易に倒せるようになるわけだ。
賢くなると敵も武器(JVM)を使うようになるが。
(それが今日の人類を形成しているわけで)
「武器(Java VM)を持たない方が(C++は)強い、刀で戦うだけでアメリカに勝てる」
だなんてまるで旧日本陸軍なんだよ。
620:仕様書無しさん
06/05/17 15:10:23
>>618
確かに、if文やループ文、boolean型など
若干変化が起こりそうだけどな。
変化というより、追加となるかな。
プログラミング言語は自然言語に近づこうとしているので
新しいプログラミング言語がJavaのような言語に近づくのは
自然な前進ともいえるがね。
その中でC++やC#、Perl, PHPやLisp、アセンブラのような言語もJavaとは
違う方向から進化してゆくものだけどね。
621:仕様書無しさん
06/05/17 15:28:18
たとえ話のセンスがない上にむちゃくちゃで話にならないな。
頭おかしいのか？
Javaは図書カードのようなもの。本屋と金券屋しか扱えない。
図書流通業界つう狭い業界でしか通用しない。基本換金できないし、加盟店でしか扱えない。
JVMは日本図書流通（株）みたいなもんだよ。ここが現金と交換しないと無意味。
他のネイティブ言語で扱ってるのは、現金そのもの。
俺もセンスないわｗ
622:仕様書無しさん
06/05/17 15:31:50
あ！思いついたわ。
Javaのバイトコードは旧日本軍が発行してた軍票のようなもの。
軍隊が威勢がいいうちはお金の代わりに使えたが、まけたとたんに紙切れ。
JVMは旧陸軍みたいなもんだな。
ネイティブのコードは、国が認証した中央銀行が発行した通貨。
プロセッサ＋OSが国家みたいなもんだろ。
親亀の背中に小亀を乗せて～
623:仕様書無しさん
06/05/17 16:04:46
JAVAよぉ～
なんだかんだでバージョン合ってないと動かなかったりするだろ・・・・
624:仕様書無しさん
06/05/17 16:20:16
>>621
いや、お前のほうが頭がおかしいw
625:仕様書無しさん
06/05/17 16:21:13
>>622
>>619にC++狂信者を旧日本軍扱いされたからといって
そうカリカリするなよw
626:仕様書無しさん
06/05/17 16:23:48
>>619
いや、その強力なJVM自体を作るのにC++屋さんの協力が必要だと言ってるのだが。
なんか話がかみ合ってないな。
627:仕様書無しさん
06/05/17 16:34:26
しかし、旧日本軍などという連中が皇軍を貶める売国奴である件に関しては語らないのか？
628:仕様書無しさん
06/05/17 16:37:01
うっせー
629:仕様書無しさん
06/05/17 16:47:55
太平洋戦争はもうとっくに終わったのだよ。
アメリカが勝利下のさ。
630:仕様書無しさん
06/05/17 16:48:55
黒船来航からの１００年戦争はまだ終わってないと思うが？
631:仕様書無しさん
06/05/17 16:56:51
あれからすでに100年以上経っているんだけど
632:仕様書無しさん
06/05/17 16:59:11
つまり、おまいは自分は皇軍の輝かしい歴史に連なる大和民族ではないと？
633:仕様書無しさん
06/05/17 18:39:32
>>632は朝鮮人ですか？
634:仕様書無しさん
06/05/17 21:27:17
>>619
意味わかんねぇよ。
何でJavaがクレーンでC++がスコップなんだよ？
っていうか、>>616の問いの答えになってねえよ。
635:仕様書無しさん
06/05/17 22:04:03
JAVA厨は頭の中が回転してないから支離滅裂の事しか言えないんだよ。許してあげて。
636:仕様書無しさん
06/05/17 22:40:41
C言語厨は頭の中が回転してないからコミュニケーション能力が欠如して
人の話を聞かずに勝手に独断で話を先に進めてかつ支離滅裂の事しか言えないんだよ。許してあげて。
637:仕様書無しさん
06/05/17 23:23:27
>>636
これが噂のJava厨か。
頭の回転とコミュニケーション能力がどう関係しているのか説明してもらいたいな。
638:仕様書無しさん
06/05/17 23:26:20
大体、スコップとクレーンってどういう脳の構造で比較するんだよ。
スコップ：ショベルカー
滑車：クレーン車
これならわかるけど。頭やっぱり壊れてるんじゃないの？おじゃばさまって。
639:仕様書無しさん
06/05/17 23:31:06
>>636のおじゃばさまの書き込みは相手より中傷する言葉の数を上回ることにより優越感を見出している。
やっぱりアホだね。
640:仕様書無しさん
06/05/18 01:06:30
中傷している時点でもC厨もアホだかな。
641:仕様書無しさん
06/05/18 01:31:02
Java厨に中傷することはアホではない
642:仕様書無しさん
06/05/18 01:32:04
Java厨を だな。日本語まともに使えない俺はアホだな
643:仕様書無しさん
06/05/18 01:32:14
>>641
お前、狂ってきているぞw
もうｱﾙｶｲｰﾀﾞみたいなw
「アメリカ人を殺せば100ドルあげるよw」みたいな
644:仕様書無しさん
06/05/18 07:50:21
SesserではPojoとJunitのみがJavaの資産であると
645:仕様書無しさん
06/05/18 08:34:58
sesserて書いてあるのを見ると
akiraのﾗｯｾｰﾗていう音楽を思い出す
646:仕様書無しさん
06/05/18 10:43:14
今C++の価値なんてもうかなり薄れている。
これもインターネットが出て、Perl/CGIが出てから
スタンドアロンアプリの価値が薄まったため。
そこへJava ServletがさらにC++に止めを刺す状況になった。
今C++は組み込み系やJVM開発など細々とした分野でしか
生き残る術が無くなってしまった。
今C++を推し薦める者の大多数はただのマニアや生産性の無いオタクだけである。
647:仕様書無しさん
06/05/18 10:46:05
>>634
Javaを武器を持ったサルや火おこしを使えるようになったサル、
C++を武器も火おこしも使えないサルに喩えている例もわかりやすいんじゃないかな。
648:仕様書無しさん
06/05/18 10:52:37
その例えで言うなら
武器と火を使いこなす一部のC++人間に支配されるJava猿、
の方が正しくね？
649:仕様書無しさん
06/05/18 10:55:01
>>647
いやむしろ、観光地で自らが作り出した工業製品を使う人類（多言語使用者）と
群がってきて勝手に車に入り込んでお菓子などを盗んでいく猿（Java厨）の差なのでは・・
650:仕様書無しさん
06/05/18 10:57:20
JVMを取り上げたら何もできないJava猿。
そいつらにJVMを作って与えたC++。
C++は神なのか？
JVMを作れる新しい言語が出てきたとして、それはJavaではないのは自明だわな。
651:仕様書無しさん
06/05/18 11:22:46
C++ 面倒な仕事を安い賃金で引き受ける中国の企業
Java 中国から安く仕入れた材料で製品を作る日本の企業
652:仕様書無しさん
06/05/18 11:52:25
C++ コア技術を擁し大もうけするM$様＆Inteｌ様
Java 秋葉原の裏道で箱に詰めて売り出すショップ
653:仕様書無しさん
06/05/18 15:49:58
>>648-652
てか、なんでお前ってそんなにJavaを目の敵にしているんだ。
一人で妄想に任せた連続投稿を繰り返して
すごい私怨の塊だなw
654:仕様書無しさん
06/05/18 16:01:35
ここまでJava嫌いな奴ってどうにかしておるで。
まあC++をマンセーしているようだけども
実際にはC++のCの字すら使いこなせない低脳さんなんでしょうな。
655:仕様書無しさん
06/05/18 16:10:02
この板、人が少ないから連投するとすぐわかるよな
656:仕様書無しさん
06/05/18 16:24:07
それにしても、彼はなぜJavaが嫌いなんでしょう？
657:仕様書無しさん
06/05/18 16:33:32
いかさま連投でっち上げ乙。
ジャバジャバあふれる低脳乙。
いいかおまいら。
コンピュータシステムはうざい。まんどいものなんだよ。
そのまんどくさい程度をさらにぐぐっ！と跳ね上げるじゃば。
うざいうざいうざいうざすぎる。
658:仕様書無しさん
06/05/18 16:36:28
はいはいわろすわろす
いかさま連投でっち上げ乙。
C言語C言語あふれる低脳乙。
いいかおまいら。
コンピュータシステムはうざい。まんどいものなんだよ。
そのまんどくさい程度をさらにぐぐっ！と跳ね上げるじゃば。
うざいうざいうざいうざすぎる。
659:仕様書無しさん
06/05/18 18:00:21
おい、1箇所修正漏れてないか？
660:仕様書無しさん
06/05/18 18:15:05
お得意のリファクタリングにまかせるんでしょ
661:仕様書無しさん
06/05/18 20:39:29
くだらん
662:仕様書無しさん
06/05/18 21:12:33
発注先に、使ってるJVMの外部仕様書まで要求したら目を回していた。
「おたくはJVM部分の保守はしないってことか？」と怒鳴ったら泣き出した。
今は反省している。
663:仕様書無しさん
06/05/18 21:14:26
じゃばうざい
[ﾟдﾟ]
/[＿]ヽ
| | リファクタリングかんりょうしますた
664:仕様書無しさん
06/05/18 21:46:08
>>662
それはたんに>>662の頭が弱いだけではないかと。
君は必死になっていつもネタを考えているようだけど、
君が作り話をしてもまず受けないし。
自作自演で自画自賛するだけでしょw
665:仕様書無しさん
06/05/18 21:48:07
なぜ改行が多いのですか
JAVAのひとはそうなんですか
666:仕様書無しさん
06/05/18 21:49:15
C++の人はどうなんですか。
ソースファイルの末端に改行を入れないのですか
あーそーですか
667:仕様書無しさん
06/05/18 23:41:52
JAVA房さ、リファクタリンとか騒ぐなら
お前の人生リファクタリングしたほうがいいぞ
日本以外じゃJAVA＝上級スクリプト系言語
レベルの扱いだぞｗ
668:仕様書無しさん
06/05/18 23:50:19
Java房から教わった、あのとき2chで始めて知った「リファクタリング」という言葉に
毒づいて根に持っているのかC言語厨w
っていうかC++厨をJava厨にリファクタリングしたほうがいいぞ。
そうすればC++厨も職にあぶれる心配もなくなる。
アメリカじゃCだけしか知らないんでは仕事も無いぞw
669:仕様書無しさん
06/05/18 23:52:39
ここはジャパンデース
670:仕様書無しさん
06/05/18 23:53:01
何回も思うんだが、お前日本語おかしい。
２ちゃん用語（２典とかな）でも見ながら書いてる第三国人の方ですか？
671:仕様書無しさん
06/05/19 00:02:16
じゃ、お前は第四国人ですかね
672:仕様書無しさん
06/05/19 00:06:28
あたまのねじが・・・
おじゃば・・・
カワイソス
673:仕様書無しさん
06/05/19 00:25:58
そもそもC言語厨ってなんでそんなに頭が悪いの？
674:仕様書無しさん
06/05/19 00:27:11
C言語厨の頭のネジをはずし
カバーをはずし
Javaチップ埋め込み手術
C言語厨の歪んだ人格が補正された！
675:仕様書無しさん
06/05/19 00:27:25
ぐー
676:仕様書無しさん
06/05/19 00:28:08
うちの会社にC++使いがやってきた。
Javaは扱ったことが無いと言うので私は得意げにJavaを教えてやろうとしました。
しかし次の日、そいつは普通にJavaを使いこなしていました。
そいつ 「Java？こんなの使えるようになるのに1日も必要ないね」
如何にJava使いは上辺だけの知識しかないということが分かりました。
677:仕様書無しさん
06/05/19 00:30:44
いつも一人でJavaに粘着しているC言語厨は
一体どんな僻みを持っているのでしょうか
678:仕様書無しさん
06/05/19 00:31:22
>>676
ネタだよね。
JavaとC++とを置き換え他方がいいんでね？
679:仕様書無しさん
06/05/19 01:05:36
ライブラリ使わせてもらって組んでるだけのクセに偉そうですよね。みんな。
680:仕様書無しさん
06/05/19 01:21:39
じゃ、Javaのライブラリ使わせて貰っているJakarta は？
681:仕様書無しさん
06/05/19 01:25:26
っていうかC言語厨がJava厨に言いがかりつけるのは
アセンブラ厨がC言語厨に言いがかりつけるのと同じ事やね。
エレキのハード屋がアセンブラソフト屋に言いがかりをつけるのと同じ
ともいえるし。
メカ屋がエレキ屋に言いがかりをつけるのと同じともいえるね。
昔の人間ほど新しいものに対する変化が弱く、恐れ、
なんとかして保身に走ろうとする。
そう、C言語厨は「変化ヲ抱擁セヨ」がなっていない人たちなのだ。
もう老人なのだよ。彼らは。
「最近のわかいもんは冷房なんかつけて贅沢しおって！私が若い頃は
冷房なんかなかったんだぞ！」とよく後輩に逆ギレをするのがC言語厨なのである。
682:仕様書無しさん
06/05/19 06:41:58
ふと想った。
Javaの言語仕様そのままでexeを作れるようになれば、
Windowsプログラムに関して言えば、
C/C++のWin32API利用なんかよりも開発速度が上がる気がする。
データ容量などの多少の犠牲があるにしても、
それを補っても費用対効果が上昇するのでは無いかなぁ。
以上、便所の落書きでした。
683:仕様書無しさん
06/05/19 07:06:29
ずっとよんだけどさ。
やっぱしあたまわるいね。おじゃばくん。
とくに>>682
おまえ、最近のLinuxいじってないだろ。
GCJもしらないんだな。
ぷろぐらまのふりはもういいから
おなにーしてねなさい。
684:仕様書無しさん
06/05/19 07:37:06
なんつーか、Java厨って、世間で言うところのオタクに見えるんだよね。
オブジェクト指向とかこっちにとっては知識のかけらでしかないのに、
Java厨にとっては世界の全てと思っているように見えてしまって興ざめする。
オタクよろしくオブジェクト指向の話しかしないしさ。
685:仕様書無しさん
06/05/19 08:44:52
サービスを作成するにはRFC仕様をじっくりと検討し
OSのAPIで実現可能か調査しセキュリティ実装の検討をし
その他もろもろの仕様検討をしクラスに落として行く。
OSとかRFC仕様とか多種多様な要件をひとつにまとめあげるスキルが必要
なんだけど、Java厨さんの場合は単純にクラスだぜ！すげえだろう
って浅く薄い発言しかできないのが気にかかるかな。
686:仕様書無しさん
06/05/19 08:47:14
下請は余計なことを悩まなくていいよ。
687:仕様書無しさん
06/05/19 11:05:28
>>668
>C++厨をJava厨にリファクタリングしたほうがいいぞ。
お前も、自分が何言ってるのかくらい認識したほうがいい。
知らない単語も使わないほうがいいな。
>>678
>JavaとC++とを置き換え他方がいいんでね？
成立しない。
C++ を「使いこなす」には、あの泥臭い仕様を理解しなければならないわけで。
…いや、理解していなくても「こんなの使えるようになるのに1日も必要ないね」
と言い放つ阿呆は確かに存在するが。
688:仕様書無しさん
06/05/19 16:55:19
Javaに欲しいものを思い出した。
1. 値としてのObject (コピーコンストラクタや代入演算子そして値としてのObject渡し)
実際使うかどうかはわかんないけど、言語としてね・・・
2. const (言われてみりゃ欲しい)
3. コンストラクタからメソッドを呼び出したときに派生クラスのオーバーライドメソッドを呼び出さないで。
これはどう考えてもC++が正解 (少なくとも1.3のときはこんな動作だった)
689:仕様書無しさん
06/05/19 18:32:23
>>683
ATL/WTL 後CLI がそれだ
Javaを使うひつようはない
690:仕様書無しさん
06/05/19 23:10:05
>>682
それだったら既にあるんだが。
691:仕様書無しさん
06/05/19 23:11:19
>>684
そうか？ C言語厨のほうがオタクに
見えるんだけどね。
金にもならない癖にC/C++マンセーするなんて
生産性の無い馬鹿のやることじゃん。
しかもオタクよろしくガンダムの話しかしないしさ。
692:仕様書無しさん
06/05/19 23:14:28
>>688
> Javaに欲しいものを思い出した。
> 1. 値としてのObject (コピーコンストラクタや代入演算子そして値としてのObject渡し)
> 実際使うかどうかはわかんないけど、言語としてね・・・
CloneableインタフェースとObject#clone()で代用すればいいことをなぜそんなに欲しがる。
> 2. const (言われてみりゃ欲しい)
static finalがあるからそういう無駄なものは不要。
> 3. コンストラクタからメソッドを呼び出したときに派生クラスのオーバーライドメソッドを呼び出さないで。
> これはどう考えてもC++が正解 (少なくとも1.3のときはこんな動作だった)
なぜそういう仕組みにしないといけないのか？、また、そうなった場合の対応方法について
知りたければ「Effective Java」、「Javaの鉄則」を読め。
693:仕様書無しさん
06/05/19 23:15:04
>>685
アセンブラ厨がC言語厨に零した愚痴にそっくりだな
694:仕様書無しさん
06/05/19 23:21:11
アセンブリ言語→アセンブル→実行形式バイナリ
C言語→コンパイル→実行形式バイナリ
Java言語→コンパイル→バイトコード
695:仕様書無しさん
06/05/19 23:24:06
しかしあれだな。Javaバカ、オブジェクト指向原理主義バカもすっかり減ったよね。
696:>>688じゃないけど
06/05/19 23:24:28
>>692
> 1
clone()は使いにくい。
> 2は同意
> 3
保守とかやってると、そういう仕組みの方が都合が良い事がある。
697:仕様書無しさん
06/05/19 23:35:49
たかがOOが銀の弾丸ならこの業界も苦労しない罠。
698:仕様書無しさん
06/05/19 23:54:13
OOすれば再利用性が高まる…そんな風に考えていた時期が、俺にもありました。
699:仕様書無しさん
06/05/19 23:55:30
そうそう。狼男のつもりでいたらヴァンパイアだったりするからな
700:仕様書無しさん
06/05/19 23:57:43
ビジネスロジックを書くのに最強の再利用手段は
コピペだ。
いやマジで。
701:仕様書無しさん
06/05/19 23:59:03
cloneがObjectのメソッドでマーキングインターフェイスで
サポートしていないクラスの場合は例外をスローするという
嫌がれせとしか思えない糞仕様を設計したやつはだれですか。
702:仕様書無しさん
06/05/20 00:16:09
「C」にしろ「Java」にしろ、仕事によって使い分けてりゃいいんでない？
言語もツールだろ？
画像処理の高速化に、アセンブラを使うようなものでないのかい？
703:仕様書無しさん
06/05/20 00:18:46
1. については、「値」のほうが便利な場合があるから。例えば再帰呼び出し。
すべてのObjectがImmutableだったらclone()一本やりでも筋は通るけどね。
代わりにせめてassign()、equals() の標準インターフェイス
2. C++でメソッドや引数につける const の事を指している。(説明不足だったな)
3. 対応(あるいはノウハウ)の必要性は少ないほうがよくないか？
704:仕様書無しさん
06/05/20 00:42:27
あっequals()はObjectで定義だったな。(ハズイ
705:仕様書無しさん
06/05/20 00:43:21
ジャバカ
706:仕様書無しさん
06/05/20 00:46:52
>>696
お前はそこいらで適当にJavaの愚痴を有ること無いこと
書いてる馬鹿と違ってまともそうな発言をしているのでレスしよう。
> >>692
> > 1
> clone()は使いにくい。
どう使いにくい？ clone()と長く書くことが苦痛か？
clone()のオーバーライドが面倒か？
それと、不変クラスを定義した場合、clone()のオーバーライドは不要。
clone()の定義が面倒か？
> > 2は同意
> > 3
> 保守とかやってると、そういう仕組みの方が都合が良い事がある。
それはお前のスキルに問題があるといいたいが、
IDEで補う事が可能。
707:仕様書無しさん
06/05/20 00:47:30
>>701
C#にも似たようなものが(ry
708:仕様書無しさん
06/05/20 00:53:37
今度のjavaのオプションにハイフンdqnが付くみたいだね
709:仕様書無しさん
06/05/20 00:57:37
>>706
コピーしたいだけなのにいちいちオーバーライドするのは面倒。
まぁ、慣れの問題だとは思うが。
710:仕様書無しさん
06/05/20 00:57:48
>>703
> 1. については、「値」のほうが便利な場合があるから。例えば再帰呼び出し。
> すべてのObjectがImmutableだったらclone()一本やりでも筋は通るけどね。
> 代わりにせめてassign()、equals() の標準インターフェイス
IDE使え。
> 2. C++でメソッドや引数につける const の事を指している。(説明不足だったな)
前者ではフィールドをfinalにしろ。
後者では引数にfinal指定をすればいいだけの話だ。
> 3. 対応(あるいはノウハウ)の必要性は少ないほうがよくないか？
既に少ない。C++と比べたら楽な門だ。
711:仕様書無しさん
06/05/20 00:58:33
cloneは何のためにある？
共通のインターフェイスとしてクローンという機能を提供するためのはずだ。
そうじゃないなら、勝手にcloneメソッドを各クラスが提供すればいいだけの話。
なら共通のセマンティックをサポートするために、不変クラスでもcloneは必要のはずだ。
で、なんでcloneがObjectのメソッドになってるのか理解できないんだよね。
上記目的をサポートするためだけなら、Cloneableにcloneメソッドがあればいい。
何もわざわざObjectレベルで付けて、しかもサポートしないときには例外なんて
おかしなことをする必要は無いはず。
まあそれ以前にclone自体が単純にいまいち使いにくいけどね。
※別にJavaに限った話ではなくてC#とかでも同じだが。
712:仕様書無しさん
06/05/20 01:00:11
>>709
クラスの定義に応じて深いクローニングや浅いクローニングを
指定する必要があるのにそれはないだろう。
それは急ぎたいのに信号無視したいといってるのと同じだぞ。
713:仕様書無しさん
06/05/20 01:01:20
>>711
> cloneは何のためにある？
> 共通のインターフェイスとしてクローンという機能を提供するためのはずだ。
> そうじゃないなら、勝手にcloneメソッドを各クラスが提供すればいいだけの話。
> なら共通のセマンティックをサポートするために、不変クラスでもcloneは必要のはずだ。
> で、なんでcloneがObjectのメソッドになってるのか理解できないんだよね。
それについてもEffectiveJava に書いてある。
> 上記目的をサポートするためだけなら、Cloneableにcloneメソッドがあればいい。
そうすると新たな問題が生まれる。
714:仕様書無しさん
06/05/20 01:02:05
>>703
> 1. については、「値」のほうが便利な場合があるから。例えば再帰呼び出し。
> すべてのObjectがImmutableだったらclone()一本やりでも筋は通るけどね。
> 代わりにせめてassign()、equals() の標準インターフェイス
assign()が何をアサインするメソッドなのか？
715:仕様書無しさん
06/05/20 01:02:28
>>702
今Cの仕事が減っているからねえ。
どうなんだか
716:仕様書無しさん
06/05/20 01:04:18
>>701
> cloneがObjectのメソッドでマーキングインターフェイスで
> サポートしていないクラスの場合は例外をスローするという
> 嫌がれせとしか思えない糞仕様を設計したやつはだれですか。
お前はクローニングについてかなり勉強不足。
そこでJavaを批判する前にまずJavaを基礎から勉強し直して出直してこい。
717:仕様書無しさん
06/05/20 01:04:45
>>700
マジレスするにしても痛い。
勉強不足。
718:仕様書無しさん
06/05/20 01:05:14
>>695
速度原理主義なC言語厨もどうにかしてると思うが
719:仕様書無しさん
06/05/20 01:07:42
>>717
学生乙
720:仕様書無しさん
06/05/20 01:09:36
>>712
> それは急ぎたいのに信号無視したいといってるのと同じだぞ。
意味が分かりません。
721:仕様書無しさん
06/05/20 01:11:37
ナイス突込
722:仕様書無しさん
06/05/20 01:15:32
>>716
それは同一クラスのインスタンスを作るという目的のこと？
それとも別の理由？
Object.cloneに当たる機能は別（出なくてもいいかも知れんけど）もってて
Cloneableにcloneがあるのではなぜいけない？
723:仕様書無しさん
06/05/20 01:18:54
このスレのC言語厨は論理的思考能力が無いアホばかりだろ。
発言一つ一つに根拠無いものばかりでな。
ようするに連中は頭がおかしいだけなんだよ
724:仕様書無しさん
06/05/20 01:19:59
>>722
それがCloneNotSupportedExceptionとどう関係有るんだ
725:仕様書無しさん
06/05/20 01:20:03
>>715
Javaのスレだったな。
じゃあ『C#』あたりで…ノシ
726:仕様書無しさん
06/05/20 01:25:00
>>723
オ マ エ モ ナ ー
とでも言って欲しいのか？
727:仕様書無しさん
06/05/20 01:25:53
C#の仕事も少ないんだなー
728:仕様書無しさん
06/05/20 01:38:07
ちょっと質問。
よくcloneメソッドをpublicなメソッドに
オーバーライドして云々て記述を見るんだけど、
これってオーバーライドしてるんじゃなくて、
正確にはオーバーロードに当たる？
729:仕様書無しさん
06/05/20 01:39:59
>>727
そ。
じゃあ『Java』で…って、そういう事いいたかったんじゃないぽw
730:仕様書無しさん
06/05/20 03:21:15
>>710
final は参照変数の不変を指示するだけで参照されてるObjectの不変の指示じゃないよ。意味が違う。
まぁ実のところネタとして理想論みたいなのをいってるだけで実用上特に問題とは思ってないよ。
だからIDE云々というのもちょっと俺にとっては的はずれ。文法レベルでという話ね。
>>714
同一クラスおよびその派生クラスの代入という意味ね。元ネタは>>688
>>728
ちょwwwおまっwww オーバーライドで正解。
オーバーロードは引数が違う場合じゃあるまいか。
731:仕様書無しさん
06/05/20 03:28:39
あっ一個忘れた
>>712
浅いコピーデフォルトでいいじゃん。
比較対照としては適切じゃないけどC++ のデフォルトの operator= はいい仕事するよ。
732:仕様書無しさん
06/05/20 03:51:43
悪い。思い残しがないように(?)もう一個だけ。
>>710
>> 2. C++でメソッドや引数につける const の事を指している。(説明不足だったな)
>前者ではフィールドをfinalにしろ。
いまいち意味がわからない。メソッド単位にObjectを変更するかしないかを指定したいのだが。
全メソッドがconstなら結果としてImmutable Objectとなるおまけも付いてくるよ。
733:仕様書無しさん
06/05/20 08:53:54
ストールマン氏は、「Java Trap」（Javaの罠）と題された論文の中で、こういったオープン
ソースプロジェクトでJavaを使うことに対する批判を展開している。
「SunのJavaプラットフォーム上でJavaプログラムを開発すれば、無意識にSun独自の
機能を利用しがちである。気づいたときには、もう何カ月もその機能を使っていて、プログ
ラムを書き直すのに、さらに多くの月日がかかるという可能性もある。『最初からやり直す
のは大変だ』ということになるわけだ。あなたのプログラムは“Javaの罠”に落ちたのである。
そのプログラムはフリーソフトウェアの世界では使えないのだ」とストールマン氏は記している。
ストール万はこんなことを言ってるようだけど、C/C++信者はストール万の批判を鵜呑みにして
Javaを批判しているんだね。
2chで批判するときは事実を歪曲して批判しているようだけど。