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

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

Javaって重くね? その10

1 :仕様書無しさん:2006/07/22(土) 14:55:16
語れ。

2 :仕様書無しさん:2006/07/22(土) 14:56:01
過去すれ

その1 http://pc8.2ch.net/test/read.cgi/prog/1131448367/
その2 http://pc8.2ch.net/test/read.cgi/prog/1136359572/
その3 http://pc8.2ch.net/test/read.cgi/prog/1138029112/
その4 http://pc8.2ch.net/test/read.cgi/prog/1139707592/
その5 http://pc8.2ch.net/test/read.cgi/prog/1140613666/
その6 http://pc8.2ch.net/test/read.cgi/prog/1143032241/
その7 http://pc8.2ch.net/test/read.cgi/prog/1145099878/
その8 http://pc8.2ch.net/test/read.cgi/prog/1146146874/
その9 http://pc8.2ch.net/test/read.cgi/prog/1148145355/


3 :仕様書無しさん:2006/07/22(土) 15:29:29
乙。どろろろろろろろろろろろろろろろろろ〜

4 :仕様書無しさん:2006/07/22(土) 20:51:37
クラス WhiteColorException

java.lang.Object
 +java.lang.Throwable
  +java.lang.Exception
   +java.lang.RuntimeException
    +java.lang.WhiteColorException

すべての実装されたインタフェース:
Serializable

public class WhiteColorException
extends RuntimeException

Javaが重くて真っ白に表示される場合にスローされます。
元ネタttp://pc8.2ch.net/test/read.cgi/prog/1149331575/50

(続く)

5 :仕様書無しさん:2006/07/22(土) 22:25:22
まだやるの?w

6 :仕様書無しさん:2006/07/22(土) 22:39:54
あるとおじゃばさまがあばれて
良いこと尽くめだから

7 :仕様書無しさん:2006/07/23(日) 09:56:01
>>4
WhitePageExceptionのほうがよくね?

8 :仕様書無しさん:2006/07/23(日) 10:36:38

  ∧_∧
 ( ´∀`)< ほわぺ



9 :仕様書無しさん:2006/07/23(日) 15:51:57
前スレの夏にしたい君がおもろいでー

10 :仕様書無しさん:2006/07/23(日) 19:40:39
うめたでー

11 :仕様書無しさん:2006/07/23(日) 19:41:38
>>8
グッ!

12 :仕様書無しさん:2006/07/23(日) 20:42:25
止まってるのに誰が例外投げるの?

13 :仕様書無しさん:2006/07/23(日) 21:22:53
javaしか投げないよ

14 :仕様書無しさん:2006/07/23(日) 23:29:16
場合によってはCより速いとか。
多少速いことがそんなに重要なのかわかりませんが。
どんな言語にもメリット、デメリットがあり、場合によって使い分けるものだと思いますが。

15 :仕様書無しさん:2006/07/23(日) 23:33:02
Cより速いってのは業務同士で組んだ場合のコード品質の差だよ
チューニングのプロ同士でやったら、どうやってもJavaはCに勝てない
生産性4倍で実行コードは2倍遅いくらいに考えとくがいいさね

16 :仕様書無しさん:2006/07/24(月) 00:15:17
c++とjavaってそんなに変わんないじゃん
javaで組める人だったらc++でも組めるんじゃない?

17 :仕様書無しさん:2006/07/24(月) 00:18:44
組めるよ。俺は元々Cから入ってるから、Javaから入った学生とかは知らんが。

18 :仕様書無しさん:2006/07/24(月) 00:26:03
生産性4倍(糞馬鹿Java厨がてきとうに作成)
デバック時間(36倍)
それでも工数が足りなくなるのがJava

19 :仕様書無しさん:2006/07/24(月) 00:27:06
java厨が問題なんだよな

20 :仕様書無しさん:2006/07/24(月) 00:27:14
Java厨は書き逃げするから
あとのテスターが泣きをみるパターンが多い

21 :仕様書無しさん:2006/07/24(月) 00:30:20
年がかりを3ヶ月で回せるのはJavaのお陰
ドカタがどれだけJavaを否定しようと経営者は判断を間違えないよ

22 :仕様書無しさん:2006/07/24(月) 00:34:44
経営者

23 :仕様書無しさん:2006/07/24(月) 00:41:42
生産性を言うならJavaは.NETに勝てないよ?
事実.NETのサイトは凄い勢いで増え続けてるしな。
どっちにしろJavaは二流以下と判断せざるを得ないよ。

24 :仕様書無しさん:2006/07/24(月) 00:52:48
二流なのは>>23だろ?プログラマは言語を選びません。

25 :仕様書無しさん:2006/07/24(月) 01:01:04
>>24
経営者云々って話の流れなのに....
いや、コーディング命の最下流には分からない話かもしれんが。

26 :仕様書無しさん:2006/07/24(月) 01:04:06
勝てないよ?とかコーダにもなれないレベルの奴が言ってもな

27 :仕様書無しさん:2006/07/24(月) 01:53:03
経営者が判断するのはコストだけ。
技術がどうこうなんてどーでもいい。
.NETの方が安く上がる、と判断すれば替えるだろ。

28 :仕様書無しさん:2006/07/24(月) 01:55:01
なら変えない奴のが多いな

29 :仕様書無しさん:2006/07/24(月) 02:02:39
.NETの敵はPHPだろ
Javaとは適用が違うんだから馬鹿なレスもってくんな

30 :仕様書無しさん:2006/07/24(月) 02:11:56
>>29
バカスwww

31 :仕様書無しさん:2006/07/24(月) 02:15:50
w君登場、もう必死かよ

32 :仕様書無しさん:2006/07/24(月) 08:00:06
生産性4倍でも品質・保守性を1/4以下に下げるJava厨様が多すぎる。
Java厨が増える程にソースに壊滅的なダメージを与えるしな

33 :仕様書無しさん:2006/07/24(月) 08:44:34
Javaバブルがはじけたころ仕事が来る寸法か

34 :仕様書無しさん:2006/07/24(月) 10:02:54
ちゅうかjavaに似た変な言語派生しすぎ。
全部Javaの仕様に統一すれば良いのに。
JavaScriptとかも言語仕様をちゃんとJavaそのものにしちゃって、
ブラウザ内で動く超軽量版Javaにしちゃえば良いのにね。

actionScriptとかも然りで。

言語仕様としてのJavaは非常に優れているのだから、(証拠にまねた言語が沢山出てるよな)
もっと汎用性を高めれば良いと思う。

大体ここの連中も速度以外では叩けていない訳で、
要はVMの仕様にしか欠点を見出せないってこと。

35 :仕様書無しさん:2006/07/24(月) 10:20:12
VMの仕様以外にも、
・乱立する粗悪なフレームワーク
・動きのあやすいAP鯖
・つきることのないXML地獄
が欠点だと思うけど

36 :仕様書無しさん:2006/07/24(月) 10:37:26
>>35
うむ。まず速度的に「使い物にならね」で閉じちゃうから
その他の問題が隠蔽されるのだな。
これはJavaにとっては歓迎すべき事なのでは。

VMの仕様以外にも、
・そのばしのぎの拡張を繰り返すAPI

37 :仕様書無しさん:2006/07/24(月) 12:23:16
javaをなくせば問題ない

38 :仕様書無しさん:2006/07/24(月) 12:42:49
汎用性を高めるより先にライブラリを統廃合すべきだろ

39 :仕様書無しさん:2006/07/24(月) 15:17:14
Javaの仕様に統一しようとすると
サンマイクロからクレームが来ますので。


40 :仕様書無しさん:2006/07/24(月) 15:26:02
java自体はべつに悪くないと俺も思う。

ただ、言語仕様とは別でライブラリはどこから手をつけたらいいかわからないくらい巨大になった感はあるなぁ。
αjavaで遊んでいるときはたのしかった。


41 :仕様書無しさん:2006/07/24(月) 15:28:15
CでWeb系、ネットワーク系でJavaより使いやすいフレームワーク教えてください。
GUIは、MFC?

42 :仕様書無しさん:2006/07/24(月) 17:22:12
.net framework

43 :仕様書無しさん:2006/07/24(月) 17:27:43
MFCがJavaより使いやすいってことはいろいろ使ってみれば
あり得ない気がするが……単なる慣れじゃね?

44 :仕様書無しさん:2006/07/24(月) 18:13:39
ヒニクにマジレスワロス

45 :仕様書無しさん:2006/07/24(月) 20:04:15
フレームワークがないとなにも出来ないのがJava厨スペック。

46 :仕様書無しさん:2006/07/24(月) 20:55:10
>>41
本気レス求む

SDKでゴリゴリ書いてつくるのしんどい
業務ロジックだけ書いたら済むCorC++のフレームワークください
それとも、いつもスクラッチor個人資産のコピペ?

47 :仕様書無しさん:2006/07/24(月) 21:07:19
>>46
残念だけどC厨は口先だけだから何も出てこないよw

48 :仕様書無しさん:2006/07/24(月) 21:41:15
Java厨もその点は同じだべ
口をつくのはいつも他人の資産だからな

49 :仕様書無しさん:2006/07/24(月) 21:47:27
>>48
うひゃ。自分じゃ絶対作る気がしないのがJava厨スペック

50 :仕様書無しさん:2006/07/24(月) 21:49:41
自分ではソースも見たことないJVMの事をさして
勉強になるから見ろといってさんざんたたかれたのは
この前のスレでの事。まあJava厨はINetに転がっている
情報の見出しだけで勝負しているのは自明。

51 :仕様書無しさん:2006/07/24(月) 22:07:12
>>47
C厨からはエロゲの話題しか出てこない…マジで

52 :C厨:2006/07/24(月) 22:12:52
さて、マブラヴでもやるか

53 :仕様書無しさん:2006/07/24(月) 22:29:10
>>51
ほほお

54 :仕様書無しさん:2006/07/24(月) 23:55:51
つうかさJAVAって結局スクリプト言語並みの糞言語だよな
Groobyだっけあんなしょうもないもの作って連携して
他のスクリプト言語とためはって勝負したりとしょうもないにもほどがあるな

55 :仕様書無しさん:2006/07/25(火) 00:30:36
スクリプト言語が糞言語という発想が既に貧相な脳を物語ってるな

56 :仕様書無しさん:2006/07/25(火) 00:48:11
結局 Java の API も Windows API と同じ道をたどりつつあるな。
Java のほうがクラスやパッケージという分類機構があるが、しかしここまで
大量になるともはや気休め程度でしかない。
汎用目的ライブラリだと各方面からの要求が激しいから、こうなるのも宿命なのかな。

家電向けに特化してれば、今頃もすっきりきれいな設計のままだったろうに・・・。

57 :仕様書無しさん:2006/07/25(火) 00:49:36
ぶっちゃけ、スクリプト言語のほうが安定してるでしょ?

58 :仕様書無しさん:2006/07/25(火) 00:50:26
C/C++ のように標準で用意するライブラリは最低限にして、あとは勝手に
サードパーティのライブラリを適当に使ってくれ、というポリシーの方が
長期的には利口なのかな。

59 :仕様書無しさん:2006/07/25(火) 00:58:41
>>56
長文で無知さらして楽しい?

60 :仕様書無しさん:2006/07/25(火) 01:00:06
>>58
ライブラリ地獄気味なのはライブラリそのものが作りやすいからだよ
心配せんでもCommonsとかの大半は使われずに消えてゆく

61 :仕様書無しさん:2006/07/25(火) 01:04:30
>>58
移植性低くなるじゃん。

>>56
同意。多すぎ。もう全部把握してる人間なんていないんじゃね?
オープンソース化したらさらにこの流れが進むかもね。
.NETに対抗しようとして、言語仕様もガンガン変えてるし。もういいよ。

62 :61:2006/07/25(火) 01:09:27
APIじゃなくて言語仕様のはなし。
仕様をグルーピングして第一水準とか第二水準とか分けて欲しいw。
今回のプロジェクトは第一水準内で作りましたみたいな。
まあ、実質あるのかな。1.4レベル 5.0レベル 7レベル。。

C++でのプロジェクトでは、一般的に仕様縛りする?テンプレート禁止とか。
例外禁止とか、クラス以外のC++機能禁止とか。

うちはやってるけど。

63 :仕様書無しさん:2006/07/25(火) 01:25:08
5.0やっててGenerics禁止にするのって馬鹿としか思えない
拡張for禁止、enum禁止とかなら、過去資産組の救済としてアリとは思うが

64 :仕様書無しさん:2006/07/25(火) 01:26:01
てかC++ってSTL使う奴少ないよな

65 :仕様書無しさん:2006/07/25(火) 01:50:26
J2MEだっけ?組み込み用。あれはAPI仕様がいくつかプロファイル定義されてたね。

66 :仕様書無しさん:2006/07/25(火) 03:54:35
Javaの可能性は無限大

67 :仕様書無しさん:2006/07/25(火) 04:09:08
>>55
> スクリプト言語が糞言語という発想が既に貧相な脳を物語ってるな
つまり「Java厨が貧相な脳」ってことになるけど、本当にそれでいいの?
Java厨は
・スクリプト言語=劣
・スクリプト言語以外=優
っていう発言をしょっちゅうしてるけど。そんなにコンパイラ型言語が偉いんかっちゅーぐらい。
スクリプト言語をバカにしてるのは否定できまい。


68 :仕様書無しさん:2006/07/25(火) 15:00:49
PHPの言語仕様のクソさに比べたら、Javaは神の領域

69 :仕様書無しさん:2006/07/25(火) 15:06:21
仕様だけ象牙の塔
実用度は別

70 :仕様書無しさん:2006/07/25(火) 15:28:52
PHPの方が軽くて早いだろ

ビジネスロジックwは無理かも試練が

71 :仕様書無しさん:2006/07/25(火) 17:33:39
つか、Javaの大飯食いと重さが異常なだけ。

72 :おじゃばさま:2006/07/25(火) 19:24:11
ライブラリが多くて収拾がつかないってのは認める。
実際、使い物にならない物も数多くあるが、今まで自作していた手間に代わって、
使えるライブラリを調査する手間がかかる物だと思ってくれ。
つまり「使えるライブラリを調査する」のもJava技術者に必要な技能なのだ。

>67
別にスクリプト言語を馬鹿にしてはいない。


73 :仕様書無しさん:2006/07/26(水) 00:09:56
え?馬鹿にし腐ってるじゃんjava厨軍団は

74 :仕様書無しさん:2006/07/26(水) 00:14:42
スクリプトのほうが軽いってどういうこと??????

75 :仕様書無しさん:2006/07/26(水) 00:20:36
けど、Javadocの見やすさは神!時々rubyやphpを使うときに死ぬほど萎える。

76 :仕様書無しさん:2006/07/26(水) 00:20:54
ピザでも食ってろ。Java

77 :仕様書無しさん:2006/07/26(水) 00:43:57
>>75
> けど、Javadocの見やすさは神!
アホ発見

78 :仕様書無しさん:2006/07/26(水) 01:00:17
そりゃPHPに比べりゃ大抵の言語は神レベルに見やすいわなw

79 :仕様書無しさん:2006/07/26(水) 07:15:14
>>73
お前一人が馬鹿にしてるだけだろ
腐ってるのはお前の脳

80 :仕様書無しさん:2006/07/26(水) 07:31:40
Java脳の恐怖

81 :仕様書無しさん:2006/07/26(水) 12:03:58
>>79が必死な件について。
今更そんなしょうもない嘘ついて何になるんだ?くだらない。
別にバカにしててもいいんじゃないか?Javaはスクリプト言語ごときに負けるわけがないんだろ?

82 :仕様書無しさん:2006/07/26(水) 17:03:56
スクリプト言語のほうがシンプルで無駄がなく
少なくともJavaよりはいいな。

83 :仕様書無しさん:2006/07/26(水) 20:36:32
>>81
何をもって勝ち負けを判定するんだ?

84 :仕様書無しさん:2006/07/26(水) 20:58:34
>41
>CでWeb系、ネットワーク系でJavaより使いやすいフレームワーク教えてください。
>GUIは、MFC?
そんなもんはねえよ、提供された最低限の機能をつかって
高品質、低コストの結果を出すのが職人の仕事だろ
フレームワ−クなんて信用できねえのは必要ない
部品がないとつくれない糞Java厨はかわいそうだね

85 :おじゃばさま:2006/07/26(水) 21:36:35
>81
俺は言語を馬鹿にしたことはない。
馬鹿にしているのは、「いつまでもたっても1つの言語しかできない厨」。

>84
使いにくいが、OpenViewなんてどうだ?


86 :仕様書無しさん:2006/07/26(水) 21:42:51
Javaは全ての言語の進化系でありJavaに精通しているということは全ての言語を網羅したことに等しい。





















とか本気で思ってそうでヤバス

87 :仕様書無しさん:2006/07/26(水) 22:02:40
CのWeb系ねぇ・・・・。

Apacheのモジュールなんかだと雛型になるソースを生成するツールがapacheに付いているが。。。
あとはcgicとか。


88 :仕様書無しさん:2006/07/26(水) 22:10:34
別スレでC++製のサーブレットコンテナ公開してたじゃん。
あんなのじゃだめなんか?

89 :仕様書無しさん:2006/07/26(水) 23:13:20
あれって結局Javaは作りやすくていいねって宣伝にしかなってないな

90 :仕様書無しさん:2006/07/26(水) 23:14:30
もうJavaのweb系を語るのは止めた方が良いんじゃないの?
.netとphpに弾き出されて絶滅寸前なんだからさ。

91 :仕様書無しさん:2006/07/26(水) 23:20:36
頼むからインデント揃えろ

92 :仕様書無しさん:2006/07/26(水) 23:21:57
>>89
もう少し開発が進んでTomcatとの性能比較とかしたら面白そうだけどな

93 :仕様書無しさん:2006/07/26(水) 23:26:50
>>90
数字調べてから語ろうな、無職

94 :仕様書無しさん:2006/07/26(水) 23:33:42
かといって自分の会社の案件ベースの数字を出しても意味がないわけだがな

95 :仕様書無しさん:2006/07/26(水) 23:43:30
.NETって単語だけで笑けてくるw

96 :仕様書無しさん:2006/07/26(水) 23:48:21
もしJava厨がいなくなったら
→仕事が増えてC/C++厨が喜ぶ

もしC/C++厨がいなくなったら
→VM更新できなくなってJava厨が困る

97 :仕様書無しさん:2006/07/27(木) 00:35:01
実際、Java案件減ってるじゃん。
たかがWebに手間かかりすぎ、金かかりすぎなんだよ。

98 :仕様書無しさん:2006/07/27(木) 00:37:15
たしかにJavaのピークは2002年から2003年にかけてだね。
もうくだりきってふもとが見え出したところだね。

99 :仕様書無しさん:2006/07/27(木) 00:47:03
減ってないから。実際お前は嫉妬に狂ってるわけで。

100 :仕様書無しさん:2006/07/27(木) 00:47:20
2000年〜2003年までかな。

101 :仕様書無しさん:2006/07/27(木) 00:48:10
減ってないって。アホ

102 :仕様書無しさん:2006/07/27(木) 00:49:58
そりゃお前の会社がドカタ派遣会社だからだろ。

103 :仕様書無しさん:2006/07/27(木) 00:50:54
C/C++専門でやってる奴がバイトオーダーとか知らなくて
笑いこらえるので大変だったことがある
さらに傑作だったのがSTLが使えないって所

あいつらってさ、単に見識無いだけだろ?

104 :仕様書無しさん:2006/07/27(木) 00:53:02
エンディアン 使うからそっちが普通じゃないと思う

105 :仕様書無しさん:2006/07/27(木) 00:53:29
と、genericsの使えないJava厨が申しております。

106 :仕様書無しさん:2006/07/27(木) 01:00:35
Cは速いからとか馬鹿のひとつ覚えを繰り返して
実際は大して使いこなせてない奴ばっかじゃん
そういう奴ほどわざわざ使いにくいキーボードを
コネクタ経由でUSB接続してたりするしw

107 :仕様書無しさん:2006/07/27(木) 01:01:45
Javaの案件が減ってないと言い張ってるのは
オプソ乞食系の馬鹿営業だろ?w

108 :仕様書無しさん:2006/07/27(木) 01:02:52
減ってないって。アホ

109 :仕様書無しさん:2006/07/27(木) 01:03:29
2003年をピークとしたJava開発の
バグ対応フェーズや保守案件がドカタ派遣会社でやっているだけだよね。
新規の案件はJavaでやるのは忌み嫌われる。

110 :仕様書無しさん:2006/07/27(木) 01:05:36
尻拭い作業がどこにも山ほどあって、そんなのにあほらしくて社員を当ててられないから、
格安でドカタをかき集めて始末させてるだけ。

そんな仕事ばかりなのに減ってないなんておめでてーな。

111 :仕様書無しさん:2006/07/27(木) 01:08:07
Javaのメモリプロファイラを列挙せよ

112 :仕様書無しさん:2006/07/27(木) 01:08:32
保守案件なんてやってないんだが。
おまえの脳内補完が一番おめでてーよ。

113 :仕様書無しさん:2006/07/27(木) 01:09:01
初期のNT4鯖並みの安定性。定期的な再起動を必要とするのがじゃば鯖

114 :仕様書無しさん:2006/07/27(木) 01:10:05
無知極まりない雑魚相手にするのも馬鹿らしくなってきたな
レッテル貼ってるだけで根拠がまるで無い
一生暇してろ

115 :仕様書無しさん:2006/07/27(木) 01:10:38
Javaの案件が減るなんて有り得るの?
今、土方を最も安く揃えられる経済性抜群な言語はJavaだと思うんだけど。

116 :仕様書無しさん:2006/07/27(木) 01:11:06
減ってないって。アホ

117 :仕様書無しさん:2006/07/27(木) 01:11:58
減ってないって。アホ

118 :仕様書無しさん:2006/07/27(木) 01:12:55
>>115
できるものはあるものの 大して使えないものばかり

119 :仕様書無しさん:2006/07/27(木) 01:13:52
JavaこそがWebサーバサイド開発究極の言語

120 :仕様書無しさん:2006/07/27(木) 01:15:49
>>119
その主張は度々耳にするけど、まともな根拠を列挙できる奴を見た事がないよ。

121 :仕様書無しさん:2006/07/27(木) 01:18:40
普通にWeb開発ならPerlやPHPのほうがシェアが高い。
Javaは仕組みがこりすぎて、システム要件が高くコンパイルを要するにも関わらず
インタープリタのスクリプト言語より重い。
以前はWebは金のなる木で企業もコストを掛けられた。
今はスピードが求められる。迅速に開発できて運用できることが望ましい。
また、Web系システムの寿命は短く、OOで再利用性を深く深く考えて設計しても
あんまりメリット無いんだな。
スクリプトでさくっと作るほうがより要求に適合しているとみなされ始めたわけだ。

122 :仕様書無しさん:2006/07/27(木) 01:21:04
正直もうHTMLは要らないな
しかしSOAPとかをびびって採用できないSEが多すぎ

123 :仕様書無しさん:2006/07/27(木) 01:22:23
>>121
普通のWeb開発ってWeb屋がやる案件のことか?
そんな単価の低い仕事よう引き受けられるな

124 :仕様書無しさん:2006/07/27(木) 01:25:15
単価の高い仕事ってどんなの?

125 :仕様書無しさん:2006/07/27(木) 01:46:19
大手の基幹システムとかやったことねーのか、ヘボ

126 :仕様書無しさん:2006/07/27(木) 02:28:07
> 正直もうHTMLは要らないな
> しかしSOAPとかをびびって採用できないSEが多すぎ
全く意味が分かりません。


127 :仕様書無しさん:2006/07/27(木) 02:36:41
お前が馬鹿だからだろ

128 :仕様書無しさん:2006/07/27(木) 03:02:37
とりあえず これ以上トラフィック量とCPUを食う処理はやめてほしい

129 :仕様書無しさん:2006/07/27(木) 09:39:20
基幹といえばcobolだろ

130 :仕様書無しさん:2006/07/27(木) 10:22:05
NTTデータのコンサルが金融系システムにjavaがたくさん使われていると言っていたから
多分javaはサーバサイドで最強なんだろう

131 :仕様書無しさん:2006/07/27(木) 15:34:07
現場を知らないやつはのん気でいいね

132 :仕様書無しさん:2006/07/27(木) 17:23:33
ウェブ Javaの新規案件 最近 減少傾向 の検索結果のページ 約 13,600 件

133 :仕様書無しさん:2006/07/27(木) 17:45:17
Javaの新規案件 最近 増加傾向 の検索結果のうち 日本語のページ 約 17,500 件中 1 - 50 件目 (0.24 秒)

134 :おじゃばさま:2006/07/27(木) 19:51:46
>127
いや俺も126の言う通り、122の意味が分からんな。
「HTMLを廃止して全てSOAPにする」って事かな?
122がSOAPを使ったことがないか、名前しか知らないって事は想像がつくが。

俺の感覚からすると、「ショッピングモール系のWEBアプリケーション」は確かに、PHPやRubyに
移っているようにも思える。しかし基幹系とかWEBでもショッピングモール系以外のサービスとかに
Javaが使われているので、トータル的には減ってない感じがする。
多分、「減っている」と言っている人は、ショッピングモール系ばかり見ている人で、
「減ってない」と言っている人は、トータル的に見ている人だと思う。

135 :仕様書無しさん:2006/07/27(木) 20:03:45
>感じがする。
>だと思う

結局おじゃばさまの感想なのね。
統計とれなんてむちゃ言わないから
身近な例でいいから減ってないとか
言ってくれ。

そっちの方が燃料として適当だ。

136 :仕様書無しさん:2006/07/27(木) 20:45:57
なあんかなあ、JavaでSOAPするとそれこそ
どろろろろろろろろろろろろろろろろろろろろろろ〜
になっちゃうよな。

137 :おじゃばさま:2006/07/27(木) 20:46:51
そうだな、感覚だけで言っては失礼だな。ただ数を出すだけでもつまらない。
ここは一つ、別の観点から言ってみるか。
あるWEBサイトの見積があった。
まあ内容はショッピングモールみたいな物だ。俺が試しに見積もってみた。
詳細は言えないが俺は約500万と見積もった。俺の友達でC/PHPマスターの見積もりは、なんと50万だった。
自作のパッケージがあってカスタマイズするだけなので50万でいけるそうだ。
追加のカスタマイズも内容によるが、1日5万円で、ほとんどのカスタマイズが1日以内に終わるらしい。
俺は思った。「これは勝てない。」

次に別の案件を見積もった。
内容は言えないが、ショッピングモールではない、少々特殊な技術が必要なシステムだ。
俺は約3200万と見積もった。俺の友達は「見積もり不可能」と言った。
やったことがないし、想定も出来ないので、正確に見積もるのは無理との事だ。
PHPでは無理なのでCで作るが、数年はかかるだろうと言っていた。
俺は思った。「見積もれないなら、勝負にすらならない。」

138 :仕様書無しさん:2006/07/27(木) 20:48:11
基幹はホストをIBMが押さえている関係で、IBMの意向をくんで周辺企業が言われたとおりJavaを使ってると思う。
ホストのリプレースが進んで、もしIBMのリプレースソリューションが蹴られた場合は、今後どうなるかわからないと見た。

と考えると、COBOLとJavaは一蓮托生な気もする。

139 :おじゃばさま:2006/07/27(木) 21:03:37
>136
自分も相手もWebLogic使って、配列とかバイナリとか特殊なことを使わなければ、本当に簡単に出来るぞ。
ただ俺はSOAPよりもRESTの方がいいと思ってるし、極端な話、CSVでもいいと思っている。


140 :仕様書無しさん:2006/07/27(木) 21:08:59
EclipseとTomcatとAxis2でやるとそうは
簡単にいかんだろう

141 :仕様書無しさん:2006/07/27(木) 21:16:29
おじゃば様にききたいんだけど
WebLogicはWWWリスナは標準IISまたはApacheを仕込む。
OracleのiASのApacheはOracleが拡張したApacheだけど
こいつに独自拡張のC++Apacheモジュール仕込むのは問題ないかな?

142 :仕様書無しさん:2006/07/27(木) 21:33:17
>>137
>PHPでは無理なのでCで作るが、数年はかかるだろうと言っていた。 

数年かかるシステムっていうのはつまりスキルがないと言う事と判断
せざるを得ないね。PHPマスターだけどCマスターじゃないんじゃね?

穿った見方すれば、お友達ってCの大規模案件経験ないんじゃね?
Cって、結局経験でしか判断できないからね。
もしくは経験があるがゆえに修辞的に“数年かかる”っていったかもな(w。


143 :仕様書無しさん:2006/07/27(木) 21:46:41
3200万の案件で何人月のシステムなの?
ありえないだろうけど、ソレ1人でやったら同じく数年かかる気がしなくもないが。

144 :仕様書無しさん:2006/07/27(木) 21:50:07
どろろろろろろって何を比喩してるの?
表現が頭悪すぎて比喩できてないよ

145 :仕様書無しさん:2006/07/27(木) 21:51:20
ブラウザでURLをたたく−>白いまま
その状態がどろろろろろろろろろろろろろろろっと続くさま

146 :仕様書無しさん:2006/07/27(木) 21:52:08
>>138
IBMの意向を結構無視してひたすらアセンブラやCOBOLやCLやRPGとかで
Javaは普及率低いんですが。

iServerにデフォでJavaが入っているのはありがたいんだが、
使える人間、劇すくねぇよ。(w

147 :仕様書無しさん:2006/07/27(木) 21:54:08
おじゃばさまってリスナ周りは弱いみたいだな。

148 :仕様書無しさん:2006/07/27(木) 21:55:53
おじゃばさまってもしかしてSOAPで作ったこと無いとか?

149 :仕様書無しさん:2006/07/27(木) 22:41:18
たぶんひいき目に見ても「SOAPを扱うライブラリ」のインタフェース叩いたことしかないんじゃないか?
.NETプログラマでもそうだろうけどな。

150 :仕様書無しさん:2006/07/27(木) 23:15:06
自作の糞重いSwingアプリをマスタングで動かしたら、
すんげー早くてうんこ漏れそうになった。
おかげで、チューニングする気が失せた。

151 :仕様書無しさん:2006/07/28(金) 00:00:25
おじゃばさまはソープが好きみたい


152 :仕様書無しさん:2006/07/28(金) 00:53:38
あげ

153 :仕様書無しさん:2006/07/28(金) 00:55:25
>>85
おまえ?javaしかできないの?


ださっ

154 :仕様書無しさん:2006/07/28(金) 00:58:34
swingは速くて最強なんだぞ!

155 :仕様書無しさん:2006/07/28(金) 07:06:41
>>150
Linux?

156 :仕様書無しさん:2006/07/28(金) 07:41:58
Javaの新規案件 最近 減少傾向 の検索結果 約 26,900 件中 1 - 10 件目

157 :仕様書無しさん:2006/07/28(金) 08:06:25
Javaの新規案件 最近 減少傾向 の検索結果 約 777,777,777,777,777,777 件中 1 - 777,777,777,777,777,777 件目

だったらいいな

158 :おじゃばさま:2006/07/28(金) 09:44:13
>140
俺がTOMCATでSOAPやったのはかなり昔の事だから、最近のTOMCATのWEBサービスは詳しくないが、
確かに昔のTOMCATのWEBサービスは悪夢のようだったな。
ソース->WSDL変換して、WSDL->ソース変換すると違う構造になったり、
WSI対応にすると互換性がなくなったり。
まだ変わってないのかな?

>141
2行目と3行目の関連がわからん。つーか2行目は質問形式じゃないな。
単にORACLEに入っているApacheにCのモジュールを組み込むのは問題がないかって事かな?
ORACLEなどに入っている拡張されたApacheやTomcatに業務プログラムを載せるのはよくない。
つーか普通やらない。モジュール組み込みもできなくはないだろうが、やめとけ。
実際、標準Apacheで動いていたモジュールが拡張Apacheで動かなくなったとか、システムが不安定に
なったって経験はある。バグを報告してもそのあたりのバグはアメリカ問い合わせだから、
早くても2カ月はかかる。ソースは秘密だから公開されない。
時間と金が有り余っているなら、ネタ用にやってみてもいいかもしれないが、俺は反対していたと
覚えておいてくれ。


159 :仕様書無しさん:2006/07/28(金) 10:02:51
OracleのApacheモジュールって
SSLをアドインした程度じゃないの?

160 :仕様書無しさん:2006/07/28(金) 12:43:10
mod_oc4jというのが入ってると思った

161 :仕様書無しさん:2006/07/28(金) 13:09:31
.soじゃなくて.dllばかりだよねOracleのApache

162 :仕様書無しさん:2006/07/28(金) 13:19:56
Linux版の10gは.soだよ(見辛いと思う、スマン)

$ ls $ORACLE_HOME/Apache/Apache/libexec/
httpd.exp mod_cern_meta.so mod_imap.so mod_ossl.so
libperl.so mod_certheaders.so mod_include.so mod_osso.so
libphp4.so mod_cgi.so mod_info.so mod_rewrite.so
libproxy.so mod_define.so mod_log_agent.so mod_security.so
mod_access.so mod_digest.so mod_log_config.so mod_setenvif.so
mod_actions.so mod_dir.so mod_log_referer.so mod_speling.so
mod_alias.so mod_dms.so mod_mime.so mod_status.so
mod_asis.so mod_env.so mod_mime_magic.so mod_unique_id.so
mod_auth.so mod_example.so mod_mmap_static.so mod_userdir.so
mod_auth_anon.so mod_expires.so mod_negotiation.so mod_usertrack.so
mod_auth_dbm.so mod_fastcgi.so mod_oc4j.so mod_vhost_alias.so
mod_autoindex.so mod_headers.so mod_onsint.so mod_wchandshake.so

163 :仕様書無しさん:2006/07/28(金) 14:07:56
FOMAってなにからなにまでjavaで作ってるの?iアプリでない部分も。
あんなにもっさりって品質管理ひどすぎだよね。


164 :おじゃばさま:2006/07/28(金) 20:05:07
>142
スキルと言っても得意分野があるからな。Cマスターでも全分野に精通している訳ではないだろう。
Cのスキル的に言えばそいつはDBすら自作出来るような化け物だよ。
当然、大規模開発の経験もある。同時100人以上のやつもな。
「数年かかる」と言ったのは実際に何年って意味ではなく、「WEBアプリに数年かけるのは現実的でない」
から、結局無理だと言うことだろう。実際には奴なら出来るのかもしれないが、会社の見積もりとしては
出せないって事だろう。

>143
WEBアプリに、一人で3年とかは会社として現実的ではないよな。

>147-149
WebLogicのSOAPで添付ファイル(バイナリ)すら扱ったことがあるぞ。
相手のスキルを予想する時は、少し探りを入れてからの方がいいんじゃないか?

>151
どちらかと言うと、泡より休憩の方が好き。


165 :仕様書無しさん:2006/07/28(金) 20:47:00
>Cのスキル的に言えばそいつはDBすら自作出来るような化け物だよ。

↑どれだけ笑えばいいの?

166 :仕様書無しさん:2006/07/28(金) 21:48:28
プッ
Java厨って悲しい生き物だな。

167 :仕様書無しさん:2006/07/28(金) 23:05:20
Cで100人って・・・。
漏れの認識だとよほど段取りしないと
逝けないと思うんだけど。


168 :仕様書無しさん:2006/07/28(金) 23:15:02
>>164
やっぱお前レベル低いよ
添付ファイル程度で「すら」とか使わないって

169 :仕様書無しさん:2006/07/28(金) 23:38:24
でSOAPって、どんな局面で使うの?

170 :仕様書無しさん:2006/07/29(土) 00:15:35
Java厨だからレベルが高いわけがないのだ。

171 :仕様書無しさん:2006/07/29(土) 00:26:30
>WebLogicのSOAPで添付ファイル(バイナリ)すら扱ったことがあるぞ。
>相手のスキルを予想する時は、少し探りを入れてからの方がいいんじゃないか?

WeblogicWorkshop使ったなら誰でもできると思うぞ
SOAPエンベロープで送る場合は結局テキストにシリアライズすることになるけどな
シリアライズ化処理を自作したとしていてもそれは大したスキルじゃない
10年前はSOAP直に叩くしかなかったのでその頃からやってたやつなら当たり前の芸当だ
まぁ、今時だとそんなとこ自作してたら、ただの馬鹿だけどな('A`)

