JavaをなめてかかっているC/C++厨は頭が悪い

1 ：仕様書無しさん：04/07/12 10:59

ポインタ演算ごときの有無でJavaをなめてかかっているC/C++厨諸君。
ポインタ演算でミス、バグを出さない自身が本当にあるのかね？
ポインタ演算を駆使することが賢い選択だと思うのかね？

ポインタ演算のことをポインタと一緒に扱い「Javaにはポインタがない」とデマを言い張るC厨諸君、
そんなに自分が凄いかね？ポインタ演算を使いこなすことがプロのプログラマと勘違いしていないか？
いまやもはやそんな時代は終わったのだよ。

2 ：仕様書無しさん：04/07/12 11:01

自身の2get

3 ：69式フリーPG ◆hND3Lufios ：04/07/12 11:01

２げっと

4 ：仕様書無しさん：04/07/12 11:02

JavaWorldが廃刊になったからって糞スレ立てないでください

5 ：仕様書無しさん：04/07/12 11:10

んじゃあ今までC/C++の雑誌がいくつ廃刊になったんだい？

6 ：仕様書無しさん：04/07/12 11:13

正直、もう C は使いたくない。　C++ なら、機会があれば使いたい。

7 ：仕様書無しさん：04/07/12 11:13

C専用雑誌ってどんなのがあったっけ？
Cマガは違うし。

8 ：仕様書無しさん：04/07/12 11:13

なぁ、JavaとCの違いをわざわざスレ立ててまで語るのに、
ポインタを挙げる>>1って、バカ？

9 ：仕様書無しさん：04/07/12 11:15

国内ではビレッジセンターのC Users Journalぐらいかな

SIGSのC++ Reportはいつごろ廃刊になったんだろ

10 ：仕様書無しさん：04/07/12 11:15

ポインタ演算ごときでタカをくくってJava勉強しようとしないヴァカなC厨に喝をいれようとしているのです。
このまま喝を入れなければ彼らはいつまでもバグメーカーのままで他人に迷惑をかけるでしょう。

11 ：仕様書無しさん：04/07/12 11:16

先生、Ｃ厨を教育してください！

12 ：仕様書無しさん：04/07/12 11:16

　 ∧＿∧ 　　
　（　´∀｀）＜　Javaにはポインタがない

13 ：仕様書無しさん：04/07/12 11:17

先生、C++ができるといってCしかできないC厨がJavaを馬鹿にしています。
このままではオブジェクト指向を駆使したソフトウェア開発が阻害され
汚いソースコードが世にいつまでも流出し続けます。
先生、C厨をオブジェクト指向教育をしてください。

14 ：仕様書無しさん：04/07/12 11:18

>>12
否。あるよ

15 ：仕様書無しさん：04/07/12 11:20

汚いソースコードは言語によってではなく
未熟なあるいは極端に値切られたプログラマによって
作られる

16 ：仕様書無しさん：04/07/12 12:30

なんか>>1の言ってる事は逆だろ。
ポインタが怖くてＣやＣ＋＋が使えないのがＪＡＶＡ厨だろ
Ｃ厨やＣ＋＋厨はいつでもＪＡＶＡに移行できるよ

17 ：仕様書無しさん：04/07/12 12:31

Java = 馬鹿用C++

18 ：仕様書無しさん：04/07/12 12:32

クラスが理解出来ないＣ厨には無理だと思われ。　故にＣ厨。

19 ：仕様書無しさん：04/07/12 12:34

とりあえず>>16-17みたいなのが>.1が抽象している傲慢なヴァカということでしょう。
まさに、ポインタ演算ごときで自分がプロだと勘違いしているというC厨の典型です。

コンピュータがこれだけ流行っているのにいまどきそろばんを
使いこなせたくらいで自分が偉い、仕事ができると勘違いしている
典型的な厨房と何ら変わりありませんね。

20 ：仕様書無しさん：04/07/12 12:36

STLが使えるようになってから言え。（ﾌﾟ

21 ：仕様書無しさん：04/07/12 12:36

>>18
Ｃ厨はアーキテクチャーパターンやデザインパターンを理解できない
どころかオブジェクト指向、
いやそれどころかクラスすら理解できないのか。

22 ：仕様書無しさん：04/07/12 12:38

なんか>>16の言っていることは逆だろ。
アーキテクチャーパターンが怖くてJavaが使えないC/C++厨だろ。
Java厨はいつでもCやC++に移行できるよ。
大抵のJava厨はC経験者だから。

23 ：仕様書無しさん：04/07/12 12:38

>>20
STL？　あんなもんjava.util.*とJ2SE5.0押さえておけばイラネ

24 ：仕様書無しさん：04/07/12 12:38

どうでもいいから、あんたらが提案してきた
アプリケーションサーバでまともな速度で
動かしてよ。遅すぎて使えないよ。よく落ちるし。

25 ：仕様書無しさん：04/07/12 12:39

あと、Jakarta Commons Connectionsも押さえておけばイラネ

26 ：仕様書無しさん：04/07/12 12:39

>>24
っていうかどういうサーバなんだか。どこの会社のサーバだ？

27 ：仕様書無しさん：04/07/12 12:41

とりあえずJavaWorld廃刊おめでとうございます

28 ：仕様書無しさん：04/07/12 12:42

>>27
まだ粘着しているのか

29 ：仕様書無しさん：04/07/12 12:44

なんかもう必死でしょ。最近のJava厨

30 ：仕様書無しさん：04/07/12 12:57

Java厨ってスルーもできない可哀相な生き物なんだね。
脊髄反射でレス返さんでもいいやん。必死杉。

31 ：仕様書無しさん：04/07/12 13:08

はぁーーーーーーっはっはっははははあははははははははああははああはっはーーーーー！！

必死だな！！　　　必死だな！！　　　必死だな！！

どいつもこいつも、必死だなーーーーーーー！！！！ｗｗｗｗｗｗｗｗ

32 ：仕様書無しさん：04/07/12 13:12

C厨の必死さはJava開発者の凌ぐけどなw

33 ：仕様書無しさん：04/07/12 13:18

>>31は必死なC厨の最後の作り笑いですw

34 ：仕様書無しさん：04/07/12 13:20

氏ね！氏ね！前世代の化石は氏ね！！

35 ：仕様書無しさん：04/07/12 13:25

Javaを甘く見ているC++厨は確かにかなり必死だよね　
　

36 ：仕様書無しさん：04/07/12 13:26

どっちもつかえるようになったらええやんけ

37 ：仕様書無しさん：04/07/12 13:28

JavaとC++を両方学んだけど、未熟なのであまり違いがわからない。
C++は画面が寂しい。その程度。喧嘩できる人たちはすごいなあ。

38 ：仕様書無しさん：04/07/12 13:48

Javaのポインタについてはこの辺が参考になるかな。
http://java-house.jp/ml/archive/j-h-b/028625.html

それはそうと、JavaとC/C++では住み分けが出来ていると思うのだが？

39 ：仕様書無しさん：04/07/12 14:01

とりあえずJavaWorld廃刊おめでとうございます

40 ：仕様書無しさん：04/07/12 14:04

Javaは別になめてかかってもいいと思うけど。落ち目だし。ｗ

41 ：仕様書無しさん：04/07/12 14:10

Javaって死滅しちゃうの？

42 ：仕様書無しさん：04/07/12 14:37

>>40
甘いな。

大規模 J a v a は甘くない
http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20030703/1/

大量データを処理する大規模アプリケーションをJavaで実現する
「大規模Java」の時代がすぐそこに来ている。銀行の要である口座振替
システムや組立型製造業の心臓部にあたる部品表管理システムをJava
で実現しようとする企業が、日本でも登場した。
いまこそ覚悟を決めて、大規模Javaの大海原に飛び込むべきだ。だが、
大規模Javaは甘くない。安易に手を出すと、大やけどはまぬがれない。
Javaの長所と短所を理解し、オブジェクト指向開発のメリットを生かし、
かつ大規模開発をスムーズに進める体制や開発手順を整えることが必須である。

43 ：仕様書無しさん：04/07/12 14:37

Javaが正式に登場したのは1996年1月。以来7年半が経過し、
Javaは企業システム開発言語の「4番打者」への道を着実に歩
んでいる。基幹系システムをJavaで構築する企業もいまでは数多い。

　Javaが普及している最大の理由は、現時点で次世代企業システムの開
発言語としての条件を最も多く満たしているからだ。オブジェクト指向言語
である、同じプログラムを異なるOSで使えるといったJava自身の特徴はも
ちろん、サーバー向けJava仕様である「J2EE」の存在が大きい。Webページ
の生成からサーバー側アプリケーションのソフト部品化、トランザクション管理
やセキュリティに至る企業システムに必要な仕組みの多くがJ2EEで標準化さ
れている。J2EE準拠をうたった製品を入手すれば、これらの機能をそのまま使
えることになる。

44 ：仕様書無しさん：04/07/12 14:38

　Javaの勢いはとどまるところを知らない。今後数年で「大規模Java」の時代が確実に訪れる。
メインフレームの牙城といわれる大量バッチ処理システムをJavaで実現することをもくろむUFJ
銀行は、典型的な先進ユーザーである。同行は1日当たり最大1000万件もの大量データを一括
処理する口座振替システムの開発言語としてJavaを採用。来年秋の稼働を目指す。実現できれば、
世界にも類を見ない大規模Javaシステムとなる。「今後勘定系システムを更新する際は、すべて
Javaを使っていく」と、UFJ銀行システム企画部の滝沢卓調査役は明言する。

　中部電力は工事、資材、経理の3部門にわたる大規模システムを開発工数1万人月をかけて
主にJavaで開発し、今年10月をめどに順次稼働させる。ほかにも日立ホーム＆ライフソリュー
ションなどJavaで大規模な基幹業務システムの刷新を進める企業は枚挙にいとまがない。

　大規模Javaシステムの構築に挑む企業はますます増えるだろう。ここで注意すべき点が一つある。
UFJ銀行や中部電力のように大規模Javaに挑戦する“資格”のある企業は、ごくわずかしか存在しないことだ。

　大規模Java開発では、システム全体を綿密にモデリングすることが不可欠である。開発標準を作り、
開発チームに徹底することも欠かせない。JavaやJ2EEの長所や短所を理解して、どの技術や製品を
使うかも見極めなければいけない。JavaでWebアプリケーションを数カ月で作るのと同じ体制や考え方
がそのまま通用するほど、大規模Javaは甘くない。

　もはや大規模Javaの流れはだれも止められない。大規模Java構築に耐えられる体制作りを、
いまから始めるしか手はない。先進事例を通じて、大規模Javaに関する課題と解決策を浮き彫りにしていく。

45 ：仕様書無しさん：04/07/12 14:39

3社の決意
Javaで“超”大規模開発に挑む

UFJ銀行
目指すは1日1000万件のバッチ処理

　「時期尚早だと思います」。UFJ日立システムズでプロダクト開発第2部口座振替システ
ムグループのグループマネジャーを務める小松高子氏は、協力会社であるシステム・イン
テグレータの担当者にきっぱり言われた。昨年夏に、「UFJ銀行の口座振替システムをJavaで
再構築したい」と伝えたときのことだ。UFJ日立システムズはUFJ銀行のシステム子会社で、
勘定系システム開発を主に手がけている。

　口座振替システムは、預金者の口座からサービス料金などを引き落とすためのもの。
大量データを処理する典型的なバッチ処理システムだ。UFJ銀行の場合、ピーク時の処理
データ数は1日当たり最大1000万件に上る（図1[拡大表示]）。これほど大量のデータ処理をこ
なすシステムは、日本でも数えるほどしかない。「大量データを一括処理するうえに、システム
の障害は許されない。そんな分野にJavaを採用するのはリスクが大きすぎる」というのが、
インテグレータ担当者の意見だった。

46 ：仕様書無しさん：04/07/12 14:40

　それでもUFJ銀行はJavaの採用にこだわった。同行は現行の口座振替システムを、
30年来メインフレームで動かしている。「振替結果をすぐに顧客企業に通知するといった
新サービスを提供するにはさすがに限界だった」と、UFJ日立システムズの関根靖プロ
ダクト開発第2部長は説明する。

　そこで口座振替システムを再構築するにあたり、オープン系プラットフォームの採用と
同時に、「開発したソフト部品を再利用できる、プラットフォームに依存しない点を買って」
（UFJ日立システムズの蒲原寧プロダクト開発第6部長）Javaの採用を決めた。

「処理性能には自信がある」

　だが、ピーク時で1日1000万件のデータ処理をこなすシステムをJavaで実現して、
処理性能に問題はないのか。「当社で性能を検証した結果、本番環境でも十分な性能が
得られることを確認できた」と蒲原部長は自信をみせる。

47 ：仕様書無しさん：04/07/12 14:40

　UFJ日立システムズは昨年末から今年初めにかけて、2種類のプロトタイプ・システム
で性能を評価した。片方は本番環境の3分の1、もう一方は3分の2のハード構成をもつ。
業務ロジック部分には、サーバー向けソフト部品仕様のEJBを採用。EJB部品から処理
を受け継ぎ、SQL文をデータベースに発行するミドルウエアを独自に開発した。この2種
類のシステムで口座振替データ100万件を処理させて、単位時間当たりの処理件数を測定した。

　いまUFJ日立システムズは、開発要員100人体制で大規模Javaに挑戦している。
「1000万件のデータをいくつかに分割して処理したらどうか」など、開発メンバーから出た
アイデアを検証し、来年9月に予定する稼働を目指す。

48 ：仕様書無しさん：04/07/12 14:46

なんかしらんが、C、C++、Java全て使えないやつが房

49 ：仕様書無しさん：04/07/12 14:49

>>42-45を要約すると、
「大規模なJavaは扱いにくい」
ということですね。

ノウハウのあるCOBOLのがよっぽどマシだと。

50 ：仕様書無しさん：04/07/12 14:49

Javaはもうじき、「Java？なにそれ？コーヒー？とコンピュータになんの関係があるの？」の運命にあるから要りません。

51 ：仕様書無しさん：04/07/12 15:44

なんでこんなに必死なのだ？サンの株でも持ってるのか？

52 ：仕様書無しさん：04/07/12 15:47

Java以外できない上にプライドばかり高いから一大事なんだよ

53 ：仕様書無しさん：04/07/12 17:16

Ｊａｖａができれば C++ もそれなりに使えるようになるんじゃないの？　よう知らんけど。

54 ：仕様書無しさん：04/07/12 17:57

>>49
そこをCOBOLとJavaとを入れ替えると意味は正論になるのだが。

55 ：仕様書無しさん：04/07/12 17:58

>>50
C/C++ですらそうなったことはまだないというのにJavaではそういうことはないな。
とくにこの業界ではな。「なにそれ？」っていうのはIT素人だけだよ

56 ：仕様書無しさん：04/07/12 17:59

>>53
使えるよ。しかしC++を使って何かを企画しようって気にはおきないな。
既存の資産がC++とかで残っているなら仕方が無くC++を使うと言うだけでね。

57 ：仕様書無しさん：04/07/12 18:00

>>51
SunはJavaでそんなに儲けていないからさすがに関係ないだろう。
儲けているのはIBMとかだし

58 ：仕様書無しさん：04/07/12 18:53

Javaの案件単価安いって聞くけどなんでそこまでJavaにこだわるの？

59 ：仕様書無しさん：04/07/12 19:10

Java以外使えないからじゃない

60 ：仕様書無しさん：04/07/12 19:14

>>58
C/C++よりもちょっとよりも高いよ。COBOLやVBとくらべたらもっと高くなるね。
C#と同じくらいらしいけど。

61 ：仕様書無しさん：04/07/12 19:18

>>60
変な会社だね

62 ：仕様書無しさん：04/07/12 20:16

publicフィールド使った構造体＆メソッドのみのクラス
というソースを見た

63 ：仕様書無しさん：04/07/12 20:37

>>61
その君の思う変な会社は世界中に多数存在するわけだが。

64 ：仕様書無しさん：04/07/12 20:38

>>61を見るとC/C++厨はかなり頑固だと思う

65 ：仕様書無しさん：04/07/12 20:38

>>62
そういうのがいるからC++厨は嫌われる

66 ：仕様書無しさん：04/07/12 21:56

お客様のお言葉です。
「日経に載ってたけどJavaって簡単なんでしょ？だったらもっと単価下げてよ。」

67 ：仕様書無しさん：04/07/12 22:23

どうだろうね。
それだったらC#とかもっと下がりそうだが

68 ：仕様書無しさん：04/07/12 22:34

>>66
実際そんな感じだよな、内容の高度さにもよるけどそれがなければ、客の要求する単価は
VB→Java→C→C++→アセンブラ
だよね

69 ：仕様書無しさん：04/07/12 23:18

とりあえずなめてかかんなよ。

とくにエンタープライズJavaはな

と。　

70 ：仕様書無しさん：04/07/12 23:20

>>68
甘い甘い。現実を知らないな。
内容の高度さにもよるけどそれがなければ、客の要求する単価は

VB < COBOL < C < C++ < C#, Java　< J2EE(Java2, Platform Enterprise Edition)
だね。

71 ：仕様書無しさん：04/07/12 23:31

コーダーってほんとバカだな。
客が言語で単価決めるわけないだろ・・・
どんなちんけなモノつくってんだ？

72 ：仕様書無しさん：04/07/13 00:13

J2EEねぇ～
遅い、高い、つかえねえの三拍子が見事にそろってるよなあ
>内容の高度さにもよる
はあ～ん　ｳﾌﾟﾌﾟﾌﾟﾌﾟ
どの位高度なの？できもしないOOの設計のような抽象的な表現だなあ>70は糞ﾁﾝｶｽ馬鹿か

73 ：仕様書無しさん：04/07/13 00:18

まあいくらJava馬鹿が騒いでも
・カーネル開発は不可能
・ドライバ開発は不可能
・ハードウェア直接制御不可能
な言語であるわけだ、そのネガティブ要素を
「あなたが書いたコードはどこでも動きます」って誤魔化しているだけ

所詮ガキのおもちゃ糞Java
多重継承不可能なﾀﾞｻﾀﾞｻOO
VBよりも簡単なくせにさも難しそうにえらぶるJava厨　ｱﾌｫの極致

74 ：仕様書無しさん：04/07/13 00:20

J2EEとJavaの区別がつきません
なんか分かれたみたいだけど、どの辺がちがうの？

75 ：仕様書無しさん：04/07/13 00:24

>>72
> J2EEねぇ～
> 遅い、高い、つかえねえの三拍子が見事にそろってるよなあ

では
どう遅く、
どう高く、
どうつかえねえ
のか論理的に説制してもらおうか？

76 ：仕様書無しさん：04/07/13 00:26

なんだ？>74ﾀﾝ
そんな事聞くとJava厨の議席がまた減るぞ

77 ：仕様書無しさん：04/07/13 00:30

>>73
> ・カーネル開発は不可能
あぁJavaで作られた開発キットでカーネル開発が不可能だぁ？
ヴァカを言え。
> ・ドライバ開発は不可能
> ・ハードウェア直接制御不可能
この発言はJiniもJava Communication APIもしらないクズが知ったかぶりしている証拠だな。
Cしか知らないからこうやって頭が悪いと馬鹿にされるんだよ。
もっとそとの世界を見てみろや。

> な言語であるわけだ、そのネガティブ要素を
> 「あなたが書いたコードはどこでも動きます」って誤魔化しているだけ
こういうセキュリティ意識の甘さがJavaを高をくくってなめてかかって痛い目を見るC厨に成り下がるんだよな。