おかげで良い探りができたということで

172 :仕様書無しさん:2006/07/29(土) 00:44:39
バイナリのシリアライズ…?
Base64のクラス流用すりゃそれで終了だろ。大抵の場合はよー。
スキルとすら呼べねぇ。

173 :仕様書無しさん:2006/07/29(土) 01:17:51
おじゃばんはいつもひまなの?

174 :仕様書無しさん:2006/07/29(土) 06:19:29
DIMEじゃないのかね?
えっそんなのなかった?


175 :仕様書無しさん:2006/07/29(土) 06:37:32
ぐぐってみた

◆SOAPとは?
 SOAPはSimple Object Access Protocolの略です。他のコンピューターにあるWebサービスを呼び出すためのプロトコルです。下位プロトコルにHTTPやSMTPを使用するためファイヤーウォールなどあっても他のコンピューターにあるオブジェクトにアクセスすることができます。
◆SOAPメッセージとは?
SOAPを使用した通信はSOAPメッセージと呼ばれるメッセージを送ることで行います。SOAPメッセージはSOAPエンベロープ、SOAPヘッダ、SOAPボディから構成されます。

これってGETとか送って通信するHTTPと何か難しさが変わるの?

176 :仕様書無しさん:2006/07/29(土) 06:58:41
>>175
何も変わらない。
Javaやってる人達って、仰々しい名前が付いてるだけで何故か大喜びするんですよ。
本質が分かってないっていうか、基礎が無いっていうか。

177 :仕様書無しさん:2006/07/29(土) 08:22:22
基礎がないというのは事実だな

178 :仕様書無しさん:2006/07/29(土) 08:26:08
>>176
>これってGETとか送って通信するHTTPと何か難しさが変わるの?
これに対して何のツッコミも入れられないお前っていったい・・・

179 :仕様書無しさん:2006/07/29(土) 08:57:44
>>178
HyperText Transfer ProtocolとSimple Object Access Protocolの両者を理解することに対して、
難易度が変わるのか?っつー話だ。どこに突っ込むところがあるんだ?別に両者自身を比較してるわけじゃねーし。


180 :仕様書無しさん:2006/07/29(土) 09:00:26
わざわざ略語分解しても程度は変わらないからw

181 :仕様書無しさん:2006/07/29(土) 09:14:14
馬鹿だなあ
HTTPで、と言われたときとSOAPで、と言われたときでは
良く分かってない奴に与えるインパクトが全然違うんだよ。
お前らJava厨の計算高さを少しは見習え。

182 :仕様書無しさん:2006/07/29(土) 09:32:39
9すれまではSOAP,WSDLあたりの話題は3日レス付かなかったけど
自発的に出してくるようになっただけJava厨も蚤の身長程度
成長しているということだ。

183 :仕様書無しさん:2006/07/29(土) 10:00:37
いやSOAP=風俗としか認識してないのがJAVA房

184 :仕様書無しさん:2006/07/29(土) 10:49:29
このスレってPHP厨がやたら連投するだけのスレだな

185 :仕様書無しさん:2006/07/29(土) 12:59:30
>>180
知らなそうだったから書いたまで

186 :仕様書無しさん:2006/07/29(土) 13:16:56
自分の痛さにまるで気づいてないようだな

187 :仕様書無しさん:2006/07/29(土) 13:41:40
もうSOAPも下火だから勉強しても仕方ないよね?

188 :仕様書無しさん:2006/07/29(土) 13:43:28
http://www.google.co.jp/search?hl=ja&ie=Shift_JIS&q=%82%A8%82%B6%82%E1%82%CE%82%B3%82%DC&btnG=Google+%8C%9F%8D%F5&lr=

189 :仕様書無しさん:2006/07/29(土) 13:45:20
おじゃばんがいきなり居るかもわからんPHP厨のせいにし出したw

190 :おじゃばさま:2006/07/29(土) 17:12:45
>165
へーDB簡単に自作できるんだ?
そいつはPostgres並のを一人で自作していたぞ。一般的にはかなり出来る部類になるんじゃないか?
今はフリーのが出すぎてやめたらしいが。

>171、172
少しは知っているようだが、「テキストにせずにバイナリのまま送る」から書いたんだよ。
ましてやBase64で送るなら、わざわざそんなこと書かないよな。
詳しく聞きたい?

191 :仕様書無しさん:2006/07/29(土) 17:19:03
>>190

Postgres並って、SQLをなげれば処理してくれんの?

192 :仕様書無しさん:2006/07/29(土) 17:24:47
>少しは知っているようだが、「テキストにせずにバイナリのまま送る」から書いたんだよ。
>ましてやBase64で送るなら、わざわざそんなこと書かないよな。
>詳しく聞きたい?

それSOAPの規格はずれてるしw
俺様仕様を詳しく聞いてもしょうがない
この分だと作ったって言うDBも俺様仕様だったのかなーと勘ぐっちゃうよ

193 :仕様書無しさん:2006/07/29(土) 18:42:24
>>190
> へーDB簡単に自作できるんだ?
> そいつはPostgres並のを一人で自作していたぞ。

RDBMSの理論なら情報工学系の大学ではまず間違いなく学んでいるだろうし、
実際に簡単なRDBMSを実習で作ってみることもある。
簡易SQLみたいなのも、構文解析器使えば簡単に実装可能。

> 一般的にはかなり出来る部類になるんじゃないか?

情報系大卒であれば、ちゃんと真面目に講義を受けましたね、って程度だな。

まあ、高卒やら三流文系大卒やらが大量に居る日本のIT業界を基準にすれば、
出来る部類に入るだろうけど。

194 :仕様書無しさん:2006/07/29(土) 19:44:32
>>193
>構文解析器使えば簡単に実装可能。

ライブラリに頼るんじゃ意味ないじゃん

195 :仕様書無しさん:2006/07/29(土) 19:47:36
こういう文脈で言ってる構文解析器って
ライブラリを使うんじゃなくてコーディングすることだと思うけど?

196 :仕様書無しさん:2006/07/29(土) 19:54:35
構文解析器ってツールに頼ることじゃねーの?

197 :仕様書無しさん:2006/07/29(土) 20:07:56
LL構文解析プログラムくらいなら情報系の学生はみんな作ったことがあるだろうけど、
それはあくまで理論を学ぶためであって、実用的なツールを作るために
構文解析器から全て実装するような面倒臭いことは普通しないだろ。
クイックソートのアルゴリズムを知っていても、実際に書くコードでは
qsort(3)を使うってのと同じだ。
# libcが信用できないから全て自前で実装するっていう変人を除けばね。

198 :仕様書無しさん:2006/07/29(土) 20:12:12
>LL構文解析プログラムくらいなら情報系の学生はみんな作ったことがあるだろうけど、

夢見すぎ

199 :仕様書無しさん:2006/07/29(土) 20:17:30
>>196が正解だろ
パーサやレキサを生成してくれるジェネレータに食わせて
構文解析のソースを生成する
あとはそのソースに実際の処理コードを追加して完成
Cだとyacc/lexやbison/flexなど、JavaだとJavaCCあたりが定番かな
手間は文法定義のところだが、SQLなど広く広まっている
構文の文法定義は、そこらへんさがせばいくらでも落ちてる

200 :仕様書無しさん:2006/07/29(土) 20:20:03
>>198
そうか?
LL構文解析器なんて、情報系では定番の課題だと思うんだがなあ。
少なくともおいらが学生の頃は、必修の実験科目での課題の一つに挙げられていたんだが。

201 :仕様書無しさん:2006/07/29(土) 20:41:15
> libcが信用できないから全て自前で実装するっていう変人
djbのことか〜


202 :仕様書無しさん:2006/07/29(土) 21:24:56
>へーDB簡単に自作できるんだ? 
>そいつはPostgres並のを一人で自作していたぞ。一般的にはかなり出来る部類になるんじゃないか? 
>今はフリーのが出すぎてやめたらしいが。 

今時の情報系の大学生ならめずらしくないな・・・。
授業レベルだけど。
Postgres並っつーのはむりぽだけど。

別に構造としてはそんなムズイもんじゃねーからな。
問題はクライアントとの通信やロック処理や安定性なんだけどな〜。

スレッド起動が失敗したとかロックに失敗したとかそーいった
レベルの作りこみやそれに付随するテストとか耐久テストとかどうよ。

Postgres並ってそういうレベルでしょ?
まあ最低限想定レベルでのテストに耐えられる又は実働しているから
お友達は"Postgres並のを一人で自作していたぞ"っていったんだよね?



203 :仕様書無しさん:2006/07/29(土) 21:45:50
高卒SEの漏れからすると大卒SEがそんなにレベル高いなら、
苦労しないんだけどなぁ。

204 :仕様書無しさん:2006/07/29(土) 22:01:52
俺は情報系の大卒だけど
アセンブラとエディタは演習で作らされた

205 :仕様書無しさん:2006/07/29(土) 22:19:50
まあ、なんだ、構文解析機つくれつやつも、DM作れるやつも(多くは)いらんのですよ。


情報工学系って、大学で学ぶ知識・技術と、実際社会に出てから必要なそれに結構乖離がある。
大学での定番は以下くらいか?
・計算機アーキテクチャ
・OS論
・コンパイラ論
・データベース論(オレのところはなかったなぁ)
・ソフトウェア工学
・文字・画像・動画・音声とかの認識系
・人工知能

あんま約に立たないよね。まあ、無駄とは言わないけど。


オレは情報系だったから、他は知らないけど、

206 :仕様書無しさん:2006/07/29(土) 22:20:35
>>203
情報系大卒が高卒の香具師と一緒に単価の安いSEやプログラマをやるわけないじゃん。

207 :205:2006/07/29(土) 22:20:44
他の工学はどうなんでしょ?


# DM→DBのうち損じ

208 :205:2006/07/29(土) 22:22:30
それも週に1回、半年やるだけだもんなぁw。

やっぱ研究室に入ってからが本番だろうか。

209 :仕様書無しさん:2006/07/29(土) 22:24:54
ソフトウェア工学は、まあ訳にたつか。
トレンドの移り変わり早すぎだけどな。

210 :仕様書無しさん:2006/07/29(土) 22:56:40
トレンドとかいってiとmとsとかがいろんなでかいところが
提唱する〇〇が今流行りだとか信じてデスマするのが
この業界のトレンドだからなぁまぁ技術なんて80年の時点で
ほとんど完成されていた。ただあのころは非力なマシンしか
なくできなかったことができるようになったただそれだけなんだよな

211 :仕様書無しさん:2006/07/29(土) 23:00:01
>>206
>情報系大卒が高卒の香具師と一緒に単価の安いSEやプログラマをやるわけないじゃん。
つまり、漏れの知っている大卒SEは学歴詐称ってFA

いや、頭がいいし、文章書くのは慣れてるのは解るけど、
プロジェクトまとめるの素直に下手だし、夢と現実の区別の
つかない設計してたりして、大変なんだが。

そいつのプロジェクトがデスマしていたので、同じ部署の漏れが
手伝いにいった程度だけどサ。

212 :仕様書無しさん:2006/07/29(土) 23:01:26
大卒たたきするとあほうがわくよ

213 :仕様書無しさん:2006/07/29(土) 23:12:07
>>212
ああ、漏れは本当はSEなんて人生設計になかったんだが、
現場の人間でタマタマ機械の扱いが上手で、
会社が情報処理の資格をとったら報奨金をくれると言うから、
資格をとったらなんでか、プログラマーにされて(w)ついでに
客先にいかされるようになって、知らない間に営業スキルを
身に付けつつ、色々仕事していたらSEになったクチなんで、
大卒はともかく、現場経験のないSEはドリーマーだよな、と思う次第。

214 :仕様書無しさん:2006/07/29(土) 23:19:18
>>210
>80年の時点でほとんど完成されていた
そうかな?
工学の世界でソフトウェアだけだぜ?こんなに不良率。

機械(冷蔵庫)、電子(AV機器、プロセッサ)、建築(橋、ビル)、そんなに不良無いだろ?
特に致命的なのは、少ない。
それはソフトウェア工学がまだまだ完成していないから。
完成できるかどうかは知らん。





215 :仕様書無しさん:2006/07/29(土) 23:45:07
年間300万台近い自動車がリコールになってることは
まったく考慮されてないの?

216 :仕様書無しさん:2006/07/29(土) 23:48:38
>>215
ソフトウェアなんてその比じゃないだろwww

217 :仕様書無しさん:2006/07/29(土) 23:50:06
>>215
世界でいくつかどうしているか検討もつかないようなWindowsに毎週バグが見つかるわけだが。

累計、何兆じゃきかないんじゃね?


バグ数×出荷数=?

218 :おじゃばさま:2006/07/30(日) 00:10:27
>192
残念だったな、WEBサービスではバイナリを送る仕様があるんだよ。少しだけ勉強が足りなかったな。
WebLogicの仕様書があるなら、WEBサービスの「添付ファイル」で調べてみな。

でも192がそれなりにWEBサービス知っている事は認めてやるよ。
バイナリが無理って言う段階で一般知識はあることが分かる。
普通の奴は「SOAPなにそれ?」ってレベルだからな。
ただ普通の人は、SOAPなんて頑張って勉強する必要はないぞ。きっと流行らないから、

なんだかんだいってPostgres並のを自作ってのは、出来るレベルって事でいいだろう。
別に友達のことだから自慢する意味もないが、評価は正しくやらないとな。
だから笑うなら、それなりの事を書いて欲しいな。
引用して「どれだけ笑えばいいの?」みたいな書き込みは、恥ずかしさを通り越して情けないよ。


219 :仕様書無しさん:2006/07/30(日) 00:13:01
そのこてやめれ

220 :仕様書無しさん:2006/07/30(日) 00:22:27
そうそう、WebLogicで思い出したけど、国内のJ2EEサーバのシェアしってた?

1位:IBM
2位:富士通、日立 (毎年入れ替わる。どっこいどっこい)
4位:WebLogic

なんだぜ?以外だろ?

221 :仕様書無しさん:2006/07/30(日) 00:22:58
WebLogicだけ製品名だったな。。orz

222 :仕様書無しさん:2006/07/30(日) 00:35:57
BEAってあまり社名は耳にしないな
WebLogicと結びついてるのかさえあやしい

223 :仕様書無しさん:2006/07/30(日) 00:37:03
情報系の大卒がそんなにちゃんとできるやつばっかりだったら世の中幸せです。


224 :仕様書無しさん:2006/07/30(日) 00:40:10
ビジネスロジック

225 :仕様書無しさん:2006/07/30(日) 00:42:05
>>218
そりゃ知らなかったな
でもWebServiceの仕様って、BEA、IBM、Microsoftでそれぞれ独自拡張してるよな
例えばWebLogicのみの仕様だとSOAPの標準仕様に沿ってはいないことになる
今時の業務じゃこの三者が入り乱れる構成ってのは考えにくいからかまわんと言えばかまわんけど
SOAPの標準仕様に沿っているのかを確認したいところだ

特にWebLogicはバックエンドのT-Engineとの連携ためにバイナリ型を用意してる可能性もある
T-Engineまで使ってるやつがそうそういるとは思えないけど

226 :仕様書無しさん:2006/07/30(日) 01:36:17
>なんだかんだいってPostgres並のを自作ってのは、出来るレベルって事でいいだろう。 
>別に友達のことだから自慢する意味もないが、評価は正しくやらないとな。 
>だから笑うなら、それなりの事を書いて欲しいな。 
>引用して「どれだけ笑えばいいの?」みたいな書き込みは、恥ずかしさを通り越して情けないよ。 

ここ笑う所、友達じゃなくておじゃばさま、な。
それなりの事を言えずに“Postgres並”で解決しているおめでたさを笑う所。


227 :仕様書無しさん:2006/07/30(日) 07:42:17
ファイルのランダムアクセスができるだけなのをPostgres並とか言わないほうがいいよ

228 :仕様書無しさん:2006/07/30(日) 08:29:14
PGrsはデーモンだからな。おじゃばはTCPアプリケーションと
デーモンの区別がつかないからなw

229 :仕様書無しさん:2006/07/30(日) 08:30:26
しかしこのスレも 10gまで来たか。オラクルのバージョンを超えて
しまうのは凄いな。

230 :仕様書無しさん:2006/07/30(日) 08:38:57
Java厨よりレベル低い奴とJava厨との狂演だからな
まあ前者は.NET厨なだけだから当然といえば当然だが

231 :仕様書無しさん:2006/07/30(日) 08:56:12
未だにSOAPとかいってる時点でレベルが低い
WSDLあればそれ以降はなんだっていいという
ことに気がつけないバカの集まりだな

232 :仕様書無しさん:2006/07/30(日) 09:11:59
レイヤーの違いでレベルが低いとか言ってる奴ほどレベルが低い奴は居ないな
HTTPに対してTCP/IPであればなんだっていいと言ってるのと変わらない

233 :おじゃばさま:2006/07/30(日) 09:23:06
ちがうだろう。Javaのソケットにはポートは使わないんだよ。糞ども。

234 :仕様書無しさん:2006/07/30(日) 09:30:13
↑騙り、イクナイ

235 :仕様書無しさん:2006/07/30(日) 11:46:35
なにかあるとすぐ再起動。
とりあえず再起動。
それがwebLogic

236 :仕様書無しさん:2006/07/30(日) 11:48:09
それはWebLogicに限ったことではない。
WASもそうだし、WebOrzもそうだよ

237 :仕様書無しさん:2006/07/30(日) 11:49:42
つまり、Javaは糞

238 :仕様書無しさん:2006/07/30(日) 12:06:19
そして再起動に5分かかる。

239 :仕様書無しさん:2006/07/30(日) 12:13:29
大規模開発ですから

240 :仕様書無しさん:2006/07/30(日) 12:15:04
>>235
JBossも同じ

241 :仕様書無しさん:2006/07/30(日) 12:16:57
>>239
確かに開発は大規模。その割りにできあがりはしょぼい。

242 :仕様書無しさん:2006/07/30(日) 12:22:20
なんだよひとつぐらいまともなAP鯖ってないの?

243 :仕様書無しさん:2006/07/30(日) 12:23:44
お前らがそうレッテル貼ってるだけなのに何がまともになるんだろうか

244 :仕様書無しさん:2006/07/30(日) 12:24:10
いやAPが100%落ちないようになることは無いんだよね
JVMがもっとまともなものにならない限りムリなんだよね

245 :仕様書無しさん:2006/07/30(日) 12:26:03
JVMが原因で落ちた経験ないし
まともじゃないのはお前らの知識

246 :仕様書無しさん:2006/07/30(日) 12:26:37
それじゃあ
VMがソース公開されたのは
優秀な誰かに直してほしかったのが公開の真相なの?

247 :仕様書無しさん:2006/07/30(日) 12:29:27
それじゃあ とか 真相 とか痛いレスしかできないのか

248 :仕様書無しさん:2006/07/30(日) 12:30:51
>>246
なんでそんなにJavaが好きなの?

249 :仕様書無しさん:2006/07/30(日) 12:32:35
HSPまんせーな奴はJavaが嫌いな奴多いな

250 :仕様書無しさん:2006/07/30(日) 12:33:31
Java好きな奴はJavaしかできないのがほとんど。

251 :仕様書無しさん:2006/07/30(日) 12:34:07
VMが糞って致命的
ハードやOSが腐ってるのようなもの

252 :仕様書無しさん:2006/07/30(日) 12:36:33
そもそもHSPマンセーなんているのかよ
C厨か.NET厨とかに勝てないからって他を持ち出してるだけだろ

253 :仕様書無しさん:2006/07/30(日) 12:37:26
>>250
おまえ学生だろ?C屋はPERLすら使えない奴でごろごろしてるぞ

254 :仕様書無しさん:2006/07/30(日) 12:37:58
>>252
このスレで負けまくって何を言ってるんだ?w

255 :仕様書無しさん:2006/07/30(日) 12:38:45
あははJava厨がマジになってる。
C屋は69式のおっさんみたいにそれ一本で需要があるんだよ。

256 :仕様書無しさん:2006/07/30(日) 12:40:43
Java厨さんよ、たまには自腹で
ソフトを購入してみろよ。

257 :仕様書無しさん:2006/07/30(日) 12:41:14
日曜なのに盛り上がんなよ...

258 :仕様書無しさん:2006/07/30(日) 12:41:25
>>255は自分の馬鹿レスに気づけない。おわっとる。

259 :仕様書無しさん:2006/07/30(日) 12:42:04
Java厨は永遠に仏滅。

260 :仕様書無しさん:2006/07/30(日) 12:42:56
C屋からすれば自腹でソフト買う奴は馬鹿なんだが・・・

261 :仕様書無しさん:2006/07/30(日) 12:43:12
ちょっと書いとけばすぐにくいつくからjava様たち

>>253以降すぐレス来ただろw

262 :仕様書無しさん:2006/07/30(日) 12:44:28
煽るのが目的であって自分が無知であっても気にしない
そんなのばっかJavaを仮想的にしてる

263 :仕様書無しさん:2006/07/30(日) 12:45:20
仮想マシンだから
仮想敵にされる。

264 :仕様書無しさん:2006/07/30(日) 12:46:17
だれが上手いこと言えと言った。

265 :仕様書無しさん:2006/07/30(日) 12:46:55
煽り目的にされちゃった

266 :仕様書無しさん:2006/07/30(日) 12:47:47
265 名前:仕様書無しさん [↓] :2006/07/30(日) 12:46:55
煽り目的にされちゃった

一度も高尚なレスがつけられないのにw

267 :仕様書無しさん:2006/07/30(日) 12:48:43
↑のレスは実に高尚ですね

268 :仕様書無しさん:2006/07/30(日) 12:49:24
どこが?国語力皆無だな

269 :仕様書無しさん:2006/07/30(日) 12:51:08
登場から10年もたつのに、VMって安定しないの?

270 :仕様書無しさん:2006/07/30(日) 12:52:02
あせだけでつくってりゃいいんだよ

271 :仕様書無しさん:2006/07/30(日) 13:00:25
C++はなぜ人気がないのか
でJavaとの比較がされている。
ttp://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050215/156201/?ST=enterprise&P=1


272 :仕様書無しさん:2006/07/30(日) 13:02:18
上記から引用
>また,C++ではテンプレート引数が特定のメソッドや演算子を
>定義していることを前提としていても,実際にそれが呼び出されない
>限り実装する必要がない。ところがJavaの場合,実際に呼び出すか
>どうかにかかわらずすべてのメソッドを実装する必要がある
>(空でもよいが)。

メモリ食いの基本仕様

273 :仕様書無しさん:2006/07/30(日) 13:02:52
>>244
そうだね。JVMがAbortするのはよくあること。

>>245
> JVMが原因で落ちた経験ないし
> まともじゃないのはお前らの知識
おまいが小規模開発しかやってないから。
まともじゃないのはお前の経験ってことになる。ってもしかして新人か?


274 :仕様書無しさん:2006/07/30(日) 13:04:43
使う必要のないものをごたごた実装して
メモリ負荷を高めてごちゃごちゃ素人がいじくるのがJava。

275 :仕様書無しさん:2006/07/30(日) 13:05:34
やっぱjavaに比べたらc++難度高いからなんだろうな
使いやすい方に流れるわけ
良いか悪いかは知らん

276 :仕様書無しさん:2006/07/30(日) 13:06:40
CPUとメモリを優先的に食いつぶすのがJavaの仕様ですか。

277 :仕様書無しさん:2006/07/30(日) 13:07:49
> C++のテンプレートに相当するジェネリック(Generics)をサポートしたこと
この記者馬鹿だろ?

278 :仕様書無しさん:2006/07/30(日) 13:09:43
>>245
> JVMが原因で落ちた経験ないし
> まともじゃないのはお前らの知識
VM Abort の検索結果 約 644,000
http://www.google.co.jp/search?hl=ja&q=VM+Abort&lr=

279 :仕様書無しさん:2006/07/30(日) 13:10:06
VirtualMachineだから、OSのリソースを全部奪い取ってVMだけでマシンのリソースを全て管理するっていう思想なんじゃないかなー

280 :仕様書無しさん:2006/07/30(日) 13:10:47
>>273
>おまいが小規模開発しかやってないから。
>まともじゃないのはお前の経験ってことになる。ってもしかして新人か?
まったくもって的外れだな

281 :仕様書無しさん:2006/07/30(日) 13:12:22
JVMは自分がわるくてもJava厨の書いたコードが
悪いように例外処理のスタックを表示するからな。

282 :仕様書無しさん:2006/07/30(日) 13:12:37
"DOT NET" Abortと件数一緒なのが面白いな

283 :仕様書無しさん:2006/07/30(日) 13:17:25
.NETとしなくてもこれだとろくでもない実装だな

284 :仕様書無しさん:2006/07/30(日) 13:17:52
JavaのSynchronizedってVM内部でどうスレッド調停してるのかな?
Java厨さんなら粋なレス返してくれるんだよね。

285 :仕様書無しさん:2006/07/30(日) 13:19:18
さあこれで3日レスつかないかスルーするかどっちかに
10おじゃば

286 :仕様書無しさん:2006/07/30(日) 13:23:42
なあんだ優秀なるおじゃばさまなら
3分以内に粋なレスが出ることを期待してたのに。とまっちゃった。

287 :仕様書無しさん:2006/07/30(日) 13:25:49
それそのものが逃げレスなんだが

288 :仕様書無しさん:2006/07/30(日) 13:26:17
>>282
内容は違うがな。"DOT NET" AbortはAbort()メソッドも含まれている。
"DOT NET" Crash の検索結果 約 599,000 件中 1 - 10 件目 (0.04 秒)
Java Crash の検索結果 約 18,900,000 件中 1 - 10 件目 (0.43 秒)


289 :仕様書無しさん:2006/07/30(日) 13:32:43
".NET" Crash
おまえらはこっちだろw

290 :仕様書無しさん:2006/07/30(日) 13:34:33
>>287
なんで?せめて理由を簡潔に述べてよ。

291 :仕様書無しさん:2006/07/30(日) 13:39:06
たかが掲示板にAP鯖
笑えた
ttp://www.virtual-pop.com/tearoom/archives/000129.html


292 :仕様書無しさん:2006/07/30(日) 13:39:26
実装によりけりだから

293 :仕様書無しさん:2006/07/30(日) 13:41:03
しかし、Javaは美しい。