> 所詮ガキのおもちゃ糞Java
> 多重継承不可能なﾀﾞｻﾀﾞｻOO
こういう発言を見るとまだまだ無知だな。インターフェース多重継承もしらない。
実装多重継承をしないほうがいい理由も知らない。ゆえにオブジェクト指向をよくわかっていない。
アフォの三拍子だな(藁

> VBよりも簡単なくせにさも難しそうにえらぶるJava厨　ｱﾌｫの極致
お前にはJava2 Platform Enterprise Editionを使いこなすことはできないがな。
お前の頭の悪さ低レベル処理しかできないC厨脳ではアーキテクチャーパターンなど理解不能。

78 ：仕様書無しさん：04/07/13 00:30

>>76
むしろＣ厨の議席が減るぞ

79 ：仕様書無しさん：04/07/13 00:32

糞ｱﾌｫの>75に説明してもしょうも無い罠
だって藻前はJ2EEしかしらねえだろ？
もうすこし勉強してからでなおせよ。なっ

80 ：仕様書無しさん：04/07/13 00:35

Javaって
演算子のオーバーロードとか
値型とか
使えるようになった？
使えるようになったら使いたい言語No1、Java。

いや、べつにJavaが嫌いなわけじゃないんだが。
今の段階ではC＃が楽でいいかな。

81 ：仕様書無しさん：04/07/13 00:35

ｹﾞﾗｹﾞﾗｹﾞﾗｹﾞﾗ
>Jiniも
>>77ってほんとに馬鹿だな。ﾌﾟﾌﾟﾌﾟﾌﾟ
JNIでコールするのはC/C++のオブジェじゃねえの？
C/C++様に土下座して使わせてもらうのか？

82 ：仕様書無しさん：04/07/13 00:35

>>74
> J2EEとJavaの区別がつきません
> なんか分かれたみたいだけど、どの辺がちがうの？

とりあえずJ2EE depends on J2SE(Java)。

簡単に説明すると
J2EE
　Java2 Platform Enterprise Edition。
　基幹系業務、オープン系、ミッションクリティカルな分野で使われる。要J2SE。

J2SE
　Java2 Platform Standard Edition。サーバにも使われることがあればクライアントサイドでも使われる。
　これがないとJ2EEもJ2MEも動かない。

このうちJ2SEのほうが大抵の者が想定しているJava。

この板で暴れている時代遅れなC厨の想定しているJavaというのは
J2EEすら頭に入っていない。連中には5年以上前のJavaのことだけしか頭にない。
J2se5.0からはますます処理速度があがっているにもかかわらず、
連中は昔のJavaのことしか理解していない。愚かだ。

83 ：仕様書無しさん：04/07/13 00:35

JAVA でサーバーを作ろうという発想が、馬鹿だよな
>>1 も大馬鹿だが

84 ：仕様書無しさん：04/07/13 00:36

>>79
なんでこうC厨は向きになっているんだろう。
やっぱりC厨は頭が悪いんでしょ？

85 ：仕様書無しさん：04/07/13 00:36

>>83
> JAVA でサーバーを作ろうという発想が、馬鹿だよな
Cでサーバを作ろうとするお前の方がよっぽど馬鹿が。

86 ：仕様書無しさん：04/07/13 00:38

>>81
> ｹﾞﾗｹﾞﾗｹﾞﾗｹﾞﾗ
> >Jiniも
> >>77ってほんとに馬鹿だな。ﾌﾟﾌﾟﾌﾟﾌﾟ
> JNIでコールするのはC/C++のオブジェじゃねえの？
> C/C++様に土下座して使わせてもらうのか？
> >Jiniも
> >>77ってほんとに馬鹿だな。ﾌﾟﾌﾟﾌﾟﾌﾟ
> JNIでコールするのはC/C++のオブジェじゃねえの？
> >Jiniも
> >>77ってほんとに馬鹿だな。ﾌﾟﾌﾟﾌﾟﾌﾟ
> JNIでコールするのはC/C++のオブジェじゃねえの？
> >Jiniも
> >>77ってほんとに馬鹿だな。ﾌﾟﾌﾟﾌﾟﾌﾟ
> JNIでコールするのはC/C++のオブジェじゃねえの？
> >Jiniも
> >>77ってほんとに馬鹿だな。ﾌﾟﾌﾟﾌﾟﾌﾟ
> JNIでコールするのはC/C++のオブジェじゃねえの？
> >Jiniも
> >>77ってほんとに馬鹿だな。ﾌﾟﾌﾟﾌﾟﾌﾟ
> JNIでコールするのはC/C++のオブジェじゃねえの？
> >Jiniも
> >>77ってほんとに馬鹿だな。ﾌﾟﾌﾟﾌﾟﾌﾟ
> JNIでコールするのはC/C++のオブジェじゃねえの？
> >Jiniも
> >>77ってほんとに馬鹿だな。ﾌﾟﾌﾟﾌﾟﾌﾟ
> JNIでコールするのはC/C++のオブジェじゃねえの？

↑ここに注目 JiniとJNIとの違いに注目(ﾜﾗ
ﾌﾟﾌﾟﾌﾟﾌﾟﾌﾟﾌﾟﾌﾟﾌﾟあわてん坊のC厨

87 ：仕様書無しさん：04/07/13 00:38

サーバーなら.NET使えば「簡単」なのにな。

88 ：仕様書無しさん：04/07/13 00:38

>>80
> Javaって
> 演算子のオーバーロードとか
Jakarta Velocityで使えるよ。

> 値型とか
使えるよ。

89 ：仕様書無しさん：04/07/13 00:40

>>87
> サーバーなら.NET使えば「簡単」なのにな。
>
とりあえずﾄﾞﾄﾈﾄﾈﾀはスレ違い。このスレはC/C++/Javaについて語るスレ。

ドトネトネタはこっちでやりなさいな。

ﾄﾞﾄﾈﾄ厨のアストロターフィングについて語るスレ
http://pc5.2ch.net/test/read.cgi/prog/1088475687/
なぜドトネト厨はそんなにJavaが嫌いなのか　5
http://pc5.2ch.net/test/read.cgi/prog/1088355111/

90 ：仕様書無しさん：04/07/13 00:40

>>88
お～、そこまで進歩しましたか。
Javaに移ろうかな～

91 ：仕様書無しさん：04/07/13 00:40

>>89
ｽﾏｿ

92 ：仕様書無しさん：04/07/13 00:43

>>79
> 糞ｱﾌｫの>75に説明してもしょうも無い罠
> だって藻前はJ2EEしかしらねえだろ？

ﾌﾟ　ｱﾌｫだな。J2EEを知るということがどういうことかわかってないようだな。
J2EEを使いこなすためには
ネットワーキング、データベース、分散、セキュリティ、TCP/IP、アーキテクチャー、メール処理、
などすべてを知らないといけないのだ。
お前の頭では無理だがなw
J2EEを知るだけでもかなり苦労するのだw
熟練したものだけがJ2EEを制することができる。

C++しか知らない者にはJ2EEを極めることなど無理。

93 ：仕様書無しさん：04/07/13 00:47

Java厨はJavaの参照機能がポインタだと言い張るのなら
C++の参照機能もやっぱりポインタだって言うのかな？

94 ：74：04/07/13 00:48

>>82
ありが㌧
もうちと勉強します…

95 ：仕様書無しさん：04/07/13 00:49

>>92
では聞くが
メール処理の　添付ファイルはどのよう処理されて相手に送信されるか
教えてくれ。神様。1分以内になっ

96 ：仕様書無しさん：04/07/13 00:55

J2EEには以下のものが含まれている。

●EJB（Enterprise Java Beans）
　Session Bean
　　Stateless Session Bean
　　Stateful Session Bean
　Entity Bean
　　BMP Entity Bean
　　CMP Entity Bean
　Message Driven Bean
●JNDI（Java Naming and Directory Interface）
●IIOP（Internet Inter-ORB Protocol）
●Java Management Extensions (JMX)
●Java RMI (Remote Method Invocation)
●JDBC API
●Java Servlet API
●Java Server Pages(JSP)
●Java Mail API
●Java Management Extensions (JMX)
●JTA/JTS（Java Transaction API、Java Transaction Service）
●Java Message Service (JMS)
●Java IDL (Object Management Group Interface Definition Language)
●J2EE Connector Architecture

97 ：仕様書無しさん：04/07/13 00:55

なんだ、ぐぐって時間かせぎか　ﾌﾟｯ

98 ：仕様書無しさん：04/07/13 00:56

>>95
掲示板をチャットと勘違いしないようにな。
掲示板をなんでも相談ホットラインみたいなのと勘違いするなよ餓鬼。
教えて君には教えてやらないぞ。
そういう宿題の系統は自分の力でやれ。

99 ：仕様書無しさん：04/07/13 00:57

C厨は自分の宿題も自分でできないのか
まだまだ青いな

100 ：仕様書無しさん：04/07/13 00:57

あっ藻前ひょっとして
頭がパッシベートしっぱなしの椰子？

101 ：仕様書無しさん：04/07/13 00:58

Ｃ++できると言い張ってる厨はろくにC++の機能も使いこなせないただのＣ厨だからね。

102 ：仕様書無しさん：04/07/13 00:58

>99
ごまかさなくっていいって　かわいいな藻前

103 ：仕様書無しさん：04/07/13 00:59

C++厨はどうせオブジェクト指向も理解できないただのCしかできないC厨の癖に<iostream.h>と書いたくらいで
C++できるぜなんて威張ってるヴァカの集まりだからな。

104 ：仕様書無しさん：04/07/13 00:59

>>102
やっぱり青いなw 背伸びして必死だな

105 ：仕様書無しさん：04/07/13 00:59

>99はJ2EEの仕様のタイトルを高々と掲げる事はできるけど
内容の詳細は一切しりません　ﾌﾟｯ

106 ：仕様書無しさん：04/07/13 01:00

はやく教えてくれよ
J2EEの仕様をそれだけ知っていればｱﾌｫみたいだろ添付の仕組みなんてさ

107 ：仕様書無しさん：04/07/13 01:01

C++厨が多重継承と威張っても実のところ継承の賢い使い方をしらないどころか
実装多重継承の欠点もしらないわけだw
じつはオブジェクト指向なんてわかっていないただのＣ厨なんだよw
構造体つくったくらいでクラスを作ったつもりになってオブジェクト指向を理解したつもりになっているアフォがC厨の正体なのですw

108 ：仕様書無しさん：04/07/13 01:01

J2EEのことすら自分で勉強できないＣ厨。

109 ：仕様書無しさん：04/07/13 01:02

ヴァカはとりあえずJBossを使ってJ2EE仕様を理解しろよw

110 ：仕様書無しさん：04/07/13 01:02

>>106
>>98

111 ：仕様書無しさん：04/07/13 01:02

じゃあもうすこし簡単なのを聞いてやるよ、かわいそうだから
DB2(WIN)
Oracle(WIN)のデフォルト公開ポート番号を1分以内に教えてくれ
J2EEに含まれるよな　SQLDB あ・俺しらないよ馬鹿だから

112 ：仕様書無しさん：04/07/13 01:03

宿題くらい自分でやりなＣ厨(ﾜﾗ

113 ：仕様書無しさん：04/07/13 01:04

ﾋｿﾋｿ
アタッチの仕様もしらないくせに
J2EEはすげえぞって言うだけのjava厨　かわいいもんだ

114 ：仕様書無しさん：04/07/13 01:04

>>79
マジレスしよう。
J2EEを「本当の意味」で知っているのだとしたら、それはそれで凄い事だと思うぞ。

115 ：仕様書無しさん：04/07/13 01:04

このスレ見ているとC開発者側があら探しに必死になっているようにみえる。

必死にトリビアな知識をひけらかそうとしているところが哀れだ。

116 ：仕様書無しさん：04/07/13 01:05

おっ！
今度はJ2EEの懐の深さを説明し出すわけね
だから、アタッチの仕様まで知らなくてもそれはよしと言う事かな
はいはい　了解

117 ：仕様書無しさん：04/07/13 01:06

インターフェース多重継承もしらない癖にJavaでは多重継承ができない
っていうＣ厨もかわいいもんだ

118 ：仕様書無しさん：04/07/13 01:07

掲示板とチャットとの区別もつかないC厨は頭が悪いことが確認されました。

119 ：仕様書無しさん：04/07/13 01:07

Ｃ厨はJamesも知らないそうですw

120 ：仕様書無しさん：04/07/13 01:08

>115
ていうか、java厨は与えられた物でしか勝負できないのだな
与えられない仕組みを自分で創り出すパワーもないし・まあ100%
出来ないよな。それがjava厨　かわいそうだよマジで。
いつまでもJVMの上で遊んでてね。

121 ：仕様書無しさん：04/07/13 01:08

C厨にはWeb Servicesなんてものは敷居が高すぎで理解できないだろうな。
　

122 ：仕様書無しさん：04/07/13 01:10

>インターフェース多重継承
正確には多重継承をシミュレートするでしょう？

123 ：仕様書無しさん：04/07/13 01:11

>>120
> >115
> ていうか、java厨は与えられた物でしか勝負できないのだな
っていうかＣ厨は勝負することしか脳がないよな。
しかも自分には何もなくてもなんでもできると勘違いしているよな。
コンパイラなくてもソースコードからバイナリコードを生成できるのかC厨(藁
catコマンドもエディタもなくてもプログラミングできるのかC厨w
マシンがなくてもそろばんだけでなんでも作れるのかC厨。
結局Ｃ厨も与えられたものがないと何もできないんだよなw
独創性があると勘違いしているんじゃないの？（ﾌﾟ

124 ：仕様書無しさん：04/07/13 01:13

ところでJava厨で「J2EEを理解している」って言う人はいるの？
ほとんどが理解している気になっているだけど思うんだけど、気のせい？

ちなみに漏れは勉強をやり始めたばかりなので、ほとんど分かってない。

125 ：仕様書無しさん：04/07/13 01:15

>>122
> >インターフェース多重継承
> 正確には多重継承をシミュレートするでしょう？
ﾌﾟﾌﾟﾌﾟﾌﾟ

126 ：仕様書無しさん：04/07/13 01:17

>>124
J2EEのServlet/JSPを理解している奴がJavaプログラマの中で最も多い。
JDBCもだ。
EJBを理解しているのは実際に少ない。
だが最近、JBossが現れた。
これによってJ2EEの中心、EJBを極める者が続々登場してくるだろう。

127 ：仕様書無しさん：04/07/13 01:17

JNIとJiniとの区別も付かない、違いもわからないC厨って馬鹿だよなー。
やっぱりC厨は頭悪いんじゃないの？

128 ：仕様書無しさん：04/07/13 01:25

C++厨が傲慢に威張り腐る時代ももう終わりだよ。

129 ：124：04/07/13 01:32

>>126
やっぱり、そんなもんか。
EJBはこれからの技術なわけね。

Java厨とC厨の煽り合いを見ていると、お互いに理解していない事を
馬鹿にしたり絶賛してる気がしてきたよ。

130 ：仕様書無しさん：04/07/13 01:36

そしてこれからはJava厨が傲慢に威張り腐る時代の到来だ。
・・・もう、始まっているよ。

131 ：仕様書無しさん：04/07/13 01:39

>>128
そう？
Webアプリ以外もJavaが支配できるかな？
全てWeb化する可能性が無いとは言わないけど。

132 ：仕様書無しさん：04/07/13 01:47

どうしてJavaWorldは廃刊になったのだろう？

133 ：仕様書無しさん：04/07/13 01:52

正直オブジェクト指向がわかってない人がJavaとかC#とか書くのやめてほしい
もれのぷろぜくとひどすぎ・・・

134 ：仕様書無しさん：04/07/13 01:58

まあ、C++はJavaと違ってmanagedもunmanagedも自由自在なわけだが。
http://www.ecma-international.org/news/ecma-TG5-PR.htm

JVM？あんな単独言語専用の将来性のないランタイムは無視ですよ。
圧倒的有利の本物の標準と手を組まないとね。ｗ

135 ：仕様書無しさん：04/07/13 02:29

WebSphereも使ったことのない奴はJ2EEを語る資格なんてないよな。(ｹﾞﾗ

136 ：仕様書無しさん：04/07/13 02:31

>>135
IBMの営業の方ですか？

137 ：仕様書無しさん：04/07/13 02:37

>>129
> >>126
> やっぱり、そんなもんか。
> EJBはこれからの技術なわけね。

EJBを仕事で使いたがるヤシが少なく、
EJBを必要としないサービスのほうが需要が大きいからな。
みんなTomcatで満足しているかEJB同等のフレームワークを自分で自作してしまっているのが現状。
しかしそれだと拡張性がね。みんな「狭い」範囲内でのみ拡張性がありが、
「広い」範囲では拡張性がいまいちになる。

138 ：仕様書無しさん：04/07/13 02:41

フレームワークの無限増殖

139 ：仕様書無しさん：04/07/13 02:49

>>134
> まあ、C++はJavaと違ってmanagedもunmanagedも自由自在なわけだが。
> http://www.ecma-international.org/news/ecma-TG5-PR.htm
またドトネトネタか。ドトネトはスレ違いといっているだろう。
そんなもん処理速度で煽っているC++も興味を持たないぞ。
本当に頭の悪いC++だけだそういうものを欲しがる。

140 ：仕様書無しさん：04/07/13 02:51

> JVM？あんな単独言語専用の将来性のないランタイムは無視ですよ。
> 圧倒的有利の本物の標準と手を組まないとね。ｗ
Windows単独OS専用の将来性のないランタイムも基幹系では無視だが。
某社が言い張る「どの言語でも動く」とうスローガンは
「どのOSでも動くという」スローガンより幻想なのだが。
プログラミング言語を無闇に無計画に乱立させる行為はLinuxのような
ディストリビューション乱立を招く。

しかもCLRを使い、ドトネトフレームワークをフルに使える、.NETの機能をフルに使える
言語は、まだまだ限られている。まさに幻想だな。どの言語も動くとは所詮幻想なのだ。
馬鹿のような単純なコードだけどの言語でも動くだろうが複雑なもの、特定の、昔のAPIを
使うとなると動かないのが現実なのだ。COBOLが.NETではそのままではうごかないように。
COBOLが,NETで動くためには面倒な設定をするか、COBOL.NETというCOBOLとは別の言語を用意する
必要があり二度手間になるのだ。どの言語も動かせるなど所詮は幻想。

VMが複数の言語も動くと言っても言語をVMに対応させないと意味がないわけだ。

> 圧倒的有利の本物の標準と手を組まないとね。ｗ
BASICは標準になったが今では見る陰もないわけだが。
ECMA標準になった程度有利か。お笑い臭いな。
逆に混乱しているC++をさらに混乱させる羽目になるぞ。
C++の乱立はLinuxのディストリビューション乱立よりもひどい。
ECMAなんて中途半端な標準にしかあいてにされないとはおめでたいな。
(使える基本機能すべてが)ISO標準にもにならないようでは大したことがないな。

141 ：仕様書無しさん：04/07/13 03:04

> プログラミング言語を無闇に無計画に乱立させる行為はLinuxのような
> ディストリビューション乱立を招く。

だからみんなJavaｲﾗﾈって言ってるんだよね。ｗ

> 特定の、昔のAPIを使うとなると動かないのが現実なのだ。

同じAPIを使って同じように動かないのか。不思議だね。ｗｗｗ

> C++の乱立はLinuxのディストリビューション乱立よりもひどい。

ﾊｧ? 規格が乱立してるんですか？ｗ

> ECMAなんて中途半端な標準にしかあいてにされないとはおめでたいな。

その中途半端な標準にも挫折した糞言語がありましたね。ｗｗｗｗｗｗ

142 ：仕様書無しさん：04/07/13 03:08

お前らアフォか、
このスレは特定の言語に偏らないプログラミング教育を促すために建てた啓蒙スレだ。
今Servletプログラマはそれほど不足していないにしてもJ2EE/EJB開発者は不足している。

C++やJavaといった言語に偏らずにここでJ2EE開発者を増やすべきだ。
これは警鐘だ。

143 ：仕様書無しさん：04/07/13 03:10

>>142
「偏る」の意味が分からない在日さんですか？

144 ：仕様書無しさん：04/07/13 03:12

警鐘といえば、Java使いの単価は下がるは、JavaWorldは廃刊だわで色々あるよな。ｗｗｗ

145 ：仕様書無しさん：04/07/13 03:14

>>142
常識がコロコロ変わるJ2EEを今覚える必要性はないなあ。ｗ

146 ：仕様書無しさん：04/07/13 03:15

>>141
> > プログラミング言語を無闇に無計画に乱立させる行為はLinuxのような
> > ディストリビューション乱立を招く。
> だからみんなJavaｲﾗﾈって言ってるんだよね。ｗ
逆だろ。その論理だと.NETイラネのほうが筋が通る。
Javaであれば言語の乱立は最小限に抑えられるってことがわかっているか？
>
> > 特定の、昔のAPIを使うとなると動かないのが現実なのだ。
> 同じAPIを使って同じように動かないのか。不思議だね。ｗｗｗ
事実だが。コピーしてもっていっただけでは動かないものなどいくらでもあるわけだが。
それを動かせるようにするにはアダプターを作るか自分でソースコードをいじくり回すしかない。
その手間はどれくらいかかるかわ両者の接点のできぐあいによって大きく変わってくる。

>
> > C++の乱立はLinuxのディストリビューション乱立よりもひどい。
> ﾊｧ? 規格が乱立してるんですか？ｗ
言語仕様が乱立しているだろうが。みな独自に互換性の低いC++環境を
ばらまき、C++が折角オブジェクト指向言語として使えても拡張性、再利用性、
汎用性なんて言語仕様の乱立でほとんど実現できずに終わってしまっただろう。

> > ECMAなんて中途半端な標準にしかあいてにされないとはおめでたいな。
> その中途半端な標準にも挫折した糞言語がありましたね。ｗｗｗｗｗｗ

お前は本当に標準化するってことがどういうことかわかってないのか。頭悪すぎだぞ本当に。
Javaを下手に標準化すればどうなるかは散々議論されてきただろう。
互換性の悪いフレームワークの乱立はかなり迷惑だろう。互換性なきものが乱立すればそれだけ
開発効率は落ちる。フレームワーク同士を部品のように組み合わせ、自由に付けはずすのも困難になる。
標準化するとネジの形状が乱立し共通規格が崩壊し部品の互換性が悪化する。
それは開発効率の大幅な低下を招く。

147 ：仕様書無しさん：04/07/13 03:16

>>145
変化に耐えられない愚か者はそのまま時代の流れに取り残されてでもいればいい。
だがそのあとはどうなっても知らないぞ

148 ：仕様書無しさん：04/07/13 03:17

まさに原理主義って感じで。ｗ
落ち目の言語と心中してくれる仲間が見つかるといいね。ｗｗｗ

149 ：仕様書無しさん：04/07/13 03:18

>>144
根拠がないな。Javaworldが廃刊になっただけで喜ぶとは視野が狭い。
よほどつまらない人生を送ってきたんだな。
C/C++の雑誌はｊ何冊が廃刊になった？
C＃の雑誌はｊ何冊が廃刊になった？
答えてみろ。

150 ：仕様書無しさん：04/07/13 03:20

>>148
原理主義はオマエサンだがw
変化に耐えられない愚か者こそ原理主義だなw

おまえには「変化ヲ用語セヨ」で有名なExtreme Programmingの
提唱者ケントベックの爪の垢でも飲ませてやりたいな。

151 ：仕様書無しさん：04/07/13 03:21

>>143
だからお前が偏っているのだよ。
都合が悪くなるとすぐ在日か。ドトネト中だかCしか知らないアフォだか知らんが
C/C#厨はこの程度か。

152 ：仕様書無しさん：04/07/13 03:24

>>131
> >>128
> そう？
> Webアプリ以外もJavaが支配できるかな？
> 全てWeb化する可能性が無いとは言わないけど。

ユビキタス系もJavaは強い仕様になっている。
Java Card APIとかJiniとかな。組み込みで強い力を持っているJava
ユビキタスコンピューティングにうってつけだ。
それから将来、ロボディクスにも使われると見ている。

あと、J2ＥＥはPerl/CGI, PHPなどと違ってWeb限定ではないぞ。
HTTP以外のプロトコルにもちゃんと対応しているわけだが。
ま、それも当然だが。

153 ：仕様書無しさん：04/07/13 07:15

うんうん。こういうキチガイが宣伝しなければならないほど、Javaも本当に落ち目なんだなあ。

154 ：仕様書無しさん：04/07/13 07:35

衰退が著しくなると先鋭化してくるものさ。ﾏｶｰと一緒だな。

155 ：仕様書無しさん：04/07/13 08:20

マ板で一日足らずで100スレ超えるとは

156 ：仕様書無しさん：04/07/13 08:21

>>152
実際にJiniとかJava Cardの普及率って、どんなもん？
次々と出てくるハードウェアにちゃんと対応できてるの？
性能面ではCやC++に比べてどうなの？
いや、煽りとかではなくて顧客とかに説明を求められたとき、あなたなら何と答える？

「xxxxに強くて、yyyyみたいな事が出来ます。」
と、言われてもな。

157 ：仕様書無しさん：04/07/13 08:49

Javaって一種の幻想みたいなものだよね。ファンタジーってのは好みが分かれるよ。
好きな香具師は好きでコスプレまでやって興奮しとるが、一般人にはちょっとね。
ﾃﾞｻﾞﾊﾟﾀがどうのOOがどうの開発手法がどうのと騒いでいるJava厨と
コスプレして世界観がどうのと喜んでいるﾊﾘﾎﾟﾀ、あるいはﾛｰﾄﾞｵﾌﾞﾘﾝｸﾞのﾌｧﾝって
受ける印象がそっくりなんだよね。普通の人からみたらちょっとｷｯﾂｲ。
そういう、それだけの話でしょう。

158 ：仕様書無しさん：04/07/13 08:50

ビルジョイのいないJiniに賭けるアホなんておらんだろ。

159 ：仕様書無しさん：04/07/13 08:53

>>153-155
この連続投稿に
「うんうん。」文字列。こいつはﾄﾞﾄﾞﾈﾄ厨ですな。

160 ：仕様書無しさん：04/07/13 08:54

Micro$oft.NETって一種の幻想みたいなものだよね。ファンタジーってのは好みが分かれるよ。
好きな香具師は好きでコスプレまでやって興奮しとるが、一般人にはちょっとね。
LonghornがどうのがGUIどうの開発環境VS.NETがどうのと騒いでいるC#,VB.NET厨と
コスプレして世界観がどうのと喜んでいるﾊﾘﾎﾟﾀ、あるいはﾛｰﾄﾞｵﾌﾞﾘﾝｸﾞのﾌｧﾝって
受ける印象がそっくりなんだよね。普通の人からみたらちょっとｷｯﾂｲ。
そういう、それだけの話でしょう。

161 ：仕様書無しさん：04/07/13 08:56

>>156
> >>152
> 実際にJiniとかJava Cardの普及率って、どんなもん？
> 次々と出てくるハードウェアにちゃんと対応できてるの？
> 性能面ではCやC++に比べてどうなの？
> いや、煽りとかではなくて顧客とかに説明を求められたとき、あなたなら何と答える？

あと5～10年くらいは様子みだな。
性能面はJavaChipを使うことで驚くことにＣよりも速くなる。
(Ｃ側もJavaChipを使わないという前提条件で)

162 ：仕様書無しさん：04/07/13 08:58

だれも.NETの話なんてしてないのに...なんでM$ひっぱりだすんだろ?
仮想敵を作って、攻撃していないと安定できないな人たちなのね、きっと。
まるで北の人たちみたいだわ。
そういや北もそうとう劇画調つーかコスプレっぽいけどな。

163 ：仕様書無しさん：04/07/13 09:00

>>161
>性能面はJavaChipを使うことで驚くことにＣよりも速くなる。
マンドラゴラの種や、蝙蝠の羽を使えば100倍も速いかもね(w

164 ：仕様書無しさん：04/07/13 09:07

>>162
>>134をみろ。どこが仮想的だ。CLIなど持ち出してさらにそいつと口調がそっくりな奴がいるし

165 ：仕様書無しさん：04/07/13 09:08

>>163
とりあえず「JavaChip」で検索してみな。お前自身の発言がアフォに見えてくるぞ。

166 ：仕様書無しさん：04/07/13 09:09

さぁ皆のもの、マントラがきたれり。
Javaの導師のマントラをきけっ!!

(実際、ｺｽﾌﾟﾚさんらにゃ付き合っとられんね(w))

167 ：仕様書無しさん：04/07/13 09:15

さぁ皆のもの、マントラがきたれり。
C厨の導師のマントラをきけっ!!

(実際、ｺｽﾌﾟﾚさんらにゃ付き合っとられんね(w))

168 ：仕様書無しさん：04/07/13 10:21

末期だねー終わったねー
Javaの技術は高度だが使う側にはその技術は必要ない、むしろ程度が低くてよい、それはよい事。
面白いのは、それを使っている信者が自分の技術も高いと信じて疑わない事、
ハイレベルなのは貴方じゃなーいよ
Javaの言語思想は融通の利かない堅物だけど
取り付く信者も融通の利かない堅物、ついでにプライドばかりが不必要に高いと来たもんだ
そして、この自信はどっから湧いてくるのかな、不思議だねー
能無しには乗り換え大変ストレス溜まっているのは判るが、
　
　あ　ば　れ　ち　ゃ　だ　め
　

169 ：仕様書無しさん：04/07/13 10:53

至るところでJava叩きですが、何かのキャンペーンですか？

170 ：仕様書無しさん：04/07/13 12:42

弱い者イジメに決まってるだろ(ｗ

171 ：仕様書無しさん：04/07/13 12:46

Swingってアプリ単体でLook&Feel変えるなんてセンス悪すぎ。
メディアプレイヤー系のお遊びソフトじゃないんだからさ。
OS毎にネイティブなLook&Feelを提供すればそれでよし。
それができないならWinでもLinuxでも相手にされないよ。

172 ：仕様書無しさん：04/07/13 13:09

JavaなんてVB.NETと大して変わらないよ。

173 ：仕様書無しさん：04/07/13 13:37

じゃあVB.NETでいいや

174 ：仕様書無しさん：04/07/13 13:39

>>172
C#がVB.NETと大して変わらないというならわかるが。
Javaをそっちと変わらないと見るには違和感ありだな。

175 ：仕様書無しさん：04/07/13 13:41

JavaってEclipse開発専用言語だろ

176 ：仕様書無しさん：04/07/13 13:41

>>168
> 末期だねー終わったねー
> Javaの技術は高度だが使う側にはその技術は必要ない、むしろ程度が低くてよい、それはよい事。

お前みたいな知らぬが仏にまでなって色眼鏡をかけてる奴には
J2EEというC++厨ですら理解するのに窮する高度なテクノロジーと取り扱うことは無理。

せいぜい小規模アプリでも作ってろや

177 ：仕様書無しさん：04/07/13 13:41

>>175
IBMに聞いてみな。どんな答えがかえってくるやら

178 ：仕様書無しさん：04/07/13 13:42

>>169-170
傲慢だなw
C++叩きキャンペーンスレだぞこのスレはw

179 ：仕様書無しさん：04/07/13 13:44

ヘ_ヘ
ミ・・ミ　ということにしたいのですね？
( ° )～

180 ：仕様書無しさん：04/07/13 13:51

C++厨って往生際が悪いねw
負けず嫌いで傲慢でC++が最強の言語だと豪語しているしw

181 ：仕様書無しさん：04/07/13 13:51

こうして一つの時代が終わるのでした……

182 ：仕様書無しさん：04/07/13 13:52

そう、C++の黄金時代は終わるのでした……………

183 ：仕様書無しさん：04/07/13 13:53

　　　　　　　　　　　　　　　そして今、

　　　　ユビキタス社会が台頭するのであった…………。

184 ：仕様書無しさん：04/07/13 13:54

ヘ_ヘ
ミ・・ミ　ということにしたいのですね？
( ° )～

185 ：仕様書無しさん：04/07/13 13:55

いや、勝者はVB.NETかもしれん。マジで。

186 ：仕様書無しさん：04/07/13 13:56

　　　．Ｎｅｔ　の　黄　金　時　代　が　今　始　ま　る　！！

187 ：仕様書無しさん：04/07/13 13:57

　　　　が　、　　　し　か　し　！　！　！　！　

　　　.　N　E　T　,　　W　i　n　d　o　w　s　の　黄　金　時　代　は　

　　　　　　1　9　9　5　年　に　す　で　に　終　わ　っ　て　い　た　！　！　！

188 ：仕様書無しさん：04/07/13 13:58

　　　　　　　　　　勝　者　は　D　言　語　な　り　！　

189 ：仕様書無しさん：04/07/13 13:59

触れてはいけないことを書き込んでしまったようです。

190 ：仕様書無しさん：04/07/13 13:59

　　　　　　1　9　9　5　年　に　す　で　に　終　わ　っ　て　い　た　！　！　！・・・はずだった

なぜだ、なぜ消えない・・・苦悶するJava厨

191 ：仕様書無しさん：04/07/13 13:59

ヘ_ヘ
ミ・・ミ　ということにしたいのですね？
( ° )～

192 ：仕様書無しさん：04/07/13 13:59

JBossの登場、Eclipseの登場、JBoss用EclipseプラグインJBoss-IDE, Lomozによって
開発が手軽になり

EJBエンジニア、すなわちJ2EEエンタープライズアーキテクトが

これから続々と現れることだろう。

193 ：仕様書無しさん：04/07/13 14:00

>>188
ﾜﾛﾀ

194 ：仕様書無しさん：04/07/13 14:01

>>190
おまい、Windows95の黄金時代を知らないのかいw
あの黄金期はもう終わっているのだよw
あのころは大人気で活気もあったWindowsも今やエンジニアの嫌われ者。

徐々に信頼性を失い他のOS、オープンソースの台頭に恐れなすM$厨

195 ：仕様書無しさん：04/07/13 14:02

Javaこそが勝者である。
これからも凄まじい勢いでフレームワークが開発され、（しかもｵﾌﾟｿ！）
年３本づつくらいのペースで増えていくだろう。
Java戦士の諸君よ。もっともっとﾃﾞｽﾏって案件を片付けろ！

このままでは現れるフレームワークを使い切れないぞ。

196 ：仕様書無しさん：04/07/13 14:03

>>195
ツマンネ

197 ：仕様書無しさん：04/07/13 14:03

. N E T は幻想に終わってしまった。

. N E T の仕様、 W in d o w s のサーバ市場での

認知度の低さに悶える M $ = M i c r o $ o f t 厨

198 ：仕様書無しさん：04/07/13 14:04

>>195よ、
おまえが明らかにアンチJavaの自作自演であることがわかる。
わざとらしくて自作自演していることがバレバレだからやめておけ。

199 ：仕様書無しさん：04/07/13 14:05

VBでWebサービスを書ける時代だからなぁ。。。。

200 ：仕様書無しさん：04/07/13 14:05

ヘ_ヘ
ミ・・ミ　ということにしたいのですね？
( ° )～

201 ：仕様書無しさん：04/07/13 14:08

>>199
多分そのうち全部Execlでできちゃうだろうね。

202 ：仕様書無しさん：04/07/13 14:09

なんだなんだ。
自宅待機になった派遣ﾄﾞｶﾀJavaPGが暴れているのか。

203 ：仕様書無しさん：04/07/13 14:10

>>198
おまいのレスは良く見るな。Javaスレで。

204 ：仕様書無しさん：04/07/13 14:13

ヘ_ヘ
ミ・・ミ　ということにしたいのですね？
( ° )～

205 ：仕様書無しさん：04/07/13 14:13

ユビキタスコンピューティングによってJiniテクノロジーが駆使されるのであった。

206 ：仕様書無しさん：04/07/13 14:18

C++厨でドトネトやってる香具師ってどれくらいいるの？
あまり聞かないんだけど

207 ：仕様書無しさん：04/07/13 14:19

>>202
つまりお前さんは自宅待機になった派遣ﾄﾞｶﾀC++orC#プログラマってところか？

おれは学生様だがな。

208 ：仕様書無しさん：04/07/13 14:21

ここで暴れているのは学生様ではなくウダツの上がらない先生様の予感(藁

209 ：仕様書無しさん：04/07/13 14:26

開発者がユビキタスなんて恥ずかしい言葉使うなよ

210 ：仕様書無しさん：04/07/13 16:00

くっくっく

もめろもめろ

くっくっく

211 ：仕様書無しさん：04/07/13 16:06

クッククック青い鳥　

212 ：仕様書無しさん：04/07/13 17:33

やっぱりＰＧって狭量なのかな。　この板では、他の業界・職種・言語
・開発手法など、自分と異なる属性の存在全てに噛み付いてるよな。

俺も気をつけよっと。

213 ：仕様書無しさん：04/07/13 17:59

>>212
自分の好む技術を褒め、それ以外を貶す。
これは自勢力を拡大するためのささやかな試みに過ぎないんだよ。

実際、仕事が入ればどんな技術でも尻尾振って飛びつくという
驚くほど従順な態度を示すのがプログラマの佐賀。

214 ：仕様書無しさん：04/07/13 18:02

Lyeeでも？

215 ：仕様書無しさん：04/07/13 18:16

YPSでも？

216 ：仕様書無しさん：04/07/13 18:22

>>206
やっぱ少ないんじゃない?
M$はC++よりC#を推してるから。

217 ：仕様書無しさん：04/07/13 19:19

つかアンマネージなコードにしか使わないんじゃない？C++。

218 ：仕様書無しさん：04/07/13 19:25

>>212
>やっぱりＰＧって狭量なのかな。
>自分と異なる属性の存在全てに噛み付いてるよな。

お前、SE だろ？

219 ：仕様書無しさん：04/07/13 20:59

ヘ_ヘ
ミ・・ミ　ということにしたいのですね？
( ° )～

220 ：仕様書無しさん：04/07/13 22:20

Javaなんかアホでもできるじゃん

221 ：仕様書無しさん：04/07/13 23:08

「アホでもできる」
それがJavaの良いところ

222 ：仕様書無しさん：04/07/13 23:18

アホでも出来る＝ﾄﾞｶﾀ言語

223 ：仕様書無しさん：04/07/13 23:39

Java＝アホでも出来る＝VB＝ﾄﾞｶﾀ言語

224 ：仕様書無しさん：04/07/13 23:48

アフォでも出来るが、アフォは極める事ができない。

225 ：仕様書無しさん：04/07/14 00:07

C/C++ Javaは住み分け出来てるだろ。

226 ：仕様書無しさん：04/07/14 00:31

そのとおり。Javaの比較対照はVB

227 ：仕様書無しさん：04/07/14 00:33

perl厨が粘着してた別のＪａｖａスレに似てるなぁ。。ここ

228 ：仕様書無しさん：04/07/14 00:38

結論を言うと>>1はｱﾌｫだと言う事だ。

229 ：仕様書無しさん：04/07/14 01:18

オブジェクト指向もいいけど
ポインタほど便利なもんはねーよ？参照なんて糞だ、糞

230 ：仕様書無しさん：04/07/14 01:33

>>209
> 開発者がユビキタスなんて恥ずかしい言葉使うなよ

どこが恥ずかしいんだか。
坂村健が好んで使う言葉だぞ。
本人はユビキタスコンピューティングという概念は私が考えたと主張しているらしいが。

ユビキタスという言葉はラテン語で「神はどこにでも偏在する」という宗教用語なんだぞ。

欧米人が信仰しているキリスト教は一神教であるにもかかわらず「神はどこにでも偏在する」
といっている。そこが巧みで教養ある欧米人にうまく伝えるためにわざとこういうネーミングにしたらしいぞ。

231 ：仕様書無しさん：04/07/14 01:36

>>229
しつこいぞ。同じことを何度も言わせるな。
Javaにはポインタがあると何度いったら解るんだ？
スパゲティコード製造機のポインタ演算が便利だと主張したいだけだろ。

232 ：仕様書無しさん：04/07/14 01:56

ぬるぽ。

233 ：仕様書無しさん：04/07/14 02:25

>>231
あなたが解釈しているポインタの定義を述べてください。
基本的にポインタ機能はメモリ操作をする機能であるはずですが、何か誤解しているような気がします。
もしかして、

参照 = ポインタ

だとは思っていませんか？
ちなみに私の周りにいる優秀なJavaプログラマは「参照」と「ポインタ」を
別物であると認識しています。

Javaにはメモリを直接、操作する機能は無いのでポインタの機能があると言われても正直、
ピンと来ません。
メモリ操作は出来ないがポインタはあると言い張っていませんか？

あと、何でポインタ変数を演算する事により、スパゲティコード製造機になるのか、説明していただけますか？

234 ：仕様書無しさん：04/07/14 02:39

ポインタが判ってる奴は「これが理解できない奴は馬鹿」だと言う。
ポインタが判らない奴は「これを使わなきゃいけない言語はダメ」だと言う。

まあ、どっちもどっち…

235 ：仕様書無しさん：04/07/14 03:07

どーでもいいですが、C擁護派は「ｗｗｗ」を使う人が
多いのはなぜですか？

236 ：仕様書無しさん：04/07/14 07:36

>>234
ポインタ解っていて「これを使わなきゃいけない言語はダメ」と言う。
本当にわかっている奴はこう言う奴です。

237 ：仕様書無しさん：04/07/14 09:02

>>233
ポインタ　＝　ポインタ演算
だと思っている香具師に偉そうに説教されたくはない。

238 ：仕様書無しさん：04/07/14 10:47

>>230
坂村氏はいいんだよ、うだつが上がってるからね。
新聞等でユビキタスって言葉を見て、新種のΣ計画か？と思った奴は相当いると思うね

239 ：仕様書無しさん：04/07/14 11:46

>>237
つか、C でいう「ポインタ」が一般的な用語だと思っている奴が大杉る。

240 ：仕様書無しさん：04/07/14 12:00

まだポインタ論議やってんのか

241 ：仕様書無しさん：04/07/14 13:19

>240
しょうがねーだろ。
コーダはこういうの好きなんだよ。

242 ：仕様書無しさん：04/07/14 13:57

>>1
悪いが、漏れはJavaをバカにしている。
が、Javaも使いこなしている。
つーか、C++できるのにJavaできない香具師はなんているのか？

243 ：仕様書無しさん：04/07/14 14:04

>>242
C++の曖昧な部分が好きで、JAVAみたいにうだうだコンパイラーに言われてしまうのが嫌な人。

244 ：仕様書無しさん：04/07/14 16:37

エラーがうるさいのはC++の方だと思うのはオレだけか？

245 ：puro：04/07/14 17:17

俺のようなプロは当然のように両方使う。

246 ：仕様書無しさん：04/07/14 18:13

>>245
使うのはいいけど、使いこなしてねーだろ

247 ：仕様書無しさん：04/07/14 18:15

頭の悪い>>1が立てたスレはここですか？

248 ：仕様書無しさん：04/07/14 19:25

弘法筆を選ばず。
プロは言語になど拘らぬものじゃ。

かく言う儂もＶＢは嫌いだが。

249 ：仕様書無しさん：04/07/14 19:58

>>243
(　´,＿ゝ`)ﾋﾟﾌﾟ-

250 ：仕様書無しさん：04/07/14 19:58

>>248
>プロは言語になど拘らぬものじゃ。

ならば、コンピュータ言語の設計者は
皆ど素人となるな。

251 ：仕様書無しさん：04/07/14 20:08

>>250
何でそんな発想が。ちょーいみわかんねー。

252 ：仕様書無しさん：04/07/14 20:12

>>251
言語に拘る必要が無ければ、
言語なんぞ作成する意味は無いだろ？

253 ：仕様書無しさん：04/07/14 22:11

>>246
なんでこういう性格が捻じ曲がったのがいるのか・・・。
親にちゃんとした愛情をもらって育てられなかったな・・・

254 ：仕様書無しさん：04/07/14 23:21

つうか何でこういつも「ポインタ」なんだ？

どんな言語だってポインタ（アドレス）がないハズもないし…
Delphiなんかで、PCharで宣言してるのが実はポインタってのが
気持ち悪い人間もいるし、ポインタを意識させない言語構造が
優れてるという人間もいる。

Javaが理解しやすいと思ってる人間はJavaで書ける仕事なら
Javaでいい。デバイスドライバでも書くハメになったらCで書け。
そういう事だろ？

255 ：仕様書無しさん：04/07/14 23:35

>>242
> >>1
> 悪いが、漏れはJavaをバカにしている。
> が、Javaも使いこなしている。
> つーか、C++できるのにJavaできない香具師はなんているのか？
いるよ。むしろそれでC++をバカにしている。
プリプロセッサとかtypedefとか演算子オーバロードつかったくらいで自分が
凄いと思っている奴を見るとどうしてもバカにしたくなるとも。
今となっては仕事には役立たない、むしろ逆に仕事の能率を
下げるスパゲティコード生成テクニックのような
マニアックなことをやっていればいつまでもみんなから凄いと思われれている
勘違い職人はとくにバカにしたくなる.。

256 ：仕様書無しさん：04/07/14 23:38

>>250, <<252のいっていることは的を得ている。

「言語に拘らない」なんて言ってる奴は綺麗事言っているだけか
恰好つけているに過ぎないのも事実。
本質が解ってない証拠。
本当は、数多くの種類の言語を使いこなせないことを誤魔化すために
逃げているだけじゃないのか？　よく文系にそういうヴァカが多いよな。

257 ：仕様書無しさん：04/07/14 23:39

>>254
> Javaが理解しやすいと思ってる人間はJavaで書ける仕事なら
> Javaでいい。デバイスドライバでも書くハメになったらCで書け。
> そういう事だろ？

そのうちデバイスドライバもJavaで書ける時代がやってくるよ。
Jiniテクノロジーの成長によって。

おっと、このスレでJiniのことをJNIと勘違いしているヴァカがいたがそれとは違うぞw

258 ：仕様書無しさん：04/07/14 23:44

>>257
>そのうちデバイスドライバもJavaで書ける時代がやってくるよ。

仮に書ける時代が来たとしても
書く時代は来ないと思う。

259 ：仕様書無しさん：04/07/14 23:48

extern "Java"

260 ：仕様書無しさん：04/07/14 23:53

JiniやJVMを実装してる言語は何なのかな？

261 ：仕様書無しさん：04/07/14 23:58

C++でJavaを作れるが、逆はできない。
よってC+＋の勝利
ガハハ（゜Д　゜）

262 ：仕様書無しさん：04/07/15 00:00

勝ち負けの問題か？

263 ：仕様書無しさん：04/07/15 00:24

友達のアメリカ人技術者にこのスレ見せたら、
「ファッキン」
と言っていました。

264 ：仕様書無しさん：04/07/15 00:31

>>261
できるんじゃね？

265 ：仕様書無しさん：04/07/15 00:47

>>258

おまえが生きている間にはJavaでドライバを書く時代はこないだろうな。
なぜならお前はもうすぐリストラされるからな！（藁

266 ：仕様書無しさん：04/07/15 00:48

>>260
JVMはC/C++で実装されている。
だがJiniはJavaで実装されている。

267 ：仕様書無しさん：04/07/15 00:49

>>261
> C++でJavaを作れるが、逆はできない。
> よってC+＋の勝利

残念だが、JavaでC++を作ろうと思えば作れるぞ。
JavaCCを使ってな。すべてのC++コードがJVMで動くのもなかなか面白そうだなw

268 ：仕様書無しさん：04/07/15 00:50

>>263
> 友達のアメリカ人技術者にこのスレ見せたら、
> 「ファッキン」
> と言っていました。
どこまで本当なのかな。
もしそれが本当なら他になんて言っていたのかな？
そしてその友達はどんな人間なのかな？

269 ：仕様書無しさん：04/07/15 00:50

>>267
実行形式ファイルを吐くコンパイラ書く、くらいのことは言ってくださいよ。

270 ：仕様書無しさん：04/07/15 00:57

ここ最近暴れているJava厨バカすぎる……
それも最早言葉にならない程にありとあらゆる色々な意味で……

271 ：仕様書無しさん：04/07/15 01:05

java遅いから嫌い

272 ：仕様書無しさん：04/07/15 01:06

いくらなんでも、CとC++とJavaは住み分けできてるだろ。
クライアントも無茶は言わないだろ？

273 ：仕様書無しさん：04/07/15 01:42

>>254
ポインタ = アドレスではない。

>>267
C/C++コンパイラをJavaで実装するって事？

274 ：仕様書無しさん：04/07/15 01:53

おもしろいスレだからしおりをはさんでおこう。

－－－－－－－－－－－－－－－－－－－－－－－－－－
俺様用しおり
　 ∧＿∧ 　　
　（　・∀・）＜　今日はここまで読んだ　　　　　　
－－－－－－－－－－－－－－－－－－－－－－－－－－

275 ：仕様書無しさん：04/07/15 02:01

ポインタなどただの序の口。ワシぐらいになるとポインタなどいちいち考えたりせずにその辺の変数などと同じように感覚的に扱える。
もっとも、Cを使えるというからにはそれぐらいはあたりまえである。
なぜそこまで人を見下したいのか。
自分に自信があるなら他の言語を貶めたりしないだろう。
やはり、自信の無さの表れなのだろうか。

276 ：仕様書無しさん：04/07/15 02:07

>>273
概念としてのポインタがアドレスではないって事か？詳細求む。
実際に変数を格納しているアドレスを指しているとは限らない
って意味なら確かにそうだがな。

>>256
全然違うな。言語というのは用途を想定して設計するものだ。
１つの言語があればいい、というのは間違ってると思う。
冷蔵庫に内臓されてるチップをJavaで書こうとする馬鹿はいないだろ…
同様にJavaでC++のコンパイラでも何でも作れるが本末転倒。

277 ：仕様書無しさん：04/07/15 02:40

ポインタより多重継承だろ。

278 ：仕様書無しさん：04/07/15 02:44

java遅いから使えない。当然反論できないよな。

279 ：仕様書無しさん：04/07/15 02:47

javaなんて、
趣味で小さいクラスをぽつぽつ作って満足してなさいってこった。

280 ：仕様書無しさん：04/07/15 02:49

みなさん、そこでIBM汎用機でJavaでWeb系ですよ

281 ：仕様書無しさん：04/07/15 02:50

java遅い。反論できないでしょ。

282 ：仕様書無しさん：04/07/15 02:50

javaなんて管理職にJavaScriptと混同されてろよ。

283 ：仕様書無しさん：04/07/15 03:00

>>276
>概念としてのポインタがアドレスではないって事か？詳細求む
「アセンブリのようにメモリを直接、扱うための機能がポインタ。」

みたいな事をCの開発者が出版した参考書に書いてあった。
ただ、初心者のうちは「ポインタ =　アドレス」と覚えてしまう人が多いと思う。

284 ：仕様書無しさん：04/07/15 03:12

Javaは性能を犠牲にして生産性・保守性を向上するのが目的なのです。
「C/C++なんだからもっと速くしろ」などというクレームはありません。
「まぁ、Javaだからな・・」で大抵のお客様は納得していただけます。
Javaはゆとり教育なのです。そこのとろをC/C++厨様にはご理解いただきたい。

285 ：仕様書無しさん：04/07/15 03:30

>>284
>「まぁ、Javaだからな・・」で大抵のお客様は納得していただけます。
物凄く良い顧客ですね。
っでJavaを使うと何で保守性が良くなるの？

286 ：仕様書無しさん：04/07/15 03:39

オブジェクトを指すモノのほうがわかりやすい

287 ：仕様書無しさん：04/07/15 03:59

>>285
C++より新しいから。

288 ：仕様書無しさん：04/07/15 06:25

ポインタを使うと保守性が下がる

ポインタがない

最高

Cは

289 ：仕様書無しさん：04/07/15 06:28

ポインタの使用を禁止する規約を設ければ良いんだよ。

290 ：仕様書無しさん：04/07/15 09:13

ポインタって、大騒ぎするほどの要素なのか？

291 ：仕様書無しさん：04/07/15 09:18

Javaにはポインタはありません。

292 ：仕様書無しさん：04/07/15 13:31

>>289
Singletonみたいなもん。決まりを作る前に、大々的に禁止してしまった方が潔いし、
迷わなくて済む。言い訳がましい根拠だが。

っていうか、Javaはキレイだよ。なんかキレイ。

293 ：仕様書無しさん：04/07/15 14:58

C++ でも　ポインタ使わずにプログラムできるでしょ

294 ：仕様書無しさん：04/07/15 16:57

>>293
可変長配列や連結リストはどうすんのさ？

295 ：仕様書無しさん：04/07/15 17:01

ヘ_ヘ
ミ・・ミ　ということにしたいのですね？
( ° )～

296 ：仕様書無しさん：04/07/15 17:17

>>294
STLも知らないの？
hello worldレベル？

297 ：仕様書無しさん：04/07/15 17:22

>>296
きっとSTLの内部でポインタが使われているって言いたかったんだろう

298 ：仕様書無しさん：04/07/15 18:35

>>296
vector<> にインスタンス持たせるの？莫迦？

299 ：仕様書無しさん：04/07/15 19:13

300 ：学生：04/07/15 20:51

なんでみんな必死なの?
プログラマになると、みんな、こうなってしまうのか?

301 ：仕様書無しさん：04/07/15 21:03

古い方が勝つわ・・・(´ω`)

302 ：仕様書無しさん：04/07/15 21:05

Ｃプログラマのほうがjavaプログラマより虫歯が多い。

303 ：仕様書無しさん：04/07/15 21:08

Javaプログラマの方がCプログラマより脇が臭い

304 ：仕様書無しさん：04/07/15 22:05

>>298
ポインタ使わずにプログラムできるかどうかという話なんだが、日本語も不自由するレベルか？

305 ：仕様書無しさん：04/07/15 22:42

ポインタ使わずに std::vector って実装できるの？

306 ：仕様書無しさん：04/07/15 22:49

>>296
>>297
同意。
っていうか常識だよな。

307 ：仕様書無しさん：04/07/15 22:58

>>305ポインタ使わずにJVMて実装できるの？

308 ：仕様書無しさん：04/07/16 00:03

ポインタ使わないと要素数の上限が固定されちゃうからvectorをポインタなしでやるのは無理。

309 ：仕様書無しさん：04/07/16 00:12

>>1
>「Javaにはポインタがない」とデマを言い張る

これはむしろJava厨だと思うんだがおまえらの職場では違うのか。

310 ：仕様書無しさん：04/07/16 00:24

ぬるぽの語源によりJavaにポインタがあることは明白

311 ：仕様書無しさん：04/07/16 00:28

言語としてはJavaも嫌いじゃないけど
VS.NETにどっぷり使った今となっては
.NETかC/C++じゃない仕事が来るとと('A`)となるのも事実

312 ：仕様書無しさん：04/07/16 00:43

まあ、JavaにはCで言うポインタは無いよ。実装にポインタがあるだけで。
それだけ環境に依存しないということも示していると思う。

313 ：仕様書無しさん：04/07/16 01:03

>>308
使う側がポインタ必須か？って話だと思うのだが…

314 ：仕様書無しさん：04/07/16 02:02

正直、糞コーダを纏めてプロジェクト完成させるのに向いてるんだよ。Javaは。
「漏れ様、ポインタやポポインタまで使ってこんな事できちゃうぜ！」
とか調子乗ったバカが僅かなオーダー削って保守性下げたりするような
自由度のある言語って正直困るのよ。

漏れも、趣味でクリティカルな処理を求められるプログラム書くときには
C/C++系の言語使うけど、大規模な業務用Webアプリとかを仕事で作るときには
Javaがいいなと思う。

結論として
中、大規模業務アプリ：Java,COBOL
小規模業務アプリ：使い慣れてりゃなんでもいい('A`)
ドライバ,組み込み：断然C。リソース増えてるんだからC++でお願いとかほざく奴はカス
ゲーム、趣味：何でもいいが、C++やDelphi使って組むと楽しいな。
偉ぶりたい趣味人：Smalltalk

315 ：仕様書無しさん：04/07/16 04:15

>>314
>保守性下げたりするような自由度のある言語って正直困るのよ。

一理あるね。どんなに賢い奴だって間違いを犯すし。
素人さんにポインタで無差別爆撃された日には一日丸つぶれです。

316 ：仕様書無しさん：04/07/16 04:35

ポインタを使うことによって、何がしたいのか明確に意味が受け取れる、と思う。
Javaのような綺麗なコードからは得られない、書き手の意思が感じれるのがC++だ、・・・と思う。
ただしほどほどに熟練した人に限る

317 ：仕様書無しさん：04/07/16 04:44

>>314

大体同意なんだが、
＞ドライバ,組み込み：断然C。リソース増えてるんだからC++でお願いとかほざく奴はカス
ここだけちょっと？？

継承や多態は使わなくても、クラスわけするメリットはある気がするけど

>>316
例示希望

318 ：仕様書無しさん：04/07/16 05:36

>>316三行目が無かったボコボコに叩かれる意見だな

319 ：仕様書無しさん：04/07/16 08:02

UFJも合併されるというのに藻前らまだそんなこといってんのか?
終わってんだよ、Javaは。まだわかんないかな。

320 ：仕様書無しさん：04/07/16 09:38

>>319
こいつらｺｰﾀﾞですからね。
言語についてくらいしか話できなんですよ。
気楽でいいなー。

321 ：仕様書無しさん：04/07/16 10:55

>>320
おい、そこのテスター
ちゃんと働け
マウスが動いてないぞ！

322 ：仕様書無しさん：04/07/16 11:34

ヘ_ヘ
ミ・・ミ　ということにしたいのですね？
( ° )～

323 ：仕様書無しさん：04/07/16 11:52

お早い夏休みの様で・・・

324 ：仕様書無しさん：04/07/16 12:40

>>317
クラス使わなくてもいい。所謂 “better C”。
それより、「リソース増えてるんだからC++」ってのがｱﾚだな。

325 ：仕様書無しさん：04/07/16 12:41

お前ら・・・JavaとC++くらい両方できないとヤバイよ。
レベルひくっ

326 ：仕様書無しさん：04/07/16 14:26

さあ、いよいよJava死滅のカウントダウンが始まりました。

投資会社が米サン・マイクロシステムズに株式の敵対買収を申し出
http://www.itmedia.co.jp/enterprise/articles/0407/16/news033.html

327 ：仕様書無しさん：04/07/16 18:11

「吸収合併サービスに最適な開発言語はJava」

採用すると漏れなく吸収合併されちゃうという最強言語Java
について語り合いましょう

328 ：仕様書無しさん：04/07/16 18:14

UFJってJavaだったっけ・・・・、あちゃあ・・・

329 ：仕様書無しさん：04/07/16 18:27

Javaにも例の法則があるのか。(ｹﾞﾗ

330 ：MS中：04/07/16 18:40

ウェブ：C#.NET
ツール・プラグイン：C++MFC　or C#.NET
ゲーム：C++ + DirectX，OpenGL

過去も未来もこれで決まり。あと５年はこれで逝ける。

331 ：仕様書無しさん：04/07/16 18:43

Javaだから法則が発動するんじゃない。

Javaってことを謳い文句に売り込む紺猿（なんで言語がセールスポイント？）の
ような詐欺師に騙される程度の経営陣でしかないから法則が発動するんだ。

これは、三菱が現代と提携したから法則が発動したのではなく、
現代のようなところと提携するような経営陣だったから三菱に法則が発動したの
と同じである。

332 ：仕様書無しさん：04/07/16 18:47

>>330
残されたJavaの牙城は組み込み（携帯）のみか・・
それもBREWとかに奪われなければいいがな（藁

333 ：仕様書無しさん：04/07/16 18:55

いつ会社が潰れてもいいように使い捨てJavaでシステム作ってたのか。なるほど。

334 ：仕様書無しさん：04/07/17 01:29

多重継承フェチなオレには
絶対ありえない言語。
まあ、OO入門用言語ですかね。

335 ：仕様書無しさん：04/07/17 02:34

こんなｽﾚ立てるﾋﾏがあるなんて、Java厨ってうらやますぃ～♪

336 ：仕様書無しさん：04/07/17 02:41

ＪａＶａって簡単だ

337 ：仕様書無しさん：04/07/17 04:37

Javaなんて、もう外人たちが必死にフレームワークとか
せっせと作ってくれてるんだから、
もう馬鹿みたいに手続きをだらだらコーディングしていけば
いいんだよ。５Ｋ、６Ｋもあるメソッドを作ればいいんだよ。
同じような機能なら、ソースをコピーすればいいんだよ。
そうすれば、「君はこんなにコードを書いたんだね。すごいね」
とほめられるから。

338 ：69式フリーPG ◆hND3Lufios ：04/07/17 07:15

ﾜﾛﾀ
いやあ、そうなんだけどねｗ

339 ：仕様書無しさん：04/07/17 13:15

>>330
2年目の社会人です。
新人研修でＣ＃やらされたけど一年間仕事で使う機会ありませんでした。

340 ：Hiro：04/07/17 13:22

こんなんわからないよぅ(:_;)

自分の名前を名字と名前に分けて全て小文字で入力したとき、
先頭の文字だけを大文字に変換して表示するプログラムを書き
なさい。
入力　tanaka makiko
出力　Tanaka Makiko

341 ：仕様書無しさん：04/07/17 14:01

>>340
質問にお答えする前にまずあなたの下着姿をＵｐして頂く必要があります。
http://rashoumon.hp.infoseek.co.jp/cgi-bin/imgboard.cgi

342 ：仕様書無しさん：04/07/17 14:01

>>330
C#.NETって何だ？

343 ：仕様書無しさん：04/07/17 14:33

どうでもいいけどここの1は本当に馬鹿だな
終了

344 ：仕様書無しさん：04/07/17 14:51

Java厨は我慢強いと思う。絵栗プスンやほにゃらかADなどのIDEの起動
の遅さに疑問を感じない人が多い。短気な漏れは起動の途中で必ず
おとしてしまうよ。
ステップトレースするのに5分待つのを苦痛に感じない鈍感な人達。
本当に尊敬するよマジで
Java厨はえらいよ。ソフトウェア動作の遅さを業界の標準にしてくれる
人たちということは間違いない。

345 ：仕様書無しさん：04/07/17 16:06

それはほんとに俺も思う。
あんなにモッサリしたのをよく仕事に使おうと思うよ。
Windows起動、eclipse起動、CVSから更新。
もうこれだけの作業してる間に朝飯食えるね。てか食ってる。

346 ：仕様書無しさん：04/07/17 17:17

ちょっとした目の休憩時間さ

347 ：仕様書無しさん：04/07/17 17:34

だからこそ

「吸収合併サービスに最適な開発言語はJava」

採用すると漏れなく吸収合併されちゃうという最強言語Java

なのですね。

348 ：仕様書無しさん：04/07/17 18:25

ヘ_ヘ
ミ・・ミ　ということにしたいのですね？
( ° )～

349 ：仕様書無しさん：04/07/17 19:50

>>344
>短気な漏れは起動の途中で必ずおとしてしまうよ。
>短気な漏れは起動の途中で必ずおとしてしまうよ。
>短気な漏れは起動の途中で必ずおとしてしまうよ。
>短気な漏れは起動の途中で必ずおとしてしまうよ。

350 ：仕様書無しさん：04/07/17 20:00

案件多くて
金とれるから
Java使ってるだけよ

351 ：仕様書無しさん：04/07/17 21:06

Javaはゆとり教育です。

352 ：仕様書無しさん：04/07/17 21:30

Java使いってUMLとかXPとか、言語と直接関係ない部分で自慢したがりますよね。
言語そのもので自慢できるものがないからなんでしょうね。

353 ：仕様書無しさん：04/07/17 21:39

Javaの開発環境って何であんなに重いの？
はっきり言って嫌がらせとしか思えない。

354 ：仕様書無しさん：04/07/17 21:42

いいえ。
CやC++でのメモリ管理、ポインタ操作などの低レベルな概念が言語レベルでカプセル化されており、
クラス設計やユースケースなどのより高度な概念を語れるようになっているだけです。
Javaプログラマは、そういった当たり前の進歩を自慢しません。開発速度の明確な違いが、全てを物語っているからです。

355 ：仕様書無しさん：04/07/17 21:51

emacs + jdkが一番マトモな開発環境のような気が

356 ：仕様書無しさん：04/07/17 23:36

だからこそ

「吸収合併サービスに最適な開発言語はJava」

採用すると漏れなく吸収合併されちゃうという最強言語Java

なのですね。

357 ：仕様書無しさん：04/07/18 00:05

確かに吸収合併するときにシステム的な移行がスムーズに行くということで
合併にかかるコストが下がるという事はあるな。

しかし、それってJavaの問題じゃねぇだろ？

358 ：仕様書無しさん：04/07/18 01:05

>>276
> >>273
> 概念としてのポインタがアドレスではないって事か？詳細求む。
> 実際に変数を格納しているアドレスを指しているとは限らない
> って意味なら確かにそうだがな。
>
> >>256
> 全然違うな。言語というのは用途を想定して設計するものだ。
> １つの言語があればいい、というのは間違ってると思う。

おまいは>>256の意図がわかっていない。
新しい言語が登場しその話題をし実績があり技術者もそろっていようが
コストもかかるまいが自分の使いたい言語が使えなくなることを
恐れて「俺は言語に拘らない」と逃げている香具師が実際に多いんこと多いこと。
とりあえず口先だけでも「言語に拘らない」といっておけば控えめな奴と思ってくれる香具師がいるからな。

359 ：仕様書無しさん：04/07/18 01:07

>>278
> java遅いから使えない。当然反論できないよな。
その遅さが目に見えない体感すら感じ得ない誤差の範囲内であれば
いくらでも反論できるぞw
コンピュータが進化すればするほど反論しやすくなるw

360 ：仕様書無しさん：04/07/18 01:08

>>291のように
「Javaにはポインタはありません。」
といっている香具師は技術者失格

361 ：仕様書無しさん：04/07/18 01:09

>>293
> C++ でも　ポインタ使わずにプログラムできるでしょ
それじゃオブジェクト指向プログラミングなんかろくにできないぞ。
それにデザインパターンも適用できない。

362 ：仕様書無しさん：04/07/18 01:11

いや簡単に実感できるんだが。

363 ：仕様書無しさん：04/07/18 01:45

ネギを値切る

364 ：仕様書無しさん：04/07/18 01:58

>>359
そうだね。
JavaとC++の性能差が1.001倍ぐらいの誤差の範囲ですむのなら問題ないと思うよ。

365 ：仕様書無しさん：04/07/18 02:01

コンピュータが進化するには時間が必要だが、
時間が経つと、もう進化する可能性のないJavaと、まだ進化するC++の性能差は開く一方になるよ。

366 ：仕様書無しさん：04/07/18 02:04

>>365
逆だろ

367 ：仕様書無しさん：04/07/18 02:07

>>365
C++の進化と言うより「コンパイラの進化」と言えば、間違いでは無いと思うんだけどな。

368 ：仕様書無しさん：04/07/18 02:09

ともかく何かしらC++は進化するさ、進化させる人がいるからね、
Javaはもう進化させる人がいなくなるさ、終わってるから。

369 ：コンパイラ屋くずれ：04/07/18 03:13

貴様らにひとついいことを教えてやろう。

Javaは遅い遅いと言われるがなぜか？
近年のJavaVMは、JITコンパイルするのが基本なので、
高頻度で実行されるメソッドは、Cとかと変わらずネイティブな
機械語が走っている。では何故遅い？
理由は色々あるが、①そのひとつに最適化のレベルが低いからである。
JITの場合、実行と並列して（機械語への）コンパイルをするので、
高度な最適化をやっていると時間がかかってしまう。だから
ある程度の最適化しかしていないのが実情だ。
SUNのclientコンパイラに至っては、最適化は殆どしておらず、
どちらかといえばJavaのコードをそのまま機械語にマッピング
しているようなもんだ（ちょっと言い過ぎだけど）。

つまり、Cでショボイコードを書いてもコンパイラが何とかして
最適化してくれるが、Javaはそうは行かない。ショボイJavaコードは
そのままショボイ機械語になる（場合が多い）。

370 ：コンパイラ屋くずれ：04/07/18 03:14

②GCが重い。GCの基本的なアルゴリズムでは、全てのオブジェクトの参照
関係を再起的に辿る。複雑な参照関係を持つプログラムはGCに時間がかかり、
スループットが出ない。

③仮想関数呼び出しが重い。実行時に実行する関数を決定しているのだから
当然だ。オブジェクト指向的なプログラムを多様すればするほど顕著。

371 ：コンパイラ屋くずれ：04/07/18 03:26

Javaで速度を出そうとすると、VMレベルの知識を結構要求される。
さらにオブジェクト指向的なプログラムを捨てる必要がある。

結論：Javaに速度を求めるな、、、、って当たり前の結論に。

372 ：69式フリーPG ◆hND3Lufios ：04/07/18 03:36

(2)は良く聞くな。

373 ：仕様書無しさん：04/07/18 03:52

JavaはいつGCしているのやらわからない。かなり時間がたっても利用メモリが減らない。
最悪のパターンは限界値まできてGCを開始し、終了までユーザ要求を保留することだ。

374 ：コンパイラ屋くずれ：04/07/18 03:54

あとはアレですよ。

OSの機能つかうとき(threadとか、I/OとかGUIとかもろもろ）は、
どうしてもOSのAPI（システムコール）を呼び出してるんだし。
APIに（汎用的で使いやすい）皮かぶせて実行してるんだから、皮の分
重くなるのは当然なわけで。

375 ：コンパイラ屋くずれ：04/07/18 04:00

>>373
SunのVMなら、
-verbose:gc
オプションでGCの発生タイミングが見れる。
っていうかそのくらい知っとけ。

＞かなり時間がたっても利用メモリが減らない。
VMのメモリ使用量が減らないことを言ってるの？
SUNのVMの場合、それは仕様です。一度OSから確保したHeapメモリは
VMは終了まで解放しません。多分他社VMも同じはず。

376 ：仕様書無しさん：04/07/18 04:13

皆様にお聞きしたいことがあります！
ＰＧをはじめたいのですが、ハードの最低環境と、お勧めのＯＳを教えて
ください・・

377 ：仕様書無しさん：04/07/18 04:18

Java屋の開発マシンは高スペックが要求される。

C/C++で開発するのは1GHz/256MBもあれば十分だが、
Javaではかなり苦しい。

378 ：仕様書無しさん：04/07/18 04:27

>>375
IBMのVMです。メモリ使用量は仕様じゃ仕方ないな。
GCで無効な参照を再帰的に探しまくる（マーク＆スイープ）方法なら、明示的にnullをセットするとGC時間が短くなると思うが
間違いないだろうか。まぁでも、明示的にnullセットしていたらC言語でfree読んでる手間と同じになるからなぁ。

379 ：仕様書無しさん：04/07/18 04:31

＞明示的にnullをセット

ﾌﾞﾋﾞみたいだね。

380 ：仕様書無しさん：04/07/18 04:34

>>379
君は勉強し直した方がよさそうだね。

381 ：仕様書無しさん：04/07/18 04:34

旧ＶＢ君はディフォルト機能としてメモリリークを実装しているからな。

382 ：仕様書無しさん：04/07/18 04:36

>>376
Servlet+JSPとかまでやりたいなら512MBぐらいは用意すべし。
OSはLinuxでいいんじゃないすか。Javaは反M$派なんですから。

383 ：仕様書無しさん：04/07/18 04:41

>>382
×反M$派
○非M$派

384 ：仕様書無しさん：04/07/18 04:53

Java厨房＝反（非Java派）派

385 ：仕様書無しさん：04/07/18 05:03

「反」は実力が拮抗している場合にのみ使用が許される。
それ以外のｶｽは「非」でひと括りにするのが正解。

386 ：仕様書無しさん：04/07/18 05:48

Java使わないのは別に構わないが、理解できてないのが
一番情けないぞ。Cにしても同じ。

387 ：いなむらきよし：04/07/18 10:05

キケー！

388 ：仕様書無しさん：04/07/18 10:16

>>364-365

もうとっくに4年前からＪａｖａとＣとの性能差は大して変わらなくなったいわれているのだが。

389 ：仕様書無しさん：04/07/18 10:22

>>369
> Javaは遅い遅いと言われるがなぜか？

C厨の使っているマシンがトロいから

390 ：仕様書無しさん：04/07/18 10:25

>>369
J2SE1.5, 1.6に期待せよ。
J2SE1.5からは.NETのPreJITコンパイラに相当する機能によりJavaがさらに高速化する。
高速化する理由はそれだけではないが。

さらにJ2SE1.6からはJavaでプロセスを管理しやすくなる。

391 ：仕様書無しさん：04/07/18 10:30

>>370
> ②GCが重い。GCの基本的なアルゴリズムでは、全てのオブジェクトの参照
> 関係を再起的に辿る。複雑な参照関係を持つプログラムはGCに時間がかかり、
> スループットが出ない。

これをよんで目を覚ませ。

C/C++ プログラマは明示的なメモリ確保と解放に慣れていて、ガベージコレクタの効率や
利点については懐疑的なようです。私は、一からガベージコレクションを念頭に置いて書
いたプロジェクトと、既存のプロジェクトを GC を使うように方向転換した経験のどちらも持
っていますが：

　　　ガ　ベ　ー　ジ　コ　レ　ク　ト　さ　れ　た　プ　ロ　グ　ラ　ム　の　方　が　高　速　で　す

392 ：仕様書無しさん：04/07/18 10:31

●コーチ屋（こーちや）に注意
主に初心者などをターゲットに忍び寄り、
「次のレースの予想はこうでこうで…」と
勝手にまくしたて（コーチをし）、
当たったあかつきにはまた近寄ってきて
「俺の予想で当たったんだから半分よこしな」
などと言ってくるクズな商売。
もちろん一銭も払うことはありません。
無視、もしくは近くの警備員へ。

393 ：仕様書無しさん：04/07/18 10:31

これは直感に反するかもしれませんが、その理由は：
明示的なメモリ管理の際によく使われる手法は、参照カウントです。
代入があるたびにカウントを増やしたり減らしたリソースを挿入するのは、
速度低下の原因になっています。スマートポインタクラスでラップしても、
速度的な解決にはなりません。（またいずれにせよ、循環参照を削除できな
い参照カウント方式は、一般的な解決策ではありません。）

394 ：仕様書無しさん：04/07/18 10:31

オブジェクトによって獲得されたリソースの解放には、デストラクタが使用されます。
多くのクラスでは、このリソースとは割り当てられたメモリのことです。GCを使えば、
ほとんどのデストラクタが空になり、完全に削除してしまえます。

メモリ管理のためのデストラクタは、オブジェクトがスタックに置かれたときに影響
が顕著になります。例外が発生したときに、全てのスタックフレームでデストラクタ
が呼び出され、メモリを解放するような仕組みが必要となるのです。もしデストラク
タが関係しなければ、例外を処理する特別なスタックフレームを設定する必要がな
くなり、コードは高速に実行されます。

メモリ管理に必要なコードは全てを合わせるとちょっとした量になります。大きなプ
ログラムになるほど、キャッシュに入らない部分が増え、ページングが多く発生し、
プログラムが遅くなります。

GCは、メモリが残り少なくなってきたときのみ実行されます。メモリに余裕があれば、
プログラムは全速力で実行され、メモリ解放に一切時間を取られません。

395 ：仕様書無しさん：04/07/18 10:32

モダンなGCは、過去の遅いものより遙かに発展しています。世代型のコピーGCには、
昔のマーク＆スイープアルゴリズムの非効率さはありません。

モダンなGCはヒープの詰め直しを行います。これによってプログラムが活発に参照す
るページの数を減らし、キャッシュヒット率を高め、スワップ回数が減ります。

GCを使うプログラムは、メモリリークの積み重ねで次第にパフォーマンスが悪化、
という事態に縁がありません。

GCは未使用のメモリを再利用しますから、長時間実行するプログラムが
システムを落とすまでじわじわとメモリを食いつぶす、いわゆる"メモリリーク"に陥るこ
とがありません。 GC付プログラムは長時間の安定性があります。

GCを使うプログラムには、ポインタ周りの見つけにくいバグがほとんど存在しません。
既に解放されてしまったメモリを指す参照が存在しないからです。メモリを明示管理する
コードが必要ないので、そのようなコードかが生むバグもありません。

GC付きプログラムは、開発もデバッグも高速です。何故なら、メモリ管理のコードを開発
する必要もデバッグする必要もテストする必要も、管理する必要もありませんから。

GC付きプログラムは、有意に小さくなります。メモリ解放を管理するコードや、メモリ
を解放するための例外ハンドラが不要になるためです。

396 ：仕様書無しさん：04/07/18 10:33

C++だけに依存しすぎるプログラマも駄目人間だな

397 ：仕様書無しさん：04/07/18 10:38

>>370
> ②GCが重い。GCの基本的なアルゴリズムでは、全てのオブジェクトの参照
> 関係を再起的に辿る。複雑な参照関係を持つプログラムはGCに時間がかかり、
> スループットが出ない。
>
> ③仮想関数呼び出しが重い。実行時に実行する関数を決定しているのだから
> 当然だ。オブジェクト指向的なプログラムを多様すればするほど顕著。

まったく未だにこのような>>370のような都市伝説を信じている愚か者がいるのか。
もっと勉強してから出直してこい。

こいつもしっかりとよんでお前のvirtualがデフォルトであること(finalでないこと)が重いという誤解を
解きほぐせ。

Javaの理論と実践: パフォーマンスの都市伝説
ガーベッジ・コレクターなどのプログラミングに棲みついているワニについて
http://www-6.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html

398 ：仕様書無しさん：04/07/18 10:41

399 ：仕様書無しさん：04/07/18 10:44

>>344
ぶっちゃけおまえのマシンが遅すぎなんだよ。
速いマシンに買い換えればお前の悩みも即座に解決される

それと、お前の使っているJavaが古すぎ。それと、お前の動かしているプログラムの
アルゴリズムがショボすぎるだけ。

400 ：仕様書無しさん：04/07/18 10:46

都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる

この神話については、10月のコラム (参考文献を参照) で紹介済みなので、ここで詳しい説明は繰り返しません。
多くの記事では、クラスやメソッドを final として宣言することが推奨されています。これは、finalにすることにより、
コンパイラーがそのクラスやメソッドを簡単にインライン化できるため、パフォーマンスが向上するはずだという理
由によります。これは確かによくできた理論です。しかし、真実でないのは残念としか言いようがありません。

同期化の神話と比べてこの神話が面白いのは、裏付けのデータが何もなく、単にもっともらしく見えるだけで
あるという点です (同期化の神話には、欠陥があるとは言え、少なくともそれを裏付けるマイクロベンチマーク
があります)。誰かがきっとこうに違いないと決め付け、自信たっぷりに他人に話したところ、それが噂になり、
大きく広がってしまったに違いありません。

この神話の危険なところは、同期化の神話とまったく同様に、実際には存在してもいない
パフォーマンス上のメリットを求めて、開発者がオブジェクト指向の優れた設計原則を破る
ことになりかねない点です。クラスを final (非virtual)にするかどうかは、そのクラスが何を実行し、
誰によってどのように使用されるか、および何らかの用途で継承される可能性があるかどうかに基づい
て決定される設計上の判断です。クラスが不変なので final(非virtual) にするのであれば、それは適切
な理由と言えます。また、継承を想定せずに設計された複雑なクラスを final(非virtual) にすることも理
にかなっています。しかし、クラスを final(非virtual) にすると速くなるとどこかに書いてあったというだけ
では、たとえそれが真実であってもそうする理由にはなりません。

401 ：仕様書無しさん：04/07/18 10:46

これでJavaをなめてかかっているC++厨の正体が
数年前のJavaの知識しかもっていないただのアフォだということが暴露され証明されたわけだ。

402 ：仕様書無しさん：04/07/18 10:51

>>373
> JavaはいつGCしているのやらわからない。かなり時間がたっても利用メモリが減らない。
> 最悪のパターンは限界値まできてGCを開始し、終了までユーザ要求を保留することだ。

java.lang.ref.Referenceの使い方くらい覚えろや。

こいつは、Javaで各オブジェクトに対してGCを発動する優先度を設定できることもしらんようだ。

こういうクズがJavaテクノロジにたいしてタカを括っていることことがよくわかる例だな。

こいつでもよく読んでアフォな発言を晒さないようにな。
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/package-summary.html

403 ：仕様書無しさん：04/07/18 10:53

GCとReferenceクラス
http://www.dmz.hitachi-sk.co.jp/Java/Tech/jre/reference.html

Referenceクラスとは？

　このクラスを使うと、まだ参照可能な変数に代入されっぱなしのオブジェクトだったとしても、
強引にGCの対象としてしまう、ということが実現できます。GCされてしまった後は、そのオブジ
ェクトは「null」に置き換えられます。

　たとえばオンメモリキャッシュのように、不特定多数のオブジェクトにいつでもアクセスできる
ようにしておきながら、もしメモリが不足してきたようなら一旦解放して、必要なときにまたその
オブジェクトを生成すれば良いような状況でReferenceクラスは役に立ちます。

　Referenceクラスには「WeakReference」「SoftReference」「PhantomReference」の３つのサ
ブクラスがあって、それぞれ「どんな条件でGCの対象とするか」が異なっています。

404 ：仕様書無しさん：04/07/18 10:54

このスレをみているとC++厨の頭がますます悪く見えてくるな。

405 ：仕様書無しさん：04/07/18 10:55

C++厨のJavaのガーベッジコレクタに対する誤解、無知がまたしてもこうして露呈され続けるのであった。

406 ：仕様書無しさん：04/07/18 10:59

ガベコレがオブジェクトを解放するためにメモリブロックを監視するから
トロいんだよ。ｱﾌｫどもが。

407 ：仕様書無しさん：04/07/18 11:00

構造体が使えれば殆ど解決できるのに

408 ：仕様書無しさん：04/07/18 11:09

ほんとなんでそんなに必死なんだろ

409 ：仕様書無しさん：04/07/18 11:19

C++がどうあれJava死滅というのが気に入らないのでしょ

410 ：仕様書無しさん：04/07/18 11:22

だってしょうがないことじゃん。そりゃやつあたりといふもの。

411 ：仕様書無しさん：04/07/18 11:22

パフォーマンスを落としてでも、Javaの安全性と生産性が欲しかった
ただ、それだけだ

Javaに求められるのは最低限のパフォーマンスと最高の生産性、そして安全性だ

412 ：仕様書無しさん：04/07/18 12:00

>>375
>-verbose:gc
>オプションでGCの発生タイミングが見れる。
少なくとも、コーディングした段階では分からないのは気持ち悪いかも。
漏れのところはJVMも作っているが、GCが絡んだ障害ってのは少なくないからな。
簡単に信頼するのは正直どうかと思う。

>>388
体感的にC+＋より、遅いと分かるのだが気のせい？
まぁ、漏れは少なくとも皆が言うほど遅くは無いと思うけど。
それより、CやC++の性能なんてのは作り手やコンパイラの最適化、ライブラリによって
雲泥の差が出るんだけどな。

>>394
ずっと、気になってたんだけど、それって諸刃の剣になってない？
最近、JVMが異常にメモリを食うようになってきたんだけど...

413 ：仕様書無しさん：04/07/18 12:06

C++に比べたらJavaは糞だが、比べなければいい言語だよ

414 ：仕様書無しさん：04/07/18 12:41

>>402
正直、そんな事はJVM側で効率良く管理して欲しいよ。
JavaでC++と同じようにオブジェクトの管理を自分でやらないと駄目なんてメンドイ。

ケース・バイ・ケースではあるとは思うけど。

415 ：仕様書無しさん：04/07/18 12:51

>>411
大ばか者。
現場ではそんな理屈は通用しないのだ。

「他社製品の○○はてめぇの所の2倍の性能が出るぞぉ！ゴルァ」

っと平気で言われる。

416 ：仕様書無しさん：04/07/18 12:57

>>412
> 体感的にC+＋より、遅いと分かるのだが気のせい？
パフォーマンスチューニングスキルが足りないぞ。
いかにしてJavaコードをJavaプログラミングだけで速くするかという職人業を
身につけろ。

417 ：仕様書無しさん：04/07/18 13:00

>>412
> ずっと、気になってたんだけど、それって諸刃の剣になってない？
> 最近、JVMが異常にメモリを食うようになってきたんだけど...

おまえ、>>402-403のリンク先をちゃんと読んだか。

最近のJVMは複数のJavaを起動してもメモリを無駄に重複消費しにくいように設計されている。
ただし古いJavaプログラムの挙動については預かり知らんが。
最新バージョンのコンパイラでコンパイルし直すなり、コーディングし直すなりの工夫を汁。

418 ：412：04/07/18 13:02

>>416
>パフォーマンスチューニングスキルが足りないぞ。
確かにそうだなぁ。
性能を出すためにJNI経由でC+＋に処理を任せた事がある。(w

419 ：仕様書無しさん：04/07/18 13:04

>>414
> >>402
> 正直、そんな事はJVM側で効率良く管理して欲しいよ。
面倒臭い処理大好きなC++マンセーの癖にそんなことで面倒臭がっているのか。

> JavaでC++と同じようにオブジェクトの管理を自分でやらないと駄目なんてメンドイ。
使ったことが無い奴が何を言っているのか。
>>403を良く嫁。サンプルコードに加え日本語で丁寧に説明されているだろうが。
ArrayListや配列オブジェクトなど巨大になりそうなオブジェクトを取り扱うときに大いに役立つものだろう。
小さく数が少ないオブジェクト群にいちいち使うものではない。

420 ：仕様書無しさん：04/07/18 13:04

C/C++とJavaで速度とメモリ使用量を
比較できるようなサンプルは無いかな

421 ：仕様書無しさん：04/07/18 13:06

>>406
>>402-403をもう一度読み返せ。
お前のマシンとお前の理解力の無い脳みそとC++のデストラクタが腐っているから
トロいんだよ。ｱﾌｫどもが。

422 ：仕様書無しさん：04/07/18 13:08

>>418
話にならん。Javaだけでやるのが通であり漢なのだ。

423 ：仕様書無しさん：04/07/18 13:09

Javaのパフォーマンスを上げたければこれを嫁

J2EEパフォーマンスチューニング
http://www.atmarkit.co.jp/fjava/rensai/j2eeprfm01/j2eeprfm01_1.html

424 ：仕様書無しさん：04/07/18 13:10

パフォーマンスチューニングなんてしなきゃいけないほど糞な言語なら
最初からC++でやったほうがいいんじゃねーの？

425 ：仕様書無しさん：04/07/18 13:10

>>407
> 構造体が使えれば殆ど解決できるのに

>>407のような構造体を押しつける者　＝　オブジェクト指向を否定する者　＝　時代遅れな老人

426 ：仕様書無しさん：04/07/18 13:22

>>422
>話にならん。Javaだけでやるのが通であり漢なのだ。

その台詞、

>話にならん。Lisp だけでやるのが通であり漢なのだ。

とか、

>話にならん。アセンブラだけでやるのが通であり漢なのだ。

だと純粋に「ｶｺｲｲ!」と感じるんだけど、何で Java だと
こうなってしまうんだろう。

不思議だ・・・

試しにこんなのも書いてみる。。。

>話にならん。COBOL だけでやるのが通であり漢なのだ。

427 ：412：04/07/18 13:27

>>417
>>402-403の内容の事は知っている。
>>最近のJVMは複数のJavaを起動してもメモリを無駄に重複消費しにくいように設計されている。
共有メモリを使っているって事？
だから、メモリ効率自体はそんなに悪くないとでも？
実際にメモリ測定を行ったらJVMは凄くメモリを使用したんだがな。

>>419
>面倒臭い処理大好きなC++マンセーの癖にそんなことで面倒臭がっているのか。
あぁ、めんどい。
それと、C++プログラマーであり、Javaも使っているがはっきり言ってC++は嫌い。
だからこぞ、Javaに期待してるんだけどね。
少なくとも今の時点では「C++と同じように」オブジェクトの管理したり、性能を意識したコーディングを
しないと駄目なんだろ？

428 ：412：04/07/18 13:45

>>422
>　話にならん。Javaだけでやるのが通であり漢なのだ。
正直言って意味が無い。
個人でやるのは勝手だが顧客先ではちゃんと妥協してくれる事を祈るよ。

性能を出すだけなら、アセンブラやC/C++の方が簡単だからな。

429 ：仕様書無しさん：04/07/18 14:34

>>397
脱仮想化の実装どうなってるのかしってるのか？
確実に明示的な呼び出しのほうが速いよ。

そのIBMの記事はもっともだ。
「クラスを final (非virtual)にするかどうかは、そのクラスが何を実行し、
誰によってどのように使用されるか、および何らかの用途で継承される可能性があるかどうかに基づい
て決定される設計上の判断です。」
↑はしごく正しいことを言っている。このとおりに設計すべきだと思う。
ただ、速度が出るかどうかは別問題だ。

トレードオフなんだよ。速度とオブジェクト指向的なプログラミングは。

430 ：仕様書無しさん：04/07/18 14:35

性能なんてどうでもいいじゃん

431 ：仕様書無しさん：04/07/18 14:44

Delphiでいいじゃん

432 ：仕様書無しさん：04/07/18 14:47

>>411
優れたパフォーマンス、高い生産性、そして信頼できる安全性
それがC#ですよ

433 ：仕様書無しさん：04/07/18 14:48

>>424
> パフォーマンスチューニングなんてしなきゃいけないほど糞な言語なら
> 最初からC++でやったほうがいいんじゃねーの？

それをいったらはっきしいってC++の方が糞だろうよ。
C++でパフォーマンスチューニングすることがどれだけ大変なことかわかってない
からそういう浅はかな発言ができてしまう。

434 ：仕様書無しさん：04/07/18 14:51

速度なんて、同じのを横に並べてみなきゃ客には分からないって
特にJavaを使う規模の業務系アプリだとそんなことあり得ないから、客にはパフォーマンスがどうとか分からん
「これだけのシステムだからしょうがないです」で納得させることができる

だから、生産性が高くてバカでもできるJavaを使うのですよ

435 ：仕様書無しさん：04/07/18 14:51

>>432
> >>411
> 優れたパフォーマンス、高い生産性、そして信頼できる安全性
> それがC#ですよ
C#なんてC++とJavaとを足して2で割って混ぜてはいけないものを無理矢理混ぜたものに
信頼性も生産性もないがな。Javaに不満があるからといってそこでC#を選ぶ奴はバカだ。
Javaに不満があるならC#よりもC++を選んだ奴のほうが賢い。
その逆も真なり。つまり、C#は中途半端な言語だということだ。

436 ：仕様書無しさん：04/07/18 14:54

>>434
何度もこのスレで言っているものもいるが
Javaの初歩はだれでもバカでもできるがJ2EEという高度なテクノロジは
バカには使いこなすことができない。実際、EJBを使える奴は少ないことがその証拠。
Javaでサーバで動くものはサーバの性能が通常のPCの性能を遙かに上回るため気にしなくてもいいケースが多い。

437 ：仕様書無しさん：04/07/18 14:58

>>434
J2EEはだれもが理解するのに苦労しているといっている。
J2EEは非所に敷居が高く、使いこなすには要求されるスキルもかなり高いものになっている。
J2EEを使いこなすにはTCP/IP, データベース.分散などC++しかしらない者には理解できない様々な技術スキルを必要とする。
Javaがバカでもできる言語ではないことをこのJ2EEが如実に物語っている。

実際、J2EEは敷居が高すぎて他のバカでもできるPerl/PHPに逃げた者もいるほどだ。

438 ：仕様書無しさん：04/07/18 15:01

>>427

昔のJVM,Javaプログラムは、プログラム起動した数だけJVMまで起動するという問題を抱えていた。
今のJavaではその問題も解消されている。だが、古いJavaプログラムを今でもそのまま使う場合は
その限りではない。

439 ：仕様書無しさん：04/07/18 15:03

>>426
おまえがJavaを毛嫌いしているだけだよ。
よほどJavaに関する仕事で何か嫌な目にあったんだな？

440 ：仕様書無しさん：04/07/18 15:07

>>436
そのEJBも3.0によって敷居が低くなるわけだが．．．

441 ：仕様書無しさん：04/07/18 15:08

>>427
> >>417
> >>419
> >面倒臭い処理大好きなC++マンセーの癖にそんなことで面倒臭がっているのか。
> あぁ、めんどい。
Javaの堅牢な例外処理ならそんなに面倒なことではなかれ。
そのまえに、java.lang.ref.Referenceを使う前にプロファイラでどこに負荷がかかっているか、どのクラス、メソッドが
最も多く呼び出されているか、どこでメモリを大量消費しているか、など
をデータをグラフなどにとってからそれらを使うかを判断するだろう。
本当にそれを使うのはどこか後で考えればよいことだ。
最適化処理というのはプログラムができあがってからやるものだ。二の次だの処理だ。
最初からやってはソースコードが読みにくくなる上に混乱しバグを増大させ悪循環を起こす結果に終わる。

> 少なくとも今の時点では「C++と同じように」オブジェクトの管理したり、性能を意識したコーディングを
> しないと駄目なんだろ？
C++と同じようにとは具体的にどういうものなのか？

442 ：仕様書無しさん：04/07/18 15:10

C#使えばええやん

443 ：仕様書無しさん：04/07/18 15:10

>>440
新たにアスペクト指向という技術をどこまで強がりを言っているC++厨が吸収できるか？
にかかっているな。

444 ：仕様書無しさん：04/07/18 15:11

>>436
正直、このスレを読んでいると
「J2EEがあるから、Javaは難しいんだ！」
と、言っているように感じる。

J2EEを理解するのとJavaを理解するのは全く別のことなのに。

445 ：仕様書無しさん：04/07/18 15:12

つまりJavaは分散処理サーバ専用言語ってこと？

446 ：仕様書無しさん：04/07/18 15:13

>>442
>>435

C#なんて

JavaとJavaScriptの中間のようなActiveXみたいなもん。
んでセキュリティ上の問題からActiveXは却下されたっけカナ。

C#も動脈(Java)と静脈(C++)が途中、心臓で混ざってしまう両生類
にように燃費が悪い。

447 ：仕様書無しさん：04/07/18 15:15

>>444
「Java」というのは広義ではJ2EE, J2MEのほかJava Cardなどを含めたテクノロジーであり言語ではない。
言語としての「狭義なJava」について語りたければ広義のJavaとの区別をつけるために
「Java言語」と読んだ方がいい。

448 ：仕様書無しさん：04/07/18 15:24

>>447
>言語としての「狭義なJava」について語りたければ広義のJavaとの区別をつけるために
>「Java言語」と読んだ方がいい。
これってSunとかが提唱しているんだっけ？
かなり誤解している人が多いと思うな。

C厨が馬鹿にしているのは「Java」ではなく、「Java言語」でない？
話が全然、かみ合ってないようにも感じたしな。

449 ：仕様書無しさん：04/07/18 15:36

>>441
>C++と同じようにとは具体的にどういうものなのか？
java.lang.ref.Reference等は使わず、オブジェクトの管理などはJVM側で効率良く、
全てやってもらいたいと思っただけなんだがな。
基本的にオブジェクト管理はGC任せであるべきだろう？

450 ：仕様書無しさん：04/07/18 15:44

だからこそ

「吸収合併サービスに最適な開発言語はJava」

採用すると漏れなく吸収合併されちゃうという最強言語Java

なのですね。

451 ：仕様書無しさん：04/07/18 15:45

なんでも自分でやらないと気がすまないC++厨

452 ：仕様書無しさん：04/07/18 15:47

まぁどっちにしろ終わっているしね

453 ：仕様書無しさん：04/07/18 15:49

言語がどうとかじゃなくて、とりあえずここにいる香具師は終わってるね
俺も含めて

454 ：仕様書無しさん：04/07/18 15:49

J2EE程度のものを高度といわれると正直困る。
こんなの、誰でもかんたんに出来るよ。

C++のいやなところはifdefとかtypedefとかかな。
俺はもっとロジックのみを考えて組みたいんだよ！

低レベルな作業は低級言語に近いC/C++系でお前らよろしく頼む！

455 ：仕様書無しさん：04/07/18 15:51

Javaにもマクロ機能が欲しい。

456 ：仕様書無しさん：04/07/18 15:53

>>455
んなもんプログラミング言語の範疇じゃないだろ。

藻前のやりたいことはAoache AntやEclipseのようなIDE,
Jakarta Velocityですべてできる。

457 ：仕様書無しさん：04/07/18 15:54

>>454
藻前のいっているJ2EEとはServletやJSP, JDBCなどに限定したものだろ。
EJB IIOP, RMIとかJNDIとかそのほか全部ひっくるめて
J2EEパターンを参考にした設計のこととか考えていないだろ。

458 ：仕様書無しさん：04/07/18 15:55

>>456
J2SEだけでやりたいんだよ。

459 ：仕様書無しさん：04/07/18 16:02

C++でJ2EEに変われる無償のライブラリって何？

460 ：仕様書無しさん：04/07/18 16:13

Javaが難しいとかJ2EEが難しいとか言ってるのは何でも記憶しようとする香具師
Javaや関連技術はドキュメントが分かりやすくまとまってるから難しくない
理解できないのは頭が悪いだけ

461 ：仕様書無しさん：04/07/18 16:16

> Javaが難しいとか
こんなこと言う奴は人っ子一人いないだろ

462 ：仕様書無しさん：04/07/18 16:25

>>461
あなたにとっては日本語の方が
よっぽど難しいようですね。

463 ：仕様書無しさん：04/07/18 16:25

Java はあと三年で終わる。

464 ：仕様書無しさん：04/07/18 16:31

C++でJ2EEだのEJBだのの機能を提供するライブラリって何？無償？

465 ：69式フリーPG ◆hND3Lufios ：04/07/18 16:35

Javaに条件コンパイルが欲しい。

466 ：仕様書無しさん：04/07/18 17:23

>>464
無いよ。悪いかよ、この乞食が！

467 ：仕様書無しさん：04/07/18 18:14

最近はC++とJavaの速度は変わらないと言うけど
実はC++のDebug版とJavaのRelease版を比べての話なんだよな。

468 ：仕様書無しさん：04/07/18 18:23

JavaはCと同程度に速いって事にしたくて仕方が無い人なんだよ
もう笑うしかない

469 ：仕様書無しさん：04/07/18 18:32

JavaはCと同程度に速い。

起動時間とGCのもたつきを除けば。

470 ：仕様書無しさん：04/07/18 19:15

>>459
> C++でJ2EEに変われる無償のライブラリって何？
Jakarta, GNU, JBoss

471 ：仕様書無しさん：04/07/18 19:29

>>467
昔2chでもJavaがＣより速くなるというケースを見たことがないのか？

-serverオプションでかなり高速化する。

472 ：仕様書無しさん：04/07/18 19:32

JavaはCよりも速い!?--驚異の"-server"オプション
http://www.geocities.jp/toshio16369/column/021108a.html
　　

473 ：仕様書無しさん：04/07/18 19:36

ランタイムライブラリで面倒見ていたメモリ管理が、GCの機嫌を伺うだけで、
とりあえずクラッシュやリークからは免れるのだぜ。凄いだろ。

474 ：仕様書無しさん：04/07/18 20:22

クラッシュしてくれたほうがありがたい。
ガベコレが無いと正常動作しないかもしれないコードなんて、恐ろしくて重要なソフトの開発には使えないよ。

475 ：仕様書無しさん：04/07/18 21:01

メモリ領域の解放をどうしてもコーディングしたいと思ったのはＣ＋＋初めて1週間だけだったなぁ

476 ：仕様書無しさん：04/07/18 21:14

そのうちD言語が双方のシェアを奪・・・えたらいいね

477 ：仕様書無しさん：04/07/18 22:10

>>472

要素数=30000で

g++ (GCC) 3.3.4 (-O2でコンパイル)
23.25user 0.00system 0:23.66elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (8major+228minor)pagefaults 0swaps

java(build 1.4.2_05-b04, 実行時 -serverオプション付き)
41.93user 0.07system 0:42.05elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2major+2535minor)pagefaults 0swaps

C3 400MHzではJavaの完敗（ｗ

478 ：仕様書無しさん：04/07/18 22:12

>>476
そしたら感動的だね

479 ：仕様書無しさん：04/07/18 22:31

27 名前：仕様書無しさん[] 投稿日：04/07/18 20:03
つうかさ、JavaPGって殆ど派遣じゃん？

企業はJavaの将来性に疑問を持ってたから、Javaの教育にコストをかける
ような無駄なことをせず、ﾄﾞｶﾀを使ってたんだけどね。

社員にしちゃうと、使い捨て出来ないでしょ？（藁

480 ：仕様書無しさん：04/07/18 22:44

>>477

漏れのせろりん566ではビミョー

gcc(2.95.3) -> 6.02sec
java(1.3.1_09) -> 8.69sec

gccの最適化が進んだのかも

481 ：仕様書無しさん：04/07/18 23:34

>>477
おいおい、坊や、そんな団栗の背比べしてどうするんだいw
大してかわらないしのう。
レスポンス性能では勝っても
スループット性能では結局Javaに負けてしまうんだしw

C++ってのは短距離走選手みたいなもんなんだよ。
そしてJavaはマラソン選手みたいなものだよ。

482 ：仕様書無しさん：04/07/18 23:48

>>477
最適化レベルO2でそのレベルだとO3/O4辺りだとコテンパンにできそだね

483 ：仕様書無しさん：04/07/18 23:50

>>472
AthlonXP2000+なのに
>g++ -O2 -mcpu=pentiumpro
は無くないか？gccのバージョン書いてないから分からんけど
古いgccでmcpu=athlon-xpが無かったのかも知れんが。
それに、Java側で高速オプション使うんだったらgccもO3/O4指定するべきだろ。
はじめから結果を決めていてそうなるように弄ったようにしか見えんよ。

484 ：仕様書無しさん：04/07/19 00:15

Baburuかよっ、と突っ込む人は居なかったのか

485 ：仕様書無しさん：04/07/19 00:33

開発は害虫(ﾄﾞｶﾀ)、運用は正社員だから社員はブチ切れまくりだよ。
何でこんなトラブル続きの糞コード書きやがるんだ、って。
苦情を言おうにもその害虫の身元も分からないしね。派遣の派遣だから。

Javaって業界の癌だよな。とっとと駆除してほしい。でもゴキブリ並みにしぶといんだろうな。

486 ：仕様書無しさん：04/07/19 00:39

ああ・・ゆとり教育の弊害が・・

487 ：483：04/07/19 00:53

ついでにテストしてみた。
左から件数,real,user,sysね。
Xeon3.06*2(1MBキャッシュ) Mem4Gで

gcc3.3.3
gcc -O3 -mcpu=pentium4
30000 0.883 0.880 0.000
50000 2.455 2.450 0.000
100000 9.939 9.930 0.010

java (build 1.4.2_04-b05) -serverオプション付きで起動
30000 1.337 1.360 0.000
50000 3.442 3.460 0.020
100000 21.254 21.210 0.030

最大で2倍以上の差がついた。

488 ：仕様書無しさん：04/07/19 01:27

こんなくそつまんねー事やってJava様は速い！いやいやC++ﾀｿのほうが早いとか
本気で言えると思ってるのか？（；´Д｀）また、言った所で何の意味があるのよ？

そもそも前提としてJavaは実行速度をある程度犠牲にしてでも
一度書けばどこでも走るという理想を夢見てる言語だからC++に総合的な速度で
勝てるわけが無いし、そこら辺を語っても仕方が無い。

489 ：仕様書無しさん：04/07/19 01:55

処理速度が命の制御系とかではJavaは使えんということだ。

490 ：仕様書無しさん：04/07/19 02:18

お前らがD言語を育てれば仲直りできる。
コンパイラの限界に合わせたOOP言語だから速度も十分。

491 ：仕様書無しさん：04/07/19 10:16

>>483
>はじめから結果を決めていてそうなるように弄ったようにしか見えんよ。
当然でしょ。

492 ：仕様書無しさん：04/07/19 10:16

>>487
測定時間をもっと伸ばせ。
短距離走ではなく長距離走で測定せよ。
サーバサイドでJavaがC++よりも優位に立っている
理由が見えてこないぞ。

493 ：仕様書無しさん：04/07/19 10:18

とりあえず団栗の背比べなど意味無し。
んなことでムキになっているC厨はもう頭が悪いどころか頭が古い。C厨の頭は化石になっているんだよ

494 ：仕様書無しさん：04/07/19 10:20

>>487
単位がわからんよ　ミリ秒なのか秒なのか分なのか？

もしそれが秒だとしたらほんどに団栗の背比べだ。
サーバアプリの稼働には損傷がないってところだな。

495 ：仕様書無しさん：04/07/19 10:23

>>492
どれだけ伸ばしたら逆転するか示していただけませんか？

496 ：仕様書無しさん：04/07/19 10:24

Javaは人海戦術を行う業務系で威力を発揮する
それは、決して速度では無い

497 ：仕様書無しさん：04/07/19 10:28

-severオプションまで惨敗で必死だな（ｗ

>494
timeコマンドも知らないお子様ですか？

498 ：仕様書無しさん：04/07/19 10:31

>>495
数値が逆転しなければ顧客に渡せないものではないだろう。
遅くてもバグを減らすことのほうが重要だ。特に金融系、基幹系、ミッションクリティカル系では。

499 ：仕様書無しさん：04/07/19 10:31

まぁ、どっちにしろUFJの吸収合併で
Java=ナチュラル・ボーン・負け組
のイメージができあがっちゃったから
ここから回復は難しいんじゃないの?

もうね、今時はJavaか三菱自動車かって感じじゃん、なんとなく。
まぁ雪印みたいなもんじゃないの?

500 ：仕様書無しさん：04/07/19 10:32

C厨のほうが人海戦術むきだけどな。

Ｃ厨にエンタープライズコンピューティングなんぞ不可能。
Ｃ厨にはエンタープライズ(進取)性など無いから。

501 ：仕様書無しさん：04/07/19 10:34

そう、Ｃ厨はエンタープライズ(進取)性がたりないから
考える必要の無いところまで常に速度のことばかり言って
ゴタゴタネチネチと拘る。
つまり、C厨にはフロンティアスピリッツが足りないんだろう。

502 ：仕様書無しさん：04/07/19 10:37

CやC#,.NETのほうが三菱自動車らしさを醸し出している感じだな。
いつまでも存在するバグを必死に隠蔽するのはC厨に多いのは事実だし。
Cではコンパイラがろくにバッファオーバーフローもチェックしてくれないし例外処理は甘いし

セキュアプログラミングスキルの足りない香具師が多いし。まさにC厨は三菱自動車だね。

Javaではそう簡単にバグを隠すことはできないから信頼性が高い。
コンパイラが鬼のように厳しいからね。ちょっとしたことではコンパイルを通してくれないし
実行時にも強力に例外をスローしてくれる。
そう簡単にバグを隠蔽することできないためJavaプログラマは必然的に設計を怠らずに
しっかりと計画的にプログラミングするようになるわけだ。

503 ：仕様書無しさん：04/07/19 10:39

へぇ～Java厨って夢見がちなのね。
大宇宙を冒険したいのかも。
お友達にバルカン星人がいるらしい。
大人になりきれないピーターパンだね(w。

504 ：仕様書無しさん：04/07/19 10:42

ある案件でJavaよりもC/C++/COBOLを選ぶ理由があるとすれば
仕方がなく選ぶってのが現実だろう。

既存の資産が、どんなバグが潜んでいるか解らないC/C++で作られており
それをどうにかしたいときとかに。

大規模開発で新規にやる場合はC++を無理して使う傾向は少ない。これからは徐々に減っていくだろう。
新規プロジェクトでC/C++が活躍する場所は非常に少ない。
なぜならC/C++は大規模開発に不向きだからだ。

C/C++が活躍する場所は、既存のプロジェクトの延長、OS、ドライバ開発、組み込み系のみに止まった。
その世界でC/C++は細々と生きてゆくことだろう。

505 ：仕様書無しさん：04/07/19 10:44

>>502
さすがにUFJの批判はできないんだな。三菱自動車にすり替えですか?
でも三菱の悪口いって大丈夫?引き取り先でしょ(w

506 ：仕様書無しさん：04/07/19 10:47

C厨のほうが夢見がちだろ。
Javaの仕事したことがないからわからないんだろうな>>503は。
バルカン星人とかいっている>>503はいつの世代の香具師だ？
30,40過ぎのオッサンだろ？　

30,40過ぎのオッサンならJavaを否定したくなるのも解らないでもないなw

>>503は思考が化石化しているからな。20年前の考え方もいつまでもいつまでもひきずっているからな。
なんでここまでJavaに否定的なのかとおもったら、
その理由は>>503みたいなJavaの時代についてゆけないオッサンばかりがJavaを必死に叩いているってことか。
長年来の謎が氷解したよ。

507 ：仕様書無しさん：04/07/19 10:48

>大規模開発で新規にやる場合

ってのは、結局、大規模な吸収合併が控えている場合のことですかね?
クワバラ、クワバラ(w

508 ：仕様書無しさん：04/07/19 10:49

>>505
お前UFJの事件を全部Javaのせいにしているな。かなり頭が悪いだろ。
全部Javaだけで作られていると勘違いしているだろアフォなことに。
C++,Cしかできない奴ってどうしてこんなに頭が悪いんだろ。
C++厨、C厨は脳が退化しているんだろうね。

509 ：仕様書無しさん：04/07/19 10:50

>>506
だから現実を見ろよ。UFJは吸収合併されちゃったぞ。
夢みてんじゃねーよっての(w

510 ：仕様書無しさん：04/07/19 10:50

>>505のように脳内変換しかできないくらいにC厨は頭が悪くなってしまったw

511 ：仕様書無しさん：04/07/19 10:51

>>507
もう論理的に反論できなくなったか？
40代のおっさんは頭が堅くなって新しい考え方についてゆけなくなったか？(藁

512 ：仕様書無しさん：04/07/19 10:51

でもJava厨大変だよね、まっ頑張ってね(w

513 ：仕様書無しさん：04/07/19 10:52

>>509
いいたいことはそれだけか？(藁
UFJごときでJavaが使えないとほざいているんだろ(嘲笑
40代のオッサンは脳細胞が死滅して新しい考え方を受けいられら無くなったんだな(藁

514 ：仕様書無しさん：04/07/19 10:54

おおっすげっ
>UFJごとき
だってさ。

凄いなぁ、さすが夢見るJava。

515 ：仕様書無しさん：04/07/19 10:55

Javaって要はコボルだろ？

516 ：仕様書無しさん：04/07/19 10:56

コボルは実用になった。
Javaはそこまでいってない。

517 ：仕様書無しさん：04/07/19 10:56

C++厨のほうが大変そうだけどな。
C/C++のコンパイラって頭悪いからバッファオーバーフローとか
監視してくれないしメモリリークをろくに監視もしないから
C/C++厨はくだらないことに余計に無駄に仕事を費やすことになるんだよねw
どの部分にどのデザインパターンをどのように実装しようか、なんて設計を
考えている暇もなく「低レベル」なことばかりやって大変だねw
C++厨は高級言語に部類に入りながらC/C++の低級な機能しか使うことができないなんて
大変だねw がんばれC++厨（藁

518 ：仕様書無しさん：04/07/19 10:58

マジでCOBOLマンセーなオッサンがいるのか(ﾜﾗ

40過ぎたハゲがこのスレで必死にJavaを叩いているのか(嘲笑

時代の流れについて来いよ(ﾜﾗ

ついていけないから20代の俺様が引っ張ってやるよ(ﾜﾗ

519 ：仕様書無しさん：04/07/19 10:58

別に言語はなんでもいいと思うけどね。
Javaじゃなければ。
なんでC++叩くのかがわからんけど。

520 ：仕様書無しさん：04/07/19 11:00

そもそもJavaなんて論外だけどな。
あんな糞重いもん使えるかっての。

521 ：仕様書無しさん：04/07/19 11:00

全体的に痛さが漂うスレ

522 ：仕様書無しさん：04/07/19 11:01

UFJのJava開発についてはここでもよんどけ
http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20030703/1/
　

523 ：仕様書無しさん：04/07/19 11:01

結局Javaにすがらなきゃ(生きて)いけないって
確かにいたいたしいかもな。

524 ：仕様書無しさん：04/07/19 11:03

>>521
確かに痛い、
こんなにハードウェアがが進化している時代に
まるで10年前のようにJavaの価値を速度面でしか評価できない
30代のおっさん、いやおにいさんが多いからねえ。

525 ：仕様書無しさん：04/07/19 11:03

>>519
C++厨は傲慢で生意気だから。
そんでもってバグを作っても平気な顔をしていられる厚顔無恥が多いから

526 ：仕様書無しさん：04/07/19 11:04

大規模Javaは甘くないか...
うむ、吸収合併されちゃうからな....

527 ：仕様書無しさん：04/07/19 11:06

それでもJavaにすがらにゃやっていけない
つらいよな、藻前らも(w

528 ：仕様書無しさん：04/07/19 11:08

>>523
Javaっていうのは言語ではなくテクノロジーなわけだが。
このスレのバカどもはJavaを言語だと勘違いしているためか次元が低い時代遅れなC厨が多い。

さらに短期的な速度のことしか頭にない。実用性のこともろくに考えていないんだなC厨は。
C厨はくみこみばかりやりすぎてサーバサイドアプリの開発のことがよくわかってないんじゃないのかな。
C厨は新たな時代にパラダイムシフトできないで必死にJavaを叩いているわけだ。

それと、君も知らぬ間にJavaにすがっている。君が携帯電話を持ったとき、
君がJavaCard搭載のクレジットカードを使ったとき
君が自動販売機でジュースを購入したとき、君があるサイト、証券会社のサイト、金融系のサイト、
オークションサイトにアクセスしたとき、
その時点で君はJavaの恩恵を知らない間に受けており、すでにJavaにすがっている。

529 ：仕様書無しさん：04/07/19 11:09

Java製システム使う分野ってC/C++でやってきた分野と
競合してないじゃんか。
なんで絡んでくるの？

530 ：仕様書無しさん：04/07/19 11:10

>>528
それにつけてもろくでもねぇもんばっかだな(w

531 ：仕様書無しさん：04/07/19 11:11

そのうち、>>523は脳の大手術を受けるだろう。
そのとき、>>523の脳にJavaChipが搭載されるだろう。
そしてそのとき、>>523は頭の悪いC++厨という烙印を押されなくて済むようになるだろう。
そしてさらに性格の悪さを補うために>>523の脳に人格補正チップも搭載されるだろう。

532 ：仕様書無しさん：04/07/19 11:12

>>529
欲求不満なんだろ。将来も怪しいしな。情緒不安定なんだよ。

533 ：仕様書無しさん：04/07/19 11:12

>>530
その通り！　Ｃ厨はろくなもんでもねえ30代の巣窟なんですなあw

534 ：仕様書無しさん：04/07/19 11:13

今どきPGじゃなくても知ってそうなことを、誇張して偉そうに書くなよ。

535 ：仕様書無しさん：04/07/19 11:14

>>531
語るに落ちてるな(w大丈夫か?

536 ：仕様書無しさん：04/07/19 11:16

>>532
藻前はそんなに将来が安定しているのか？　まるで社会主義国の人間みたいに。
今の日本をみて将来が安心できるやつなんて誰もいないだろw
安心しているのは事業に成功した香具師とかバブル時代大儲けした団塊の世代くらいだろ。
10～20代みんな不安がって当たり前だろ。
30年後には中国が台頭して日本は衰退しているかもしれないんだからな。
40代の香具師らは30年後にはすでに定年退職しているからどうでもいいと思っているんだろうけれどな。

537 ：仕様書無しさん：04/07/19 11:16

>>534
このスレには知らないヴァカが多いし説明してほしそうだったから
語ってやったんだろ？

538 ：仕様書無しさん：04/07/19 11:20

恥ずかしい香具師だな

539 ：仕様書無しさん：04/07/19 11:22

こいつリアルで何かやらかすんじゃないかと、だんだん心配になってきた

540 ：仕様書無しさん：04/07/19 11:22

つーか八つ当たりやめれ、みっともない

541 ：仕様書無しさん：04/07/19 11:24

ここでCﾏﾝｾｰしている人ってCやってる人間からも
嫌われてるんじゃない？

542 ：仕様書無しさん：04/07/19 11:30

>>517
Javaはコンパイラがバッファオーバーフローをチェックしてくれるか？

543 ：仕様書無しさん：04/07/19 11:39

>>541
おやっ?Cﾏﾝｾｰしている人ってどこ?
見当たらないが?

544 ：仕様書無しさん：04/07/19 11:55

>>542
そんなコンパイラ作ったら、コンパイルにどれだけ時間かかるんだよ･･･
>>517のような頭の悪い子はほっとこうよ

545 ：仕様書無しさん：04/07/19 11:59

>>544
>コンパイルにどれだけ時間かかるんだよ･･･
>コンパイルにどれだけ時間かかるんだよ･･･
>コンパイルにどれだけ時間かかるんだよ･･･

546 ：仕様書無しさん：04/07/19 12:13

そーだなぁ。
コンパイラが考えられる全ての入力の組み合わせを想定してそれからおもむろにテストを始めるとして・・・・
まぁ、ざっと４５億年ってとこか。

547 ：仕様書無しさん：04/07/19 12:44

遅くても許される温い環境だけだな、Javaが生きていけるのは。
Java厨は温い環境で仕事してんだろうな。うらやましいｗ

548 ：仕様書無しさん：04/07/19 12:56

確かにシビアなタイミング制御を要求されたりするC/C++は大変だな。
ゲーム業界も凋落気味だし…。正直頑張れ！

549 ：仕様書無しさん：04/07/19 13:08

クリティカルな部分ではインラインアセンブラが結構つかえるぞ。

550 ：仕様書無しさん：04/07/19 14:22

Java厨はDel厨と戯れてればいいじゃん
C++と張り合おうだなんて驕りにもほどがある

551 ：仕様書無しさん：04/07/19 14:42

Javaの比較対象はC/C++じゃなく、VBやCOBOLですぜ。

552 ：仕様書無しさん：04/07/19 14:51

クライアントじゃVBの敵にもならなんよ。

553 ：仕様書無しさん：04/07/19 15:30

JavaにせよCにせよ、一つの言語しか使えない奴は
努力が足りてないか能力が足りてないかのどっちかだ。

554 ：仕様書無しさん：04/07/19 15:32

頭が足りてない可能性もな

555 ：仕様書無しさん：04/07/19 17:29

>>502
>いつまでも存在するバグを必死に隠蔽するのはC厨に多いのは事実だし。
この発言はいくらなんでも痛すぎる。
まともなJavaプログラマが可哀想だ。

>>517
>C/C++のコンパイラって頭悪いからバッファオーバーフローとか
>監視してくれないしメモリリークをろくに監視もしないから
Javaコンパイラはリークやバッファオーバーフローのチェックをコンパイル時にしてくれるのか？
凄いですね(w

556 ：仕様書無しさん：04/07/19 17:36

>>498
現場にいったことが無いヤシか？考えが甘いよ。
顧客にとって品質が良いのは当然のことなのだ。

他社製品と性能面で比較された事が無い？

557 ：仕様書無しさん：04/07/19 17:47

>>528
>さらに短期的な速度のことしか頭にない。実用性のこともろくに考えていないんだなC厨は。
実用性に速度は含まれない？
どっちにしても>>1はJava厨から見ても、ｱﾌｫだと言う事でよろしいですか？

558 ：仕様書無しさん：04/07/19 18:00

全処理爆速ですが48時間ごとに再起動お願いしますなシステムより
DBのアップデートに一晩かかりますが、半年放置で大丈夫ですなシステムのほうが
需要あったりするんだよな。

当然一番いいのは全処理早くて保守が楽なシステムだが。

559 ：仕様書無しさん：04/07/19 18:04

>>558
いずれにしてもJ2EEサーバはそのどの条件も満たせないわけだが

560 ：仕様書無しさん：04/07/19 18:08

DBのアップデートに一晩かかりますが、8時間ごとに再起動お願いします

561 ：仕様書無しさん：04/07/19 18:11

>>560
顧客に殴られないようにな

562 ：仕様書無しさん：04/07/19 18:14

全処理爆速ですが48時間ごとに再起動お願いします。
なお、再起動に要する時間は47時間となっております。

563 ：仕様書無しさん：04/07/19 18:37

ﾂﾏﾗﾝ

564 ：仕様書無しさん：04/07/19 18:44

ﾏﾗｿﾝ

565 ：仕様書無しさん：04/07/19 19:31

>>560
アップデートが終わったら再起動ですか。
WindowsUpdate的。

566 ：仕様書無しさん：04/07/19 19:32

ﾏﾗﾂﾝﾂﾝ

567 ：仕様書無しさん：04/07/19 20:03

>>565
設定変更やアップデートのために、makeし直す必要のあるOSよりマシだろ

568 ：69式フリーPG ◆hND3Lufios ：04/07/19 20:16

メモリ管理をガベコレに委ねることで回避できるのはクラッシュとリークだけ。
結局、それが粗雑なソフトでは、コアダンプ等の明確な形で症状があらわれない
だけで、パフォーマンスに問題が生じたりするもの。

569 ：仕様書無しさん：04/07/19 20:34

つまりJavaは業務用ってことだな。とにかく動くことが大切なんだから
クラッシュとかリークしないってのは超重要

570 ：仕様書無しさん：04/07/19 20:59

だから、COBOLがライバルと皆指摘してるのに、Java厨はなぜかCと比較したがる。

571 ：仕様書無しさん：04/07/19 21:09

その通り。Javaって、GCがｶﾞｰってなってもいいからクラッシュしてはいけない
用途専用なんだよ。

572 ：仕様書無しさん：04/07/19 21:16

JavaはCOBOLほど進化していない

573 ：仕様書無しさん：04/07/19 21:19

COBOLはその用途に特化してるからねぇ。
Javaじゃ勝てないね。

574 ：仕様書無しさん：04/07/19 21:23

Javaってさ、そもそも適用分野を想定して開発された言語じゃないじゃん？
CならOS記述、COBOLなら業務用、FORTRANなら学術計算みたいな。

まずJavaありきなんだよね。
んで、最初はWebページ埋め込みでアプレットを謳い文句にしていたけど、
フラッシュに破れ、クライアントは泣かず跳ばずでVBに完敗、
サーバサイドと携帯にやっと安住の地を見つけたけど、.NETやBREWに
追いまくられている。

575 ：仕様書無しさん：04/07/19 21:24

放浪言語Java

576 ：仕様書無しさん：04/07/19 21:53

JAVAはほんとに終わりかけていると思う。
線香花火の最後に光るって感じ。
俺もJAVA使いだけどみんな感じてるよね？

577 ：仕様書無しさん：04/07/19 22:00

ぜんぜん

578 ：仕様書無しさん：04/07/19 22:06

線香花火ですか

ﾎﾟﾄ

579 ：仕様書無しさん：04/07/19 22:08

.netがBSDで動けばjavaはいらんかもしれんが、
趣味で鯖書いてBSDで動かすのにC使うのはだるすぎ

580 ：仕様書無しさん：04/07/19 22:13

BSD厨はウニ板へお帰りください

581 ：仕様書無しさん：04/07/19 22:15

犬糞厨は犬糞板へお帰りください。

582 ：仕様書無しさん：04/07/19 22:16

>>581
ぎゃはは
さすがBSD厨

583 ：仕様書無しさん：04/07/19 22:31

ちゅうか線香花火みたいに輝いてないよ。

584 ：仕様書無しさん：04/07/19 22:42

350-450くらいを見てたら、煽りスレがＪａｖａチューニングスレに化けるか？
とおもったけど、煽りスレに戻ってしまった。

おいたわし。

585 ：仕様書無しさん：04/07/19 22:44

>>584
マ板にそんなもん期待するのはお前ぐらいなもん

586 ：仕様書無しさん：04/07/19 22:46

>>583
努力ぐらい認めてやれよ(w
必死で書き込んでるだから(ww

587 ：仕様書無しさん：04/07/19 22:55

博士!
数値が出ました
このスレの素人率98%です

588 ：仕様書無しさん：04/07/19 22:56

普通に考えてC#のほうが優れてるだろ。
スタックに確保するほうが適切な場合は多々ある。

589 ：仕様書無しさん：04/07/19 23:12

まあ、既にJavaはﾌﾞﾋﾞ.NET以下ということだ。

590 ：仕様書無しさん：04/07/20 00:45

Eclipseがある限りJAVAを使い続けます

591 ：仕様書無しさん：04/07/20 10:37

| ＼
|Д｀)　ﾀﾞﾚﾓｲﾅｲ，ｵﾄﾞﾙﾅﾗｲﾏﾉｳﾁ
|⊂
|

　　♪　　Å
♪　　　／＼　　　Javaﾉｱﾎｳﾆ
　　　ヽ(´Д｀;)ﾉ　　C#ﾉｱﾎｳ
　　　(　へ) 　　　ｵﾅｼﾞｱﾎﾅﾗｵﾄﾞﾗﾆｬｿﾝｿﾝ
　　　く　　

592 ：仕様書無しさん：04/07/20 20:28

Javaしかできんヴァカは無能。
プログラマ界不適合者なので、辞めちゃってください。

593 ：仕様書無しさん：04/07/20 22:33

Javaもできんヴァカは不能。
J2ED。

594 ：仕様書無しさん：04/07/21 12:13

>>593
はいはい、氏んでね。

595 ：仕様書無しさん：04/07/21 12:34

漏れのできる言語。

アセンブラ, C, C++, VC++(SDK, MFC), VB, VB.NET, C++.NETﾏﾈｰｼﾞ拡張, C#, Java
（完全死滅言語は省略）

元々、組込系出身だったけど、最近はWinアプリばかり（鬱
何かM$厨な自分がちょっと恥ずかしい・・・。
しかし、WinアプリでJavaを使う利点がわからんなぁ。
完全に環境に依存しないわけじゃないしなぁ。

596 ：589：04/07/21 12:39

>>589
> まあ、既にJavaはﾌﾞﾋﾞ.NET以下ということだ。

ﾄﾞﾝﾄﾈｯﾄ厨でかつJava厨の漏れは、この意見には同意する。
言語仕様からしてみて、.NET言語はとても卑怯だと思う。
（Java＋VB＋VC）の良い所 / 3.1 のような感じ。
初め、.NET言語にすごい嫌悪感を抱いていたが（Java厨だったので）、
使ってみると、VBの生産性の良さ（開発効率）VCとまでは逝かないが早い処理速度・・・
Javaをパクったが如くの言語仕様の統一感・・・.NET Frameworkとか・・・

まあかといってJavaをバカにするわけではない。今でもJavaは好きだし。

597 ：仕様書無しさん：04/07/21 23:17

ジャバネゴキブリはなかなか滅びないなぁ。

598 ：仕様書無しさん：04/07/22 00:20

実はCOBOLが一番得意な>595

599 ：仕様書無しさん：04/07/22 00:34

>>595
てか終わりすぎ。
俺も似たようなもんだけどな。

600 ：仕様書無しさん：04/07/22 01:10

敗北宣言

601 ：仕様書無しさん：04/07/22 01:28

つまりＣ厨はJavaとC/C++との速度比較を
相対評価でしか見ることができないんだよ。
絶対評価でみれば誤差にすっぽりおさまりたいしたことがないのに
自分の立場を守り懐古主義に走って保身に走りたいがために
相対評価をもちだして無理矢理Javaは使えないとこじつけているということだ。

602 ：仕様書無しさん：04/07/22 01:31

>>579
フッ、甘いな。ドトネトのすべての機能をWIndows以外のOSで
フルに使いこなせると思ったか無知なC++厨め。
お前はどうやらM$厨が掲げるドトネトのインチキスローガンなんぞに騙されたようだな
まだまだ修行が足りんぞ。

603 ：仕様書無しさん：04/07/22 01:39

>>556
C厨が速度ばかり気にしすぎてバグを続出させて品質を落としては本末転倒だな
今の時代には。
>>556のようなド素人はスタンドアロンアプリしか作ったこ
とがないからくだらない性能比を比較をするという頭の悪さを抱え込んでいる。
サーバ上で動くサービスには速度よりも最優先すべき事がある。
信頼性、セキュリティ性、移植性だ。
これらはC/.C++/C#ではどの点に置いてもJavaよりも劣ることは明らかである。
個人情報を流出させるような事はあってはならない。
速度を優先したために個人情報を漏洩させた、機密情報を漏洩させた、
大切なデータを破壊してしまった、では本末転倒。
そこら辺をC/C++厨はろくに理解しておらず浅はかと言うか。
向こう見ずというか。C/C++厨はまるで、無計画に突進するイノシシみたいだ。

604 ：仕様書無しさん：04/07/22 01:48

どうでもいいが、
＞速度を優先したために個人情報を漏洩させた、機密情報を漏洩させた
これは多分違うぞ。

605 ：579：04/07/22 02:24

>>602
いや俺どっちかといったらjava厨なんですけど
>趣味で鯖書いてBSDで動かすのにC使うのはだるすぎ
だからjava使ってると付け足してください＿|￣|○
趣味で書くプログラムはjavaかC#で十分

Cは自分で書くのは良いけど人が書いたソース読みたくない
仕事以外ではあえて使いたくない

606 ：仕様書無しさん：04/07/22 02:32

>>605
一応BSDでもMONOは動かなかった？バージョン制限あるんだっけか？

C/C++厨だけど最後の部分は同意だな。
Cで書かれた他人のソースなんて読む気にならん
C++かJavaなら良いんだけどね･･･

607 ：仕様書無しさん：04/07/22 04:15

漏れもC++厨だけど、Cのソースは読みたくないなあ。
一定以上の規模になった時点で一気に香ばしくなる。
C++やJava「だから」いいってもんでもないけどね。

608 ：556：04/07/23 00:39

>>603
だから、考えが甘すぎるよ。間違いなく現場に言った事が無いだろ、おまえ？

>>556でも書いたが品質が良いのは顧客に取って当たり前の事だ。
わざわざ、品質が悪い物を導入しないよ。Javaを使ってようがC++に関係なくな。
性能だってC++とJava、どちらを使っていても関係なく同じように求めてくるのだ。

そもそもJavaを使う事により、簡単に品質やセキュリティが良くなると思ってる考えが甘すぎ。
同じようにC++を使う事により、性能が簡単に良くなると思ってる考えも甘すぎ。

素人はお前じゃねぇの？

609 ：仕様書無しさん：04/07/23 00:41

Java様、太りすぎでつよ。

610 ：仕様書無しさん：04/07/23 00:42

Java the FAT

611 ：仕様書無しさん：04/07/23 00:56

今日も元気なジャバネゴキブリ

612 ：仕様書無しさん：04/07/23 01:09

31 名前：エリート営業マン本日のレス投稿日：04/07/23 01:00
プログラマ諸君へ

プログラマに居座り続けるなら、世界で通じるプログラマーを目指しなはれ。
インド、中国と肩を並べるくらいの技術と給料でないとな・・
月１０万ぐらいかな・・月５０万以上は失業の道へまっしぐら。。

32 名前：仕様書無しさん本日のレス投稿日：04/07/23 01:09
>>31
そのためにはオブジェクト指向は必要不可欠だ。
現代の日本人のプログラマにはオブジェクト指向という栄養素がいちじるしく不足している。
今こそ、彼らにオブジェクト指向教育、アーキテクチャーパターン教育、
アジャイル開発教育、ラショナルユニファイドプロセス教育、UML教育、
エクストリームプログラミング教育を施してやるべきだ。

613 ：仕様書無しさん：04/07/23 01:11

>>606
> >>605
> 一応BSDでもMONOは動かなかった？バージョン制限あるんだっけか？
いっておくが、Monoはドトネトのすべての機能をフルに使いこなすことはできないぞ。
XML Web ServicesなんぞほぼWindows専用だ。

614 ：仕様書無しさん：04/07/23 01:17

>>608
> >>603
> だから、考えが甘すぎるよ。間違いなく現場に言った事が無いだろ、おまえ？
> >>556でも書いたが品質が良いのは顧客に取って当たり前の事だ。
> わざわざ、品質が悪い物を導入しないよ。Javaを使ってようがC++に関係なくな。

考えが甘いのは果たしてどちらだろうか？
それと、その「品質」というものが、果たして、真の意味で良品質だと誰にでも断言できるだろうか？
果たして、Javaよりバグの頻度が減ると断言できるだろうか？
C++だけで開発して、それくらいの意気込みがあるだろうか？
C++プログラマが品質が良いものを作れると思いこんでいるだけではないだろうか？
ちゃんとテストプログラミングは怠っていないだろうか？
顧客が実際に使ってからはじめてわかってしまうような
目に見えにくい潜在的なバグに対する対策はできているだろうか？
テスト駆動開発は怠っていないだろうか？
ケントベックをちゃんと見習った開発を怠っていないだろうか？
諸君がJavaよりもC++に拘る理由について、いつも疑問に思うことである。

615 ：仕様書無しさん：04/07/23 01:19

>>614
お前只のコーダーだろ？ｗ

616 ：仕様書無しさん：04/07/23 01:19

>>613
WindowsFormsの間違いでは。

617 ：仕様書無しさん：04/07/23 01:21

>>615
真面目語れ？
俺は大学院生だ。

618 ：仕様書無しさん：04/07/23 01:38

社会人ですらないのか、話にならん

619 ：仕様書無しさん：04/07/23 01:50

>>614
結論が分からない。
正確に相手へと物事を伝えたいのなら、結論は文章の始めに書くべきだ。
基本だよ。

620 ：仕様書無しさん：04/07/23 02:29

>>618
大学院生ですらないのか、話にならん

621 ：仕様書無しさん：04/07/23 02:30

>>619
2chで、しかも煽りスレでマジレスか

622 ：619：04/07/23 02:34

>>621
だから、どうだと？

623 ：仕様書無しさん：04/07/23 06:58

結論を最初に書く手法はインパクトを与えることができる。
とくにこのような入り乱れた激しい話し合いの中ではそれが効果的だろう。

624 ：仕様書無しさん：04/07/23 07:11

…ちゃんと読んでやれよ。

>614 名前：仕様書無しさん投稿日： 04/07/23 01:17
>～だろうか？　　　×9
>いつも疑問に思うことである。

結論も糞も、疑問をぶつけているだけだ。

625 ：仕様書無しさん：04/07/23 08:21

っていうかそろそろバカな話し合いはヤメレ

C++は保守性やら可読性やらJavaよりはるかに下。
集合論使って複素関数やるみたいなもん

626 ：仕様書無しさん：04/07/23 08:42

>>624
結論は書くべきだ。
結論がないと典型的な分かりにくい文章になる。
>>614が分かり易い例だな。

627 ：仕様書無しさん：04/07/23 09:23

COBOLとかPerlとかと喧嘩してればいいのに。

628 ：仕様書無しさん：04/07/23 09:26

>>627
だよな。
JavaがC++に挑むなんて、曙がK-1に出るくらいおかしい。

629 ：仕様書無しさん：04/07/23 10:57

「言語仕様の違い」と「品質」に関連性が存在する
っていう命題そのものが理解できん

630 ：仕様書無しさん：04/07/23 11:32

知ってる超人の一人に、COBOLでコンパイラ書いてしまう化け物がいます。
彼のコードは、下手なJava厨の書いたJavaソースよりは１００億倍読みやすいです。
FORTRANの世界にも化け物がいます。
所詮言語仕様よりはその人のスキルじゃないかと。

631 ：仕様書無しさん：04/07/23 12:26

化け物が書いたコードをぜひ読みたい

632 ：仕様書無しさん：04/07/23 16:41

ＣＯＢＯＬで何の言語のどのＯＳで動くバイナリを生成するコンパイラを書けるのか述べられていないのでいまいち凄いかどうかわかりません。

633 ：仕様書無しさん：04/07/23 16:48

>１００億倍

証明してみろ（w

634 ：仕様書無しさん：04/07/23 18:12

>>632
見たのはCOBOLで書いたPascalコンパイラでした。
洒落で書いたというLispとAPLインタプリタも見せてもらいました。
（こっちはバイナリだけでソースは未見）
ACOS-6上で動いてました。

635 ：仕様書無しさん：04/07/23 19:34

芳ばしいなぁココ（ｗ

636 ：仕様書無しさん：04/07/23 20:46

Java厨、香ばしいですね。

つーか、C++できるのにJavaできねー香具師なんていねーだろ。

637 ：仕様書無しさん：04/07/24 00:13

ゴジラとガメラどっちが強い？級の不毛な論議・・・・

638 ：仕様書無しさん：04/07/24 09:38

>>637
両方できて当然だしな（ｗ

639 ：仕様書無しさん：04/07/24 09:39

>>626
結論を予測しよう。
「C++はJavaよりも大規模開発に向いていない。」

640 ：仕様書無しさん：04/07/24 09:43

>>639
それは、その会社の人材のレベルが低いとしか言いようがない。
C++ができるのにJavaができない香具師はいない。が、
JavaはできてC++が全くできない（本領を発揮できない）のは多いからな。
まあ、言語の特性ってのがあるからな・・・漏れもJavaの方が好きだが。
ただ、C#には負ける。開発効率も断然上。C#やってみると他の言語に戻れない・・・

641 ：仕様書無しさん：04/07/24 09:45

>>636
> Java厨、香ばしいですね。
>
> つーか、C++できるのにJavaできねー香具師なんていねーだろ。

そういう香ばしいC++厨がいるんだよ（ｗ

もぅ、ほんっとに香ばしいC++厨だよ。まさに厨って感じ。
多重継承できないことに気づかずなんどもJavaコンパイルに手こずるC++厨にはﾜﾗﾀよ。
コンストラクタの扱いも異なりC++よりも厳密性を重視するので書き方間違えて
コンパイルに成功できずに手こずっているC++厨にもﾜﾗﾀよ。
いままでよほど汚いソースコードを書いていたってことが一目でわかってしまうから面白い。

JavaコンパイラはC++厨のスパゲティレベルを測定できる素晴らしい装置だね（ｗ

642 ：仕様書無しさん：04/07/24 09:55

>>640
> >>639
> それは、その会社の人材のレベルが低いとしか言いようがない。
> C++ができるのにJavaができない香具師はいない。が、
その傲慢さが命取りになるのだよ。
チミはその中でレベルが高いC++プログラマであることを証明できるか？
C++できるといっている奴の9割以上はレベルが低い人間だといっても過言ではない。
実際にはCしかできないレベル、オブジェクト指向を解っていないレベルが多すぎるからだ。
しかもコーディングではやらたとtypedefやら演算子オーバローディングを濫用し
ソースコードを汚しオブジェクト指向言語としてのC++を生かし切れずにプロジェクトを破綻と
デスマーチのほうに導いてゆく。

643 ：仕様書無しさん：04/07/24 09:56

> JavaはできてC++が全くできない（本領を発揮できない）のは多いからな。
> まあ、言語の特性ってのがあるからな・・・漏れもJavaの方が好きだが。
> ただ、C#には負ける。開発効率も断然上。C#やってみると他の言語に戻れない・・・
C#はC++ほどではないがJavaより便利に見えて数多くの落とし穴を持った機能が多数ある。
演算子の "自動" オーバローディングは便利に見えて余計なお世話ともいえる機能だ。
C#独自の”プロパティ”も癖がある。GUIプログラミングしかやらないものにしかほとんど恩恵がない。
setter,getterメソッドの記述のしやすさなんぞツールで補うことができるので無駄な機能だ。
delegate, インデクサもほど同様だ。J2SE5.0には似たような機能がでるとはいえ、C#とは全く異なる仕様だ。
C#がJavaより優れている点は「属性」だけだろう。それ以外は何ら新規性というものがない。
C#で痛い点はthrowsの扱いを怠っていること、セキュリティモデルが貧弱なことだ。
それとC#のすべての機能をフルにWindows以外で高い互換性を文字しつつ使うことができないことも痛い。
MonoProjectなんてものもあるが、Window.Formsなんてものも無く、Linux用にはLinux用に独自に実装しているため
Windows版C#とはまったく異なるものとなってしまった。

しかもC#が使っている.NET frameworkはオブジェクト指向的にみても貧弱だ。
特に初期の頃はWin32 APIをそのままラッピングしただけのもがほとんどでオブジェクト指向
をなめた仕様であった。今でもその名残はまだまだ残っている。
それとC#のライブラリはオブジェクト指向をしらなくてもすぐに使えてしまうため、
拡張性に乏しく気が付くと汚いコードを書いて汎用性、保守性、移植性、堅牢性を下げる。

644 ：仕様書無しさん：04/07/24 10:00

つまり

C#はJavaベクトルとC++ベクトルを足して２で割ったような中途半端な言語だということだ。

動脈(Java)と静脈(C#)が途中で心臓で混ざってしまう両生類のような言語、それがC#なのだ。
やはり動脈と静脈は鳥類やほ乳類のようにちゃんと分離されている方が燃焼効率がいいねえw
C#は中途半端な仕様だから燃費が悪いしC#を中心に添えるドトネト(.NET)もXML関連機能など
ほとんどがWindows環境でしか動かないという欠点をかかえているし。

JavaはJava, C++はC++としっかり分離させた方が効率がいいことにこしたことはないさ。
そのためにJNI(Java Native Interface)というものがあるわけだし。

645 ：仕様書無しさん：04/07/24 11:07

プロパティの癖ってなんじゃらほい？

646 ：仕様書無しさん：04/07/24 11:32

>>641
Javaで多重継承しようとした元C++厨

647 ：仕様書無しさん：04/07/24 11:40

やたらいろんな言語使ってるとチャンポンになるときがあった

648 ：仕様書無しさん：04/07/24 12:36

C++厨は頭が悪いことがこのスレを読んでよくわかりました。

649 ：仕様書無しさん：04/07/24 12:45

>>645
独自にget, set というキーワードをJavaの命名規約set,getで始まるコーディングを
しなくて済み、データの出し入れもまるでpublicなインスタンスフィールドに
アクセスするかのように使うことができてC#のプロパティは一見便利そうに見える、
とくにVB信者には人気があるようだ。
しかしプロパティ隠れた落とし穴が存在する。

使うときはpublicなインスタンスフィールドに
アクセスしているように見えるので、それがプロパティなのかフィールドなのか一目でわかりにくい。
フィールドにアクセスするときにアクセスに細かい条件分けされたsetter,getterメソッドという分割ができない。
無理矢理分割するには結局新たにメソッドを作る羽目になりC#のプロパティは本末転倒。

(例えば値を10～100までしか入れたくない場合、1000を入れようとした場合はある処理によって別の
オブジェクトをフィールドに入れたい、また0を入れた場合あるオブジェクトを入れたい、といった処理など。)

表向きはプロパティだがコンパイラは専用の頭にset_, get_とつくメソッドとして解釈されるため
set_既存プロパティ名, get_既存プロパティ名と名が付くメソッドを同じクラス内でつくろうとするとコンパイルエラーになる。

という欠点をC#は抱えている。C#のプロパティは便利そうに見えて大して便利ではないのである。

650 ：仕様書無しさん：04/07/24 13:03

> 演算子の "自動" オーバローディングは便利に見えて余計なお世話ともいえる機能だ。

使わなければいい。

651 ：仕様書無しさん：04/07/24 13:49

つかわなければいいってなあのな。
標準APIでは殆ど使われているしequals()との使い分けがしずらいし余計なお世話だ。
しかもアンチJavaなC#厨に使わせると必ずといってもいいほど厨のように使いたがる。
そうでないC#開発者のクラスとを使い分けるのも大変だ。いちいちチェックしないといけない。

しかもアンチJavaなC#厨のオーバロードの基準もいい加減。
C#厨は元VB厨が多いからオーバロードの仕方も実にいい加減だ。

652 ：仕様書無しさん：04/07/24 13:54

どういうオーバーロード見たん？

653 ：仕様書無しさん：04/07/24 14:00

C++/C#厨がequals()メソッドをオーバライドするときは
こいつを見習って実装しろ。

http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/builder/EqualsBuilder.html

654 ：仕様書無しさん：04/07/24 14:10

チームで開発ならそういうの最初に決めないのか？
使わないってのも一つの手だよ

655 ：仕様書無しさん：04/07/24 14:15

だれかが作ったライブラリを使おうと思ったら肝心なときにへぼいオーバローディングを濫用しやがって
てなケースが多い。

656 ：仕様書無しさん：04/07/24 14:47

>>651
C#でAPIって・・・、あなたは想像がいい加減ですな

657 ：仕様書無しさん：04/07/24 14:51

>アクセスしているように見えるので、それがプロパティなのかフィールドなのか一目でわかりにくい。
あなたは、実装に対してプログラムをするな、インターフェイスに対してプログラムせよという、オブジェクト指向の基本中の基本ができてませんな。

658 ：仕様書無しさん：04/07/24 15:54

>>643
> セキュリティモデルが貧弱なことだ。

具体的に

659 ：仕様書無しさん：04/07/24 16:04

>>657
（ﾟДﾟ）ﾊｧ?
そこで「オブジェクト指向の基本中の基本ができていない」だって？
プロパティのどこがオブジェクト指向なんだ(藁

660 ：仕様書無しさん：04/07/24 16:14

C#のWebアプリをUnixサーバー上でうごかしたいのですが
どうすればいいですか

661 ：仕様書無しさん：04/07/24 16:23

getter、setterはリレーショナルなプロパティを別に設けてる場合のみに使うもんだ
カウンタとかに使うのは正直微妙だな

662 ：仕様書無しさん：04/07/24 16:27

>>659
完全なオブジェクト指向では、
変数も関数もみんなオブジェクトですが？

プロパティは、Javaのような中途半端なオブジェクト指向と、
SmallTalkのような完全なオブジェクト指向の間の機能。

663 ：仕様書無しさん：04/07/24 16:47

すげーな。
彼は休日返上でいったい何箇所に脳内コピペしまくってるんだろう。

664 ：仕様書無しさん：04/07/24 16:50

プロパティってのはJavaのpublicフィールドをなくしたものと考えればいいよ。
Javaでも継承できないとか、あとから制限をかけるときに困るなどの理由で
publicなフィールドは使わないとするコーディング規約もあるだろ？
使いもしないものがある必要はないよな？
C#は全てがgetter/setter方式。

665 ：仕様書無しさん：04/07/24 17:06

>>664
お前はJavaで平気でpublicフィールドを作っているのか？

666 ：仕様書無しさん：04/07/24 17:24

>>665
どこをどう読んだらそうなるんだ？ｗ

667 ：仕様書無しさん：04/07/24 17:35

命名規約で混乱を避けるのが普通

668 ：仕様書無しさん：04/07/24 17:51

一体どんな混乱が避けられると言うのかｗ

669 ：仕様書無しさん：04/07/24 17:56

>>649
> フィールドにアクセスするときにアクセスに細かい条件分けされたsetter,getterメソッドという分割ができない。
日本語になってないんだが？

670 ：仕様書無しさん：04/07/24 18:42

意味は普通にわかるだろ

かわいそうに

C#厨が一生懸命噛み付いているよ

671 ：仕様書無しさん：04/07/24 18:54

↑
コミュニケーション能力のない、一生SEになれないコーダードカタ

672 ：仕様書無しさん：04/07/24 18:58

public とか private とかフィールドとか全然関係ないんだけどな。
「インターフェイスに対してプログラムせよ」の真意はまったく分らないんだろうな。
ここにいるバカJava厨だけだと信じたい、普通のJava屋はそんな事はないよな・・・多分。

673 ：仕様書無しさん：04/07/24 19:22

>>670
おれ普通にわからない・・・、その部分

674 ：仕様書無しさん：04/07/24 20:45

>>662
おいおい、おまえは>>659からどうして「完全なオブジェクト指向」なんて話に
なるんだか。脳内変換しすぎだ。

675 ：仕様書無しさん：04/07/24 20:48

>>671
とりあえずお前はこれを嫁。
最近、こいつみたいなコミュニケーションの意味がわかってないで説教たれるバカが
わんさかといて厚かましい。

真のコミュニケーションとは？
http://pc5.2ch.net/test/read.cgi/prog/1088786819/

676 ：仕様書無しさん：04/07/24 20:51

>>664
> プロパティってのはJavaのpublicフィールドをなくしたものと考えればいいよ。
だめだな。おまえのほうがオブジェクト指向を解っていないな。

> Javaでも継承できないとか、あとから制限をかけるときに困るなどの理由で
> publicなフィールドは使わないとするコーディング規約もあるだろ？
Core APIに使っているものが有るわけだがw
> 使いもしないものがある必要はないよな？

> C#は全てがgetter/setter方式。
どこがC#は全てがgetter/setter方式なんだ？ (藁
VBのやりすぎて脳みそが溶けちまったんじゃねえのか元VB厨なC#厨(w

677 ：仕様書無しさん：04/07/24 20:55

>>672
> public とか private とかフィールドとか全然関係ないんだけどな。
> 「インターフェイスに対してプログラムせよ」の真意はまったく分らないんだろうな。

オブジェクト指向もろくに解っていないｳﾞｧｶC#厨が
「インターフェイスに対してプログラムせよ」
だの宗教みたいなスローガンを掲げてアフォな説教を垂れているとわな。

具体例を明示できずに言葉だけが先行して「エコロジー」だ「国際化」だと
叫んでいたバカどもと同じだなC#厨は。

678 ：仕様書無しさん：04/07/24 21:18

get～、set～メソッドは普通に分かりにくいからいやだ。
名前でプロパティと判断するって何て原始的な。

＞Core APIに使っているものが有るわけだがw
それはフィールドであってプロパティではないのだと意識して使わないとまずい物なわけ？

679 ：仕様書無しさん：04/07/24 21:28

>>670
>>671では無いがお前はSEに向いていないな。
どうすれば、相手に理解出来るように物事を伝える事が出来るか、
ちゃんと考えてみるんだな。

680 ：仕様書無しさん：04/07/24 22:28

>>679
お前はあらゆる物に向いていないな。
一日中ぬるぽでもしてろ

>どうすれば、相手に理解出来るように物事を伝える事が出来るか、
>ちゃんと考えてみるんだな。

俺は最初から何も言っていないが…

しかもいまさらレスしてるところを見るとよっぽど悔しかったのか

681 ：仕様書無しさん：04/07/24 22:31

Java厨＝コーダーってのはデフォルトだから仕方ない。

682 ：仕様書無しさん：04/07/24 23:04

>>680
煽りとかじゃなくて、まともなレスをして欲しいなぁ。
やっぱり、お前はSEに向いてないな。
何を言うにも根拠が無い。

>　意味は普通にわかるだろ
だから、>>670の意味が分からないんだけど？

>しかもいまさらレスしてるところを見るとよっぽど悔しかったのか
これも意味不明。

683 ：仕様書無しさん：04/07/24 23:07

開発言語大杉

684 ：仕様書無しさん：04/07/24 23:15

>>682
人のメールばっかみてねぇで、チャンと仕事しろよ。

685 ：仕様書無しさん：04/07/24 23:25

???

686 ：仕様書無しさん：04/07/24 23:26

墓穴掘ったJava厨がファビョってるな

687 ：仕様書無しさん：04/07/24 23:27

危機感をひしひしと感じているんだろう。

688 ：仕様書無しさん：04/07/24 23:43

>>684
またも、謎の発言。

689 ：仕様書無しさん：04/07/25 01:50

SE以前に社会人として不適合

690 ：仕様書無しさん：04/07/25 09:02

>>688
だから俺の発言じゃないって。
バカじゃないの？

691 ：仕様書無しさん：04/07/25 10:04

いつのまにかC/C++とjavaの比較がC#との比較にすりかわってるな

692 ：仕様書無しさん：04/07/25 10:51

C++使いは言語間の争いなど眼中に無い

693 ：仕様書無しさん：04/07/25 11:15

マクロ使いすぎなC++はどの言語にも移植しにくくて使い勝手が悪いな

694 ：仕様書無しさん：04/07/25 12:20

>>690
だから誰もお前の発言だなんて言ってないって。
バカじゃないの？

695 ：仕様書無しさん：04/07/25 14:50

結局、オブジェクト指向言語で、（必ずしもオブジェクト指向的な考えに
則ったわけではない）ちょっと便利な機能がもたらす言語としての整合性の悪さを
少し批判したら「君、本当にオブジェクト指向わかってる（プゲラ」って言い出す
ドキュソ低レベルコーダーが居ただけの話だな。
低レベルってのは、貶す意味じゃなくて、ハードよりの機械語に近いって意味な。

696 ：仕様書無しさん：04/07/25 17:54

どうして694や690のようなつまらないプライドを守ろうとするやつばかりなんだろう

697 ：仕様書無しさん：04/07/25 17:55

>>696
それお前自身のことじゃねーの？

698 ：仕様書無しさん：04/07/25 18:12

いややや
キモイよ～>>697

699 ：仕様書無しさん：04/07/25 18:27

>>698
それお前自身のことじゃねーの？

700 ：仕様書無しさん：04/07/25 18:27

>>698
それお前自身のことじゃねーの？

701 ：仕様書無しさん：04/07/25 18:28

かぶった。

702 ：仕様書無しさん：04/07/25 18:37

ワンパターンなレスや、同じレスを繰り返すことによって自分の本音を殻で覆い隠し、わずかなプライドを守ろうとしている。
そうまでしてネット上の自分を守りたい理由は、ネットしか偉そうにしていられる場所が無いからである。
まるで思春期の高校生。
こういうことは高校で卒業しておかなければならないのに、二十歳を過ぎていまだ精神が成長していないのだ。

かわいそうな人なのね・・・。

703 ：仕様書無しさん：04/07/25 18:39

>>696や>>698もずいぶんと低脳なレスなんだが、
自分のことを棚に上げる奴いるよな。
そしてわずからプライドを守るとしているｗ

704 ：702：04/07/25 18:44

+すぐ人の真似をしたがる
自分というものを持っていないんだね。

705 ：702：04/07/25 18:46

>>704
その通りですが何か？

706 ：702：04/07/25 18:53

はやくプライド捨てて精神科行ってくれ
迷惑なんだよホント。
こんなスレを立てられるだけでもさ。

707 ：仕様書無しさん：04/07/25 18:55

おまいらせめて言語の話すれ
荒れてるようで妙に居心地のいいスレだったのに。

708 ：仕様書無しさん：04/07/25 19:58

JavaがもっとOS代わりに使えるようなパフォーマンスを突き詰めんとな。

709 ：仕様書無しさん：04/07/25 20:44

今のパフォーマンスでもじゅうぶんだと思うぞ
Javaが求められる場面じゃパフォーマンスは要求されない
パフォーマンスが要求される場面にJavaは求められていない

710 ：仕様書無しさん：04/07/25 20:47

>>709
Javaは確実にOS意識してるぞ
ちょっとは動向に目をやろうな

711 ：仕様書無しさん：04/07/25 21:37

Java最強

712 ：仕様書無しさん：04/07/25 22:16

Java厨 = オートマ車に乗っていきがる厨房

713 ：仕様書無しさん：04/07/25 22:48

先端技術の革新についていけない、前時代の化石はいつの時代もいるものです。
AE86に乗ってるDQNがオートマ車を馬鹿にするようなものかな。

714 ：仕様書無しさん：04/07/25 22:50

なんでC++使ってる人は
すべての言語の頂点に立っているような態度をとりますか

715 ：仕様書無しさん：04/07/25 22:53

-----------数年前----------------------------------
SUN「JAVAで憎き敵ゲイツ帝国をやっつけようぜ！JAVA連合結成だ！」
IBM他「そうだ！そうだ！」
SUN「MSを訴えるぜ！イェーイ！」

-----------現在----------------------------------
MS「最近カネに困ってるようだねSUN君。
　　JAVAがこんなに流行ってるのに、なんで困ってるんだい？」
SUN「JAVAは儲からないの…　でもいいんだ。JAVAへの貢献はプライスレスだから」
MS「サーバ市場をIBMに食われてるんだって？　君の本当の敵は誰なんだ？
　　俺か？　IBMか？　LINUXか？　オープンソースコミュニティか？」
SUN「…」
MS「さあ、僕に突きつけたその物騒なものを仕舞ってくれ。仲良くしようじゃないか。
これは取っておきたまえ、ほんのポケットマネーだが。」
SUN「ああ、これだけあれば当分しのげます。。。ありがとうございます…　ご主人様」
MS「おっと。ご主人様は禁句だぜ。独禁法がうるさいからな。」
SUN「かしこまりました。ごしゅ、、いいえ。。。」
MS「それはそうと、我々のJavaと.NET のことなんだが、これも、俺たちの仲じゃないか、
　　持ってるものは隠しっこなし、お互いの意見もおおいに取り入れていこうや。
　　そのほうがそもそも顧客のためだよ。」
SUN「おっしゃるとおりです。」
MS「ただね。もう.NETは道筋ついちゃってて、ほとんど完成しちゃってるんだわ。次のOSの分もね。」
SUN「はあ。」
MS「まあ細かいことは、そのうちゆっくりと話あって決めていくとして、とりあえず、Javaのこの部分だが
　　ちょっとばかし気に入らない部分があってね。」
SUN「あ、でもそれは。」
MS「おいおい、君困るよ。顧客のためなんだからね。」
SUN「もちろんです。」
MS「ま、他にもいろいろあるんだが、とりあえずプレスリリースしちゃうよ？」
SUN「すべてお任せいたします。」

716 ：仕様書無しさん：04/07/25 22:53

IBM「おいSUN　JAVAをオープンソースにしてくれよ」
SUN「そんなことしたら私の存在理由がなくなるじゃん…」
IBM「お前邪魔なの。さっさと死んでくれ。その方がJAVAの為になる」
SUN「ひ、ひどい！　ブチ切れた！　悪魔に魂を売ってでも生き残ってやるわ」

717 ：仕様書無しさん：04/07/25 22:55

まあUNIX専属のSUNより、自由なプラットフォームで販売できるIBMのが旨みが有るわな

718 ：仕様書無しさん：04/07/25 23:53

じゃあビックカメラなんか最高ですね

719 ：仕様書無しさん：04/07/26 00:04

小売はどうかと

720 ：仕様書無しさん：04/07/26 13:04

>>714
C++が「まとも」に出来れば、殆どの言語はできる香具師ってことになるからだろう。
ああ、あくまで「まともに」出来ればの話ですから、気になさらず。

実際、漏れはC++ → Javaの順だったので、Javaは楽だったなぁ。
いい言語だと思うよ、JavaもC++も。

721 ：仕様書無しさん：04/07/26 13:09

>>712

> Java厨 = オートマ車に乗っていきがる厨房
ワロタ。

じゃあ、C++厨房は、MT車だからっていばる厨房ってとこか。

722 ：仕様書無しさん：04/07/26 17:18

ちがうだろう

Java厨　デチューンしたエンジンでマフラー換えて音だけ速くしている馬鹿

723 ：仕様書無しさん：04/07/26 17:24

>>722

ｵﾄﾞﾀﾞｹﾊﾔｸﾞｼﾞﾃﾞﾙｯﾃﾅﾝﾃﾞｨｽｶ-?

　　　|人
　　　|ｗ0）　　ｼﾞｰ。
　　　|⊂
　　　|

724 ：仕様書無しさん：04/07/26 17:28

>>723
　　　　　　人
　　　　∑(;0w0)　ﾅｽﾞｪﾐﾃﾞﾙﾝﾃﾞｨｽ!!
　　　　(＼＼
　　　　））

725 ：仕様書無しさん：04/07/26 17:30

> デチューンしたエンジンでマフラー換えて音だけ速くしている馬鹿

音だけ速くしてるってどういうこった？
音だけ早くしてるに置き換えても、意味不明。
車の速度じゃねーのか？おしえてくれ。
ﾀﾁﾞｬｰﾅｻﾞﾝ!!

726 ：仕様書無しさん：04/07/26 23:25

>714
むしろなぜJava信者は速度や難解さでC++と勝負するのか？
明快さとか規則性とか、そういうもんで挑めばいいのに。

727 ：仕様書無しさん：04/07/26 23:52

速度や（無駄な）難解さでC++に挑んでる奴など居ない。
大抵、「保守性高いし読みやすいしJavaの時代だPo」
って言ってるJava厨に
「けど、速度で無いしマクロ使えないし(ﾌﾟｹﾞﾗ」
ってC/C++陣営が言ってるように思うんだが。

構造的にネイティブ陣営には絶対勝てないながらも、
何とかネイティブ陣営の速度に近づこうとしてる
Javaの姿勢は評価してもいいな

728 ：仕様書無しさん：04/07/27 00:01

>>725
音にも速度はあるんだぜ。知らないのか？

729 ：仕様書無しさん：04/07/27 00:23

じゃバはアプレットにしておけばどこからでもブラウザで見れるのがいいね。

730 ：仕様書無しさん：04/07/27 09:08

>>728
それはわかるが、「この場合は」車のスピードの間違いじゃねーのか？

731 ：仕様書無しさん：04/07/27 10:50

パワーを上げる社外品のマフラーに交換するのではなく、
純正品のまま、カッターだけ大口径に換えてジャッキアップし、
マフラーに五寸釘で穴を空けで音だけでかくすることを言いたいんでないのん？

２０年位前、430とかでよくやってるDQNがいたぞ。

732 ：仕様書無しさん：04/07/27 10:58

音だけ爆音仕様の車のことを、「音だけ速い」って普通に言うよ。
ｷﾓｦﾀは知らないだろうけど。

733 ：仕様書無しさん：04/07/27 12:46

>>732
>普通に言うよ。
>普通に言うよ。
>普通に言うよ。
君もなかなかｷﾓいな。一般人は言わんよ。

734 ：仕様書無しさん：04/07/27 12:49

あらあら三連呼ですか。よほど不愉快だったようでｗ

735 ：仕様書無しさん：04/07/27 13:19

キモいってのは否定しないんだね。

736 ：仕様書無しさん：04/07/27 13:28

ｷﾓｦﾀ　←この辺が気に障るようです。

737 ：仕様書無しさん：04/07/27 13:29

ｷﾓｦﾀが珍走用語を知っているはずが無い。

738 ：仕様書無しさん：04/07/27 13:30

珍走というより走り屋用語じゃないのかな。似たようなもんだけど。
どっちにしろｷﾓｦﾀには無縁だ罠

739 ：仕様書無しさん：04/07/27 13:52

ﾊｹﾞﾃﾞﾌﾞｷﾓｦﾀｵｻｰﾝには図星だったようだな。(ｹﾞﾗ

740 ：仕様書無しさん：04/07/27 15:21

>>708
> JavaがもっとOS代わりに使えるようなパフォーマンスを突き詰めんとな。

J2SE1.6に期待せよ。
1.6からはプロセス管理ができるようになるという

741 ：仕様書無しさん：04/07/27 15:21

>>678
> get～、set～メソッドは普通に分かりにくいからいやだ。
> 名前でプロパティと判断するって何て原始的な。

それだったら、Java、C#両方にあるコーディング命名規約で
メソッド名は動詞にするべきだという考え方はわかりつらいとでもいうのかい？

742 ：仕様書無しさん：04/07/27 15:25

>>721
> >>712
>
> > Java厨 = オートマ車に乗っていきがる厨房
> ワロタ。
>
> じゃあ、C++厨房は、MT車だからっていばる厨房ってとこか。

むしろ、使い勝手の悪い時代遅れな馬車を乗り回しただけで凄いと
勘違いして自慢しているC++厨ってところだろうか。
年代車両の高級車のほうがまだマシなのだがw

743 ：仕様書無しさん：04/07/27 15:52

C++が使いこなせないから喚いてるだけのレスはいかがなものか
JavaとC++は使われる場所が違うだろうに

744 ：仕様書無しさん：04/07/27 15:53

Javaの比較対照はCOBOLとVBでつよ。

745 ：仕様書無しさん：04/07/27 16:07

「Tiger」ことJ2SE 5.0が互換性を分断する？
http://www.itmedia.co.jp/enterprise/articles/0407/26/news061.html

やっぱ「一度書けばどこでも動く」って「究極の幻想」だな

746 ：仕様書無しさん：04/07/27 16:10

質問です。Cで
#ifdef HOGE
　　hoge( hoge );
#else
　　hoge2( hoge );
#endif
ってのをJAVAで書くとどうなるん？

747 ：仕様書無しさん：04/07/27 16:12

>>745
バージョンアップしなければいいだけ

748 ：仕様書無しさん：04/07/27 16:13

その通り！DOSは今でも現役だ！

749 ：仕様書無しさん：04/07/27 16:26

>>743
そんなことはないな。
演算子オーバーロードとかtypedefつかったソースコードの解析を迫られるのが
ウザイっていう訴えがあるかもしれないな。

750 ：仕様書無しさん：04/07/27 16:27

>>745
C#やC/C++の互換性と比べたらたいしたことがないよ。

そういう問題はリファクタリングツールでほとんど解決してしまう問題だし。

751 ：仕様書無しさん：04/07/27 16:28

>>746
Jakarta Verlocityを使って記述する。

752 ：仕様書無しさん：04/07/27 16:42

>>750
ふーん。リファクタリングを使えばJ2SE5.0以前でjava.util.concurrentが使えるようになるんだね。

お前馬鹿だろ？

753 ：馬鹿には理解できないだろうから：04/07/27 16:44

SeaJUGの一部メンバーが表明したのは、新しい「java.util.concurrent」などの
APIをめぐる懸念だ。これらのAPIは、アノテーションとジェネリックスを使用し、
プログラミング言語C++のテンプレートに近い。これらのAPIを使いたいのであれば
Java 5に移行しなければならず、そうでなければ従来バージョンを使えばよい。
これは、「不便を我慢してJava 1.3.0あるいは1.4.0にとどまるべきか、短期的な
リスクを覚悟でJava 5.0に移行すべきか」という問題を提起する。

754 ：仕様書無しさん：04/07/27 17:17

J2SE 5.0のソースそのものをリファクタリングしてgenericsを無効にしろってことか。
さすがキチガイの考えることは一味違うな。

755 ：仕様書無しさん：04/07/27 18:01

C#と同じぐらい仕様がころころ変わる完成度の低い言語だとは思ってなかったし、
JVMもIBMとMSとでは挙動が違う所もある扱いづらい言語だとは思ってませんでした。

Javaをなめると痛い目にあいます

756 ：仕様書無しさん：04/07/27 18:15

C#って仕様ころころ変わってるん？

757 ：仕様書無しさん：04/07/27 18:55

>>752
またまたハリポタ信者君か。脳内変換しちょって。
頭悪そうな釣りだな藻前。

758 ：仕様書無しさん：04/07/27 18:56

>>756
VB厨やVC++厨にとっては大幅な仕様変更だがなw
VB厨やVC++厨にとってはは新たにC#を覚えさせられる羽目になっているんだからなw

759 ：仕様書無しさん：04/07/27 18:58

>>752
誰がダウングレードの話をしているんだか。脳内変換するなよクズ。

1.4までのコードを1.5でも使えるようにするときの話をしているんだが。
オマエさんには脳たりんので理解できなかったかな？

760 ：仕様書無しさん：04/07/27 18:59

>>753
C++のtemplateとJavaGenericsは別物です。

761 ：仕様書無しさん：04/07/27 18:59

>>753
移行した方がいいがな。
Mutexや瀬間フォが使えるンなら

762 ：仕様書無しさん：04/07/27 19:30

いつものカルシウム不足の彼が降臨したようです。

763 ：仕様書無しさん：04/07/27 19:47

藻前の場合はカリウム不足だと思う

764 ：仕様書無しさん：04/07/27 20:00

すべて不足してるだろ

765 ：仕様書無しさん：04/07/27 20:18

>>759
>>745のリンク先読んでないの？ｗ
じゃあ、>>750の「そういう問題」って何？答えてみ。

766 ：仕様書無しさん：04/07/27 21:31

ここは、最近ではマ板代表の香ばしいスレになってしまいましたね。
理由は何でしょうか？

767 ：仕様書無しさん：04/07/27 21:55

>>741
＞それだったら、Java、C#両方にあるコーディング命名規約で
＞メソッド名は動詞にするべきだという考え方はわかりつらいとでもいうのかい？

全然話が違うだろ、何が言いたいんか意味不明なんだが…

メソッドである事を区別するのが動詞の名前かどうかで決まるという
言語があったら分かりづらいとでも言うのかい？

ってことならとっても分かりにくいといっておこう。

768 ：仕様書無しさん：04/07/27 23:32

みんな知っていると思うけど厨房のために一言言わせてください
Javaにはポインターという名前のポインターはないが参照という名前のポインターがある

失礼しました

769 ：仕様書無しさん：04/07/28 00:00

だから、ポインタと参照は違うといってんだろーが！

770 ：仕様書無しさん：04/07/28 00:03

だから、演算可能なポインタという概念と参照は違うといってんだろーが！

771 ：仕様書無しさん：04/07/28 00:04

どうでもいいけどﾎﾞｲﾝﾀﾝはいいよね。ﾊｧﾊｧ

772 ：仕様書無しさん：04/07/28 00:30

ハードあってのソフト、ソフトあってのハード。
そこからは離れてったものにはもう興味ねぇ。

773 ：仕様書無しさん：04/07/28 00:39

リファクタリングで互換性問題も解消。ﾌﾟﾌﾟ

774 ：仕様書無しさん：04/07/28 00:50

言語系のスレを見るたびに思うわけだが
みんな勉強が足りないと思うんだよねぇー。

言語仕様とか、そゆ表面的なことだけじゃなくてさ
その言語がどういう歴史的背景・思想の元に誕生したのかを
勉強してみなよ。そうすれば、こんなアホなスレは立たないと思うんだよ。

775 ：仕様書無しさん：04/07/28 00:52

ﾊｧ?

776 ：仕様書無しさん：04/07/28 00:53

D言語のリファレンス読んで感動した
C#やJavaと逆方向のアプローチでC++を倒しに行っている

777 ：仕様書無しさん：04/07/28 00:55

相手にされてないけどな

778 ：仕様書無しさん：04/07/28 01:00

資本力がないからな。
こういうのこそオープンソースにして、更に標準化させちまえばいいのに。

779 ：仕様書無しさん：04/07/28 01:38

>>775
JavaとC++は、仏語と、独語ぐらい違うって言いたいのさ。
言語仕様がこれだけ違うのに、単純比較しようってこと
自体が馬鹿げてると思わんですか？

780 ：仕様書無しさん：04/07/28 07:14

JavaとC++じゃ用途も違うし、そもそも比較対象にならない。
JavaのライバルはVBとCOBOL

781 ：仕様書無しさん：04/07/28 08:20

そこでVBとCOBOLを出されることが一番腹が立つ
まだC厨に遅いと言われていた方が良い

782 ：仕様書無しさん：04/07/28 08:58

>>781
>一番腹が立つ
自分で作ったわけでもない言語のことで腹を立てる、その気持ちが解らんが…
まあ取り敢えず反論くらいしてみたら？

783 ：仕様書無しさん：04/07/28 09:02

＞JavaのライバルはVBとCOBOL

ありえない。
Javaは中途半端すぎて、クライアントではVBに完敗。
サーバサイドではCOBOLERの確保が困難になっていることから健闘しているが、
COBOLの圧倒的なシェアを崩すところまでは至っていない。

784 ：仕様書無しさん：04/07/28 09:04

Java厨は自分の愛してやまない言語に妄想を抱いてるからなぁ。
洗練されてはいるけど、システム記述言語ではないよ。Javaは。

785 ：仕様書無しさん：04/07/28 13:07

住み分けできてるからいいじゃん。
使い分ければ。
C++分かってるならJAVAもVBも当然できるでしょう。

786 ：仕様書無しさん：04/07/28 13:51

VBは実情知らんのでなんとも言えんが、Javaは普通に使えるな、C++使えるなら。
言語仕様がどうこう以前に環境自体に揺らぎがないのは大きい。
どの処理系で使ってもJavaはJavaだし。

787 ：仕様書無しさん：04/07/28 16:19

JavaVMはバッファオーバーフロー起こします。C/C++で作られてるから。

788 ：仕様書無しさん：04/07/28 17:08

じゃあ、Javaなんか使えないな。怖くて。

789 ：仕様書無しさん：04/07/28 21:50

Javaを否定はせんがね、使いやすさの問題だろ。
用途で分けりゃいいじゃねぇか。
マルチプラットフォームでやりたいならJava、それ以外ならCでとかさ
もっとも、各OSのAPI叩いて動く様な言語が完全にマルチプラットフォーム
出来てるとは思えんがね…。
（実際北見工大の信号処理研究室ではLinuxで動くのにWinで動かないとかで苦労してるらしい）
正直CもC++も分からんからと己の無能さを棚に上げて非難してるようにしか見えない。
Javaにtempleteもvirtualもoperatorも無い以上使う価値を見出せない。
もちっと勉強してからスレ立てような>>1

790 ：仕様書無しさん：04/07/28 21:54

>（実際北見工大の信号処理研究室ではLinuxで動くのにWinで動かないとかで苦労してるらしい）

まあ学生なんだろうけど
場違いだな

791 ：仕様書無しさん：04/07/28 21:56

C厨は北見工大の学生さんかいｗｗｗ

792 ：仕様書無しさん：04/07/28 22:07

>>790
まぁね。
その一行はあくまで例を示したいだけであって場違いなのはその１行
他の行はこのスレに対する意見だが何か？
ってかこんな説明入れなきゃ納得出来ないほどお子様なのかね？
正直揚げ足取りにしか見えんよ

793 ：仕様書無しさん：04/07/28 22:09

ほのかに夏の香りがただよってまいりました

794 ：仕様書無しさん：04/07/28 22:11

>Javaにtempleteもvirtualもoperatorも無い以上使う価値を見出せない

これも

795 ：仕様書無しさん：04/07/28 22:11

>>791
あ～北見工大ではJavaを授業で使ってるからC厨は俺だけじゃない？
尚今回のレスは意味無しなんで791共々無視ヨロ

796 ：仕様書無しさん：04/07/28 22:12

Java厨は毎日が春夏秋冬じゃん。

797 ：仕様書無しさん：04/07/28 22:16

ま、使いやすさの問題と先に言ってある通り。
Javaをなめてるつもりは無い。あくまで「俺は嫌いだ」とは言っとく。
好みの差だろ。大々的に
>いまやもはやそんな時代は終わったのだよ
と言い切れるLvじゃないね＜Javaの完成度
まぁプログラムの入門言語としては優秀じゃない？
後はネットワークプログラムは割とやりやすいとは思うけどね＜Java

798 ：仕様書無しさん：04/07/28 22:16

>>789
>>795
Googleの検索結果貼ってもいい？(・∀・)ｱﾋｬ!!

799 ：仕様書無しさん：04/07/28 22:18

いいぜ、是非とも見たいものだ

800 ：仕様書無しさん：04/07/28 22:20

書けば書く程ボロボロになってくのは悲しいね

801 ：仕様書無しさん：04/07/28 22:22

社会に出たら落胆するのかな･･･彼は

802 ：仕様書無しさん：04/07/28 22:24

　ビ　ス　ケ　ッ　ト　を　た　ら　ふ　く　食　べ　た　イ　チ　ロ　ー　を　ジ　ロー　が　食　う　

803 ：仕様書無しさん：04/07/28 22:28

このスレ死んでるんじゃない？
>>802
参照

804 ：仕様書無しさん：04/07/28 22:38

夏の風物詩がさらにレベルを低くする

805 ：仕様書無しさん：04/07/28 22:46

出品者は「非常に良い」と落札者を評価しました。

コメント：商品が届き安心しました。この度は迅速な対応ｳﾝｺｰ！(ﾟ∀ﾟ)！ございました。またの機会を楽しみにしています。 (7月 12日 18時 46分)
コメント：すみません。僕の辞書が勝手に変な変換をしてしまい、不快感を与えるコメントをしてしまい大変申し訳ございません。この度は迅速な対応ありがとうございました。 (7月 12日 19時 7分) (最新)

806 ：仕様書無しさん：04/07/28 22:48

辞書は体を表す

807 ：仕様書無しさん：04/07/28 22:51

ここまで熱心にレス返すのも良いがせめてまともなレスにしような。
まともな意見（題に即した反論、意見）でも無いのにレスする気は無いからね。
いい加減遠吠えに付き合うのも飽きたし俺の書きたいこと書いたから
このスレから離れるわ。
もうちょいまともな反論が出るまで一人で騒いでなさい。
反論出来たらこっちも意見してあげる

808 ：仕様書無しさん：04/07/28 22:54

勝利宣言+書き逃げパターン

809 ：仕様書無しさん：04/07/28 22:55

なんだなんだ。Java厨は大学生に撃退されたのか。
一応プロなんだろ？悲惨だなｗ

810 ：仕様書無しさん：04/07/28 22:57

撃退されたように見えるのか。。。。

811 ：仕様書無しさん：04/07/28 22:57

>>809
Java厨を苛めるな！Javaの思想は素晴らしいんだぞ。
1.6からはプロセス制御ができるんだぞ！

812 ：仕様書無しさん：04/07/28 22:58

専門学校卒の派遣が国立大生に勝てるわけないべ。

813 ：仕様書無しさん：04/07/28 23:00

思想はすばらしいが現実がそれに追いついているかの問題
>>811

814 ：仕様書無しさん：04/07/28 23:01

厨房恐るべし

815 ：仕様書無しさん：04/07/28 23:02

大学生にいなされるJava厨っていったい・・・

816 ：仕様書無しさん：04/07/28 23:06

ダメダコリャ

817 ：仕様書無しさん：04/07/28 23:39

APIが仕様どおり動かないMSにも原因があるな

818 ：仕様書無しさん：04/07/28 23:41

そのAPI?

819 ：817のC厨：04/07/28 23:44

あははｗ
激しく同意
>>817

820 ：仕様書無しさん：04/07/28 23:46

面白い意見
>>817
VC++.NETやってるとそういうの良く見る

821 ：仕様書無しさん：04/07/28 23:51

アホだこいつら。。。。

822 ：仕様書無しさん：04/07/28 23:53

C厨のふりをするなよ。専門学校卒の派遣JavaPGども。
具体的に、MSDNのリファレンス通りに機能しなかったAPIについて書いてみろよｗ

823 ：仕様書無しさん：04/07/29 00:02

HANDLE m_hMutex = CreateMutex(FALSE, 0, _T("DM-00"));
if(::GetLastError() == ERROR_ALREADY_EXISTS)
{
CloseHandle(m_hMutex);
return FALSE;
}
をかましてみたんだが動かない事が稀にあったかね。
状況次第って条件が付くが仕様どおりではなかろう。

824 ：仕様書無しさん：04/07/29 00:06

ミューテックスの所有者って何？

825 ：仕様書無しさん：04/07/29 00:07

APIレベルのバグってそうそう無いだろ。
機種依存で出来ない関数とかありそうだがハードの問題ではね…
PC重いと動かなかったり実行おかしかったりってのはあるだろうけどね
MFC辺り探すと面白そうだがあんな膨大なライブラリなんぞ見てられんよ

826 ：仕様書無しさん：04/07/29 00:09

HANDLE CreateMutex(
LPSECURITY_ATTRIBUTES lpMutexAttributes, // SD
BOOL bInitialOwner, // initial owner
LPCTSTR lpName // object name
);

827 ：仕様書無しさん：04/07/29 00:12

bInitialOwner パラメータを使うと、既存のミューテックスの所有権を即座に
要求できます。ミューテックスがスレッドに所有されている場合は非シグナ
ル状態になり、呼び出し側スレッドがそのミューテックスの所有権を要求す
るには待機関数（WaitForSingleObject など）を使わなければなりません。
その状態でミューテックスがシグナル状態になると、待機スレッドの 1 つに
所有権が割り当てられ、そのミューテックスは非シグナル状態へ変化し、
待機関数は制御を返します。特定のミューテックスを所有できるスレッドは、
一度に 1 つだけです。所有権を解放するには、ReleaseMutex 関数を使い
ます。

828 ：仕様書無しさん：04/07/29 00:13

ミューテックスオブジェクトは、どのスレッドにも所有されていない場合はシグナル状態になります。

829 ：仕様書無しさん：04/07/29 00:13

ほうほう。>>823はオーナー権限を捨てた後に閉じようとしてる訳だね。
実に興味深い。

830 ：仕様書無しさん：04/07/29 00:15

さらしage

831 ：仕様書無しさん：04/07/29 00:22

BOOL TransparentBlt(
hdc hdcDest,
int nXOrgDest,
int nYOrgDest,
int nWidthDest,
int hHeightDest,
hdc hdcSrc,
int nXOrgSrc,
int nYOrgSrc,
int nWidthSrc,
int nHeightSrc,
COLORREF crTransparent
)
MFC:古い機種だと動かないヤツあるらしい漏れのPCで動かんかったよ
（ﾉД；

832 ：仕様書無しさん：04/07/29 00:23

Javaには「ポインタ操作」が無い。

833 ：仕様書無しさん：04/07/29 00:25

>>831
それはグラフィックスカードのドライバが原因と思われ。

834 ：仕様書無しさん：04/07/29 00:25

>>831
Requirements
Windows NT/2000/XP: Included in Windows 2000 and later.
Windows 95/98/Me: Included in Windows 98 and later.

835 ：仕様書無しさん：04/07/29 00:27

>>832
Javaにはポインタ「しか」ない
ttp://www.amazon.co.jp/exec/obidos/ASIN/4774113611/qid=1091028401/ref=sr_8_xs_ap_i1_xgl/250-9177713-7381826

836 ：仕様書無しさん：04/07/29 00:30

>>831 >>833 >>834
＞それはグラフィックスカードのドライバが原因と思われ。
が該当（ﾉДT

837 ：仕様書無しさん：04/07/29 00:30

>>835

前橋ﾊｹｰﾝ!!

838 ：仕様書無しさん：04/07/29 00:31

さあ、だいぶ香ばしくなってきますた！

839 ：仕様書無しさん：04/07/29 00:33

だから無理してC厨のふりすんなって。自覚無いだろうけど笑われてるぞ。

840 ：仕様書無しさん：04/07/29 00:37

Javaは使いやすいし、趣味とか速度を気にしない分野ではそれなりにイケてる。
でも業務でアプリ開発するならJava単体ではお話にならない。
結局C/C++コンパイラ付属のプリプロセッサのお世話になる。
開発用のPCには大体C/C++のコンパイラ入ってるし、問題にはならんけどな。

841 ：仕様書無しさん：04/07/29 00:39

>>838 諦めましょうもうCの勉強会（？）始まってる雰囲気ですよ。
Java原理主義はスレ明け渡しても良いのでは？
ここぞとばかりに質問。
これからWinでプログラム始めるのに「Winのクセ」見たいなの
ありませんか？

842 ：仕様書無しさん：04/07/29 00:40

クセが何を指すのか分からん>>841

843 ：仕様書無しさん：04/07/29 00:42

Mutexと二重起動でぐぐると、サンプルコードが腐るほど引っかかる。
VBやDelphiのサンプルもあり、C++特有の知識ではない。

さて、第２引数は何だ？

844 ：仕様書無しさん：04/07/29 00:42

>でも業務でアプリ開発するならJava単体ではお話にならない。
そのお話にならないシステムは沢山動いてるな

>結局C/C++コンパイラ付属のプリプロセッサのお世話になる。
なりません

>開発用のPCには大体C/C++のコンパイラ入ってるし、問題にはならんけどな。
バカですか?

845 ：仕様書無しさん：04/07/29 00:44

>>840
プリプロセッサがないとどうにもならないなんてことを自身満々に
いうなんて、「私は低能です。OOPわかってません。」といっている
のと同じですよ。あんた馬鹿でしょ？

846 ：仕様書無しさん：04/07/29 00:45

プリプロセッサが存在する言語はOOPではない。邪道だ。

847 ：仕様書無しさん：04/07/29 00:45

そこでJNIですよ

848 ：仕様書無しさん：04/07/29 00:45

VelocityはOOPじゃないぴょーん

849 ：仕様書無しさん：04/07/29 00:48

第二引数の記述
bInitialOwner
ミューテックスオブジェクトの初期の所有者を指定します。
このパラメータで TRUE を指定し、呼び出し側がミューテックス
を作成していた場合、呼び出し側スレッドはそのミューテックス
オブジェクトの所有権を取得します。FALSE を指定すると、
呼び出し側スレッドはそのミューテックスの所有権を取得しません。

この場合０わたしてるからFALSEでしょ？

850 ：仕様書無しさん：04/07/29 00:49

既にミューテックスが存在していた場合、そのミューテックスの所有者は誰なの？

851 ：仕様書無しさん：04/07/29 00:50

>>847
はっきりいってJNIを避けて通ろうとする標準APIの作り方は糞としかいいようがない

852 ：仕様書無しさん：04/07/29 00:51

>>843
検索してみたけど、ネット上のサンプルは1の場合と0の場合があるね。

853 ：仕様書無しさん：04/07/29 00:55

>>845
趣味でしかプログラムしたことないでしょ？
それだと、違うプラットホームで同じコード走らせたりとか、移植考えなくていいしね。

854 ：仕様書無しさん：04/07/29 00:58

ミューテックス作成　名前「DM-00」
ERROR_ALREADY_EXISTS
（同じ名前のミューテックス作ろうとすると発生）
で発生したら終了。
別プロセスのどっかで「DM-00」なるミューテックスプロセス
があると落ちる。考えられるのは
１、なんらかの別プログラムでたまたまこの名前を使ってる
２、既に同じプログラムがメモリ上で動作していて、そいつが保持してる
３、２のプログラムが開放するのを忘れてる

855 ：仕様書無しさん：04/07/29 01:08

>>854
API仕様見たかんじ保持っていうより存在だけさせてる感がないか？
保持はしてないで存在だけさせてれば同じプログラムの多重起動は
防げるだろ。多分そういうこと

856 ：仕様書無しさん：04/07/29 01:15

どうでも良いが
>>854 >>855
ageるな

857 ：仕様書無しさん：04/07/29 01:26

OpenGLではだめでつか？
（まだまだ発展途上っぽいですが）

858 ：仕様書無しさん：04/07/29 03:05

javaの価値はサーブレット(Servlet)のみにあり。

859 ：仕様書無しさん：04/07/29 06:26

とりあえず、JavaはWebアプリにしか使えませんな
しかし、その分野での開発効率は最も優れている

860 ：仕様書無しさん：04/07/29 06:56

Javaって銀行用ネットワーク言語というイメージしかない
携帯もC++が入って来てるしね

861 ：仕様書無しさん：04/07/29 08:52

>>856
どうでもいいなら書き込むな

862 ：仕様書無しさん：04/07/29 08:55

今、　>>768がいいことをいった

863 ：仕様書無しさん：04/07/29 08:59

>>780
> JavaとC++じゃ用途も違うし、そもそも比較対象にならない。
> JavaのライバルはVBとCOBOL

　JavaとVBでも用途が違いすぎるどころかあまりにも分野からかけ離れている。
　VBはほぼクライアントサイド専用言語に過ぎないからだ。しかもGUIを作るためにあるようなレベル。

同様にして、
　JavaとCOBOLとでも時代も用途もあまりにも違いすぎるどころかあまりにも分野からかけ離れている。
　今はメインフレーム時代ではないためCOBOLとは比較対象にはならない。
　WebServices, HTMLクライアント、リッチクライアントという分野が出た以上、COBOLだけでは取り扱えない
　分野なのでまず比較対象にするには無理。

864 ：仕様書無しさん：04/07/29 09:02

>>787
> JavaVMはバッファオーバーフロー起こします。C/C++で作られてるから。
言っている意図をりかいできないのうだろうか？
C/C++だからバッファーオーバフローを起こすとは限らないわけだが。
注意深く作ればバッファーオーバフローは起こりにくい。
だが、だれもが、どのC++厨をもが注意深くコーディングしているだろうか？
注意深くコーディングしテストを何度も繰り返したものだけに
限定して世に公開するということをやっているだろうか？
そこが問題だ。1

865 ：仕様書無しさん：04/07/29 09:23

>>789
> Javaを否定はせんがね、使いやすさの問題だろ。
> 用途で分けりゃいいじゃねぇか。
> マルチプラットフォームでやりたいならJava、それ以外ならCでとかさ
> もっとも、各OSのAPI叩いて動く様な言語が完全にマルチプラットフォーム
> 出来てるとは思えんがね…。

誰が、いつ、どこで、どのようにして「各OSのAPI叩いて」いるのか？
説明がわかりにくいぞ。

> （実際北見工大の信号処理研究室ではLinuxで動くのにWinで動かないとかで苦労してるらしい）
> 正直CもC++も分からんからと己の無能さを棚に上げて非難してるようにしか見えない。

どこの三流大学生の発言なんだか。
そういう発言を職人的発言というんだよ。
効率というものをわかっているかな。あんたの発言は、素手で荷を運ぶ職人が
クレーンを使って荷を運ぶ者を無能といっているようなものだぞ。

信号処理の研究をしているところほとんどがオブジェクト指向に否定的なところが多いからな。
画像工学では以外に、使われる傾向があるが、音声ではまだまだだな。
オブジェクト指向の利点がわからず「関数だけで」十分とと言い切る程度の
小規模プログラミングしかできない無能ヴァカが集まるところだからな。

866 ：仕様書無しさん：04/07/29 09:23

> Javaにtempleteもvirtualもoperatorも無い以上使う価値を見出せない。
> もちっと勉強してからスレ立てような>>1

勉強するのはあんたのほうだな。templateはJavaGenericsでもう何年か前から既に使えるようになっている。
virtualは書かなくてもvirtual扱いになる。変わりにfinalとかけば継承禁止になる。だが、継承を禁止にすると
処理速度が速くなると言う時代遅れな都市伝説をあんたは未だに信じているのか？

これをみればあんたのほうが無能だということを自覚するだろう。

Javaの理論と実践: パフォーマンスの都市伝説
ガーベッジ・コレクターなどのプログラミングに棲みついているワニについて
http://www-6.ibm.com/jp/developerworks/java/030627/j_j-jtp04223.html

operatorについては散々語られているが、オペレータオーバーローディングは濫用すればするほど
ソースコードを汚しオブジェクト指向言語としてのC++を生かし切れずにプロジェクトを破綻と
デスマーチのほうに導いてゆく結果になるぞ。それを解ってから発言しような>>789よ。

867 ：仕様書無しさん：04/07/29 09:24

>>780
> JavaとC++じゃ用途も違うし、そもそも比較対象にならない。
> JavaのライバルはVBとCOBOL

ﾊｧ? バカじゃネーノ。

868 ：仕様書無しさん：04/07/29 09:28

>>867
お前がな

869 ：仕様書無しさん：04/07/29 09:28

都市伝説その2: クラスやメソッドをfinalとして宣言すると処理が速くなる

この神話については、10月のコラム (参考文献を参照) で紹介済みなので、
ここで詳しい説明は繰り返しません。多くの記事では、クラスやメソッドを final と
して宣言することが推奨されています。これは、finalにすることにより、コンパイラー
がそのクラスやメソッドを簡単にインライン化できるため、パフォーマンスが向上するは
ずだという理由によります。これは確かによくできた理論です。しかし、真実でないの
は残念としか言いようがありません。

同期化の神話と比べてこの神話が面白いのは、裏付けのデータが何もなく、単にも
っともらしく見えるだけであるという点です (同期化の神話には、欠陥があるとは言え、
少なくともそれを裏付けるマイクロベンチマークがあります)。誰かがきっとこうに違いな
いと決め付け、自信たっぷりに他人に話したところ、それが噂になり、大きく広がってし
まったに違いありません。　　

この神話の危険なところは、同期化の神話とまったく同様に、実際には存在してもいない
パフォーマンス上のメリットを求めて、開発者がオブジェクト指向の優れた設計原則を破る
ことになりかねない点です。クラスを final にするかどうかは、そのクラスが何を実行し、
誰によってどのように使用されるか、および何らかの用途で継承される可能性があるか
どうかに基づいて決定される設計上の判断です。クラスが不変なので final にするのであれば、
それは適切な理由と言えます。また、継承を想定せずに設計された複雑なクラスを final にす
ることも理にかなっています。しかし、クラスを final にすると速くなるとどこかに書いてあったとい
うだけでは、たとえそれが真実であってもそうする理由にはなりません。　　

870 ：仕様書無しさん：04/07/29 09:30

Javaにvirtualが無いくらいで偉そうな態度とる北見工大の学生もまだまだ未熟だな

871 ：仕様書無しさん：04/07/29 09:34

>>840
> Javaは使いやすいし、趣味とか速度を気にしない分野ではそれなりにイケてる。
> でも業務でアプリ開発するならJava単体ではお話にならない。
> 結局C/C++コンパイラ付属のプリプロセッサのお世話になる。
> 開発用のPCには大体C/C++のコンパイラ入ってるし、問題にはならんけどな。

お前はさ、サーバサイド開発をやっていないからそういうことをいえるんだよ。
どうせスタンドアロンアプリしか作ったことが無いんだろ。

872 ：仕様書無しさん：04/07/29 09:35

ようは、Ｃ厨は考え方が古いってことでしょ。
ネットワークとか、クライアントサーバシステムっていわれてもC++厨にはわからないんだよ。
だから「Javaは遅い」といっていられるんだよ

873 ：仕様書無しさん：04/07/29 10:27

C++　 =　東工大
Java　= 北見工大

874 ：仕様書無しさん：04/07/29 10:28

だからJAVAで#ifdefの使い方教えろ

875 ：仕様書無しさん：04/07/29 10:33

COBOL = 平成国際大学
VB　 = 都立中野中学

876 ：仕様書無しさん：04/07/29 11:11

preprocesser.define("unko");

if(preprocesser.ifdef("unko"))
{

print("unko");

}
else if(preprocesser.elseIf("unko2"))
{

print("unko2");

}

877 ：仕様書無しさん：04/07/29 13:25

つーかそんなに速度って重要か?
javaでも十分はえーと思うが

878 ：仕様書無しさん：04/07/29 18:43

>>877
世の中、お前みたいな暇人ばかりではないんだよ。

879 ：仕様書無しさん：04/07/29 19:54

両立しようよ…どっちも出来なきゃどうしようもないんだしさ…
C++の言語仕様はキモくたってJavaよか痒いトコに手が届くし
Javaは言語仕様が割と分かりやすいし安全性ではC++よかいいしさ…。
このスレ立てたのJava厨なんだろ～けどさJava厨もC厨も厨止めてそれぞれを
認めないと厨止まりで終わるよ？

880 ：仕様書無しさん：04/07/29 20:10

JavaとC/C++は用途が違うと何度いえば（ｒｙ

881 ：仕様書無しさん：04/07/29 20:21

200 仕様書無しさん 04/07/28 02:16
C++とJavaって....
クライアントでしか使い道の無い言語と
サーバでしか使い道の無い言語を比較してんの？

201 仕様書無しさん sage 04/07/28 02:17
>>200
それが何か？

202 仕様書無しさん sage 04/07/28 02:19
>>201
いや､､､別に良いけど....

203 仕様書無しさん sage 04/07/28 02:26
>>202
そうですか、別に良い事を聞くとは変わったお人だ。

882 ：仕様書無しさん：04/07/29 20:26

このスレ自体C/C++ユーザへの誹謗中傷であってこのスレ自体が
「別に良い事」であるに一票

883 ：仕様書無しさん：04/07/29 23:52

>>874
> だからJAVAで#ifdefの使い方教えろ
Jakarata Velocityを使え。

以上

884 ：仕様書無しさん：04/07/29 23:53

>>883
いい奴だなお前

885 ：仕様書無しさん：04/07/30 00:15

すげえな、このスレ。
痛々しいとか香ばしいとかそういう次元を超越している。
ここまでくると、清々しささえ感じてしまう。

こんな清々しさ感じさせてくれたJavaに感謝age

886 ：仕様書無しさん：04/07/30 00:21

>>840
> Javaは使いやすいし、趣味とか速度を気にしない分野ではそれなりにイケてる。
C/C++厨のほうが趣味でやってる香具師が多いが。Javaの案件とC++の案件の数の
さが引き起こしている現状を見てみればよくわかるように。

> でも業務でアプリ開発するならJava単体ではお話にならない。
むしろ業務アプリでこそJavaが使われているぞ。
J2EEは基幹系業務向けにつくられているからな。
実際、J2EEを使うところも増えている。J2EEのEJBを使わずTomcatでServlet系だけを使うところが多いが。
それでも業務系に使われている。クライアントサーバシステムといえばJavaだと言い切っていいくらいに。

> 結局C/C++コンパイラ付属のプリプロセッサのお世話になる。
> 開発用のPCには大体C/C++のコンパイラ入ってるし、問題にはならんけどな。

おまえ、それはLinuxとか*BSDとかのことをいっているのか？
だったらJavaコンパイラだって入っているぞ。

887 ：仕様書無しさん：04/07/30 00:22

>>885
すげえ痛々しい奴だなお前。
三流北見工業大学のC厨か?(ﾜﾗ

888 ：仕様書無しさん：04/07/30 00:22

と、専門学校卒の派遣JavaPGが申しております。

889 ：仕様書無しさん：04/07/30 00:24

>>857
> OpenGLではだめでつか？

OpenGLを使うならば Java3D API, JOGL, Xith3D, jGL
を使うことが望ましい。

チャレンジしてみてくれたまえ

890 ：仕様書無しさん：04/07/30 00:26

>>860
> Javaって銀行用ネットワーク言語というイメージしかない
> 携帯もC++が入って来てるしね

BREWはJavaほどに流行らないだろう。

BREW用に作ったコードを世に出すだけでも
金のかかる認証が必要な上に登録も必要。

それだけBREWは開発の自由を奪われていると言うことである。
しかもJavaよりも安く開発してくれと頼んでくる案件が多いんだそうだ。

891 ：仕様書無しさん：04/07/30 00:27

>>888
ﾊｧ？　大卒で今大学院生だが。

892 ：仕様書無しさん：04/07/30 00:28

>>888は三流北見工大卒のﾊﾞｶ派遣Cプログラマだったのか(嘲笑

893 ：仕様書無しさん：04/07/30 00:33

北海道の大学生がJavaをなめてかかって墓穴を掘って恥をかいたスレはここですか？

894 ：885：04/07/30 00:38

いやいや、Javaの偉大さを知らしめるのに、
これほど、ふさわしいスレはないでしょう。
このスレはをみたC/C++厨は恐れおののくに違いない。

どんどんあげていきましょうage

895 ：仕様書無しさん：04/07/30 00:40

北見広大ってはじめて聞いて調べたら底辺じゃないか。こんな大学は高学歴なら全く知らなくて当然。
なのに知ってる>>892はたぶん高卒で学歴コンプを２ｃｈに植え付けられたバカ。

896 ：仕様書無しさん：04/07/30 00:46

>>890
> Javaよりも安く開発してくれと頼んでくる案件が多い
如何にも潰れそうな会社だな

897 ：仕様書無しさん：04/07/30 00:47

いや、そもそも北見工大ごときで自慢できると勘違いしているヴァカ大学生をからかうために
言っただけだよｗ

by 大卒の大学院生

898 ：仕様書無しさん：04/07/30 00:49

>>896の発言にはどういう根拠があるんだろうな。
10年前にそういう発言すればそう思うものがいてもおかしくなかったがな。
今では>>896のような発言をしても赤っ恥をかくだけに過ぎない。
C++にいつまでもすがりついている香具師は時代遅れで思考が10年前で止まっている人と言われる。

899 ：仕様書無しさん：04/07/30 00:51

by 大卒の大学院生

ふつう恥ずかしくてこんなことかかねぇぞ
専門卒の派遣さん

900 ：仕様書無しさん：04/07/30 00:52

>>896
そもそも、BREWなんて認証に金のかかるような案件を引き受けるだけでも収支が大幅に減るんだよ。
Javaよりもバグを出しやすいため開発コストがかさむからねえ。
顧客側がJavaよりも高い金をだしてくれるんなら引き受ける会社も多いんだろうけど。

901 ：仕様書無しさん：04/07/30 00:52

>>899
何だ？　お前は本当に専門卒だったのか？
それか高卒の派遣Ｃプログラマか？それとも、高卒の北見工大の大学生か？w

902 ：仕様書無しさん：04/07/30 00:53

>>899
いやマジで大学院生なんだが。

903 ：仕様書無しさん：04/07/30 00:54

>>902
リアルでそうならパラサイトシングルよろしくフリーターコースだな

904 ：仕様書無しさん：04/07/30 00:58

でも正直Javaって完全に盛りを過ぎてるだろ、
COBOLがあれだけ隆盛を誇ったのにあっと言う間に廃れたのと
同じ感じがする
Cは今のPascalのように、未来で主流ではないがしぶとく生き残る
だろうけど

905 ：仕様書無しさん：04/07/30 01:06

C厨の言い分：
　「Java厨はJavaでジャバジャバ水遊びでもしてりゃいいんだよ（ﾌﾟ」

Java厨の言い分：
　「C厨はCでシコシコオナってやがれ（ﾌﾟ」

906 ：仕様書無しさん：04/07/30 02:52

>>898
C++はここ五年くらいで激変している、止まってしまっているはむしろJavaの方
また、Javaは現状にとどまる事を望んでいるし、それがJavaの強みかつ弱みだ
もし進んでいると思うなら、それは妄想。

907 ：仕様書無しさん：04/07/30 03:05

アスペクトJってどうなの？何か拡張の仕方が厨じみてるんだけど

908 ：仕様書無しさん：04/07/30 10:33

>>902
院生はふつー大卒ですね。

909 ：仕様書無しさん：04/07/30 10:35

>>904
>COBOLがあれだけ隆盛を誇ったのにあっと言う間に廃れたのと
　　　　　　　　　　　　　　　　　　　　　　　　￣￣￣￣￣￣￣￣￣
甘いな

910 ：仕様書無しさん：04/07/30 10:54

> by 大卒の大学院生

こういうこと書く香具師は、本当の意味で「バカ」
勉強できれば良しと思ってる時点で、仕事はできない香具師だろうな。
応用力のない高学歴者はﾂｶｴﾈ。しかもプライドは高いときやがる。

仕様不備を指摘したら、
SEで「文句があるなら東大くらいでてこい！」

名言でしたね（ﾌﾟ　今や、我が社では無能伝説ですよ。

911 ：仕様書無しさん：04/07/30 10:56

> 大卒の院生

っていうか... 院生っていうのはフツー大卒ですね :)

漏れは、仕事のできるできないは学歴と関係ないと思うのだがな。
かくいう私も大卒だが、だからなんだって感じだし。
大卒でできる人間っていうのは、学歴に拘らん香具師だと思うが。
漏れの後輩の高卒で頭があがらない香具師はいくらでもいるし。
我が社では、大卒SE＜それ以外のSE＜大卒PG≒専門卒PG＜高卒
と、高卒が１番仕事ができるんだが...。

うちの会社だけかのう。

912 ：仕様書無しさん：04/07/30 10:57

単に経験が多いってだけじゃなくて？

913 ：仕様書無しさん：04/07/30 12:16

というかスレと関係無い所でしか叩けない君らが無能では？

914 ：仕様書無しさん：04/07/30 12:26

>>913
ﾌﾟｯ。

915 ：仕様書無しさん：04/07/30 12:29

>>912
うん。後から入ってきた高卒新人PGの方が使えるくらいだもん。
応用力のない香具師は「経験」をいくら積んでも無能。

じゃあ、聞くが、君が大卒の管理者ならどっちを使う。
ちなみに実力が均衡してても迷わず、高卒PGを選ぶ。
プライドが高い香具師は、使いづらい（命令しづらい）

・1を聞いて10を知る有様の高卒PG
・プライドが高く、経験は豊富だが応用力のない口だけ達者な大卒PG

916 ：仕様書無しさん：04/07/30 12:32

>>868==>>780
無能。もういっぺん言語仕様勉強してこい。

917 ：仕様書無しさん：04/07/30 12:38

>>916
同意。

JavaとVBとCOBOLでは畑が違います。はい。
Javaと.NET言語の場合は、言語仕様的にWindows上ではライバル。
つまり、>>780は超無能。
自分で挙げた言語くらいまともにやってから、えらそーなこと言ってくれ。

918 ：仕様書無しさん：04/07/30 12:45

そんなことより、このスレは香ばしい人
（Javaしかできない香具師 || C, C++しかできない香具師）
が多いですね。

結構似てるんだし、両方できるようにしてくださいです。

919 ：仕様書無しさん：04/07/30 12:47

>>918
同意。が、C++しか出来ないやつってあんま見ないような…
少なくともJavaは出来るだろ
（やった事無いって香具師は居そうだが）

920 ：仕様書無しさん：04/07/30 12:50

>>919
俺は、C++ → Javaだが。
やったことなくてもできたからなぁ。

921 ：仕様書無しさん：04/07/30 12:54

＞Javaを叩くC++厨房
JavaはC++ができれば、まあできる。
とにかくやってみて、文句言え。
以外と好きになるぞ。
ただし、その後.NET言語をやると戻れなくなるぞ。

＞C++を叩くJava厨房
C++もやってみれ。
Javaほど統一感はないけど、びっくりするほど色々できる。
ただし、その後.NET言語をやると戻れなくなるぞ。

＞.NET厨
んー、戻りたくないんだよねぇ・・・。
わかるよ、漏れもそうだから（C++ → Java → .NET です…戻れません…）
.NET言語・・・卑怯なくらい良い所だけパクリ。藤木みたいだな。
（VBの生産性のよさ＋C++ほどではないが早い＋Javaの統一感）

922 ：仕様書無しさん：04/07/30 12:56

そうだよ、お前ら仲良くしろ。
両方やってみれ。

923 ：仕様書無しさん：04/07/30 13:55

JavaはC++のサブセットですよ。

924 ：仕様書無しさん：04/07/30 13:57

Javaはお猿さん用C++ですよ。

925 ：仕様書無しさん：04/07/30 16:42

Javaは補助輪つきC++ですよ
転ばないから安心でちゅよ

926 ：仕様書無しさん：04/07/30 23:37

しかし転ぶ人多すぎ

927 ：仕様書無しさん：04/07/31 05:06

ジャイロをつけるとC#になりまつか？

928 ：仕様書無しさん：04/07/31 06:07

Cを馬鹿にしてる奴→両方やってみて使いやすいほうを選択した人間。苦い経験から。
javaをコケにしてる奴→Cしかできないまま年食った化石。ひがみ。

929 ：仕様書無しさん：04/07/31 06:12

Delphi

930 ：仕様書無しさん：04/07/31 07:11

C#やん。
おまえらみんなぬるぽ。

931 ：仕様書無しさん：04/07/31 21:10

>>906
Boostを使ったくらいで自分が「できるC++プログラマ」と勘違い
する香具師が最近増えてきたという激変か。

932 ：仕様書無しさん：04/07/31 21:15

>>910
> > by 大卒の大学院生
>
> こういうこと書く香具師は、本当の意味で「バカ」
> 勉強できれば良しと思ってる時点で、仕事はできない香具師だろうな。

お前なあ、何か勘違いしていないか？
大学院というところは勉強するところではなく研究するところだぞ。
書いたくらいでバカよばわりするの藻前のほうがバカだ。

> 応用力のない高学歴者はﾂｶｴﾈ。しかもプライドは高いときやがる。
だれもがそうだとは限らんぞ。

> 仕様不備を指摘したら、
> SEで「文句があるなら東大くらいでてこい！」
> 名言でしたね（ﾌﾟ　今や、我が社では無能伝説ですよ。

だれもがそんな言い逃れをするとは限らないだろうが。偏見持ちすぎだ藻前は。

933 ：仕様書無しさん：04/07/31 21:17

>>918
まずJavaしかできない香具師はいない。
Javaで食っていくためにはデータベース、ネットワーク、
サーバ管理といったスキルを要求されるからだ。
Javaができるや知ってのはOracleやPostgreSQL, TCP/IP、
*ＢＳＤやLinuxなどのスキルも持ち合わせている者が多い。
さもないとServletの仕事なんてやっていられないから。

934 ：仕様書無しさん：04/07/31 21:19

>>921
つまり藻前はドトネト厨房か。
戻れないっていうかWindows依存症だろ。
Unix使えよ。戻れなくなるぞ。

935 ：仕様書無しさん：04/07/31 21:20

C/C++信者が主張するJavaに対する自由度ってのは
セキュリティホール丸出しにできることばかりだからなあ。
自由と言うよりも、まるで人に殺される自由を手に入れた無法地帯の人間に
なれるぞっていっているみたいだなあ。それをC/C++信者は、

「いつ殺されるかわからない、無法地帯にいく『勇気』が無い者は臆病者だ」と主張するんだよなあ。
おいおい、そんなのは真の『勇気』じゃないって。
彼らにはエクストリームプログラミングの提唱者、ケントベックの爪の垢でも飲ませてやりたいよ。

936 ：仕様書無しさん：04/07/31 21:40

C/C++がJavaに対して持っている最大の自由度は
素のCPUで動くか、VMがいるかって違いだな

C/C++でもJavaでも、C/C++コンパイラやJavaコンパイラはかける
また同様に、C/C++でもJavaでもJVMが書けるが、
Javaで書いたJVMは、それとは別にJVMがないと動きゃしない

937 ：仕様書無しさん：04/07/31 21:45

単に吐き出したコードが、CPU命令かVM命令かってだけじゃん。
こんなの命令セットの違いだけで自由度とは言わん。

938 ：仕様書無しさん：04/07/31 21:57

>>937 たのしい？

939 ：仕様書無しさん：04/07/31 22:01

その吐き出す命令セットの違いがあり
その違いは、決定的かつ致命的だからこそ
JVMはJavaで書かれていないわけだが

940 ：仕様書無しさん：04/07/31 22:08

制限すること目的に書かれたJavaに対してCと比べて自由度が足りないってのは笑えるな。

941 ：仕様書無しさん：04/07/31 22:11

制限するのが目的のわけないべ
制限するのは、安全とのトレードオフ
安全性向上が目的

とはいえあくまでトレードオフさ

942 ：仕様書無しさん：04/07/31 22:17

>>941
そうね、言いたかったのはお前の書いたとおりだ。
つーか、Java使ったことのある奴なら常識なんだが、判ってない奴
がうろついてる。