294 :仕様書無しさん:2006/07/30(日) 13:41:47
Java村
Perl村
(w

295 :仕様書無しさん:2006/07/30(日) 13:44:40
perlに比べりゃな
javaが美しいとまでいか泣けど

296 :仕様書無しさん:2006/07/30(日) 13:46:06
>>291
さすがに酷いな
Javaでも50万仕事だと思う

297 :仕様書無しさん:2006/07/30(日) 13:50:14
>>292
それは簡潔な理由なのかな?
SUNのVM限定という前提でいいよ。

298 :仕様書無しさん:2006/07/30(日) 13:51:39
SUNそのもので変わってるだろ
セマフォ以外になんと言えばいいんだ

299 :仕様書無しさん:2006/07/30(日) 13:53:12
え!ほんとにセマフォでいいの?

300 :仕様書無しさん:2006/07/30(日) 13:54:53
?の意味が分からん

301 :仕様書無しさん:2006/07/30(日) 13:56:27
ソースみた?

302 :仕様書無しさん:2006/07/30(日) 13:58:41
見てない

303 :仕様書無しさん:2006/07/30(日) 14:01:39
見てないで断定できるんだね。すげえな。神だな。

304 :仕様書無しさん:2006/07/30(日) 14:03:29
mutexだろうがなんだろうが結局カウント1のセマフォだしな
ワイルドカードで答えてるだけだ

305 :仕様書無しさん:2006/07/30(日) 14:03:53
Java神登場か

306 :仕様書無しさん:2006/07/30(日) 14:05:20
うむ。>302は新時代のJava厨神だな。
あがめようではないか。

307 :仕様書無しさん:2006/07/30(日) 14:12:24
神とか言ってるが何で書けばセマフォじゃなくなるんだ?

308 :仕様書無しさん:2006/07/30(日) 14:27:43
ということはセマフォしかしらないのというテスト

309 :仕様書無しさん:2006/07/30(日) 14:33:14
>>284
マシン後レベルによるCASまたは、pthread_mutex_lockだろ。

310 :仕様書無しさん:2006/07/30(日) 14:34:48
Winの場合は、pthread_mutex_lockの変わりにセマフォだ。
ソース公開されてるんだから、見ればいいやん。

311 :仕様書無しさん:2006/07/30(日) 14:36:29
mutexがセマフォじゃないというのが良くわからん
mutex=キュー=1要素のセマフォじゃねーの?

312 :仕様書無しさん:2006/07/30(日) 14:41:42
>>311
そうだよ。セマフォ系のAPI(SemaWaitとかだっけ?WaitForSingleObjeとか?)を、mutex_lock
とかと同じ用につかってるだけ。セマフォとしては使ってなかったとおもう。
まあ、バージョンによっても違うかもしれないので余り信じるな。

待ちスレッドのキュー管理は、JVM内で独自にやってる。

313 :仕様書無しさん:2006/07/30(日) 14:42:41
mutex==セマフォの機能限定版

314 :仕様書無しさん:2006/07/30(日) 14:57:13
JVMは、C/C++の実装は得意じゃないし制御厳しいから
中途半端に実装してるね。どこもかしこも限定限定、最小機能ばかり


315 :仕様書無しさん:2006/07/30(日) 14:59:33
そらWindowsでkqueueは使えん罠

316 :仕様書無しさん:2006/07/30(日) 15:11:36
>>314
日本語でOK

317 :おじゃばさま:2006/07/30(日) 18:53:14
>226
少しだけ頑張ったようだが、その程度の説明か。しかも論点ずらしてるし。まあいいや。
俺のおめでたさを笑う所なんだ。
へー、笑うほど面白いのかね。リンク厨の思考原理は難しいね。
ちなみに、202はその説明だけでも俺の言いたいことを大体理解しているみたいだけどね。


318 :仕様書無しさん:2006/07/30(日) 19:07:03
EPを目指すときの保証を極めようとするとすぐにレベルが上がる。
マルチスレッドにしてもそうだ細かいチューニングや保証は理論以外にも
経験則も必要だし厳しいそれは言語というレベルではなく現実的なクリティカルな
問題として難しいんだよ
でもね、JAVAはこのクリティカルな問題をやるには不向きだよ

319 :仕様書無しさん:2006/07/30(日) 19:13:48
EPって衛星放送?

320 :仕様書無しさん:2006/07/30(日) 20:22:54
>>317
すまんが大爆笑だ。
202=226なんだすまん。

Postgres並って言うんでどうせこんな
もんだろって206で指標書いてんで
最低限何台クライアントが接続できるかとか
どれ位の耐久性があるのかとか
”それなりの”返答するとおもったら

>なんだかんだいってPostgres並のを自作ってのは、出来るレベルって事でいいだろう。 

をいをい、こんな適当以前の台詞吐いたら、

>ここ笑う所

って書くしかないだろ?
もれどういう返答したら言いの?
納得したって引き下がれば良いの?

釣ったつまり毛頭ないんだが、Webロジック改め幸せロジックに多いに笑わせて
貰った。


321 :仕様書無しさん:2006/07/30(日) 20:24:10
釣ったつまり毛頭ってなんだ?

322 :仕様書無しさん:2006/07/30(日) 20:37:48
つまり毛が頭にない、禿ってことだろ

323 :仕様書無しさん:2006/07/30(日) 21:19:53
しかし、Javaは美しい。

324 :仕様書無しさん:2006/07/30(日) 22:16:02
けど使い物にならん

325 :仕様書無しさん:2006/07/30(日) 22:40:37
君が使いこなせないだけ。

326 :仕様書無しさん:2006/07/30(日) 22:43:02
Javaやってる人って、すごい人と使えない人との両極端で、中間層が薄い気がする。

327 :仕様書無しさん:2006/07/30(日) 22:46:19
>>325みたいなのが使えない人
おじゃばさまが中間層かもね

328 :仕様書無しさん:2006/07/30(日) 22:47:10
時代のツールだから使ってるだけってのもあるしな

329 :仕様書無しさん:2006/07/30(日) 22:50:25
せっかく、synchronizedの実装がどうなっているとかそういう話になりかけてたのに、
また醜い煽りあいですかwwwwwwww

だからダメなんだよ

330 :仕様書無しさん:2006/07/30(日) 22:55:33
.NET厨の酷さは今に始まったことじゃないって

331 :仕様書無しさん:2006/07/30(日) 23:09:37
synchronizedをどう実装しろって決まってるわけではないんじゃないの?


332 :仕様書無しさん:2006/07/30(日) 23:09:49
昔はCやっててJavaがやりたいといって転職したら.NETをやらされた俺が来ましたよ

333 :仕様書無しさん:2006/07/30(日) 23:11:53
HotSpotで実装変わってるしな

334 :仕様書無しさん:2006/07/30(日) 23:14:14
>>331
外部使用は当然決まっているが、どう実装しようが自由。とうぜんだろ

335 :仕様書無しさん:2006/07/30(日) 23:16:12
>>334
だよな。
だから、329はアフォ。

336 :仕様書無しさん:2006/07/31(月) 00:20:51
C#かjavaやてたらどっちもいけるから無問題

337 :仕様書無しさん:2006/07/31(月) 02:24:36
PGで言語厨が出てくるのは、複数の習得が難しいからなのかな?
どの言語も、他人の掘った穴にすぎないが。

338 :仕様書無しさん:2006/07/31(月) 08:58:32
・信者体質である
・生活がかかっている
・実運用に入って酷い目にあった

他にもあるかも

339 :仕様書無しさん:2006/07/31(月) 12:13:44
昔はCやってて(ものにならなかったんだなかわいそうに)
(だから)Javaがやりたいといって転職(したってだめだぞ)
ひとつのものをきちんとまじめに取り組む事が大事。

340 :おじゃばさま:2006/07/31(月) 19:46:16
>320
202=226なのか、そりゃびっくりだ。

>まあ最低限想定レベルでのテストに耐えられる又は実働しているから
>お友達は"Postgres並のを一人で自作していたぞ"っていったんだよね?

これに回答しなければいけなかったのか。
的確な理解だったので回答を省略してしまったが、「はいそうです」って言っておこう。
さすがに接続数や耐久性は答えないだろう。この質問で。

つーか「ここ笑う所」では、ただのリンク厨と勘違いしたよ。
コテハンかもう少し説明があれば、考えたかもしれないがな。
本気の釣りなら釣られた訳だが、そっちも天然だったって事で、引き分けぐらいにしとくか。

紛らわしいから、俺がコテハン付けてやるよ。
「釣りC」ってのはどうだ?


341 :仕様書無しさん:2006/07/31(月) 20:20:10
「.NETはJavaを打ち負かした。次の相手は誰だ?」とMS
http://www.itmedia.co.jp/enterprise/articles/0607/31/news017.html

342 :仕様書無しさん:2006/07/31(月) 21:16:18
javaいらねけどM$がちょうしにのるのもいや

343 :仕様書無しさん:2006/07/31(月) 21:48:55
Postgres並

344 :仕様書無しさん:2006/07/31(月) 22:37:37
Java2006年死亡説は当たりだな。

345 :仕様書無しさん:2006/07/31(月) 22:43:26
1.5に何処も移行出来ない。未だに1.4系のまま。。
.NETの登場に焦ってユーザーがついていけないVerUpをやらかしたSunの負け。


346 :仕様書無しさん:2006/07/31(月) 22:48:17
Javaっが死亡しても蓄積資産がまったく残らない悲しさよ。

347 :仕様書無しさん:2006/07/31(月) 23:00:45
そうして今夜もWebLogic再起動

348 :仕様書無しさん:2006/07/31(月) 23:04:07
念のため明日の朝も再起動

349 :仕様書無しさん:2006/07/31(月) 23:57:25
ネットワーク系の学科なので、
大学で一回生からjavaしかやらないんですが大丈夫ですか?

350 :仕様書無しさん:2006/08/01(火) 00:01:14
大丈夫。
講義のレベルなんて何の役にもたたん。

351 :仕様書無しさん:2006/08/01(火) 00:01:52
初心者と五十歩百歩。どんぐりの背比べ。

352 :仕様書無しさん:2006/08/01(火) 00:03:19
むしろ初心者の方が、教えたこと素直に吸収してくれる。

353 :仕様書無しさん:2006/08/01(火) 00:26:28
>>350-352
レスありがとうございます。

なんか講義って言うより、適当にヒント出されて、
こういう動きをするプログラム書けって授業です。

354 :仕様書無しさん:2006/08/01(火) 00:38:09
無意味だから、必修じゃないなら出なくていいよ

355 :仕様書無しさん:2006/08/01(火) 00:59:44
>>349
Javaは別にやっといて損は無い。ただそれだけではダメだ。
LispかPrologもやっておくべき(今ならHaskellも候補?)
理由は、これらが広く使われているということではなく、
別種の言語を学んでおいた方が他の言語の理解が深まるからだ
(Java厨じゃない人には分かるよな?)

あと、アセンブラかBrainfuckをかじっておくとなお良い。
コンピュータがどのように動くかを見るのにもってこい。

ネットワーク系を理解するなら、C言語でテキストブラウザを作るという課題が俺的に最高。
フレームワークに隠されて見えない部分が見えるようになり、
フレームワークの理解が更に深まる。


356 :仕様書無しさん:2006/08/01(火) 01:03:31
訂正。
> ネットワーク系を理解するなら、C言語でテキストブラウザを作るという課題が俺的に最高。
「C言語で」は脳内消去してくれ。別に言語は何でも構わん。ただしTCP Socketを直接使うことが条件。


357 :仕様書無しさん:2006/08/01(火) 01:05:36
Java厨じゃないが
C++を勉強するほうがいいとおもうぞ。
Javaをほしがるのは三流ビジネスロジック会社だけ。偽装派遣系。
C++はメーカーの研究室などで使われる。

358 :仕様書無しさん:2006/08/01(火) 01:08:18
ネットワーク系を理解するならば
DNSのパケットダンプを解析するとめちゃ勉強になるぞ。

359 :仕様書無しさん:2006/08/01(火) 07:26:17
とりあえず、勉強の成果として基本情報は取っとけ。

360 :仕様書無しさん:2006/08/01(火) 10:30:35
DNSパケット(UDP)をJavaでやるのはめんどくせえ
C++のほうがすっきりできる。UDPのJavaラップはダサすぎ。

361 :仕様書無しさん:2006/08/01(火) 14:36:03
Javaやってるとハゲるぞ。

362 :仕様書無しさん:2006/08/01(火) 16:32:20
Haskelが時代を席巻するのはいつごろですか?

363 :仕様書無しさん:2006/08/01(火) 18:41:27
おじゃばちゃんは今日はマダ?

364 :おじゃばさま:2006/08/01(火) 20:02:09
C厨の馬鹿さ加減にも本当にあきれたよ。俺がC++のプロだって言う事ぐらい
見抜いてくれよ。Javaと両刀使いと言う事ではおそらく2chマ板最高峰だろう。

365 :仕様書無しさん:2006/08/01(火) 20:20:07
今度亀田が試合するのはチャンピオンだと誤解している人が多い件について

違 い ま す

亀田が試合するのは、チャンピオンではなく
1階級下でやってきた昨年12月で引退する予定だったランダエダという選手です。
(チャンピオンという称号も持っていません。)

階級を1つ落とす亀田vs階級を1つ上げるランダエダ
・・・・実質2階級下の選手、しかも引退予定だった選手と
お互い一度もライトフライで試合をしたこともないのに、
突然1位と2位にランクされて王座決定戦をやるのです


実力もなにもない堀江も持ち上げるだけ持ち上げ、落とされたのを忘れたか。
とにかく本気で世界チャンピオンになりたい世界を取って親孝行したいと本気で思ってるなら、素人で柄の悪いあの父親をトレーナーから即刻外して、大竹トレーナーに一任し根本的にやり直さないと手遅れになるだろう。

父親『ジャブを打たないのが亀田流』こんな素人が世界チャンピオンを育てられる程甘くはない。

366 :仕様書無しさん:2006/08/01(火) 20:20:07
今度亀田が試合するのはチャンピオンだと誤解している人が多い件について

違 い ま す

亀田が試合するのは、チャンピオンではなく
1階級下でやってきた昨年12月で引退する予定だったランダエダという選手です。
(チャンピオンという称号も持っていません。)

階級を1つ落とす亀田vs階級を1つ上げるランダエダ
・・・・実質2階級下の選手、しかも引退予定だった選手と
お互い一度もライトフライで試合をしたこともないのに、
突然1位と2位にランクされて王座決定戦をやるのです


実力もなにもない堀江も持ち上げるだけ持ち上げ、落とされたのを忘れたか。
とにかく本気で世界チャンピオンになりたい世界を取って親孝行したいと本気で思ってるなら、素人で柄の悪いあの父親をトレーナーから即刻外して、大竹トレーナーに一任し根本的にやり直さないと手遅れになるだろう。

父親『ジャブを打たないのが亀田流』こんな素人が世界チャンピオンを育てられる程甘くはない。

367 :おじゃばさま:2006/08/01(火) 20:39:54
364は偽物だ。
俺も偽物が出るぐらい有名になったんだな。ちょっと嬉しい。

364は320かな?俺が命名した「釣りC」は気に入らないのか?
じゃ天然をつけよう。「天然釣りC」でどうだ?


368 :おじゃばさま:2006/08/01(火) 21:00:01
言い忘れたが、本当はJavaしかできない。
やっぱり嘘はつけないな。

369 :仕様書無しさん:2006/08/01(火) 21:43:55
おじゃばさまはトリップ付けろよ!

と今から言ってもいろんなトリップのおじゃばさまが出てくるわけだな。

370 :仕様書無しさん:2006/08/01(火) 21:51:43
C厨がつければ十分だろ

371 :仕様書無しさん:2006/08/01(火) 21:54:14
Postgres並w

372 :仕様書無しさん:2006/08/01(火) 21:56:19
どうでもいいが最近このスレつまらんぞ。
初代おじゃばみたいに誰か暴れてくれ。

373 :おじゃばさま ◆9Ce54OonTI :2006/08/01(火) 22:25:12
はいよ。
これで文句ないな?

374 :仕様書無しさん:2006/08/01(火) 22:30:10
バカ1人

375 :仕様書無しさん:2006/08/01(火) 22:48:07
なんだよ俺のことかよー!
じゃあお前はアホだ!
アホバカコンビでも組もうぜ

376 :仕様書無しさん:2006/08/02(水) 01:23:57
おそらくJavaエンジニアの多くが、HTMLベースのおなじみのWebアプリケーション開発の現場で、
ある種の“カベ”に直面しているのではないだろうか。顧客のニーズを満たすために、 HTMLの制約と
格闘する苦労。データベースとHTML間のバケツリレーに終始する中で生じる、

「なぜPHPではなくJavaなのか」という疑問。



377 :仕様書無しさん:2006/08/02(水) 04:59:46
SUN Java Desktop
これほど笑えるデスクトップもねえよw

378 :仕様書無しさん:2006/08/02(水) 09:04:49
ふつーのGNOMEデスクトップに見えたので
笑いのツボを教えていただけると嬉しい

379 :仕様書無しさん:2006/08/02(水) 12:50:14
ただのGNOMEデスクトップにJavaと冠する必死具合が笑いどころ。

380 :仕様書無しさん:2006/08/02(水) 12:56:50
俺、このJavaのデスマが終わったら、PHPで開発するんだ

381 :仕様書無しさん:2006/08/02(水) 13:35:43
ちょ、それ死亡フラグ

382 :仕様書無しさん:2006/08/02(水) 13:57:33
うっせーハゲ

383 :仕様書無しさん:2006/08/02(水) 13:57:36
>>380
無茶しやがって・・・・
(AAry

384 :仕様書無しさん:2006/08/02(水) 20:01:52
>>379
「Sun Java」でひとくくりだからな。
Sun 「Java Desktop」ではない。

385 :仕様書無しさん:2006/08/02(水) 20:36:15
そういや、SunのLinuxディストリ使ってる奴見たこと無いな

386 :おじゃばさま:2006/08/02(水) 20:46:06
ああ、今年の夏は暇だな。あまりに暇なので、Javaでシステムを1つ作ってみるかな。
最近の研究ネタは「掲示板における情報伝達」なんだ。
つーわけで、「自動祭り発生プログラム」と「自動スレッドストッパー」を作ってみるかな。
これが完成すれば、2ch制圧も夢じゃない。

387 :仕様書無しさん:2006/08/02(水) 22:01:43
俺はJavaしか出来ない。
でも、もうJavaはやりたくないぞ。
色々めんどくさい事が多すぎるし
経歴詐称して何とか現場に入ってきてる奴らも多すぎる。
Javaの案件も確かに減っている。
.NETとかに移行しないと仕事なくなるぞ。
て言うかJavaやってる奴らは、ほんとにJavaの限界感じてないの?

388 :仕様書無しさん:2006/08/02(水) 22:07:27
感じてないから、おじゃばさまなんだよ

389 :387:2006/08/02(水) 22:11:31
何でなんだろうなぁ。。。
Javaやってる奴らの方が、効率の悪さ分かってると思うけど。
.NETはGUI作るの楽だ。
VB勉強し始める事にするぜ。
だって、ほんとにJavaしか出来ねんだもん。

390 :仕様書無しさん:2006/08/02(水) 22:17:59
別にJavaはGUI作るの面倒じゃないぞ
.NETってかMFC+VCフォームエディタくらい速度で作れる
あとC++とかはJava専門で入った俺より雑魚い奴多くて引く時あるから
多言語にあまり夢見ん方がいいぞ

選り好みせず満遍なく抑えとくってのはいいことだけどね

391 :仕様書無しさん:2006/08/02(水) 23:04:39
>>374=馬鹿

392 :仕様書無しさん:2006/08/02(水) 23:04:43
大量アクセスも軽々とさばくPHP

ttp://quizzes.yahoo.co.jp/quizresults.php?poll_id=3218&wv=1


393 :仕様書無しさん:2006/08/02(水) 23:11:22
よかったね
ファン・ランダエタの勝利だって

394 :仕様書無しさん:2006/08/02(水) 23:17:54
>>391
ようコテつけた奴w

395 :仕様書無しさん:2006/08/03(木) 00:16:41
>>394=馬鹿

396 :仕様書無しさん:2006/08/03(木) 09:22:36
ここまで俺の自作自演

>>1-1000=馬鹿














あれ?

397 :仕様書無しさん:2006/08/03(木) 17:30:38
ファイティング原田は?

398 :仕様書無しさん:2006/08/03(木) 23:01:58
モスクワはもうすくわれないな

399 :仕様書無しさん:2006/08/04(金) 22:42:54
>>389
あぁ、GUI使うショボイのだったら.netだろうな。
でもな、基幹業務やってるような人は.netなんか最初から相手にしないんだよ。

400 :仕様書無しさん:2006/08/04(金) 23:41:41
いや基幹業務だったらついでにJavaも相手にしたくないがw

401 :仕様書無しさん:2006/08/05(土) 01:31:31
やはりCOBOLか。

402 :仕様書無しさん:2006/08/05(土) 01:33:15
MQだ時代はMQだってさこれから30年ご見据えた技術それがMQ

403 :仕様書無しさん:2006/08/05(土) 02:34:23
MQの旬は既に終わってると思うが。
非同期蓄積型通信のメリットはわかるが、MQに絞って使う必要性は感じない。

404 :仕様書無しさん:2006/08/05(土) 06:29:43
MQは既にJ2EEの1パーツとして定義されてるじゃん
だからJ2EEまんせーというわけじゃないが、MQが主役にはならんよ

405 :仕様書無しさん:2006/08/06(日) 13:00:58
MQってトランザクション処理に使えねーじゃん。
分散が広がらない根本的な理由がトランザクションなのに何言ってんだ。

406 :仕様書無しさん:2006/08/06(日) 13:28:00
>>405
お前が何を言ってるんだ?

407 :仕様書無しさん:2006/08/06(日) 13:55:52
>>405
分散が広がらない根本的な理由がトランザクションなのに何言ってんだ。

日本語OK?

408 :仕様書無しさん:2006/08/06(日) 15:11:36
>>407
MQと分散と根本的につながりは無いんだが。
J2EEは分散だけとかどこのDQN上がりだ?

409 :おじゃばさま:2006/08/08(火) 20:27:16
分散って処理分散?データ分散?

410 :仕様書無しさん:2006/08/08(火) 20:50:59
はいはい亀があるくようなWebサービスをJavaで公開しないでね

411 :仕様書無しさん:2006/08/08(火) 21:20:09
>>410亀とは…


おまいやさしいんだな

なめくじでいいのに

412 :仕様書無しさん:2006/08/08(火) 21:32:45
いや、塩かけられたなめくじでいい

413 :仕様書無しさん:2006/08/08(火) 23:48:24
[ レイプ ] [ 声優 ] [ 無修正 ] 林原めぐみが病院で無理やりいけない検査をされる.avi
50b22a08c194dad2f79109cd8271f14d

中身は知的障害者をマスクかぶせて水に顔を突っ込ませたり
フルオートのガス銃で撃ったりして暴行しているのを撮ったビデオ。
中身に期待して損した…
しかもドス黒い気持ちになるわ。これ撮った奴に同じことしてやりたい。

414 :おじゃばさま:2006/08/09(水) 19:39:58
>410
WEBサービスをJavaで公開しないでってのは、
「サーバ側がJavaなWEBサービスを公開するな」って言っているのか?
それとも「クライアントで使うJava-AIPを公開するな」って言っているのか?
文脈を見ると前者のようだが、そうなるとクライアント側のAPIは何を使うんだ?
Cのライブラリを提供されても環境依存で動かないのは困るんだよな。
それともフォーマットだけ公開されて、「自作してください」って事かな。
それならJava-APIが提供される方がマシだと思うが。


415 :仕様書無しさん:2006/08/09(水) 19:49:08
( ゚д゚)

416 :仕様書無しさん:2006/08/09(水) 19:49:20
はあ?
クライアントはなんでもいいのがWebサービスじゃないの?

417 :仕様書無しさん:2006/08/09(水) 20:43:08
>>416
まあまあ、相手はJava厨なんですから・・・

418 :仕様書無しさん:2006/08/09(水) 21:22:07
おじゃばさまってスキル低いんだね

419 :仕様書無しさん:2006/08/09(水) 21:32:23
なんかネタっぽいなぁ・・・

420 :仕様書無しさん:2006/08/09(水) 21:40:43
いや、マジでSOAPやWSDLの部分は知らずにJavaのラッパーでお手軽関数コールしてるのかもしれない。
.NETもそんな感じだけど。

421 :仕様書無しさん:2006/08/09(水) 21:43:10
Java厨ってさ、観念的というか素人っぽいんだよな。

422 :仕様書無しさん:2006/08/09(水) 22:14:58
J2EE鯖にコネクションぷーリングやJNDIキャッシュとかいろんな機能があるのに、
Java使いのSEはJDBCドライバを直接操作したりして性能でねぇと文句を言う。
JavaVMも重いが、そこで動くプログラムはさらに糞実装。

423 :仕様書無しさん:2006/08/09(水) 22:51:24
ハゲるぞw

424 :仕様書無しさん:2006/08/09(水) 22:52:32
深夜に叩き起こされてじゃば鯖再起動。
ああ、また髪の毛が抜けていく。

425 :仕様書無しさん:2006/08/09(水) 23:02:38
遅いもんは遅いから

426 :仕様書無しさん:2006/08/09(水) 23:04:53
富永一○ってまだ生きてるんだっけ?

427 :仕様書無しさん:2006/08/09(水) 23:07:28
レバノンで爆死しなかったっけ?

428 :仕様書無しさん:2006/08/09(水) 23:07:38
グゴォー
フガフガフガフガフガフガフガフガ


429 :仕様書無しさん:2006/08/09(水) 23:08:23
スキルで言ったらJavaやってる奴らより
.NET の奴らが最悪だろ。
あいつらは言う事だけはいっちょ前で
実はプログラマーじゃないな。
IDEの性能の良さや、便利なタグライブラリを
自分のスキルだと勘違いしてる激痛なやつら多すぎ。

まぁJavaやってる奴らも、せめてOOPぐらい
分かれば?って奴ら多いけど。
.NETの奴らがOOPをまっ・・・・・たく!分かってないのは
言うまでもない。
データを渡してデータを戻すだけの関数の集合体
勘弁してくれよ。。。




430 :仕様書無しさん:2006/08/09(水) 23:09:17
まぁ、そんな奴らでも動くシステム作れる
.NET は素晴らしいね

431 :仕様書無しさん:2006/08/09(水) 23:09:39
ブッ○ュって未だ生きてるんだっけ?

432 :仕様書無しさん:2006/08/09(水) 23:10:37
シンスケキモイw

433 :仕様書無しさん:2006/08/09(水) 23:15:37
タモ○って未だ生きてるんだっけ?

434 :仕様書無しさん:2006/08/09(水) 23:35:08
いやいや屑でシンプルさのかけらもないAPIを覚えても明日がない。
再利用性もない。つうか推奨されないものだらけ。
こんな夢の島のような環境で生きていられるJava厨は凄いよ。マジで
ハゲるわけだよw

435 :仕様書無しさん:2006/08/09(水) 23:36:48
あれからなー
API作ってから「ありゃ遅いねこりゃだめだな」
よーし内緒で推奨しないマークつけちゃえってやってるのかな?

436 :仕様書無しさん:2006/08/09(水) 23:36:57
>>429
それはそれでデータ中心型のアプローチになってるなら、OOPにないメリットとかはあるかも。

437 :仕様書無しさん:2006/08/09(水) 23:38:06
Javaデバッグってすげえとろくて待たされてイライラしてハゲちゃうよね

438 :仕様書無しさん:2006/08/09(水) 23:38:18
swingは高速なんだぞGUIバリバリなんだぞ!
操作速過ぎて全然イライラぶち殺したくならないんだぞ!

439 :仕様書無しさん:2006/08/09(水) 23:38:52
お客に納品したら「遅い!」つて起こられてばかりだからハゲちゃうよね

440 :仕様書無しさん:2006/08/09(水) 23:39:59
MVCのコントローラテストサーバにあげてもぜんぜん再読み込みしてくれなくて
OSごと再起動して待っている時間にイライラしてハゲちゃうよね

441 :仕様書無しさん:2006/08/09(水) 23:44:30
この前Java専門にやっている会社に面接にいったんだ。
面接官(ピカピカ)「で・きみはJavaはどの程度できますか?」
私(フッサフッサ)「ええ、まあそこそこには」
面接官(ピカピカ)「では開発の現場を見学してください」
私(フッサフッサ)「はっはい」
面接官(ピカピカ)「ここが開発第一部です」
・・・頭がすだれ、バーコード、てっぺんはげ、生え際危険
ほとんどがハゲだった。。。

442 :仕様書無しさん:2006/08/09(水) 23:47:01
ちゃんと組めばJavaは、もう言う程遅くはないだろ。
時間のかかる処理の大半がDBアクセスだ。
テーブル設計、インデックス設計、SQLをきちんと書けば
普通には動くぜ。
処理時間のほとんどがロジックにかかるとか普通ない。

Javaのデメリットをパフォーマンスとしか言えない奴らは
お前らがへちょいだけ。
最大のデメリットは何と言っても工数かかりすぎ、めんどくさい、
フレームワークとAPI多すぎのため勉強してもキリがない。
これに尽きる。

443 :仕様書無しさん:2006/08/09(水) 23:47:45
>MVCのコントローラテストサーバ
意味不明w

444 :仕様書無しさん:2006/08/09(水) 23:49:29
ふぉがぐふぁふぇふぃうひゃー眠い

445 :仕様書無しさん:2006/08/09(水) 23:51:37
ザ低脳

446 :仕様書無しさん:2006/08/09(水) 23:52:32
モデルビューコガコガフガフガ・・・

447 :仕様書無しさん:2006/08/09(水) 23:52:56
MVCモデルって不毛だよな。
同士のBEAには弱点指摘されて勝手に改良されちゃったし。
その改良も弱点をちょっと補強しただけだし。

448 :仕様書無しさん:2006/08/09(水) 23:53:52
転職天国

449 :仕様書無しさん:2006/08/09(水) 23:55:57
正直、新しい物は変な設計が多いからな。

450 :仕様書無しさん:2006/08/09(水) 23:58:21
MS-DOSの設計も変だったがw

451 :仕様書無しさん:2006/08/10(木) 00:01:20
ぶっちゃけ、Java鯖の運用してる人はマジでハゲが多い。

452 :仕様書無しさん:2006/08/10(木) 00:03:16
デブは?

453 :仕様書無しさん:2006/08/10(木) 00:04:14
短足は?
メガネは?

454 :仕様書無しさん:2006/08/10(木) 00:37:21
結局さ、食ってくには何がいいのよ?
お前らがいいって言うものを勉強するからよ。

455 :仕様書無しさん:2006/08/10(木) 00:51:06
農業かな

456 :仕様書無しさん:2006/08/10(木) 03:05:24
WIN系はパソコン&エロゲオタクばかりけどな〜

457 :仕様書無しさん:2006/08/10(木) 08:50:11
>>456
自己紹介乙

458 :ハゲ厨:2006/08/10(木) 09:38:47
いいんだよ、ハゲなヅラボクサーにも毛が生えたんだし

459 :おじゃばさま:2006/08/10(木) 09:53:25
>415-420
WSDLだけあれば、自動生成で作ったAPIで必ずつながるって言っているのかな?
それとも自動生成のAPIを手動で修正して動くように出来ないのはスキルが低いって言っているのかな?


460 :仕様書無しさん:2006/08/10(木) 11:04:34
WIN系というかマはオタク

461 :仕様書無しさん:2006/08/10(木) 11:06:38
半角キモイ

462 :仕様書無しさん:2006/08/10(木) 11:07:16
C臭がする

463 :仕様書無しさん:2006/08/10(木) 11:29:44
>>458はCハゲスレに逆上したCハゲ

464 :仕様書無しさん:2006/08/10(木) 11:30:12
>>459
そう気を揉むな。お前には何も言ってない。

465 :仕様書無しさん:2006/08/10(木) 12:24:05
はーげーはーげー つるっぱげw

466 :仕様書無しさん:2006/08/10(木) 15:12:09
Javaよくしらないんだけど、そんなに再起動が必要なの?

467 :仕様書無しさん:2006/08/10(木) 15:47:47
http://naoya.g.hatena.ne.jp/naoya/20060513/1147489425

# takuya 『藤田社長のブログから来たけど、このはてなって会社大丈夫?
この方法では、小規模な開発しかできない。
また、組織として開発することもできない。
数人の非常に優秀なプログラマーでの開発にのみ適用できる方法だ。
独りよがり、世間知らずの考えから抜けた方がいいですよ。
コミュニケーションなくても仕事するような人は、そもそも少数派。少数派を中心に考えてはならない。会議に出さないって、どうやって目的を伝えるの?
大規模システムにおいては、仕様・要件の文書化、コミュニケーションは必須です。
また、それなりの人数の会社組織を破綻させない為には、上記のような生産性は高いが好きなときに仕事する人は、非難されなければなりません。
また、それらをスピードを損なわずに行うことは可能です。
なぜ、はてなのサービスが伸びないかもここに根ざしてると思います。
独りよがりな雰囲気がするんだよ。解らなければ、使わなくていいよみたいなさ。ふつうの人はそれだけで、バイバイだよ。一生懸命作った便利な機能について、認知しようともしない。
こんな見当はずれのコメント出す前に、自分を良く見つめ直してほしいものです。』


468 :仕様書無しさん:2006/08/10(木) 16:04:55
禿禿って、Javaやってる人には禿が多いのか?

469 :仕様書無しさん:2006/08/10(木) 16:19:02
そうなのよー

470 :仕様書無しさん:2006/08/10(木) 17:17:14
体育会系は少ない。
酒も煙草もやらない知性のある人が多いな。

大酒飲みのDQNはCOBOLとかCしか出来ない爺。

471 :仕様書無しさん:2006/08/10(木) 19:12:14
人を見下す奴とはやらねぇよ。
やってて不愉快、無理。
こっちが気を使ってりゃ調子にのって上から物を言うようになる。
コミュニケーション取れないのはどっちだか。

472 :仕様書無しさん:2006/08/10(木) 19:38:42
問題の全てはキミの自信のなさにある。
能力があろうが無かろうがその挙動じゃ無いように見えるし、
調子にのられて詐欺にあいやすい。

恐怖を倒せばきっと本来の力が発揮できる筈。
己との戦いだ・・・・。

473 :おじゃばさま:2006/08/10(木) 19:52:34
JavaとCじゃ、Cの方がハゲが多いだろう。
ただそれは言語のせいじゃなくて、年齢のせいだろう。

474 :仕様書無しさん:2006/08/10(木) 19:53:47
. . . . . . . . . . . ∧_∧
. . . . . . . . . . (. .・∀・). . \
. .‐=≡t─‐/ヽ、_つ). .__s)
‐=≡(ニニ(. . ..)../\\-.\
. .‐=≡(. .(ニ:(. ./oz|. .(O)T
. .‐=≡ヽ、__,ノ ̄. . ヽ、_,ノ

475 :仕様書無しさん:2006/08/10(木) 20:03:51
Java系の使えない奴は自分が使えないと分かってていつもびくびくしてる
C系の使えない奴は自分の無理解を切れてごまかそうとする
どっちも救えなさ加減はおなじもんだが

476 :仕様書無しさん:2006/08/10(木) 21:20:08
チッ、ブッ○ュは生きてたか

477 :仕様書無しさん:2006/08/10(木) 21:21:24
mission failed...

478 :仕様書無しさん:2006/08/10(木) 21:29:26
9.11.. 8.11.. 7.11....

479 :仕様書無しさん:2006/08/10(木) 21:44:11
tikajika omaewo biku biku sosite ang saseteyaruyo

480 :仕様書無しさん:2006/08/10(木) 21:47:42
Racial discrimination

481 :仕様書無しさん:2006/08/10(木) 22:00:15
To cyber terrorist

482 :仕様書無しさん:2006/08/10(木) 22:34:24
重い重いと騒いでるのは禿げたおっさんか。

483 :仕様書無しさん:2006/08/10(木) 23:00:08
サーバの処理性能が上がってるから今ならそんなに重くなくね?
よっぽどクソなプログラム組んでるか1秒未満の処理時間の差すら感じられるスーパーPGなら別だが。

484 :仕様書無しさん:2006/08/10(木) 23:03:33
一秒未満の処理速度の差って割と分かると思うがw
感じるか感じないかじゃなくて、気になるか気にならないかだな

485 :仕様書無しさん:2006/08/11(金) 00:26:53
なんかJava厨の痛いのが騒いでるな。
おじゃばさまが恋しくなってくるぜ。

486 :仕様書無しさん:2006/08/11(金) 00:45:51
どうしてプログラマは仲が悪いんですか?

487 :仕様書無しさん:2006/08/11(金) 06:37:13
組み込み分野では1ms以下の世界を考えなければならないんだが

488 :仕様書無しさん:2006/08/11(金) 07:26:49
典型的な馬鹿レス登場w

489 :仕様書無しさん:2006/08/11(金) 11:12:49
ロジックの組じゃなくて同期処理等を突き詰めると、
数百ms単位で早くなる場合があるんだが。

490 :仕様書無しさん:2006/08/11(金) 11:34:58
Java厨の視点−>サーバを利用する側での視点しか持てない

491 :仕様書無しさん:2006/08/11(金) 13:18:17
Java は難いよな。

492 :仕様書無しさん:2006/08/11(金) 16:37:47
ショップブランドPCを買おうと思っているのですが
秋葉原のお店でどこがおすすめですか?

493 :仕様書無しさん:2006/08/11(金) 19:53:45
マハーポーシャとグレイスフルと・・・・あとどこだっけ?

494 :おじゃばさま:2006/08/11(金) 21:01:24
まあ分野によるだろう。
WEB屋なら1秒ぐらい大したことないかもしれんが、電話や動画屋だと500msぐらいからヤバイ。
ルーター組み込み屋とかだと487の言う通り、1ms以下の世界だしな。
でもJavaで出来るのは電話や動画以上だから、1ms以下の話は意味ないな。
ただ電話屋にとっては1秒は長すぎるぞ。WEBと電話で分けて話した方がいい。

495 :仕様書無しさん:2006/08/11(金) 21:08:23
組み込みJavaは実際にあるし何とも言えんな
まあランタイム系ならエンドポイントの精度は期待できん
ミリ秒で処理出来る出来ないの話だけならできるがね

496 :69式フリーPG ◆hND3Lufios :2006/08/11(金) 22:32:00
Javaがブレイクした2000年頃というのはCPUのクロックが1GHz越えを目指した頃で、
半年毎にバンバン上がっていってた。

で、2003年頃から3GHz前後で停滞期に入るんだな。

Javaが広まり、停滞した理由はこの辺にもあったり。

497 :仕様書無しさん:2006/08/11(金) 22:41:15
Core2 3GHzが普通にノートに載るような時代が来れば
俺はJavaだけでいいかなと思ったりもする。

498 :仕様書無しさん:2006/08/11(金) 22:49:22
     /⌒ヽ ∩ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    / ´_ゝ`)/<先生!アウトローSTOP115です!w
 _ / /   /   \____________
\⊂ノ ̄ ̄ ̄ ̄\
 ||\        \
 ||\|| ̄ ̄ ̄ ̄ ̄||
 ||  || ̄ ̄ ̄ ̄ ̄||


テイノウイミナシバカスレバカレス

499 :仕様書無しさん:2006/08/12(土) 00:18:15
>>494
電話って言われると携帯からJTAPIまで幅広く上げられるがどーいうレベル?

500 :仕様書無しさん:2006/08/12(土) 00:28:54
おじゃばさまだと、SIPのServletとか挙げるだけで精一杯だろう。
あんまりいじめるなよ。

501 :仕様書無しさん:2006/08/12(土) 10:49:09
javaは変なUIを改善して欲しいし、
変なフォントも辞めて欲しいし、
IDEが軽くして欲しい
バージョンをまとめて欲しいし、
JDBCドライバもフレームワークも優秀なのを1個にしてほしい

502 :仕様書無しさん:2006/08/12(土) 11:29:22
Eclipseなんか捨ててemacsを使おう。

503 :仕様書無しさん:2006/08/12(土) 11:40:17
emacsつかうとなにかいいことあんノ?

504 :仕様書無しさん:2006/08/12(土) 11:41:45
軽い

505 :仕様書無しさん:2006/08/12(土) 12:10:17
コピペがマウスを使わずに素早くできる

506 :仕様書無しさん:2006/08/12(土) 13:30:53
Ctrlボタンが禿げる

507 :仕様書無しさん:2006/08/12(土) 13:50:03
ESCもハゲるまるでJava厨

508 :仕様書無しさん:2006/08/14(月) 01:34:19
ビジネスロジック

509 :仕様書無しさん:2006/08/14(月) 21:34:19
結局、重いのか重くないのか

510 :仕様書無しさん:2006/08/14(月) 21:43:25
その昔はemacsといったら重量級ソフトの代名詞だったのにw

511 :仕様書無しさん:2006/08/14(月) 22:17:57
重くねぇっつってんだろ

512 :仕様書無しさん:2006/08/14(月) 23:06:14
>>519
Seasar厨乙

513 :仕様書無しさん:2006/08/14(月) 23:07:36
>>519


514 :仕様書無しさん:2006/08/14(月) 23:16:55
>>519
じゃあ俺も、乙

515 :仕様書無しさん:2006/08/15(火) 00:35:50
じゃあ私は、乙女

516 :仕様書無しさん:2006/08/15(火) 01:05:06
>>519


517 :仕様書無しさん:2006/08/15(火) 01:54:35
# emacsは起動以外重いとは感じない。

それで、Javaは結局 起動時も起動時以外も常に重いの?

518 :仕様書無しさん:2006/08/15(火) 02:53:59
>>517
重くないと思うよ、128ノードのクラスタ使ってるけど
遅いとかいってるやつの脳みそどうなってるか本当に知りたくなるよ

519 :仕様書無しさん:2006/08/15(火) 03:50:54
>>497
そのころはJavaがもっと重くなってる

520 :仕様書無しさん:2006/08/15(火) 09:01:02
>>517
> それで、Javaは結局 起動時も起動時以外も常に重いの?
重いね。重いというほどひどくはなく、もっさりしているという感じ。
それでも多言語で作ったアプリを触ってからだと重さが際立つね。

521 :仕様書無しさん:2006/08/15(火) 09:02:43
多言語→他言語

522 :仕様書無しさん:2006/08/15(火) 11:42:30
518の脳味噌覗いて見るか

523 :仕様書無しさん:2006/08/17(木) 12:38:17
レスありがとうございました。
私のPCがどこか格別おかしいってわけじゃないらしいことが
なんとなく分かりました。

ただ、私はそのもっさりにストレスを感じずにいられません。
# ストレスを感じないコツってありますかね?

Javaに期待している人達って、H/Wの処理能力が将来
画期的に向上することを想定しているんですかね。
# OOであることがその次世代の何かと親和性があるなら
# Javaはそういった将来で結実するのかな。

今は重いですけど。
私は1ノードで開発しなければなりません。
Javaの良さがいまいち分かりません。
現状の重さを犠牲にしてJavaは何を優先させていますか?

524 :仕様書無しさん:2006/08/17(木) 13:12:02
ふ〜んすごいね

そんなに自身の生産性が高いならそれを活かせるシステムを新たに作れば良いだけじゃないの?
どうせ奴隷の様に働くしかないんだからゆったり仕事すれば良いのに

525 :仕様書無しさん:2006/08/18(金) 22:51:08
おじゃばちゃんは最近来ないね。
自殺したのか?

526 :仕様書無しさん:2006/08/18(金) 23:41:02
だからお前ら何度も言わせるな。
Javaのデメリットをパフォーマンスとしか言えない奴らは
お前らがへちょいだけ。
最大のデメリットは何と言っても工数かかりすぎ、めんどくさい、
フレームワークとAPI多すぎのため勉強してもキリがない。
これに尽きる。
分かったか?

527 :仕様書無しさん:2006/08/19(土) 00:11:17
すれ停滞してるからってわざわざねたふらんでもいいよ

528 :仕様書無しさん:2006/08/19(土) 07:24:02
>>526
じゃ、フレームワーク使わなきゃえぇやん。
APIもそんなにたくさん使うか?
SEが使うAPIなんてたかがしれてるだろ?

529 :仕様書無しさん:2006/08/19(土) 09:24:35
工数掛かりすぎってどこの雑魚だよw

530 :仕様書無しさん:2006/08/19(土) 12:25:40
>>526
おまえは一生こつこつ車輪の再発明でもやってろ。

531 :仕様書無しさん:2006/08/20(日) 01:34:48
>>528
自社で受託開発をしてれば、フレームワークを使わんでもええとか
言ってられるかもしれんが、
現場に出てたらそんな事言える訳ないだろが。
その会社独自フレームワークを使ってたりしたら、派遣相手でも
講習会とか研修あるぐらいやぞ。
struts, O/Rマッピング, DIコンテナ を押さえてれば
どこ行っても似たようなもんだが、それでもその会社が作った
リファレンス見ながらの作業は明らかに非効率だぜ。

>>529
>>530
はいはい、お前らはちょっとかじって出来る気になってる
痛い奴らやから黙ってろ。
実際にJavaの開発現場を何箇所も踏んでて、実状を知ってる奴らなら
そんな事絶対言わんからな。
200 〜 300 人規模のプロジェクトで 1 〜 2 年かかってんのは
工数かかりすぎじゃないのかよ。
10 人程度の小規模プロジェクトで半年とか、かかってんのは
工数かかりすぎじゃないのかよ?
それに人件費だけでどんだけかかると思ってんだ?
Javaの案件が減少してて、.Net なんかの案件が増加してきてる傾向が
全てを物語ってるだろうが。

532 :仕様書無しさん:2006/08/20(日) 01:43:21
200〜300人規模の.NET案件が増加しているという強引な論調にワロス

533 :仕様書無しさん:2006/08/20(日) 01:49:18
>>532
それはJavaの案件の話で、.NET の事は良く知らん。
逆に.NET でもそんな大人数でやるプロジェクトとかあんの?

534 :仕様書無しさん:2006/08/20(日) 01:58:32
>>531

> どこ行っても似たようなもんだが、それでもその会社が作った
> リファレンス見ながらの作業は明らかに非効率だぜ。

お前にとってはそうかもしれないが、会社側からすれば保守やメンテなどがあるからな。
一部の作業が非効率だろうが、全体を通して効率があがればよい。
とはいうものの、できてない現場のほうが多いが・・・。
管理側からしてみれば、俺の作ったフレームワークで俺が思うとおりに書いてくれ。
インデントすらも俺の好みにあわせろ!ってかんじだろ。
派遣なんて使い捨てだからな。

後、フレームワークやAPIが多くて勉強してもキリがないとか言っているが、
こんなもん、どの言語でも一緒だろ。
どの言語でも、会社による独自APIや、ライブラリがあるだろ。
CやC++の独自ライブラリにはひどいものが山ほどあったぞ。

.Netはまだ普及ぐあいが中途半端なので、独自なんちゃら〜ができてないだけで
普及しだすと山ほどふえるだろ。


> 200 〜 300 人規模のプロジェクトで 1 〜 2 年かかってんのは
> 工数かかりすぎじゃないのかよ。

PMなどがへぼすぎるだけ。
これが、C++だろうが、.Netだろうが同じくらいの工数がかかる。


535 :仕様書無しさん:2006/08/20(日) 02:00:52
それより今の時代、半年以上かかってモノ作って間に合うのか?

536 :仕様書無しさん:2006/08/20(日) 02:04:21
>>535
間に合わないんじゃないかな。
1年以上かかってるのは破綻したプロジェクトじゃないの?
やめるにやめられず、追加予算をどんどん投入してるうちに、
2年がたってしまったとか。

537 :仕様書無しさん:2006/08/20(日) 02:05:34
Javaはさぁ、あの xml 地獄が俺は嫌いなんだよ。

538 :仕様書無しさん:2006/08/20(日) 02:42:27
機能を作るのに掛かる工数と、言語と環境による制約から来る
制限を回避する工数とをごちゃごちゃにしないできちんとわけてから
話せ

539 :仕様書無しさん:2006/08/20(日) 08:35:59
>>531
PMにフレームワークを使うデメリットをきちっと説明できれば受け入れてもらえるかもよ。
まぁ、使うメリットが大きいから採用してるはずだがな。

540 :仕様書無しさん:2006/08/20(日) 23:32:06
大手にいる奴なら>>526の言い分はおおむね正しいと感じるはず。

541 :おじゃばさま:2006/08/21(月) 19:53:28
ああ、夏休みも終わってしまった。
オマエラ、ちゃんと夏休み取ったか?1週間。

542 :おじゃばさま:2006/08/21(月) 20:08:12
>523
Javaの利点は互換性だよ。
・多種多様なOSで動作する。
・膨大な無料のライブラリが使える。
もし、Windowsで1から全部作るような開発をやっているなら、Cでもいいんじゃないか?

工数は場合によるが、一般的にJavaよりCの方がかかるぞ。

543 :仕様書無しさん:2006/08/21(月) 21:20:26
eclipseってServer.xmlのタグ壊すの知ってるか?

544 :仕様書無しさん:2006/08/21(月) 22:55:22
>>542
>・多種多様なOSで動作する。

確かにプラットフォームを選ばないのは一番(唯一?)の利点と言える。

>・膨大な無料のライブラリが使える。

これがデメリットに成り得るんだよ。
一見、多様な選択肢があって嬉しいように思うが
開発者を惑わす事がほとんどだ。
一部の有名どころだけ押さえておけば良い。

>工数は場合によるが、一般的にJavaよりCの方がかかるぞ。

組み込みとWebを一緒にするんじゃねぇよ。
Webシステム如きに半年とか1年とかかけてる所がやばいんだろが。

545 :仕様書無しさん:2006/08/21(月) 23:17:52
いや、マルチプラットフォームなのはあくまでC製の「JavaVM」であって、
Javaのバイトコード自体は唯一無二の仕様のJavaVMという1つのプラットフォームでしか動かない。


と屁理屈でもこねてみるか。

546 :仕様書無しさん:2006/08/21(月) 23:29:40
おじゃばんには理解不能だろう

547 :仕様書無しさん:2006/08/22(火) 00:25:55
つうか、なんであんなアホみたいになんでもかんでもxmlなの?
パーサがまた重いんだ。

548 :仕様書無しさん:2006/08/22(火) 00:29:30
当時はXMLも流行ったからなー

549 :おじゃばさま:2006/08/22(火) 20:11:04
>544
Javaの場合は使用するライブラリの調査に「Javaを知る優秀な人間」と「十分な時間」をかける必要がある。
これを怠ると、544の言う通りデメリットになり得る。
一番問題なのはこの調査作業を甘く見ている人が多く、「新人」や「CはスペシャリストだがJavaは初心者」
のような人にやらせることがある事である。

このあたりをちゃんとやっていれば、普通はCよりJavaの方が工数は少なくなるだろう。
Javaで半年かかるシステムなら、Cで作ればそれ以上かかるだろう。

>545,546
理解は出来たが、言っている事は間違っているだろう。
WindowsのJVMとLinuxのJVMは違う物な訳だから、マルチプラットフォームとは言えないだろう。

>547
個人的にはXMLは嫌いだが、XMLを使う理由は2つある。
漢字のエンコードが指定出来るのと、データの親子関係が指定出来る事である。
ただ個人的には漢字さえどうにかすれば、CSVの方がいいと思っている。
また重いのも問題だが、使いにくい方が大問題だろう。パーサーを直に使うとひどい目に遭う。
個人的には自動生成は好きではないが、直使いよりはマシなので、RELAX-NGを使っている。
まあ今の段階では、各種自動生成ツールを使うのが妥当だろう。


550 :仕様書無しさん:2006/08/22(火) 21:16:38
SQLでえぇやん

551 :仕様書無しさん:2006/08/22(火) 21:21:47
iniファイルでええやん

552 :仕様書無しさん:2006/08/22(火) 22:52:49
>>549
真面目に質問だが、その調査に半年かかるのでは?

JAVAがマルチプラットフォームを主張するが、
もともとCはシンプルを吉とする、移植性の高い言語である。
プラットホームの違いが関係しない部分は、Cで書いても簡単に移植できる。

そして、UIは手間でも、そのプラットホーム専用を作るべきではないか?
JAVA側の意見は、なんでも人のせいにする言い訳にしか聞こえない。

XML< 複雑なデータ構造なら「バイナリ」で扱えばいいだけ
単純ならCSVで問題なし。



553 :仕様書無しさん:2006/08/22(火) 22:54:15
マルチプラットフォームは幻想

554 :仕様書無しさん:2006/08/22(火) 23:41:46
>>549

>WindowsのJVMとLinuxのJVMは違う物な訳だから、マルチプラットフォームとは言えないだろう。

Javaが出てくる前はマルチプラットフォームと言えばそういうもんだったよ。
おじゃばさまはJavaができてから技術者になったクチ?

で、プラットフォーム依存の部分は基底ライブラリ化してすげ替えてたもんだ。
その部分を思い切って単独アプリにしちゃったのがJavaVMという位置づけ。

昔とやってることは基本的に変わらない。

555 :仕様書無しさん:2006/08/22(火) 23:43:47
それゆえ本当のプラットフォーム依存のおいしい処理が全くできずに単なるウェブ言語に成り下がった

556 :仕様書無しさん:2006/08/23(水) 08:07:13
Java厨Web屋がソースファイル数百本程度のプロジェクト見て大騒ぎしてた。
WebシステムはPGをあほにする。

557 :仕様書無しさん:2006/08/23(水) 08:26:47
>>556
人による、プロジェクトによると言ったところだろうか
何となくどっちも痛いような気がするのはなぜ?w

558 :おじゃばさま:2006/08/23(水) 09:50:50
>552
調査に半年かかるという意見も、確かに全てを調べようと思えばそう言えるかもしれない。
これにはいくつかのコツがある。参考までに書いておく。(適用は自己責任で)
・サンプルでやっているやり方から大幅に変更しない。
・漢字が正しく使えるか調べる。
・リソースリークしないか調べる。
まずほとんどのライブラリにはサンプルコードがついている。
開発の前提として、そのサンプルコードの使い方から大幅に変更しないようにする。
サンプルコードが付属しない機能については、できるだけ使わない方針にする。
次にプロトタイプを作成する。
競合の問題もあるので、プロトタイプにはできるだけ使用するライブラリ全てを取り込むようにする。
そして問題になるのは2点だ。海外製のライブラリが多いJavaでは漢字の問題をクリアしていない
物も少なくない。これが大丈夫か調べる。次にマイナーなライブラリでは連続稼働試験が行われて
いない事が多い。サンプルコードを改修して連続稼働させリソース量を監視し、メモリやコネクション
などがリークしていないか調べる。
まあ最低でも2週間。普通は1カ月ぐらいは期間を確保して欲しい。

Cが移植性が高い事は認めよう。
しかし他社製のライブラリを使っていて、それが移植先のOSでは出ていない場合はどうだろう?
この場合はどうしようもない。諦めるか自作するかだが、使用箇所が極端に少なくない限り、
前者となるだろう。


559 :おじゃばさま:2006/08/23(水) 09:52:07
UIをOS依存で作る?
それについて利用者にとって何か利点があるのだろうか?
また開発者は操作説明書を複数作る事になると思うが、それを考慮しているのか?
時代逆行としか思えないが。

複雑な構造ならバイナリ?
本来XMLは自分の設定ファイルと言うより、データの受け渡しに使用する。
画像データや音声ファイルならともかく、テキストに出来るデータをバイナリで扱うとは...
時代逆行が流行っているのか?


560 :仕様書無しさん:2006/08/23(水) 10:30:28
XDRとかBERとか知らないうちに結構使ってるものですよ

561 :仕様書無しさん:2006/08/23(水) 13:26:24
UIはOS依存の方が全然使いやすいと思うわ
使いにくい共通より100倍まし

562 :仕様書無しさん:2006/08/23(水) 19:39:18
>>561
それ真理だな。

563 :仕様書無しさん:2006/08/23(水) 21:20:35
ついにJavaにもクロージャ? - James Gosling氏らJDK7へ導入提案

Java言語の主要アーキテクトであるGilad Bracha氏、Neal Gafter氏、James Gosling氏、Peter von der Ahe氏らは
18日(米国時間)、Java言語において関数型やクロージャの導入を提案するホワイトペーパを公開した。現在、
Javaには関数型やクロージャは用意されていない。同氏らの提案ではJDK7を目処にこれら機能を
統合していきたいとしている。

関数型やクロージャは関数型言語やスクリプト言語には用意されていることが多い機能のひとつ。同機能をもった
代表的なプログラミング言語にはPython、Ruby、Perl、JavaScript、Common Lisp、Scheme、Smalltalk、Scala、C#などを
あげることができる。
もともとSmalltalkを使ってきたプログラマなどは、JavaにクロージャがないことをJavaに対する不満としてあげることが多い。
クロージャはときに熱狂的に支持される機能である。略


http://journal.mycom.co.jp/articles/2006/08/23/java7closuer/

使用例
public static void main(String[] args) {
  int plus2(int x) { return x+2; } // ローカル関数を定義
  int(int) plus2b = plus2; // 関数型の変数にローカル関数を代入
  System.out.println(plus2b(2)); // 関数型の変数からローカル関数を実行
}

564 :仕様書無しさん:2006/08/23(水) 21:43:25
JavaでもCollectionにdoやselectやcollectが実装されるのか〜

565 :仕様書無しさん:2006/08/23(水) 22:11:20
>>556
組み込み屋です。
「本」ってどういう単位?

566 :仕様書無しさん:2006/08/23(水) 23:03:04
>>558
そういや昔見たJava屋はクラスライブラリのリファレンスを見ただけでは何も作れないやつだった。
デザインパターンとかサンプルソースとかそういうのがないとどう組み合わせて使えばいいのか自分で発想できないらしい。しかも参考にすると言うよりほとんどコピペしてた。
そして自分の思い通りに動かなかったらまず「クラスの設計がおかしい」と言っていた。
あれじゃ、Java以外を書かせても、自分では何も応用できないだろうなと思った。

567 :仕様書無しさん:2006/08/23(水) 23:38:49
>>566
それってJava屋がどうとか言う以前の問題だな。

568 :仕様書無しさん:2006/08/23(水) 23:50:38
>>565
業務系って「本」っていう便利な単位が使えていいよね。
「マスタ○本、エントリ△本、照会□本、帳票×本」とか。
本単位を基準にすると見積もりが楽。

でもそういう単純な見積もりが可能なところが
業務系って単純ドカタ作業ってことを示している気がする。


569 :仕様書無しさん:2006/08/24(木) 00:34:59
hoge.cで一本じゃないのん?

570 :仕様書無しさん:2006/08/24(木) 00:51:00
1本2本…は業務系ドカタさんたちが数えるときに使う単位

571 :仕様書無しさん:2006/08/24(木) 00:59:27
業務系ドカタはステップ数でつよ

572 :仕様書無しさん:2006/08/24(木) 06:26:51
1本っていったら百万のことだろ?

573 :おじゃばさま:2006/08/24(木) 09:47:58
>554
ああ、そういう時代もあったな。
確かに原理的には大きく違わないとも言えるが、実質的にはかなり違うぞ。
それは「コンパイルが必要ない」って事だ。実際に移植しようとすると、コンパイルオプション地獄や
リンク地獄に陥るだろう。あの無駄な作業から解放されるだけでも大変な違いと言えるだろう。

>561
マルチプラットフォームとUIの話が混ざってきて分かりにくくなっているが、
Windowsでしか動かさないプログラムにJavaのUIを使えと言っている訳ではない。
Windowsクライアント用ならVBなどでも使えばいいわけで、共通化は必要ない。
マルチプラットフォームからの話なので、WindowsサーバやLinux、Solarisなどでも同じプログラムを使う
必要がある場合に、共通IFを使った方がいいと言っている訳だ。

WEBシステムを馬鹿にする奴もいるが、WEBシステムの特徴を分かって言っているのかと気になる時がある。
たとえば、画面をまたがってトランザクションが発生するような設計をする奴とか、
サーバイベント駆動型の設計をする奴とか、ブラウザ使用のくせに表崩れを認めない奴とか。
できなくはないが、そんな仕様のために作業者が苦労するのを見て、当の設計者は
「これだからWEB屋はダメだ」とか言う奴がいるからな。


574 :仕様書無しさん:2006/08/24(木) 10:05:08
http://www.ryoken-inq.mofa.go.jp/fw/dfw/csv/direct/shinki/d_shinki.html

Java2 Runtime Environment

申請画面を表示するために必要になります。
セキュリティ向上のため、最新バージョンの使用が推奨されますが、
お住まいの都道府県により使用すべきバージョンが異なりますのでご注意ください。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

575 :仕様書無しさん:2006/08/24(木) 10:17:50
>>574
ベンダー出て来い(w

576 :仕様書無しさん:2006/08/24(木) 16:19:37
Javaにいもうとクロージャとかいってる糞スラの人間を
見ても2chの糞JAVA房見ても思うが
JAVAのやつって本当に使えない死んだほうがいいやつばかりだよな

577 :仕様書無しさん:2006/08/24(木) 16:28:54
JAVAを使ってるやつは何のために生きてるんだ?毎度毎度BUG出して
挙句の果てには、火事を出す。お前らは技術者ヤメロ、お前らは無能なんだよ
口ではできます。できます。なんていってるけど頭の中じゃいつ逃げようか
いつ死のうかそれしか考えてないだろ。もう消えろよ

578 :仕様書無しさん:2006/08/24(木) 16:58:53
そんなにストレス溜める前に Javaと激安派遣JavaPG使うの
やめればいいのに

579 :仕様書無しさん:2006/08/24(木) 17:25:28
それでは解決しない、クズを根絶やしにしないとダメだ?
チョンやシナを見たら解るだろ?増殖するとやっかいんだよ

580 :仕様書無しさん:2006/08/24(木) 19:34:58
>マルチプラットフォームとUIの話が混ざってきて分かりにくくなっているが、
>Windowsでしか動かさないプログラムにJavaのUIを使えと言っている訳ではない。
>Windowsクライアント用ならVBなどでも使えばいいわけで、共通化は必要ない。

現在クライアントマシンのほぼ100%がWINDOWSマシンです。
ではサーバーと如何にして連帯を取るか? 以下のような方法があります

ローカルIPネットワーク
広域IPネットワーク
WEB経由
メタフレーム

クライアント部分はWINDOWSで動けばよい。あとは通信方法のみ
一般客用のインターフェイスはWEB「IE」
業務用アプリはその他の通信
データーの高速通信が必要なら、メタフレーム等を使う

JAVAのマルチプラットホーム開発能力がどこに必要なんだ?


581 :おじゃばさま:2006/08/24(木) 20:35:56
>580
だからマルチプラットフォームが必要なのはサーバの話。
UIで言うと、サーバーのインストーラーや設定ツール、監視ツールなど。
俺は「サーバツール」の話をしていて、561達は「クライアントツール」の話をしていたのかな。


582 :仕様書無しさん:2006/08/24(木) 20:37:20
つーか

>マルチプラットフォームからの話なので、WindowsサーバやLinux、Solarisなどでも同じプログラムを使う 
>必要がある場合に、共通IFを使った方がいいと言っている訳だ。 

という考えがJavaありきで、嫌。

まあ、それはともかく、WindowsやLinuxやSolarisで同じプログラムが動いてるのって
(Javaでも)稀なケースでしか無い様な気がするんだが。

そーでもないの?おせーて。

583 :仕様書無しさん:2006/08/24(木) 20:44:24
ツールとかならメリットあるからJavaでもいいかとおもうけど
クライアントアプリはOS依存UIのほうがよいに決まってる

584 :仕様書無しさん:2006/08/24(木) 21:02:46
やはりWFCだね

585 :仕様書無しさん:2006/08/25(金) 02:21:59
>>579
偉そうにwエロゲオタクがwww

586 :仕様書無しさん:2006/08/25(金) 02:24:15
まあエロゲオタだからネットウヨになんかなるんだろうな

587 :仕様書無しさん:2006/08/25(金) 02:38:28
蛇馬は、まれにみる糞言語。w
マルチプラットを謳えど、バージョン差異で動かないのは、この言語ぐらい。
パッケージソフトを買うときは気をつけよう、注意一秒、蛇場一生。

こないだも、アプリケーションが二種類以上あって、それぞれ違うバージョンの
蛇場を要求するんだよ。どうするんだよ、バカなエンドユーザーをどう指導するんだよ。w
シネヨ蛇場。

WINのVer上がっても、昔の蛇場入れろといわれても、インスコラーが対応してねえんだよ。

おいコラ。このウンコ蛇馬士ね士ね士ね士ね士ね士ね士ね士ね士ね士ね士ね士ね士ね。


588 :仕様書無しさん:2006/08/25(金) 03:31:01
蛇馬w
注意一秒、蛇場一生ww
おいコラ。このウンコ蛇馬士ね士ね士ね士ね士ね士ね士ね士ね士ね士ね士ね士ね士ねwww

589 :仕様書無しさん:2006/08/25(金) 07:20:54
まあ、.NETで同じ目にあったわけだが、、、。
あれも、1.1と2.0両方抱えないとどうしようもない。
これから先もどんどんディスクの肥やしになってくんだろうな。

590 :565:2006/08/25(金) 20:39:28
>>568-570
遅れたけどサンクス。
ファイル数のことなのね。

それで見積もれること自体驚きだ。

591 :おじゃばさま:2006/08/25(金) 20:54:37
>587
それは基本的にソフトを導入する前にチェックする必要がある。
あとJVMやアプリケーション(TOMCAT等)も本当に必要がなければバージョンアップしない。
最新の物が「悪い」のはJavaの特徴だ。
仕事で使うなら、今はJava1.4のTOMCAT5.0当たりが無難だろう。

592 :仕様書無しさん:2006/08/25(金) 21:36:48
最新の物も初代からの物も全て悪いのがだろ

593 :仕様書無しさん:2006/08/25(金) 21:44:12
>>590
見積もったんじゃなくて、既存のものに手を入れる時のことじゃないかと

ドキュメント枚数まで見積もり時に決めるとこrもあるから ありえなくはないけど

594 :仕様書無しさん:2006/08/25(金) 21:47:59
少なくともファイル数に何の意味もないことは明かだな
1行のファイルも100000行のファイルも一本なんだろ

595 :仕様書無しさん:2006/08/25(金) 22:04:02
ボタンとテキストボックス数個のUIの互換性を優先する為に、JAVAを選択するなら本末転倒だ。
複雑なUIの互換性が出来てこそ意味がある。


馬鹿みたいな工数をかけて「得たいの知れない互換性を保つ為に」JAVAで作るなら、
1人のプロのマニュアル書きに、OSに特化したアプリ用の綺麗なマニュアルを作ってもらったほうが良い。





596 :仕様書無しさん:2006/08/26(土) 01:07:56
>>563
もうJAVAでなくていいんでないのか…

597 :仕様書無しさん:2006/08/26(土) 02:03:22
JDK7からJava VMのセキュア性能がちょっと落ちるらしいな
スクリプト対応のためにも関数型の実装は必要だったし
Java VMとJavaを分けて考えようという動きはあるらしい

598 :仕様書無しさん:2006/08/26(土) 09:25:48
JVMはオプソになればすぐに高速化するし問題も解決する。
実際IntelがJVMを構築するためのミドルウェアを既に開発済みだ

ではどこが悪いのか考えてみよう、糞仕様連発する太陽のせいで
JAVAは複雑かつ糞になってきた

599 :仕様書無しさん:2006/08/26(土) 13:20:27
うえーんいたいよう…

600 :仕様書無しさん:2006/08/26(土) 13:28:46
顧客要求に振り回されて糞仕様になっていくのはJava本体も同じということか。

601 :仕様書無しさん:2006/08/26(土) 13:33:30
javaを無理矢理使いたいんだろうな

602 :仕様書無しさん:2006/08/26(土) 18:26:01
マルチプラットフォームといいつつ、バージョン間の互換性がだめだめ

603 :仕様書無しさん:2006/08/26(土) 19:08:14
100000行のソースファイルですかw

604 :仕様書無しさん:2006/08/26(土) 19:57:42
>>602
それが一番糞だよマジで

605 :仕様書無しさん:2006/08/26(土) 20:27:33
ああ、例の枝番の件?

606 :仕様書無しさん:2006/08/26(土) 20:28:55
そんなもん選ばんよ

607 :仕様書無しさん:2006/08/26(土) 20:29:53
あのさあ、この先糞な新仕様が続々でてくるだろう。
新仕様も皆VMのメモリに読み込んでから実行。
この先も無駄なメモリを使い続ける。
それに過去の推奨されない機能の分も読み込むわけでこれもまた無駄だねえ。

608 :仕様書無しさん:2006/08/26(土) 21:00:27
Javaの得意分野に代替言語なんて無いけどな

609 :仕様書無しさん:2006/08/26(土) 21:02:18
javaの得意分野って何?

610 :仕様書無しさん:2006/08/26(土) 21:09:41
Webアプリ+ビジネスロジック

611 :仕様書無しさん:2006/08/26(土) 21:15:48
perlでいいいじゃん。軽いし早いし互換性高いし。

612 :仕様書無しさん:2006/08/26(土) 21:17:52
ビジネスロジックが外だし出来ないだろ
ネットモールレベルの最適言語ならPHPとか.NETと競合してるし

613 :仕様書無しさん:2006/08/26(土) 21:20:18
使い分けでJavaを使うってことで、得意分野(?)に特化した仕様だけに意固地に拘って洗練していくのが良いと思うのだが、現状は逆ってことか。
JavaありきでなんでもJavaでできるようにという使う側の都合に振り回されて仕様拡張していくのはあまりうまくないと思うが、誰が得をするんだろうね。

JavaはJavaVMが1台マシンを乗っ取ってJavaVM以外への効率的なリソース配分を邪魔するから、1つでもJava製のアプリを入れると他は全部Java製にしないと自慢のスループットも出ない、というのが現状でそこからこの流れなのかな、と勘ぐってみた。

614 :仕様書無しさん:2006/08/26(土) 21:25:22
Sunは既にJVMのJavaからの卒業を意識してるよ
JavaがJavaじゃなくなる日は無いだろうが、
JVMを動かす言語がJavaじゃなくなる可能性はある

615 :仕様書無しさん:2006/08/26(土) 21:32:20
おいおい、JVMがJavaを動かしてんだぜ?仕組みわかってる?

616 :仕様書無しさん:2006/08/26(土) 21:35:58
知ってるよ、コンパイル元がjavacじゃなくなるって意味だ

617 :仕様書無しさん:2006/08/26(土) 22:36:44
つまりMSのCLR(CommonLanguageRuntime)と同じ方向ってことかな。
SQLServerのストアドプロシージャでVB.NETが動くってのをうらやましく思ったとかが動機の方針なら寒いが。w

618 :仕様書無しさん:2006/08/26(土) 22:44:54
>>613
スレッドストレスツールを作った
こいつを動作させてJavaを動かすと笑える

619 :仕様書無しさん:2006/08/26(土) 22:56:54
>>617
OracleでJavaをストアドプロシージャに使えたような・・・

620 :仕様書無しさん:2006/08/26(土) 23:20:28
これがまた使えないんだ。
OracleにはPL/SQL.


621 :仕様書無しさん:2006/08/26(土) 23:25:44
使えるよ、無知って恥ずかしいよな

622 :仕様書無しさん:2006/08/26(土) 23:29:06
OracleでJavaストアドって何年前の話してんだ
話題フル杉

623 :仕様書無しさん:2006/08/26(土) 23:31:07
OracleにJavaストアドが導入されたのは8iからだよ

624 :仕様書無しさん:2006/08/26(土) 23:40:01
PostgreSQLもJavaストアドが使えるようだ。

http://itpro.nikkeibp.co.jp/members/ITPro/oss/20040212/2/

625 :仕様書無しさん:2006/08/26(土) 23:42:03
真のストプロ書きはJavaなんか使わないよ。

626 :仕様書無しさん:2006/08/26(土) 23:44:25
OracleもVB.NETでストアドプロシージャ書けたような?

627 :仕様書無しさん:2006/08/26(土) 23:50:05
http://www.oracle.co.jp/database/application/

Oracleは何でもあり

>また、データベース内にPL/SQLエンジンおよびJVMを内蔵しているため、PL/SQLやJavaで書かれたストアド・アプリケーションを高速に実行することが可能です。

内蔵ってどのバージョンだろうねw

628 :仕様書無しさん:2006/08/26(土) 23:54:32
PL/SQLは互換性高いからね。
少なくとも過去のヴァージョンで書かれたものがその後のもので
動かないって事例は聞いたこともない。

629 :仕様書無しさん:2006/08/26(土) 23:57:25
>>628
出来ることが極端に少ないからな

630 :仕様書無しさん:2006/08/27(日) 00:01:09
>>627
たぶんJDK1.0系
時代が1.2になろうとしてる時にOracleインストーラが1.0.7を
勝手に入れてトラブル発生しまくりだったからな

631 :仕様書無しさん:2006/08/27(日) 00:02:31
ストプロではできることが制限されていることが望ましい。
DB上で動作するという特性上、制限されていないと困るのだ。
これは、javaがC言語と異なりメモリやレジスタ、それにI/Oを直接扱えないことと同じだ。

632 :仕様書無しさん:2006/08/27(日) 00:10:32
ストアドで何でもできないと困るような糞設計には幸い今のところ出くわしたことはない。

633 :仕様書無しさん:2006/08/27(日) 00:11:54
つまり>>617が意味不明なのですね。


634 :仕様書無しさん:2006/08/27(日) 00:13:00
>>632
ぶっちゃけたところトリガすらまず使わないことが多いしな

635 :仕様書無しさん:2006/08/27(日) 00:18:19
oracleでスカトロ使えるのかすげぇぇぇぇぇ

636 :仕様書無しさん:2006/08/27(日) 00:18:54
ところがどっこい
データとメソッドを常にひとまとめにしなければ納得がいかないオブジェクト指向基地害が設計すると・・・・・

637 :おじゃばさま:2006/08/29(火) 09:15:32
>595
サーバツールの話でいいんだよな。馬鹿みたいな工数かけてJavaで作る?
なんでJavaで1つ作るのと、各OS用に複数作るのとで、1つ作る方が「馬鹿みたいに工数かかる」のか?
Javaで作る方は素人で、各OSの方は熟練者なのかな?同じ熟練者で考えてくれよ。
595がJava知らないから、上手く作れないってだけじゃないか?

あとサーバツールの操作マニュアルなんて基本的に初心者に書かせるようなものだから、
そんな所にスキルの高い者を使う事を想定してはだめだろう。


638 :仕様書無しさん:2006/08/29(火) 09:28:43
Javaはバージョン毎に調整・テストしなきゃいけないから1つで済むとは限らん。
Java以外ならマルチプラットフォームGUIライブラリを使うんだから各OS用に作る必要無し。


639 :仕様書無しさん:2006/08/29(火) 19:35:19
>>638
そういうものがあると実際使えるは全然違うぞ
ちゃんと働いてからもの言おうな

640 :仕様書無しさん:2006/08/29(火) 20:44:51
プロパにJMeter使えといわれたよ。。。。

マジで鬱・・・orz

641 :仕様書無しさん:2006/08/29(火) 21:25:42
鬱の原因は何よ?

642 :仕様書無しさん:2006/08/29(火) 22:21:29
サーバもJMeterも同じノート(128MB)で試せといわれたに違いない

643 :仕様書無しさん:2006/08/30(水) 00:33:10
例えば彼女からの別れの電話がかかってきたとき
JMeterでテストをしていてトラウマになったというのはどうか

644 :仕様書無しさん:2006/08/30(水) 00:43:02
「オレのぶっといテスト計画でお前のウブなサーバを溢れさせてやるぜ」
みたいなセクハラ発言かな?


645 :仕様書無しさん:2006/08/30(水) 09:00:55
>>639
> >>638
> そういうものがあると実際使えるは全然違うぞ
> ちゃんと働いてからもの言おうな
C++/wxWidgets製の製品をリリースしてますが?
パフォーマンスも良いし、OSネイティブなGUIになるため親和性が高い。
ソースファイルも一つで済むから一度書けばどこでも動く。
Java/Swing版もあったがOS毎に挙動が違って使い物にならず配布中止。
元々異なるものを一つに統一しようなんて所詮無理なんだと思った。

646 :おじゃばさま:2006/08/30(水) 20:43:48
>645
ほう、なかなか良さそうだな。時間が出来た時に試してみるか。
ところで「Solaris64ビット版」と「HP-UX」でもちゃんと動くか?
最近Solaris見捨てられたのか、まともに動かないのが多いんだよな。
特にSunStudio11のC++とか使ったりすると。そこが気がかりだ。

647 :仕様書無しさん:2006/08/30(水) 21:24:57
>>646
C++のコードくらいviで書けよ。

648 :仕様書無しさん:2006/08/30(水) 21:39:12
>>647
あからさまに寒すぎて既に痛いよ
もっと上手にぼけろ

649 :仕様書無しさん:2006/08/30(水) 21:41:18
>>647は素ですw

650 :仕様書無しさん:2006/08/30(水) 23:43:34
大学の演習でviでC言語組まされてるんだけど
実際現場でもviなの?教授が言うにはviで組むと超速く書けるらしいが・・・

651 :仕様書無しさん:2006/08/30(水) 23:48:50
>>650
Unix上でviな
viだけではまだだめ

652 :仕様書無しさん:2006/08/30(水) 23:52:27
別に超速くかけても出来上がるソースはバグって無いかはわかりません
マウスカチカチ野郎やコピペでご丁寧にぺちぺちぺちぺち様とかだったら
ちんでくださいとぶん殴れる許可がもらえる程度(まじ見てるといらついてくるから)

653 :650:2006/08/30(水) 23:55:43
>>652
自分そのスタイルなんですが・・・CTRL+X,C,Vは一応使ってる
さてどうしませう

654 :仕様書無しさん:2006/08/30(水) 23:57:22
ネットワーク管理者ならviでokだが、PGならemacsを使えないとね。

655 :仕様書無しさん:2006/08/30(水) 23:59:58
プッ

656 :仕様書無しさん:2006/08/31(木) 00:06:27
>>655
ペッ

657 :仕様書無しさん:2006/08/31(木) 00:06:51
おれemacsはおわらせかたしかしらねw

658 :仕様書無しさん:2006/08/31(木) 00:08:51
それでいい

659 :仕様書無しさん:2006/08/31(木) 00:17:17
ESC-x help-with-tutorialでおじさんと勉強しよう

660 :仕様書無しさん:2006/08/31(木) 00:19:21
それなら人差し指だけタイピングでな

661 :仕様書無しさん:2006/08/31(木) 00:22:15
わるいけどおれこゆびないんだ・・・

662 :仕様書無しさん:2006/08/31(木) 10:16:50
人差し指だけあればいい

663 :仕様書無しさん:2006/08/31(木) 12:06:09
.NETが日本で最も普及しているプログラム言語
http://pc8.2ch.net/test/read.cgi/tech/1156986942/

664 :仕様書無しさん:2006/08/31(木) 18:42:17
クソスレ立てんな

665 :おじゃばさま:2006/09/01(金) 20:56:13
ところでC#のIDEって別に早くないよな。
Eclipseと変わらない気がするが。

666 :仕様書無しさん:2006/09/01(金) 21:31:10
変わるよw
・リークしない
・不振な挙動しない
・糞プラグインが無用

667 :仕様書無しさん:2006/09/01(金) 22:37:25
滅びゆくローマ帝国、それはマイクロソフト
http://pc8.2ch.net/test/read.cgi/prog/1157114477/

668 :おじゃばさま:2006/09/04(月) 09:06:30
>666
逆に言うと、スピードは変わらんって事か?


669 :仕様書無しさん:2006/09/04(月) 11:39:48
Javaより遅いものはこの世に存在しません

670 :仕様書無しさん:2006/09/04(月) 13:06:32
>>669
ポケコンのBASIC

671 :仕様書無しさん:2006/09/04(月) 22:56:08
swingは目にもとまらない速さなんだぞ!!!!!!!!!!

672 :仕様書無しさん:2006/09/04(月) 23:00:06
>>671
GUI失格ですな

673 :仕様書無しさん:2006/09/04(月) 23:03:06
なんだとおらswingをなめんじゃえーよ
javaの最高峰なんだぞ!!!!

674 :仕様書無しさん:2006/09/04(月) 23:07:00
javaの最高峰w

675 :仕様書無しさん:2006/09/04(月) 23:12:07
韓国で最強、とかそんなものか?

676 :仕様書無しさん:2006/09/04(月) 23:32:23
>>672不覚にもワロタ

677 :仕様書無しさん:2006/09/05(火) 01:20:59
駄目だ・・・社長がJava(アプレット)でやる気だ・・・

組むのは俺なのに。。。 orz...

678 :仕様書無しさん:2006/09/05(火) 01:53:15
カワイソス

679 :仕様書無しさん:2006/09/05(火) 06:29:14
>>677
そういうときこそくそ重いプロトタイプを作って計画を変更させれ

680 :仕様書無しさん:2006/09/05(火) 06:57:51
なぜに今時アプレット?

681 :仕様書無しさん:2006/09/05(火) 07:11:52
アプレットってあったなぁそういえば

682 :仕様書無しさん:2006/09/05(火) 07:16:16
10年くらい前だったっけ?
もう忘却の彼方だ。

683 :仕様書無しさん:2006/09/05(火) 12:31:37
今ならJavaプラグインでSwing使ってもそこそこ使えるかも

未だ証券会社のチャート描画AppletでもMS Javaで間に合ってるけど

684 :おじゃばさま:2006/09/05(火) 20:05:42
マシンが早くなったせいか、社内システムやサーバ設定ツールではアプレットが復活して来てるよ。
WEBのクライアント側では、FlashやAjaxになってるけどな。

ところでC#はどうなってんだ?C#よりむしろC++の方が話があるんだが。


685 :仕様書無しさん:2006/09/05(火) 20:08:36
C#はテスト用のテキトーツールとかを作るのにめちゃ便利。

686 :677:2006/09/05(火) 21:19:41
DB鯖との通信をやると(アプレかアプリか)
PHPじゃ駄目なのかと聞いたらタグやらのパケ量が勿体無いと。
まず何のためにやるのか言ってくれよ。。。

687 :仕様書無しさん:2006/09/05(火) 21:47:13
設定ツールのGUI部分をそこまで作り込む意味はあるのか?
HTML吐くCGIでも事足りると思うが

688 :仕様書無しさん:2006/09/06(水) 12:51:52
>>687
サーバ側の負荷の問題もあるんじゃね?

689 :仕様書無しさん:2006/09/06(水) 18:00:15
>>670
あんがいポケコンBASICのほうが速いかもしれんぞw

690 :おじゃばさま:2006/09/06(水) 20:22:58
>687
測定ツールだとリアルタイム表示とか、グラフ表示とかあるのがあるからな。

691 :仕様書無しさん:2006/09/07(木) 02:55:41
ハードの成長が停滞してきたのに、まだまだ遅いJavaに未来はあるのかと
不安になる今日このごろ。

692 :仕様書無しさん:2006/09/07(木) 09:17:14
簡単なプログラムのベンチマークは素晴らしい成績なんだけどね。
ある程度の規模になるとズタボロになるよね。

693 :仕様書無しさん:2006/09/07(木) 10:29:57
簡単なプログラムのベンチマークは、
C使ったほうがほぼ最高のパフォーマンス出せるだろ

694 :仕様書無しさん:2006/09/07(木) 10:33:55
>>686
PHPでソケット通信書けばいいんじゃね?
つ[http://search.net-newbie.com/php/ref.sockets.html]

695 :仕様書無しさん:2006/09/07(木) 12:08:16
アプレットは1.4の関数使ったりしたら動かない、とか言われたりして面倒。
MSが載せるのやめた時点で、使えない代物になってしまった。

696 :仕様書無しさん:2006/09/07(木) 12:41:59

iアプリのiMona(タグ無し+gzip圧縮でパケ代助かってる)しか使ってないが
iMonaの鯖側ってperl(cgi)だし、直にソケット使わなくてもいいかも


697 :677:2006/09/08(金) 00:11:10
>>694
2週間ぐらい前にやったよ >PHPでソケット
403認証を済ませるのに

けど、受けはJavaアプレットだと思う
HTMLを吐く時点でコード増えるから

698 :仕様書無しさん:2006/09/08(金) 00:30:11
PHPとJpGraphでほぼ問題なし

699 :おじゃばさま:2006/09/08(金) 19:45:02
JavaはEJBやSOAP、XMLやO/Rマッピングでわざと遅くしているんだから、
本気で組めばWEBサイトになら問題ない程度には早く出来るよ。

700 :仕様書無しさん:2006/09/08(金) 19:49:56
JavaはVMでわざと遅くしてるんだから
本気で組んでもやっぱり遅いと思うよ

701 :仕様書無しさん:2006/09/09(土) 10:05:07
>>699
JavaだとどうしてもApache前提になるぞ。
まあ小中規模ならゲーム鯖でも問題なく動くが。

702 :仕様書無しさん:2006/09/09(土) 20:20:52
>>700
決してわざとじゃねーだろw

703 :仕様書無しさん:2006/09/10(日) 00:00:31
F1 の速度測定のシステムはアプレットで出来てるらしいな。

704 :おじゃばさま:2006/09/13(水) 20:12:15
VC++のSTLってみんな使ってるか?
基本的な質問なんだけど、文字列はstring使ってる?char[]使ってる?

705 :仕様書無しさん:2006/09/13(水) 21:29:49
>>704
使っている。
まあstringとvector位。
テンプレートはC++の参考書みながら1回だけ。
charは普通に使う。

ああ、質問の意味はnew charの方だと思うんだが、
普通は使わないめんどい。
MFCで組むとnewなんてものは基本的に使わんですむ。

個人的にVC限定ならATLで一から組んだ事あるの?
の方が刺激的だと思う。
ちなみに自分は無いです。

706 :69式オサンクローン ◆4E1yVnBRhg :2006/09/14(木) 00:08:23
あるぞ

707 :仕様書無しさん:2006/09/14(木) 08:34:58
山手線を歩いて一周するみたいなもんだな

708 :仕様書無しさん:2006/09/14(木) 23:14:44
>>705
メソッドからオブジェクトをcreateするときどうすんの?
newなしじゃデストラクタが動くと思うんだけど

709 :仕様書無しさん:2006/09/15(金) 03:45:06
Javaなんて同時アクセスが3人ぐらいまでのシステムしか組めないだろwwww
mixiもperlらしいね

710 :仕様書無しさん:2006/09/15(金) 08:23:47
>>708
静的変数。
基底のクラスで宣言。
ユーザーインターフェーススレッドで宣言。
関数内で使い捨て。

無論無駄が多いけどね。



711 :おじゃばさま:2006/09/15(金) 23:49:37
>705
JavaのプログラムをそのままC++に移植したら、どのぐらい早くなるのか見ようかと思っているのだが、
C++のstringってnewしたらdeleteしなきゃならないのかな?




712 :仕様書無しさん:2006/09/15(金) 23:56:24
>>711
newはデストラクタのきっかけをdeleteに委譲すると考えればOK

713 :仕様書無しさん:2006/09/15(金) 23:58:23
>>711
newしたらdeleteしなきゃならんし、
newしなければdeleteする必要はない。

714 :仕様書無しさん:2006/09/16(土) 00:46:33
最近の C++ は new はしても、自分で delete する機会はほとんどないだろ。
標準ライブラリや boost のスマポもあるし。

715 :677:2006/09/17(日) 01:32:49
コンストラクタを書いた後にデストラクタを書くのは普通じゃないのか

716 :仕様書無しさん:2006/09/17(日) 03:22:26
なんというソフト・・・
起動させるだけでイライラしてしまった
このソフトの言語は間違いなくJava

   / ̄\
  | ^o^ |
   \_/

717 :仕様書無しさん:2006/09/17(日) 06:05:32
Java重すぎるうえに規格がいろいろだめだね。
これからは.NET。C#万歳。

718 :仕様書無しさん:2006/09/17(日) 14:51:33
>>645
C++/wxWidgetsで
> バージョン毎に調整・テスト
が必要ない理由がわからん。スタティックリンクだからとか言う話?

> ソースファイルも一つで済むから
コンパイラとバイナリはターゲットごとに必要だよな。
ネイティブAPI使えばできるのに、っていうようなことは結局ifdefになるし
wxWidgetの機能だけでやろうとすると全OSで共通化されてる部分しか使えない。

> OS毎に挙動が違って
これはwxWidgets使ってても変わらなくね?



719 :仕様書無しさん:2006/09/17(日) 16:44:49
>>704
CString

720 :仕様書無しさん:2006/09/19(火) 09:00:12
>>718
御託を並べる前に一回使ってみて。マジで考え方変わると思うよ。

721 :おじゃばさま:2006/09/19(火) 11:21:44
じゃstringでもnewしたらdeleteしなきゃならないのか。
それだとJavaソースをそのまま移植は無理だな。
C++の説明にスコープを抜けると自動的に解放されるような事が書いてあるが、どうなんだ?
フィールド変数のnewしたstringだけは、deleteしなきゃならならないって事じゃないのか?

722 :仕様書無しさん:2006/09/19(火) 12:33:50
移植したいJavaソースを抜粋して晒したら C++ の達人が教えてくれるかも

723 :仕様書無しさん:2006/09/19(火) 17:12:57
>>721
それは自動変数でオブジェクトを宣言したときだ
値型ってやつだっけ?
ー>じゃなくて.でアクセスする


724 :仕様書無しさん:2006/09/20(水) 00:35:35
つ スマートポインタ。

つーかどういう経緯でstringをnewするの?
普通に宣言して突っ込めば勝手に拡張するし、
後始末もしてくれるだけど。

725 :仕様書無しさん:2006/09/20(水) 01:08:56
つ コピーコンストラクタ

string hoge()
{
string str = "hogehoge";
return str;
}

newなんてつかわんでもいいの


726 :仕様書無しさん:2006/09/20(水) 10:28:06
今までC++を知らずに叩いていたのが露呈した

727 :仕様書無しさん:2006/09/20(水) 23:24:04
>>725
こんなことしてるからJavaより遅くなるんだよ
そういやC++も最近はGCライブラリ使ってるとこあるしな
D言語のとこの会社も使ってたし

728 :仕様書無しさん:2006/09/21(木) 01:37:32
>>727
Javaが早いって冗談ですか?

729 :仕様書無しさん:2006/09/21(木) 02:35:56
>>727
何言ってんだお前は


730 :仕様書無しさん:2006/09/21(木) 03:12:04
コピコン使ってても速いとか思ってるほうが異常
単に無知なだけか

731 :仕様書無しさん:2006/09/21(木) 04:29:15
>>727
日本語でおk

732 :仕様書無しさん:2006/09/21(木) 10:17:26
>>730
Effective C++でも読め

733 :仕様書無しさん:2006/09/21(木) 22:40:15
そいつには無理

734 :仕様書無しさん:2006/09/22(金) 00:13:11
JavaだけじゃなくC++すら知らないのか。
コピコン使ってたらどう足掻いてもJavaより早くならねーよ。

735 :仕様書無しさん:2006/09/22(金) 02:19:46
サンプル書いて比較してみればいいのに

736 :仕様書無しさん:2006/09/22(金) 16:07:33
コピーコンストラクタでひとくくりにするよーなやつがC++を語るのか?


737 :仕様書無しさん:2006/09/22(金) 19:56:45
そうです

738 :仕様書無しさん:2006/09/22(金) 20:16:45
>>725のコードにかばう余地なんてないだろ

739 :仕様書無しさん:2006/09/22(金) 20:58:26
では見本をお願い

740 :仕様書無しさん:2006/09/22(金) 21:09:46
まんまだろ、どこまで馬鹿なんだ

741 :仕様書無しさん:2006/09/23(土) 17:09:02
では次のネタをお願い

742 :仕様書無しさん:2006/09/23(土) 20:12:20
んーとねぇ、じゃあ何故 727, 730, 738, 740 は何故こんなにも阿呆なのか?

743 :仕様書無しさん:2006/09/23(土) 20:17:08
>>742が馬鹿だからだね。

はい次。

744 :仕様書無しさん:2006/09/23(土) 20:22:43
>>743は利口なの?

745 :仕様書無しさん:2006/09/23(土) 21:14:09
きっと>>725のコードは最適化前提なんだよ

746 :仕様書無しさん:2006/09/23(土) 21:19:26
ちがうよおまいらに問題を出したんだよ

747 :仕様書無しさん:2006/09/23(土) 21:39:13
Java 使いが C++ の RVO を知らなくてもまあしょうがないだろうけど、
735 や 739 が実測してみろと助言しているのにそれを無視して >>740
のようなレスを返すこいつはプログラマには向いていないとおもわれ。

748 :仕様書無しさん:2006/09/23(土) 21:48:58
馬鹿どもが
も前らまとめてビジネスロジックやってろ!!

749 :仕様書無しさん:2006/09/23(土) 21:54:44
と、ビジネスロジックという単語にコンプレックスを持つ 748 が吠えてます。

750 :仕様書無しさん:2006/09/23(土) 21:55:58
大規模開発

751 :仕様書無しさん:2006/09/23(土) 21:59:09
ポーリングするマルチスレッド

752 :仕様書無しさん:2006/09/23(土) 22:00:09
リークしてクラスを読み込まないテスト環境

753 :仕様書無しさん:2006/09/23(土) 22:20:34
>>747
助言ってのは参考なって始めて助言なんだぜ

754 :仕様書無しさん:2006/09/23(土) 22:34:09
>>753
助言を求めてもな理解できない奴は理解できないんだよな。
答えが目の前にあっても理解でき無い奴は珍しくない。

755 :仕様書無しさん:2006/09/23(土) 22:59:28
>>725じゃないが計測してみたらJavaの圧勝だった

マシンが古いんで申し訳ないが、比較したコンパイラ
Java: 1.4.1_01
C++: g++ 3.1

文字列生成を10万回繰り返し、その処理時間をmsで表示
bash> ./a.out
222
162
bash> ./a.out
165
165
bash> ./a.out
166
170
bash> java w
8
42
bash> java w
8
40
bash> java w
8
41



756 :755:2006/09/23(土) 23:02:08
C++のソース

bash> cat w.cpp
#include <iostream>
#include <string>

unsigned long long gettime() {
struct timeval t;
gettimeofday(&t,NULL);
return (unsigned long long)t.tv_sec * 1000000 + t.tv_usec;
}

using namespace std;
int main(int argc, char *argv[]) {
unsigned long long s, e;
s = gettime();
for (int i = 1; i < 100000; i++) string s1 = "HELLO";
e = gettime();
cout << (e - s) / 1000 << endl;

s = gettime();
for (int i = 1; i < 100000; i++) string s2("HELLO");
e = gettime();
cout << (e - s) / 1000 << endl;

return 0;
}


757 :755:2006/09/23(土) 23:03:42
Javaのソース

bash> cat w.java

public class w {
public static void main(String[] args) {
long s, e;
String s1, s2;
s = System.currentTimeMillis();
for (int i = 0; i< 100000; i++) s1 = "HELLO";
e = System.currentTimeMillis();
System.out.println(e - s);

s = System.currentTimeMillis();
for (int i = 0; i< 100000; i++) s2 = new String("HELLO");
e = System.currentTimeMillis();
System.out.println(e - s);
}
}


758 :仕様書無しさん:2006/09/23(土) 23:11:32
VC++2005 Express
諸設定:Releaseモード
測定結果:26624663回

class GetString {
string str;
public:
GetString() { str = "oisu-"; };
string Get() { return str; };
};


int _tmain(int argc, _TCHAR* argv[])
{
GetString getter;
long count = 0;
clock_t limit = clock() + 5000;
while (limit > clock()) {
string local = getter.Get();
count++;
}
_tprintf(_T("%d"), count);
Sleep(5000);
return 0;
}

759 :仕様書無しさん:2006/09/23(土) 23:12:12
Sun JDK1.5.0_06
実行オプション:(サーバーVMを使い実行前にコンパイル)
-server -Xms10m -Xmx10m -XX:+UseCompilerSafepoints -XX:+UseOnStackReplacement
結果:54769719回

static class GetString {
private String str;
public GetString() {
str = "oisu-";
}
public String get() {
return str;
}
}

public static void main(String[] args) {
GetString getter = new GetString();
long count = 0;
long limit = System.currentTimeMillis() + 5000;
while (limit > System.currentTimeMillis()) {
String local = getter.get();
count++;
}
System.out.println(count);
}

760 :仕様書無しさん:2006/09/23(土) 23:14:33
配列コピー対参照渡しなんだから
ベンチマークしてみろって言ってる時点でプログラマじゃないよな

761 :仕様書無しさん:2006/09/23(土) 23:19:08
734 名前:仕様書無しさん [↓] :2006/09/22(金) 00:13:11
JavaだけじゃなくC++すら知らないのか。
コピコン使ってたらどう足掻いてもJavaより早くならねーよ。

ここで思いっきり説明されてるのに・・・

762 :仕様書無しさん:2006/09/23(土) 23:19:21
VC++ 2005ってRVOサポートしてるだろ
でも生成時点で差がついてちゃ意味ないね

763 :仕様書無しさん:2006/09/23(土) 23:27:19
これだけ差があるとコピコン以前の問題だな
C++捨ててもいいですか

764 :仕様書無しさん:2006/09/23(土) 23:31:53
速い作り方すりゃ速いんだから捨てる必要は無いだろ。
単にこのスレのお客様が最近のC++屋もGC使ってるって事実を知らないだけ。

765 :仕様書無しさん:2006/09/24(日) 00:13:42
実行オプションまったくつけなくても差はないな
クライアントVMも最近は優秀らしい

766 :仕様書無しさん:2006/09/24(日) 00:23:05
725でも755でもないけど。756を(配列コピーじゃなくて)std::stringのコピーコンストラクタを使うように修正した。

#include <sys/time.h> // 足した
#include <iostream>
#include <string>
unsigned long long gettime() {
struct timeval t;
gettimeofday(&t,NULL);
return (unsigned long long)t.tv_sec * 1000000 + t.tv_usec;
}
using namespace std;
int main(int argc, char *argv[]) {
const string HELLO = "HELLO"; // 足した
unsigned long long s, e;
s = gettime();
for (int i = 1; i < 100000; i++) string s1 = HELLO; // 変更した
e = gettime();
cout << (e - s) / 1000 << endl;

s = gettime();
for (int i = 1; i < 100000; i++) string s2(HELLO); // 変更した
e = gettime();
cout << (e - s) / 1000 << endl;

return 0;
}


767 :766:2006/09/24(日) 00:23:37
MingW32でコンパイルして実行したら計測不能だった
$ a.exe
40
40

ついでにjavaのやつも測ったけど
C:\temp>java -cp . w
0
20


768 :仕様書無しさん:2006/09/24(日) 00:25:09
Java版
static DecimalFormat df = new DecimalFormat("0000000000");

public String method(int index) {
String retval = new String(df.format(index));
return retval;
}

C++版
string method(int index)
{
char buff[16];
sprintf(buff, "%010d", index);
string retval = buff;
return retval;
}

固定文字列でなく毎回違う文字列を返すように
整数値をフォーマットして返すのをやってみた。
環境によると思うがC++版のほうが2.5倍速かった。

java version "1.4.2_12" 実行時オプション無し(デフォルトで-hotspot)
gcc version 3.3.4 コンパイル時に-O2 オプション

一つのサンプルということで

769 :766:2006/09/24(日) 00:30:42
ごめん。環境書き忘れた。

$ gcc --version
gcc.exe (GCC) 3.4.2 (mingw-special)
コンパイルオプションなし

C:\temp>java -version
java version "1.5.0_08"
コンパイルオプション-O

ついでに言うと、Java版は2回目以降は、ちょっとだけ速くなった
C:\temp>java -cp . w
10
10

770 :仕様書無しさん:2006/09/24(日) 00:33:50
どうでもいいけどそれってsprintfとDecimalFormatのベンチでは?

771 :仕様書無しさん:2006/09/24(日) 00:53:18
doubleの計算を再帰でやるベンチをたのむ

772 :仕様書無しさん:2006/09/24(日) 00:53:59
Javaは高速なはずなのにJavaでつくられたアプリを動かすと糞重たいのは何故なんだぜ?

773 :仕様書無しさん:2006/09/24(日) 00:56:28
Javaは長い時間をかけてコンパイルをするためです。
環境情報とコードの使われ方を計測して最適化するためサーバ用途に偏ります。
別に俺の使ってるJavaアプリは重くないんだけどね。

774 :仕様書無しさん:2006/09/24(日) 01:05:14
その用途ではC++のクラス使わないでCで書けばいいんじゃね?
オブジェクト指向使う必要ない規模だろ?

と思ってしまう実用一辺倒な俺。

775 :仕様書無しさん:2006/09/24(日) 01:07:31
>>774
何の話?

776 :仕様書無しさん:2006/09/24(日) 01:18:51
>>771か。まあC++いらんわな。

777 :仕様書無しさん:2006/09/24(日) 01:30:20
C++はCのみで書くという芸当はできるがJavaではどうあがいても代替案はないな

778 :仕様書無しさん:2006/09/24(日) 01:33:07
まあC#でもいんじゃね。HP-UXとか使うから俺はJavaをやめられんけど。

779 :仕様書無しさん:2006/09/24(日) 06:20:02
>>777
Javaにはstaticメソッドだけで書くという技もあるな
もはやオブジェクト指向じゃないが

780 :仕様書無しさん:2006/09/24(日) 08:25:16
普通に整数の再帰演算(フィナボッチ数の算出)をやらせてみたが
Javaの方が速いってのはコンパイラの違いか

C++
279 277 279
Java
105 111 102

C++コード(以下のコードをfb(30)で呼び出す)
int fb(int i) {
if(i < 2) {
return 1;
} else {
return fb(i - 2) + fb(i - 1);
}
}

Javaコード(以下のコードをfb(30)で呼び出す)
public static int fb(int i) {
if(i < 2) {
return 1;
} else {
return fb(i - 2) + fb(i - 1);
}
}



781 :仕様書無しさん:2006/09/24(日) 10:41:31
>>780
C++の書き方というか最適化の方法知らない無知なんだな。
おもしれーよ。

学生ならJAVAメインの企業で生涯終わらせるべき、C++やCには絶対近づかないほうがいい。
PGかSEならJAVAだけの案件やる以前の問題だから市ぬか、中国にでも消えろ

782 :仕様書無しさん:2006/09/24(日) 11:04:13
>>781
そこまでいうなら>>780を最適化してくれよ

783 :仕様書無しさん:2006/09/24(日) 11:26:32
何にせよ、ソースだけじゃなく、とりあえず、コンパイルオプションくらいは
書いてほしいけどな。デフォルト生成コードで比較したいってことなのかもし
れんけど。

784 :仕様書無しさん:2006/09/24(日) 11:34:32
なんかC++厨が必死になってるスレですね

785 :仕様書無しさん:2006/09/24(日) 11:43:28
>>782
じゃあルール決めろよ何使ってもいいか不明だし
出したら出したでそれは違うからダメとか言うんだろ?お前らのその手には
釣られねーよボケwwww

longに変更してfb(45)計算してみろよめちゃくちゃおせーだろ?
でもな俺の書くたいしたことの無いC++ならfb(30)もfb(45)もほぼ等速で終わるぞ

786 :仕様書無しさん:2006/09/24(日) 11:49:06
これが脳内ベンチと言うヤツですかw

787 :仕様書無しさん:2006/09/24(日) 12:09:44
まずは>>785に「fb(30)もfb(45)もほぼ等速で終わる」C++ソースをさらしてもらって
それをもとにベンチを考えたらどうだろ?

788 :仕様書無しさん:2006/09/24(日) 13:06:07
プログラマってアグレッシブですね

789 :仕様書無しさん:2006/09/24(日) 13:11:33
実業務のコードとかけ離れたコードを何万回とか実行するベンチなんかやって意味があるのか?
科学技術計算ならFORTRANでもつかっとけ。

790 :仕様書無しさん:2006/09/24(日) 13:20:03
ベンチといえばモモベンチだ。
それ以外は認めない。

791 :仕様書無しさん:2006/09/24(日) 14:16:52
人生のベンチマークをするにこのスレでぎゃあぎゃあ騒ぐことが無駄だと判明した。

792 :仕様書無しさん:2006/09/24(日) 14:41:01
template<long n> class fb
{
public:
enum
{
result = factorial<n - 2>::result + factorial<n - 1>::result
};
};
template<> class fb<2>
{
public:
enum { result = 1 };
};
template<> class fb<1>
{
public:
enum { result = 1 };
};

int main()
{
std::cout << fb<45>::result << std::endl;
return 0;
}

793 :仕様書無しさん:2006/09/24(日) 14:50:01
コンパイルする時計算終わってるから意味ねーだろって
答えになるぐらいの糞の話しだから次の話題にいくべ

794 :仕様書無しさん:2006/09/24(日) 15:24:00
>>792
コピペ乙
だがfactorialをfbに直し忘れてるよ
たしかにこれじゃベンチにはならんわな

795 :仕様書無しさん:2006/09/24(日) 16:42:16
・Java厨はC++のコンパイル時コード生成を知らない。
・オブジェクト指向じゃないコードにすれば書けばJavaも速い。
でFA?

796 :仕様書無しさん:2006/09/24(日) 17:10:25
便利っちゃ便利だが定数しか渡せないようじゃあまり使い道なさそう
ちょっと複雑な定数計算に使うくらいだな

797 :仕様書無しさん:2006/09/24(日) 17:17:42
このスレって煽ってる奴よりJava厨のがレベル高くて悲しくなるな

798 :仕様書無しさん:2006/09/24(日) 18:15:58
>>796
C++ のテンプレートは理論上チューリング完全な言語内言語だ。
Java の Generics とは違うのだよ。

>>797
そう感じられるのはお前がJava厨のレベルにも達していないからさ。

799 :仕様書無しさん:2006/09/24(日) 18:39:06
>>798
チューリング完全な言語内言語かぁ
でもコンパイル時コード生成ってことは定数しか渡せないわけだろ


800 :仕様書無しさん:2006/09/24(日) 18:46:03
>>798
定数以外渡したくてJavaの方が早い事例を
出せよ話はそれからだ

801 :仕様書無しさん:2006/09/24(日) 18:50:45
>>797
実際さんざん煽ってソース出されてダンマリってのを
何度もこのスレで繰り返してるからな

802 :仕様書無しさん:2006/09/24(日) 19:02:03
なんだなんだ、不毛な議論はやめなよ。
ジャバは糞だよ。
ある定常負荷を超えた点から、マルチスレッドのコンテキストスイッチが
遅延しだす。それから後は寝ぼけたような動作に入り、再起動。

コンパクトなコードはメモリにキャッシュされて扱われるから
時としてC/C++より速いスペックを出すようがだ、それなりのサイズ
になったらクラスを読み込むだけで明日になるぐらい遅くなる。

803 :仕様書無しさん:2006/09/24(日) 19:04:26
ちょっとしたサンプルレベルだといいんだけど、本格的に使い出すと破綻するんだよね。

804 :仕様書無しさん:2006/09/24(日) 19:15:57
JAVA坊お前たちはサンプルレベルでしか話ができないのか?
それとも、あれか何億回も実行するような極端な例しか出せないのか?



805 :仕様書無しさん:2006/09/24(日) 19:19:14
>コンパクトなコードはメモリにキャッシュされて扱われるから

だったらC/C++ももっと速くなるのでは?

定常負荷が具体的にナニをさすのか知らんけど、
メモリが足りない場合は…、とか言うなら微妙な感じだが。

まあ、漏れも最初から負荷が高いと解っている処理は
Javaではやらんけどサ。

806 :仕様書無しさん:2006/09/24(日) 19:25:16
喫煙者の吐いた息を毎日吸い込んでるとかなり体に悪いらしいよ。
会社とかで向かい側や両隣に座ってる人達は要注意だって。
子供も学校の先生が喫煙者の場合は、前の方に座ってるとやばいんだって。

807 :仕様書無しさん:2006/09/24(日) 19:40:37
吸ってない人の隣に吸う人がいて肺が吸ってる人になってる人居たな

808 :仕様書無しさん:2006/09/24(日) 19:42:35
>>806
じゃあ無人島にでも行って健康に暮らせ。
誰も止めない。

809 :仕様書無しさん:2006/09/24(日) 19:46:37
つーかたばこなんか吸ってるやつってアホだろ?

810 :仕様書無しさん:2006/09/24(日) 20:00:57
Javaのスレッドってさー

811 :仕様書無しさん:2006/09/25(月) 00:28:47
実行速度だけで言えばC++よりJavaの方が速かったっちゅーレポートあったよね?
メモリはJavaの方が2倍喰ってたけど。
これをどう評価する?限られたハード資源を前提にすればダメだけど、
「メモリ?足りなきゃ足せよ」みたいな状況を前提にすれば"あり"だし…。

812 :仕様書無しさん:2006/09/25(月) 00:32:31
早く作れて実行速度も遅くない。ただしメモリは犠牲になる。
それがJavaのこれまでの、そしてこれからも続く特徴だろ。
業務サーバーでJavaの需要が減らないのは、
実際に先に悲鳴を上げるのはいつもDBだからだしね。

813 :仕様書無しさん:2006/09/25(月) 00:33:13
だからさ、C++のSTLは標準ライブラリよりも70%程度の
パフォーマンスしかでないのよ。プログラミング作法 Brain W.Kernighan
読め。予想だけど、JVMは巨大マッピングメモリ上でmem系の関数で
データ処理してるんじゃないのかな。だからANSI Cで同等の処理をすれば
それよりは絶対速いはずだろ。

814 :仕様書無しさん:2006/09/25(月) 06:28:47
えー。メモリ2倍も喰うの?
せっかく計算が速くても、キャッシュミスが頻発するような気が。
まー、サーバーみたく、贅沢なバンド幅を使えるなら問題ないかもしれないけど。

815 :仕様書無しさん:2006/09/25(月) 06:32:59
ねーなんで>>811-813のような思い込みだけで書いた文章信じるの?
ベンチとればいいじゃん

816 :仕様書無しさん:2006/09/25(月) 08:12:07
上の方でstring系の処理で固定文字列を違う文字列にしたら、
C++の方が早くなったろ?最近のstring系は同じ文字列は
同じメモリ領域を参照するようにしている場合がある。

つまり、全然メモリ確保しない状態でやってた可能性があると
思うんだが。

そもそも単純な数値計算じゃ、Javaの方が早いケースもあるって前の
スレで結果出ていると思うんだが。で、少しでもややこしい
ファクターが入るとあっという間に速度が遅くなると。

817 :仕様書無しさん:2006/09/25(月) 08:52:36
>>816
ちょっとまて、Javaのコードの方ももそうじゃないのか?

for (int i = 0; i< 100000; i++) s1 = "HELLO";
"HELLO"という内容の文字列オブジェクトへのポインタをs1に代入。

for (int i = 0; i< 100000; i++) s2 = new String("HELLO");
"HELLO"という内容の文字列オブジェクトを引数にしてコピーコンストラクタを実行し、そのポインタをs2へ代入。

つまり、Javaのコードの方も、配列を確保する必要なんかないはず。


818 :仕様書無しさん:2006/09/25(月) 13:34:20
>>780
CPUが実行するコード貼ってみたら? Javaじゃ難しいのかね?
おなじCPU同士ならどっちがなぜ速いのか、あるいは遅いのか
一発で理由が分ろうが。

819 :仕様書無しさん:2006/09/25(月) 22:19:43
Javaがメモリ倍食うとか言いながらも携帯アプリって
Javaが多いらしいけどなんか矛盾してね?

820 :仕様書無しさん:2006/09/25(月) 22:28:03
>>819
PCのJavaと携帯のJavaは別物だよ

821 :仕様書無しさん:2006/09/25(月) 22:54:38
別物っていうほど言われるシロモノでもないと思う

822 :仕様書無しさん:2006/09/25(月) 23:02:37
誰かJavaでJavaVM書いて、その上で同じバイトコード走らせて比べればいいんじゃね?

823 :仕様書無しさん:2006/09/26(火) 08:41:37
gcj はネイティブコードにコンパイルできるんだったっけ?
それと C をgcc でコンパイルしたものとを比べてみるとか。

824 :おじゃばさま:2006/09/27(水) 20:11:27
C++でCORBAやろうとしているんだが、いつものごとくコンパイルが通らない。
付属のサンプル全く手を入れず、付属のMakefileを使っているのにエラーが出る。
どういう事だ?コンパイラのバージョンか?
Net探してもレビューは見つからないし、付属のドキュメントとサンプルファイル構成が微妙に違うし。
やっぱC++は、終わってるな。

825 :仕様書無しさん:2006/09/27(水) 21:30:41
つうかCORBAが終わっているんだよ

826 :仕様書無しさん:2006/09/27(水) 21:43:51
>>824
なんでもC++のせいにするな。

827 :仕様書無しさん:2006/09/27(水) 22:18:00
>いつものごとくコンパイルが通らない

そんなのおまえだけだろうw

828 :仕様書無しさん:2006/09/27(水) 22:21:22
DQNがあっさり釣れました
http://sakura03.bbspink.com/test/read.cgi/kageki/1154013557/126n-

829 :仕様書無しさん:2006/09/27(水) 22:22:18
みんなひどいな、他人の努力は応援するもんだぞ。
頑張れの一言位言えよ。

頑張れ。


830 :仕様書無しさん:2006/09/27(水) 23:26:10
うむ。うまい焼き鳥をおごってくれれば
1H程度のプレミアム研修をしてやるぞ。

831 :仕様書無しさん:2006/09/27(水) 23:28:29
CORBAでスケルトン吐かせないでひたすらサンプル通り直打ちしてたらワロスだが。

あと、CORBAはC++Onlyのものではない。
JavaCORBAやらCOBOLCORBAやらいろんな言語に対応してる。
ってかそのための仕組みだし。

832 :仕様書無しさん:2006/09/27(水) 23:38:25
CORBAやるならWebサービス(C++)やったほうがいいと思うよ。

833 :仕様書無しさん:2006/09/27(水) 23:52:33
CORBAやるならMQのほうが絶対いいよ
I、N、MといろんなところがこれからはMQが来るって
いってるからねぇ

834 :仕様書無しさん:2006/09/27(水) 23:54:28
こーぼらーるるるるるー




こーぼらーるるるるる〜

835 :仕様書無しさん:2006/09/28(木) 00:24:47
俺の中ではMQは10年前に終わってるんだがなー。
来るっていうのは担いでるのがIだからとか、政治的な理由?

Javaしか眼中になくてWebSphereしか眼中になくてってとこの人の意見ならわからんでもない。
それでも結局Javaバブルのが続くことが前提での話なんだろうけど。

836 :仕様書無しさん:2006/09/28(木) 00:52:13
MQだめでしょう。Webサービスに負けてる。しかもWebSphereは
Webサービスクライアントをささっと簡単に作れない弱さがある。
その点MSのVS.NETに軍配が上がる。

837 :仕様書無しさん:2006/09/28(木) 00:55:14
Java周りのひどい環境
・CORBA 開発環境が最低
・MQ 既に死んだ技術。サーバサイドでの非同期処理をJavaからコントロールできない
・J2EE クラスリソースが巨大化し続ける
・スレッドパニック - JVMがマルチスレッドを多数作成し動作させている。
巨大メモリキャッシュでごまかしつつもコンテキストスイッチ切り替えなどのオーバヘッドがそろそろ飽和点


838 :仕様書無しさん:2006/09/28(木) 01:35:52
ちょいと質問なんですが・・・

サーブレットのメソッド(doPostとか)から呼ぶクラスメソッドの中でローカルなオブジェクト
をnewするのってまずいんでしたっけ? つまり、マルチスレッド環境で、下のhoge()を呼ん
でも問題ないでしょうか? それともhoge() にsynchronized つけるべき?

class A {
 static void hoge() {
  B b = new B(100);
  int x = b.getFuga();
   :
 }
}

839 :仕様書無しさん:2006/09/28(木) 02:03:20
クラスBの実装による。クラスBにstaticフィールドがなければ問題なし。
staticフィールドがあれば、それがクラスBの内部でスレッドアンセーフかチェックしろ。

840 :838:2006/09/28(木) 02:17:04
>>839
ありがとうございました。
Bにはstaticフィールド無いので大丈夫そうです。
おかげさまで先に進めます。

841 :おじゃばさま:2006/09/28(木) 20:13:30
つーかC++でSTL使って、さらにCORBAやっている人いる?
やっぱりいないのかな。

842 :仕様書無しさん:2006/09/28(木) 21:23:55
CORBAやるならあの本がいいぞ

public class Sample extend ....
...
 CORBA.ORB Orb;
 CORBA.Object Obj;

 Orb = CORBA.ORB_init(arg,"ORB ID");
...

843 :仕様書無しさん:2006/09/28(木) 21:30:17
Orb

が毛を逆立てて威嚇している猫に見えてしまう漏れ。
もうダメぽ。


844 :仕様書無しさん:2006/09/28(木) 21:49:53
なあーんかダサくてやるき無くすのがCORBA

845 :仕様書無しさん:2006/09/28(木) 22:30:31
なんで高齢童貞、アニオタ、ロリコンはネット右翼になるの?

846 :仕様書無しさん:2006/09/29(金) 01:00:01
な、何でわかった?

847 :仕様書無しさん:2006/09/29(金) 01:40:42
類友だから

848 :仕様書無しさん:2006/09/29(金) 01:42:38
思想にすがるようなのは大体からして電波で負け犬だから

849 :仕様書無しさん:2006/09/29(金) 01:49:25
いやいや思想は大事だよ
思想がないということは単なる馬鹿ってことだろ

850 :仕様書無しさん:2006/09/29(金) 01:56:47
いや、思想だけの馬鹿もいる。
実行力が伴わないと成果は出ないからな。
オレモナー

851 :仕様書無しさん:2006/09/29(金) 02:01:05
思想というか、自我だな

852 :仕様書無しさん:2006/09/29(金) 09:17:39
それをいうなら超自我だろ?

853 :仕様書無しさん:2006/09/29(金) 11:17:47
マルチプラットフォームで
コーディング楽で
超軽量で・・・・
そんな言語ねぇよ

854 :仕様書無しさん:2006/09/29(金) 11:25:31
C#.NETがあるじゃないか。

855 :仕様書無しさん:2006/09/29(金) 11:38:25
VB6は全関数、全イベント、実行環境のバグ等々全部暗記してるから個人的には最強。

C#.NETはいろいろ知恵絞ってるのはわかるけど、
全部暗記するのはきついだろ。

結果的にVB6の方がコーディングも早い。

C#って実行時はネイティブコードにコンパイルしてるって言うけど、本当かよ?


856 :おじゃばさま:2006/09/29(金) 19:42:42
awkがあるじゃないか。

857 :仕様書無しさん:2006/09/30(土) 00:51:14
>>853
Perl とか Ruby とか、スクリプト系はいい線行ってると思うが。

858 :仕様書無しさん:2006/09/30(土) 03:49:59
>C#って実行時はネイティブコードにコンパイルしてるって言うけど、本当かよ?
わりいあれうそだ。


859 :仕様書無しさん:2006/09/30(土) 16:55:21
Perlコンパイラってどうしてないの?

860 :仕様書無しさん:2006/09/30(土) 18:23:55
現状javaってどういう場面でよく使われてる?
何に強いと思う?

861 :仕様書無しさん:2006/09/30(土) 18:26:37
サーバだけでしょ、

862 :仕様書無しさん:2006/09/30(土) 18:31:26
携帯

863 :仕様書無しさん:2006/09/30(土) 19:02:25
携帯Javaってゲーム以外なんかあんのか

864 :仕様書無しさん:2006/09/30(土) 19:09:22
ゲームでも立派な商売だし

865 :仕様書無しさん:2006/09/30(土) 19:29:06
日本のソフトで世界に通用するのはゲームしかないだろ

866 :仕様書無しさん:2006/09/30(土) 19:56:47
ゲームが通用するのはシナリオ、グラフィック、音が優秀なだけ。
プログラムは典型的なドカタコード

867 :仕様書無しさん:2006/09/30(土) 20:00:45
じゃあどんなのが素晴らしいコードなんだよ

868 :仕様書無しさん:2006/09/30(土) 20:05:06
おまいにとってすばらしいコードとはグラフィックや音がすばらしいものなのか

869 :仕様書無しさん:2006/09/30(土) 20:37:14
シナリオ?
シナリオのあるゲームって何だ?

870 :仕様書無しさん:2006/09/30(土) 20:39:48
ゲームのソースって依然見たことあるけどありゃひどいな。
1メソッド数千行とかあるw

871 :仕様書無しさん:2006/09/30(土) 20:43:09
おいおいジャワでゲーム作ったひにゃ、電源いれてから
30分またないと遊べないものになっちゃうぞw

872 :仕様書無しさん:2006/09/30(土) 22:37:19
10年くらい前のパソコンの持ち主なのかな・・・

873 :仕様書無しさん:2006/09/30(土) 23:03:25
じゃないかな
携帯も持ってないみたいだしね

874 :仕様書無しさん:2006/10/01(日) 05:48:54
>>866
こやつはゲーム知らないおじさんだな

875 :仕様書無しさん:2006/10/01(日) 08:27:10
昔のゲームはハードが貧相だったから高度なテクニックも駆使してたけど、
携帯JavaのゲームはAPI呼ぶコードをフレームワークの隙間に埋めてるだけでしょ?

876 :仕様書無しさん:2006/10/01(日) 08:29:56
ゲームって開発費はかさむ一方なのに全然売れなくなったね。
ゲーム自体が終わってると思う。

877 :仕様書無しさん:2006/10/01(日) 08:50:57
まぁ20年ぐらいもった隙間産業だったてことじゃね

878 :仕様書無しさん:2006/10/01(日) 08:51:15
Javaなんか使うからだろ

879 :仕様書無しさん:2006/10/01(日) 09:28:33
ハードをギリギリまで使うのがゲームプログラミング。
普通マルチスレッド使う理由は平行動作の為だが、
ゲームの場合は計算速度上げるためという理由だからな。



880 :仕様書無しさん:2006/10/01(日) 09:35:55
>>875
と思って作るとサイズとメモリと速度が足りなくなる罠
携帯JAVAは、まずオブジェクト思考をやめることからはじまる
変数もスタティックにしてさらに使い回す
メソットを増やすと容量がかさむからまとめる
まともなコーディングなんてしたら、作れない代物だよ

881 :仕様書無しさん:2006/10/01(日) 10:11:42
携帯Javaはやったことないけど、
変数とかの使いまわしとかメソッドの辺りは普通にクラス設計の段階の話だと思うが。

まともなコーティングをナニを刺すのか知らんが、
まともにクラス設計できない人間が、泥くさいコーディング
してるのはタマに見る。

882 :仕様書無しさん:2006/10/01(日) 10:26:58
そもそもクラスなんて使わないよ

883 :仕様書無しさん:2006/10/01(日) 10:28:03
プリミティブな変数しか使わないのが鉄則

884 :仕様書無しさん:2006/10/01(日) 10:33:32
それだとc使うのと大差ないと思うが。

885 :仕様書無しさん:2006/10/01(日) 10:37:27
おいおい、java使うのはサンドボックスのためだよ

886 :仕様書無しさん:2006/10/01(日) 10:41:43
extern "C"{}とかでCのコード埋め込めるJavaとかあったら最強じゃね?

887 :仕様書無しさん:2006/10/01(日) 11:03:37
>>881
やったこと無いなら語らない方がいいぜ

888 :仕様書無しさん:2006/10/01(日) 12:45:29
携帯JavaはJavaしか選べないでしょ。
誰もあんな糞言語でやりたいとおもってないよ。
ソースも全然ooじゃないし。
そもそもそんなことしてたらメモリ足りない。処理速度追い付かない。

889 :仕様書無しさん:2006/10/01(日) 15:32:31
つまり携帯に適した言語で最高なのはマシン語(懐かしい響きだな)でFA

890 :仕様書無しさん:2006/10/01(日) 15:35:27
はいはい頭が20年前の人は大変だね

891 :仕様書無しさん:2006/10/01(日) 15:46:02
しかし、最近の携帯はファミコン以上ではあるだろw

892 :仕様書無しさん:2006/10/01(日) 17:22:43
携帯Javaのゲームなんて20年前のゲームの復刻版か焼き直しみたいな屑しかないからそれでいいんだよ。
つか、そもそもその程度しか出来ない。

893 :仕様書無しさん:2006/10/01(日) 17:56:49
PSPでナムコミュージアムばかりで遊んでいる漏れが言うのもアレだが、
ゲームに関しては昔のゲームの方が楽しいと感じるけど。

892は携帯アプリがC#ならもっと高度な事が出来るといいたいんだろうか?

894 :仕様書無しさん:2006/10/01(日) 18:02:22
どこをどう読んだらそういう解釈が湧いてくるんだろうか。

895 :仕様書無しさん:2006/10/01(日) 18:29:35
892の文書は
Javaなんてとか、昔のゲームは屑
と明確に発言してるが。

あ、894=892か。

896 :仕様書無しさん:2006/10/01(日) 22:36:11
携帯でC#が使えるとはしらなかった。

897 :仕様書無しさん:2006/10/01(日) 22:38:57
Javaだと20年前のゲームしか出来ないのね。

898 :仕様書無しさん:2006/10/02(月) 01:50:53
携帯Javaこそが>>866

899 :おじゃばさま:2006/10/02(月) 20:07:35
ゲーム開発でCのコードを書くのは全体からすると少しだけだろう。
実際にはそのゲーム開発用のツールを使って作業する訳だから、
JavaやCより、VBやフォトショップに近いんじゃないか?

ところで最近、C++でSTL使って組んでいるんだけど、これ本当にすごいのか?
どのあたりが優れているんだ?


900 :仕様書無しさん:2006/10/02(月) 22:08:38
なにを持って凄いというのかな。
比較する対象がないとすごいともへぼいとも言えない。
少なくとも対象がジャワだったら、ものすげえ良いよ。全てにおいてね。

901 :仕様書無しさん:2006/10/02(月) 23:37:47
>>899
CからC++に移行した人はまずSTLコンテナの便利さにはまるんだけど
Javaからだとむしろハッシュテーブルがまだ非標準なのかよって感じかもな。

とりあえず algorithm のソート関連を眺めてみると sort とか stable_sort
とか partial_sort とか partition とか nth_element とか充実してる。
こいつらを自由に使える、しかも評価関数をファンクタにすればインライン展開される、
というところで俺はSTLにはまったのだが、もちろんSTLの真価はそんな浅いものじゃない。

まずは定番の「Effective STL」を一通り読んで後はいろいろ使い込んでみるといいよ。
そうしてSTLはC++の一部というよりむしろ独立したひとつのプログラミングパラダイム
なんだってわかってくるとSTLがすごく面白くなってくるから。

あとゲーム開発についての発言はあまりにも無知すぎる。ちょっとは自分で調べろ。

902 :仕様書無しさん:2006/10/02(月) 23:39:58
そおいや、X68000でgccでゲーム作ってたなぁ。
ナツカシス

903 :仕様書無しさん:2006/10/02(月) 23:41:58
>>901
そいつにレスしても無駄だぞ

904 :仕様書無しさん:2006/10/03(火) 00:39:12
>>903
740 とかその同類のコピーコンストラクタと型変換コンストラクタの区別も付かない
***よりは数等まともだと思うが。アウェイのおっさんスレでもがんばってるしな。

905 :仕様書無しさん:2006/10/03(火) 01:16:02
>>904
その台詞は世のマトモなC++プログラマーに対する侮辱だな。
newの使い方知らんでああだこうだ言われてたわけだったんだよなぁ。



906 :仕様書無しさん:2006/10/03(火) 02:16:45
メモリ資源の乏しい携帯電話でメモリ馬鹿食いするをJava使おうってのがそもそも間違いな気がする。
オブジェクト指向を全然活かさない書き方しないといけなくなるし。

907 :仕様書無しさん:2006/10/03(火) 12:38:15
馬鹿だな
携帯でやろうと思った時点でGUI周りをひっくるめて言語仕様として機能を全て持ってたのがJavaしかなかったからだろ
いちいちアセンブラでSH用、MIPS用、PowerPC用、ARM用とか書けってのかよ
そんなのめんどくさくて誰もやらねえよ
そもそもOO言語だからってOOPしろだなんて誰も言ってねえよ


908 :仕様書無しさん:2006/10/03(火) 13:23:41
ARMとPowerPCは素直で良い子だからアセンブラでガリガリと書く気になる。
別に難しいことは何もないし。

909 :仕様書無しさん:2006/10/03(火) 23:49:54
いちいちアセンブラでSH用、MIPS用、PowerPC用、ARM用のVM作ってる身にもなれよ。

910 :仕様書無しさん:2006/10/04(水) 00:57:20
そんなことは知るはずもないおじゃばさまどもは

911 :おじゃばさま:2006/10/04(水) 09:40:37
>901
mapもvectorも、それらのソートもjavaの方が豊富だろう。
それよりstring関係の弱さがが気になる。トリムやトークン切り出しが見つからない。
しかしそれが真価じゃないのか。その本を読んでみるよ。
確かにSTLを使うのと使わないのでは、全然違うな。

>905
悔しいがまだnewが良く分からない。
この前聞いた結果をまとめると、
・newしたらdeleteは必要
・そもそもnewする必要はない
ネットで調べたのをまとめると
・^しておけばdeleteは不要
・gcがあるのでスコープ外れると勝手にdeleteされる
・やってはいけないnewがある(コンストラクタ内でのnew禁止)
など、いろいろあって検証しきれていない。

912 :仕様書無しさん:2006/10/04(水) 10:57:54
new/deleteを再定義してデバッガで追うか、Purify/BoundsCheckerみたいな
メモリチェックツールつかえば分かるデスよ。

フリーのメモリチェックツールもあるらしいけど(Electric Fenceとか)知らん。

913 :仕様書無しさん:2006/10/04(水) 11:26:21
>>911
空気を読まずにマジレス
> ・そもそもnewする必要はない
メンバ変数かauto変数で事が足りる場合が多いという意味じゃないの?
> ・^しておけばdeleteは不要
知らん
> ・gcがあるのでスコープ外れると勝手にdeleteされる
誤解があるような気がする
> ・やってはいけないnewがある(コンストラクタ内でのnew禁止)
コンストラクタでnewするくらいなら、メンバ変数にするという意味じゃないの?



914 :仕様書無しさん:2006/10/04(水) 11:30:54
>>909
ゲーム作るたびにVM作るわけじゃないだろ低脳
苦労するのはごく一部だけで良いんだよ

915 :仕様書無しさん:2006/10/04(水) 22:20:50
>>911
>それよりstring関係の弱さがが気になる。トリムやトークン切り出しが見つからない。
そういう贅沢な機能は非標準ライブラリを使えってことになっている。
例えば boost::regex とか boost::tokenizer とか boost::format とか。

>・^しておけばdeleteは不要
それは C++ じゃなくて C++/CLI だ。.net framework が必要になるぞ。

916 :仕様書無しさん:2006/10/04(水) 22:23:43
携帯アプリでアセンブラやC使わせたらウイルスだらけになるだろ?

917 :仕様書無しさん:2006/10/05(木) 01:02:44
>>916
BREWは大丈夫だぞ
ああゆう拝金主義的なプラットフォーム出すと
問題ないぞ

918 :おじゃばさま:2006/10/05(木) 21:12:31
>913,915
newの件に関してはようやく全て分かった。
確かにauto変数で足りるから、new使わなくてもいけるな。
「=」が代入というよりコピーになっているんだな。Javaとmapの扱いが少し違うので少し戸惑った。
しかしポインタを使わずにJavaのように組むと、コピーしまくるな。
これで本当に早いのだろうか?

あとはクラスライブラリの方か。
トークン切り出しやトリムは贅沢なのか。Javaじゃ標準だから他のライブラリになるとは思わなかった。
贅沢って言ったら正規表現あたりからかと思っていたが。
まあ、ちょっと標準ライブラリだけで頑張ってみるよ。EffectiveSTL見ながら。

919 :仕様書無しさん:2006/10/05(木) 22:14:24
甘いなおじゃば

autoはスタックフレームに生成する
いい気になって使うとスタックオーバフローだ。こいつはどこが悪いか
ぜんぜん分からないバグになる。
スタックが少ない実行環境もあるから気をつける事だな。

920 :仕様書無しさん:2006/10/05(木) 23:53:28
きみらの話はネタだよな?

921 :仕様書無しさん:2006/10/06(金) 00:12:42
なんかそれ、もう見飽きた。

922 :仕様書無しさん:2006/10/06(金) 00:36:11
>>918
C/C++ を「Java らしく」書いたら、そら不自然になる罠。
COBOLer の書いた Java プログラムが妙ちくりんなのと同じ。


923 :おじゃばさま:2006/10/06(金) 20:09:56
いやC++のSTL使用は、Cより遥かにJavaに近いって事が分かった。
C++知っている人ならJava文法の良さは身に染みて分かると思う。速度は別にして。
C++/STLは早い訳じゃ無くて、技術があれば早くできるだけって事が分かった。
良く知らずに使えば、速度の問題どころかまともの動作しないって事も分かった。

EffectiveSTL読んでいるが、C++を業務で使うのはかなり厳しいのではないかと思っている。
コンパイラによって動きが違ったり、見えにくいバグが多かったり、いくらでも凝れたり。
この言語は人を選ぶよ。開発者全員にこれをマスターさせるのは不可能だと思う。

ところでgetMutexFor()がないんだけど、何使えばいい?

924 :仕様書無しさん:2006/10/06(金) 21:03:01
>ところでgetMutexFor()がないんだけど、何使えばいい?
STL は一応マルチスレッド環境に配慮して作られてはいるんだけど
C/C++ 標準ライブラリにスレッドという概念はないのでそれは開発環境に依る。
Windows なら win32api に含まれているし、UNIX系なら pthread がある。
ポータビリティを求めるなら boost::thread があるが日本語の資料は少ない。
後は知らんのでそれ以外の開発環境ならム板の環境依存OKスレにでも聞いてくれ。

925 :仕様書無しさん:2006/10/06(金) 21:47:17
>C++知っている人ならJava文法の良さは身に染みて分かると思う
全くそうは思わないが
インラインスタイルでしか書けないのはうざいよ

926 :仕様書無しさん:2006/10/06(金) 22:05:23
逆に聞くが、hとCPPに分けて書くスタイルってどー思った。

927 :仕様書無しさん:2006/10/06(金) 22:21:11
>>923
STL(や boost)をそれらしく使えば使うほど、Java よりはむしろ
Lisp とかのほうに似てくる罠。

まあ正直、Java の文法の C++ を意識した感じとかはあまり良いとは
思わんけどな。まああくまで文法そのものがだが。

928 :68式オサン :2006/10/06(金) 23:09:33
>コンパイラによって動きが違ったり、見えにくいバグが多かったり、いくらでも凝れたり。

JAVAは環境(バージョン)によって動きがちがったり、見えにくいバグもある。
そして幾らでも冗長性がある。(回りくどい)


どっちがいい?w

929 :仕様書無しさん:2006/10/06(金) 23:43:01
結局バカでもできるJAVAだと
虫けら学徒がバグを大量に出してくれるからノウハウは
はっきりいってJAVAの方が積まれるぞ

神格化した今のC++では誰も手が出せないからノウハウ貯まらないかなぁ



930 :仕様書無しさん:2006/10/06(金) 23:55:09
肥大化して手を付けられないのがJavaだろうに

931 :仕様書無しさん:2006/10/07(土) 00:26:18
SGML への反省から XML が生まれても結局複雑怪奇になったのと同じ道を
Java はたどりつつあるよな。

932 :仕様書無しさん:2006/10/07(土) 08:03:56
それを言ったら長く使われているプログラミング言語は
みんな同じ道をたどってしまうとも言えるな

933 :仕様書無しさん:2006/10/07(土) 08:06:04
確かに多くの人に使われている言語はそういう道をたどるしかないよな。

934 :仕様書無しさん:2006/10/07(土) 08:25:47
Cはもう30年。COBOLにいたっては・・・

935 :仕様書無しさん:2006/10/07(土) 20:38:28
JavaってLinuxと同じ進化をしているな。
Linuxは初期のバージョンはWindowsよりリソースが少ない環境でX-Winも
使えるというのが売りだった。ところが今じゃDVDじゃなきゃ配布できない
ぐらい巨大化してしまった。
Javaもきっとメモリがテラオーダつめるサーバ以外は動作しなくなるのだろう。

936 :仕様書無しさん:2006/10/07(土) 20:41:37
別にDebianはフロッピーからでもインストールできると言ってみるテスト

つーか、Linuxのウリを勘違いしてJavaを引き合いにだして
デタラメ言うのもどーかと思うが。

937 :仕様書無しさん:2006/10/07(土) 20:49:47
JavaはWeb系だけにしとけばいいのにさ。

OS上のファイなんか扱い始めると、どうにもこうにも。
Java経由でプロセス起動したり、最近の若い奴のやる事は恐ろしい。
なぁ、H○さん。(しばらくお世話になりますが)

938 :おじゃばさま:2006/10/10(火) 20:37:07
>924
スレッドが機種依存なのか。
使いたくないが、CORBAはスレッドだろうな、きっと。

>926
HとCPPを分けて書くやつか。はっきり言って良くない。メンテナンス性も悪いし、同じような事2回書くし。
Cの負の遺産を引き継いだって感じだな。

>927
C++もJavaも悪いって事かな。まあそうかもな。

>928
JavaはVMによって動きが違うなんてほとんどないぞ。見えにくいバグ?
まあリークは見えにくいけど、NullPointerもIndexOutOfもException出すぞ。
C++が凝れるって言ったのは、演算子のオーバーロードやテンプレートで短縮出来るけど、
理解不能になるって事だよ。冗長とはむしろ逆の意味だ。
だからその文のJavaへの当てはめ自体、バグってる。

>929
C++は選ばれた勇者しか使わないから品質がいいって事かな。
まあ、そうともいえる。

>930
確かにJava初めて見た時はクラスの多さにびっくりしたが、9割以上使わないと分かったら
気にならなくなった。Javaでは新しいクラスは無視が基本だから、別に手をつけられないって事はない。
昔は嫌で仕方なかった長いパッケージ宣言も、慣れれば使いやすい。
C++のネームスペースは破綻しているからな。


939 :仕様書無しさん:2006/10/10(火) 23:46:49
サーバ側はマルチスレッドよりマルチプロセスの方がアーキテクチャ的に有利らしいが、
サーバ側がJavaじゃ無理か?

940 :仕様書無しさん:2006/10/11(水) 18:54:41
J2EEの立場は・・・

941 :おじゃばさま:2006/10/11(水) 19:49:12
いや全部Javaにすれば何も問題ないのだが、前提条件がC++だから仕方ない。
C++の方はプロセスとスレッドで選択出来るみたいだから、プロセスにすればいいのかもしれないな。

ただアーキテクチャー的に有利と言うのが何を示しているか分からないが、
速度とメモリの面でもスレッドの方が有利だろう。プロセスが有利と言うのは堅牢性ぐらいかな。
だから、なんでスレッドにしないかと聞かれたらピンチだな。
C++のスレッド管理が怪しいのでとか、アーキテクチャー的に有利とか言ったら説明させられそうだ。

はっきり言って、C++は問題がありすぎる言語だよ。
JavaやDが作られたのも、MSがC#に逃げたのも納得出来る。
これを素晴らしいって言ってる人は、本当はC++を知らないんじゃないか?

942 :仕様書無しさん:2006/10/11(水) 20:00:23
なあ、Javaのコードって全部try〜catchで囲わなければいけないのか?

943 :仕様書無しさん:2006/10/11(水) 20:01:37
LinuxではJavaでマルチスレッドのコードを書いてもマルチプロセスになるぞ。
おじゃばさまはpsコマンドって知っているか?

944 :仕様書無しさん:2006/10/11(水) 22:32:10
そりゃpsコマンドがスレッド単位で表示しているという落ちだった気がする

945 :仕様書無しさん:2006/10/11(水) 22:55:28
>>942
全部じゃぁない。

946 :仕様書無しさん:2006/10/11(水) 22:58:11
つーか、マルチプロセスの方が有利って言うのは
ステートレスなプログラムを作った方が処理が分散できるって意味だろが。

重要なのはC++でもJavaでもスケーラビリティの高いプログラムを作る事。

PHPとか、ステートをそもそも上手く持ちにくいという制約が逆にスケーラビリティを
高める事になったりしてるしね。

そーゆー背景を理解せずに

「psで見てみろよ。マルチプロセスだぜ」
「psはスレッド単位だぜ」

とか、単なる要素にしか過ぎないものに深入りする時点でお前ら終わってるよ

947 :仕様書無しさん:2006/10/11(水) 23:04:37
>>941
スレッドのオーバヘッドって考慮していっているの?
それに、メモリは有限だぉ。
ところでプロセス間通信の事考えて発言している?



948 :仕様書無しさん:2006/10/11(水) 23:22:17
linuxのスレッドはプロセスのcloneだよ。java厨はOSのこと全然わかってないんだな

949 :仕様書無しさん:2006/10/11(水) 23:24:39
マルチプロセスの方が有利なのは、プロセス単位でリーク等を始末できるからだよ。
スケーラビリティはマルチスレッドのほうが出る。Javaで組んでも出ないけど。

950 :仕様書無しさん:2006/10/11(水) 23:34:48
なかなかNPTL普及せえへんな

951 :946:2006/10/11(水) 23:48:12
>>949
お前の言うスケーラビリティって、1CPU,1サーバーで目指すスケーラビリティじゃねぇ?
俺が言ってるのは複CPU,複サーバーの環境での話。

もっとも、最終的には言語やアプリのボトルネックよか、
DBとかIO周りのボトルネックに行き着くのは間違いないのだが。

952 :仕様書無しさん:2006/10/11(水) 23:52:11
javaもlinuxもsmpじゃダメダメ

953 :仕様書無しさん:2006/10/12(木) 00:28:02
メモリ有限とかいってるやつって何時代って問い詰めたくなる
バカ言うのもほどほどにしておけて
ここ5年ぐらいは、少なくとも俺の関わるプロジェクト(利用者500万人規模のシステム)
128GBとか当たり前だぞ。
マルチプロセスなんていみねーし、スレッドだけありゃいい

954 :仕様書無しさん:2006/10/12(木) 00:32:05
おまえどこの未来から来たんだよwww

955 :仕様書無しさん:2006/10/12(木) 00:36:37
>>953
そういう点では、MS-DOS ってシングルタスクだし超最先端だったんだなw
ちゃんと 64 ビット対応させれば今でもいけるんじゃね?www
え? スレッド? そんなもん config.sys でドライバ読み込めば(ry


956 :仕様書無しさん:2006/10/12(木) 00:44:49
>>953
そこまでの御大尽を一般人に求めるのは酷かと。


957 :仕様書無しさん:2006/10/12(木) 12:03:14
>>956
え?
想定ユーザー数が数十万ユーザーとかって普通に仕事あるよ
数百万もちょっと大きいねって感じだな
嘘みたいだけどw

958 :仕様書無しさん:2006/10/12(木) 17:53:02
でたでたスレッドコンテキストスイッチの仕組みすら知らない馬鹿が

959 :仕様書無しさん:2006/10/12(木) 18:38:23
爺は巣に帰れよ。

960 :おじゃばさま:2006/10/12(木) 18:52:18
>946
プロセス/スレッドと、ステートレスは関係ないだろう。
何か勘違いしていないか?まるでスレッドを知らないように見えるが。

>947
946に言っているのではなく、俺に言っているのかな?
俺に言っているとすると、
プロセスの方が使用メモリが少なく、プロセスの方が同期も簡単って意味になるが、
そう言いたいのかな?


961 :仕様書無しさん:2006/10/12(木) 23:49:36
128GBあるから

962 :おじゃばさま:2006/10/13(金) 20:05:15
JavaをC++並に早くする方法。

最近C++の調査を行っているが、C++の構文はほとんどJavaと変わらないと言う事が分かった。
C++はこれでも早いのかなと疑問に思ったが、いろいろ調査を進めるうちにやはり遅いと言うのが分かった。
ではどうして速度にうるさいCユーザに受け入れられているのか。それは頑張れば速くできると言う事だった。
つまり、C++で速くするのは、vectorやmapやstringを使うなら、適切な初期領域を設定しろと言う事だ。
そんな面倒な事が出来るかと思ったが、ふと思った。
JavaでもListやMapやStringの初期領域を設定すれば速くなるのかなと。

次に問題になるのは、実行ファイルだ。
C++はネイティブでスタティックリンクしているので速い。
Javaは中間ファイルだし、Jarからクラスを検索するのですごく遅い。
しかしそれはコンパイラの問題だ。ネイティブの実行ファイルを作るコンパイラがあれば。
ありました。「Excelsior JET」と「GCJ」
これで理論的にはC++と同じはず。


963 :仕様書無しさん:2006/10/13(金) 20:17:30
それ以前にアプリケーション鯖が不安定すぎるよ。

964 :仕様書無しさん:2006/10/13(金) 21:35:44
>>962
>C++はこれでも早いのかなと疑問に思ったが、いろいろ調査を進めるうちにやはり遅いと言うのが分かった。 
あんた、こういっちゃ何だけど毎回急ぎ結論出しているけど、過程を言わんので正当性を疑う以前に
信用できないんだよ。チラシのウラにそこまで書けっていうのは酷かもしれんが一行でも良いから信用に
足る技術的な事を書け。

>つまり、C++で速くするのは、vectorやmapやstringを使うなら、適切な初期領域を設定しろと言う事だ。 
逆説的だが、C知らんで別言語から入ってきた人間はこういう考え方をするという典型ですな。
点として30点位かな?

>そんな面倒な事が出来るかと思ったが、ふと思った。 
>JavaでもListやMapやStringの初期領域を設定すれば速くなるのかなと。 
JavaとかC++という点をとりあえず置いて聞いてくれ、あんたのプログラミングの技量を上げる方法として
学校のコンピュータとプログラミングの授業の初級・中級の授業を受ければよいと思う。
コンピュータとプログラミングの基礎から勉強しなおしてくれ。

マジで。

車輪の再生産は確かに馬鹿だと思う。だけど車輪作れないどころか仕組みもしらない奴にそんなこといわれたくないよ。マジで。



965 :仕様書無しさん:2006/10/13(金) 21:44:58
Java厨ってさ、バイナリサーチも知らないんだね。
あらかじめソートされたコレクションに1要素追加するのに、最後尾に追加して
全ソートしてるの。大爆笑だった。

966 :仕様書無しさん:2006/10/13(金) 22:38:06
>>965
Collectionになかったっけ?Arraysかな

967 :仕様書無しさん:2006/10/13(金) 22:38:54
幾らなんでもそんなへぼいことはしないだろw

968 :仕様書無しさん:2006/10/13(金) 22:48:05
>965
馬鹿じゃないのかw
binary searchぐらいで得意気に語っているお前の方が笑えるんだがwww
死んだ方がいいんじゃない?それにそういうデータならどういう方法が最適なのかも
しらないのか?binary searchが最適だと思っている時点で小学校からやり直せよwww
ちなみに小2でbinary searchぐらいしっていたぞw 
お前のその脳味噌の中に入っているソートアルゴリズムをあげてみろよwww
それぐらいで得意になってプログラマをやっているお前が心底笑えるよ
まぁがんばれよ。先はながくはないとは思うけどwww

969 :仕様書無しさん:2006/10/13(金) 22:51:30
恥ずかしくて顔が煮えたぎってしまった人↑

970 :仕様書無しさん:2006/10/13(金) 22:56:03
次の文章考え中かな?

971 :仕様書無しさん:2006/10/13(金) 23:02:27
binary searchで得意になっているところをみると本当に低レベルだよな
このスレの住人はwww

972 :仕様書無しさん:2006/10/13(金) 23:06:54
>964
JavaがCよりも早いという研究論文はかなり出てきているよ。
もちろん特殊なケースなんだけど

今は昔はMPI(並列処理をさせるライブラリ)はCやC++のみだったが
Javaもすでに開発されている。実行速度を気にする並列処理でだ。
Java以前の問題としてプログラマでありながら本当に基本的なアルゴリズム
をしらない人間が5万といる。
また世界的に有名なACMのプログラミングコンテストの世界大会
でも問題読解能力とともに実行速度を気にする上位参加者がJavaを使うことも
よく見られるしなぁ・・・

ちなみにJavaで書かれた3Dレンダリングエンジン(Java3Dではない)もかなり
のスピードなんだよ



973 :仕様書無しさん:2006/10/13(金) 23:28:09
でもクライアントPCにもメモリ馬鹿積みしてJVMは-serverオプション必須なんだろ?
JavaはうまくいけばWindowsみたいな立ち位置には着けるかもね
糞だ糞だと言われ続けるが、結局それが速く走る環境がもてはやされるという図式

974 :仕様書無しさん:2006/10/13(金) 23:38:45
コスト増大を狙ってるからね

975 :仕様書無しさん:2006/10/13(金) 23:51:14
>>972
論文持ち出さなくても、Javaが早いケースは、過去スレや関連スレで
簡単なテストを何度もされている。
ループでstringに追加するとかいう簡単なテストでJavaが早いけど
追加する文字をランダムにするとC++が早いとか無かったっけ?

とりあえず、JavaがC++より早いってそんなもんでしょ?

976 :仕様書無しさん:2006/10/13(金) 23:59:52
>973
自分はCやC++でMPI使って並列処理など色々やってきたけど
最近はまるで書いていないし、JavaのMPIで書いたことはないので正確なことはいえないんだが
恐らくそうかも知れない。

ただメモリを馬鹿積みしたから(その方が確かに早くなる確率は高いが)といって並列処理
が早くなるとは言えないしノード(PC)の数やデータのshapeそしてにも処理が異質のものなのか
同質なものなのかにもよるからね。

5年ぐらい前まではもっぱらCやC++でやっていたが今は訳あってJavaで組んでいる。
アルゴリズムの知識さえあれば、致命的な遅さは自分からすると感じられない
んだが・・・それもかなり大規模なコードを書いてみたんだけど。ソフトの設計が悪かったり
アルゴリズムが悪かったりするからじゃないのかなぁ・・・と個人的には思うけど。
CやC++が嫌いなわけでもないんだけど、Javaはかなり改善されているとおもうけどな

>975
いやString等のそういったケースではない。科学技術計算の分野なんだが・・・ちょっとかなり前に
読んだ論文なんでなんとも言えないんだけど。ただ自分もすべてにおいてJavaが早いとは思っていないが、
ただ自分もJavaで組んでいて致命的に遅いなとはあまり感じなかったから。ただそれだけ。



977 :仕様書無しさん:2006/10/14(土) 00:21:15
ここを見てると、おおかたJavaが致命的に遅いと言う人と
問題視するほど遅くないと言う人の二つに意見が分かれるね
意見が違う原因は何なんだろう?やっぱり好き嫌いの問題?

978 :仕様書無しさん:2006/10/14(土) 00:22:32
俺のパソコンだと致命的に遅いぞ

979 :仕様書無しさん:2006/10/14(土) 00:22:44
アプリケーションサーバを使うかどうかだったり

980 :仕様書無しさん:2006/10/14(土) 01:07:35
JAVAは全然遅くないよ
今128ノードで稼動しているデータセンターで
仕事してるけど別にJAVAだろうがCだろうが大して
差が感じられないよ。昔はJAVAなんて遅くて使えないと
思ったけどそんなことないよ全然ねぇ。

981 :仕様書無しさん:2006/10/14(土) 01:42:46
そりゃデータセンター側はDBボトルネックでわからんだけとかいう落ちでは。

982 :仕様書無しさん:2006/10/14(土) 04:21:06
Javaやってるとデータ構造の使い方は覚えても作り方は覚えない。

983 :仕様書無しさん:2006/10/14(土) 20:42:49
作り方なんて覚える必要ないもん

984 :仕様書無しさん:2006/10/15(日) 14:22:26
今のJava Swingはネイティブに頼っているSWTよりも高速なんだよね

985 :仕様書無しさん:2006/10/15(日) 16:58:26
( ゚д゚)

986 :仕様書無しさん:2006/10/15(日) 17:01:25
swingははやいんだぞ

保存する時すら一瞬なので操作不能になることなんて無いんだぞ!!!!!!!!!!!!!!!!


987 :仕様書無しさん:2006/10/15(日) 17:27:33
つまらん演技じゃ。

ネイティブにすれば高速化すると妄信して作られたSWTはもう遅いし
最適化技術をなめちゃいかんよ


988 :仕様書無しさん:2006/10/15(日) 18:30:47
>>987
そうだね、アセンブラを使って最適化するのは基本だよね。

989 :仕様書無しさん:2006/10/15(日) 19:25:19
>>953
あほ


990 :仕様書無しさん:2006/10/15(日) 19:33:09
はんともほほえましい意見ですな。
いつの時代の基本でしょうかねえ


991 :仕様書無しさん:2006/10/15(日) 19:33:36
ume

992 :仕様書無しさん:2006/10/15(日) 19:54:47
>>987
ゴミはしんでろ

993 :仕様書無しさん:2006/10/15(日) 20:30:32
なんというソフト・・・
バグだらけでまともに動作しない
しかも認証に30秒かかる
このソフトの言語は間違いなくJava
そして作ったのはジャワ厨

   / ̄\
  | ^o^ |
   \_/


994 :仕様書無しさん:2006/10/15(日) 21:59:18
Windows Vistaって重くね埋め

995 :仕様書無しさん:2006/10/15(日) 22:02:10
結局managed C++って何だったのか埋め

996 :仕様書無しさん:2006/10/15(日) 22:28:16
次スレ
http://pc8.2ch.net/test/read.cgi/prog/1160918783/

997 :仕様書無しさん:2006/10/15(日) 22:35:03
__gcしてりゃ幸せでいいよな

998 :仕様書無しさん:2006/10/16(月) 01:55:24
徹夜してまでmalloc()とfree()を必死に使い回してれば
幸せで言いよなw



999 :仕様書無しさん:2006/10/16(月) 02:32:07
999

1000 :仕様書無しさん:2006/10/16(月) 02:38:27
次スレ
http://pc8.2ch.net/test/read.cgi/prog/1160918783/

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

196 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)