1 :
仕様書無しさん :
2006/07/22(土) 14:55:16 語れ。
2 :
仕様書無しさん :2006/07/22(土) 14:56:01
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 (続く)
まだやるの?w
6 :
仕様書無しさん :2006/07/22(土) 22:39:54
あるとおじゃばさまがあばれて 良いこと尽くめだから
>>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
止まってるのに誰が例外投げるの?
13 :
仕様書無しさん :2006/07/23(日) 21:22:53
javaしか投げないよ
14 :
仕様書無しさん :2006/07/23(日) 23:29:16
場合によってはCより速いとか。 多少速いことがそんなに重要なのかわかりませんが。 どんな言語にもメリット、デメリットがあり、場合によって使い分けるものだと思いますが。
Cより速いってのは業務同士で組んだ場合のコード品質の差だよ チューニングのプロ同士でやったら、どうやってもJavaはCに勝てない 生産性4倍で実行コードは2倍遅いくらいに考えとくがいいさね
16 :
仕様書無しさん :2006/07/24(月) 00:15:17
c++とjavaってそんなに変わんないじゃん javaで組める人だったらc++でも組めるんじゃない?
組めるよ。俺は元々Cから入ってるから、Javaから入った学生とかは知らんが。
18 :
仕様書無しさん :2006/07/24(月) 00:26:03
生産性4倍(糞馬鹿Java厨がてきとうに作成) デバック時間(36倍) それでも工数が足りなくなるのがJava
java厨が問題なんだよな
20 :
仕様書無しさん :2006/07/24(月) 00:27:14
Java厨は書き逃げするから あとのテスターが泣きをみるパターンが多い
年がかりを3ヶ月で回せるのはJavaのお陰 ドカタがどれだけJavaを否定しようと経営者は判断を間違えないよ
22 :
仕様書無しさん :2006/07/24(月) 00:34:44
経営者
生産性を言うならJavaは.NETに勝てないよ? 事実.NETのサイトは凄い勢いで増え続けてるしな。 どっちにしろJavaは二流以下と判断せざるを得ないよ。
二流なのは
>>23 だろ?プログラマは言語を選びません。
>>24 経営者云々って話の流れなのに....
いや、コーディング命の最下流には分からない話かもしれんが。
勝てないよ?とかコーダにもなれないレベルの奴が言ってもな
経営者が判断するのはコストだけ。 技術がどうこうなんてどーでもいい。 .NETの方が安く上がる、と判断すれば替えるだろ。
なら変えない奴のが多いな
.NETの敵はPHPだろ Javaとは適用が違うんだから馬鹿なレスもってくんな
w君登場、もう必死かよ
生産性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の仕様にしか欠点を見出せないってこと。
VMの仕様以外にも、 ・乱立する粗悪なフレームワーク ・動きのあやすいAP鯖 ・つきることのないXML地獄 が欠点だと思うけど
36 :
仕様書無しさん :2006/07/24(月) 10:37:26
>>35 うむ。まず速度的に「使い物にならね」で閉じちゃうから
その他の問題が隠蔽されるのだな。
これはJavaにとっては歓迎すべき事なのでは。
VMの仕様以外にも、
・そのばしのぎの拡張を繰り返すAPI
javaをなくせば問題ない
汎用性を高めるより先にライブラリを統廃合すべきだろ
Javaの仕様に統一しようとすると サンマイクロからクレームが来ますので。
java自体はべつに悪くないと俺も思う。 ただ、言語仕様とは別でライブラリはどこから手をつけたらいいかわからないくらい巨大になった感はあるなぁ。 αjavaで遊んでいるときはたのしかった。
41 :
仕様書無しさん :2006/07/24(月) 15:28:15
CでWeb系、ネットワーク系でJavaより使いやすいフレームワーク教えてください。 GUIは、MFC?
.net framework
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
Java厨もその点は同じだべ 口をつくのはいつも他人の資産だからな
>>48 うひゃ。自分じゃ絶対作る気がしないのがJava厨スペック
自分ではソースも見たことない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
54 :
仕様書無しさん :2006/07/24(月) 23:55:51
つうかさJAVAって結局スクリプト言語並みの糞言語だよな Groobyだっけあんなしょうもないもの作って連携して 他のスクリプト言語とためはって勝負したりとしょうもないにもほどがあるな
スクリプト言語が糞言語という発想が既に貧相な脳を物語ってるな
56 :
仕様書無しさん :2006/07/25(火) 00:48:11
結局 Java の API も Windows API と同じ道をたどりつつあるな。 Java のほうがクラスやパッケージという分類機構があるが、しかしここまで 大量になるともはや気休め程度でしかない。 汎用目的ライブラリだと各方面からの要求が激しいから、こうなるのも宿命なのかな。 家電向けに特化してれば、今頃もすっきりきれいな設計のままだったろうに・・・。
ぶっちゃけ、スクリプト言語のほうが安定してるでしょ?
58 :
仕様書無しさん :2006/07/25(火) 00:50:26
C/C++ のように標準で用意するライブラリは最低限にして、あとは勝手に サードパーティのライブラリを適当に使ってくれ、というポリシーの方が 長期的には利口なのかな。
>>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++機能禁止とか。 うちはやってるけど。
5.0やっててGenerics禁止にするのって馬鹿としか思えない 拡張for禁止、enum禁止とかなら、過去資産組の救済としてアリとは思うが
てかC++ってSTL使う奴少ないよな
J2MEだっけ?組み込み用。あれはAPI仕様がいくつかプロファイル定義されてたね。
66 :
仕様書無しさん :2006/07/25(火) 03:54:35
Javaの可能性は無限大
>>55 > スクリプト言語が糞言語という発想が既に貧相な脳を物語ってるな
つまり「Java厨が貧相な脳」ってことになるけど、本当にそれでいいの?
Java厨は
・スクリプト言語=劣
・スクリプト言語以外=優
っていう発言をしょっちゅうしてるけど。そんなにコンパイラ型言語が偉いんかっちゅーぐらい。
スクリプト言語をバカにしてるのは否定できまい。
68 :
仕様書無しさん :2006/07/25(火) 15:00:49
PHPの言語仕様のクソさに比べたら、Javaは神の領域
仕様だけ象牙の塔 実用度は別
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
スクリプトのほうが軽いってどういうこと??????
けど、Javadocの見やすさは神!時々rubyやphpを使うときに死ぬほど萎える。
76 :
仕様書無しさん :2006/07/26(水) 00:20:54
ピザでも食ってろ。Java
>>75 > けど、Javadocの見やすさは神!
アホ発見
そりゃPHPに比べりゃ大抵の言語は神レベルに見やすいわなw
>>73 お前一人が馬鹿にしてるだけだろ
腐ってるのはお前の脳
Java脳の恐怖
>>79 が必死な件について。
今更そんなしょうもない嘘ついて何になるんだ?くだらない。
別にバカにしててもいいんじゃないか?Javaはスクリプト言語ごときに負けるわけがないんだろ?
スクリプト言語のほうがシンプルで無駄がなく 少なくともJavaよりはいいな。
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++製のサーブレットコンテナ公開してたじゃん。 あんなのじゃだめなんか?
あれって結局Javaは作りやすくていいねって宣伝にしかなってないな
もうJavaのweb系を語るのは止めた方が良いんじゃないの? .netとphpに弾き出されて絶滅寸前なんだからさ。
頼むからインデント揃えろ
>>89 もう少し開発が進んでTomcatとの性能比較とかしたら面白そうだけどな
かといって自分の会社の案件ベースの数字を出しても意味がないわけだがな
.NETって単語だけで笑けてくるw
もし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年にかけてだね。 もうくだりきってふもとが見え出したところだね。
減ってないから。実際お前は嫉妬に狂ってるわけで。
100 :
仕様書無しさん :2006/07/27(木) 00:47:20
2000年〜2003年までかな。
101 :
仕様書無しさん :2006/07/27(木) 00:48:10
減ってないって。アホ
そりゃお前の会社がドカタ派遣会社だからだろ。
C/C++専門でやってる奴がバイトオーダーとか知らなくて 笑いこらえるので大変だったことがある さらに傑作だったのがSTLが使えないって所 あいつらってさ、単に見識無いだけだろ?
エンディアン 使うからそっちが普通じゃないと思う
105 :
仕様書無しさん :2006/07/27(木) 00:53:29
と、genericsの使えないJava厨が申しております。
Cは速いからとか馬鹿のひとつ覚えを繰り返して 実際は大して使いこなせてない奴ばっかじゃん そういう奴ほどわざわざ使いにくいキーボードを コネクタ経由でUSB接続してたりするしw
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のメモリプロファイラを列挙せよ
保守案件なんてやってないんだが。 おまえの脳内補完が一番おめでてーよ。
113 :
仕様書無しさん :2006/07/27(木) 01:09:01
初期のNT4鯖並みの安定性。定期的な再起動を必要とするのがじゃば鯖
無知極まりない雑魚相手にするのも馬鹿らしくなってきたな レッテル貼ってるだけで根拠がまるで無い 一生暇してろ
Javaの案件が減るなんて有り得るの? 今、土方を最も安く揃えられる経済性抜群な言語はJavaだと思うんだけど。
116 :
仕様書無しさん :2006/07/27(木) 01:11:06
減ってないって。アホ
117 :
仕様書無しさん :2006/07/27(木) 01:11:58
減ってないって。アホ
>>115 できるものはあるものの 大して使えないものばかり
119 :
仕様書無しさん :2006/07/27(木) 01:13:52
JavaこそがWebサーバサイド開発究極の言語
>>119 その主張は度々耳にするけど、まともな根拠を列挙できる奴を見た事がないよ。
121 :
仕様書無しさん :2006/07/27(木) 01:18:40
普通にWeb開発ならPerlやPHPのほうがシェアが高い。 Javaは仕組みがこりすぎて、システム要件が高くコンパイルを要するにも関わらず インタープリタのスクリプト言語より重い。 以前はWebは金のなる木で企業もコストを掛けられた。 今はスピードが求められる。迅速に開発できて運用できることが望ましい。 また、Web系システムの寿命は短く、OOで再利用性を深く深く考えて設計しても あんまりメリット無いんだな。 スクリプトでさくっと作るほうがより要求に適合しているとみなされ始めたわけだ。
正直もうHTMLは要らないな しかしSOAPとかをびびって採用できないSEが多すぎ
>>121 普通のWeb開発ってWeb屋がやる案件のことか?
そんな単価の低い仕事よう引き受けられるな
124 :
仕様書無しさん :2006/07/27(木) 01:25:15
単価の高い仕事ってどんなの?
大手の基幹システムとかやったことねーのか、ヘボ
> 正直もうHTMLは要らないな > しかしSOAPとかをびびって採用できないSEが多すぎ 全く意味が分かりません。
お前が馬鹿だからだろ
とりあえず これ以上トラフィック量とCPUを食う処理はやめてほしい
129 :
仕様書無しさん :2006/07/27(木) 09:39:20
基幹といえばcobolだろ
130 :
仕様書無しさん :2006/07/27(木) 10:22:05
NTTデータのコンサルが金融系システムにjavaがたくさん使われていると言っていたから 多分javaはサーバサイドで最強なんだろう
現場を知らないやつはのん気でいいね
ウェブ 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が使われているので、トータル的には減ってない感じがする。 多分、「減っている」と言っている人は、ショッピングモール系ばかり見ている人で、 「減ってない」と言っている人は、トータル的に見ている人だと思う。
>感じがする。 >だと思う 結局おじゃばさまの感想なのね。 統計とれなんてむちゃ言わないから 身近な例でいいから減ってないとか 言ってくれ。 そっちの方が燃料として適当だ。
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で作るが、数年はかかるだろうと言っていた。 俺は思った。「見積もれないなら、勝負にすらならない。」
基幹はホストを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モジュール仕込むのは問題ないかな?
>>137 >PHPでは無理なのでCで作るが、数年はかかるだろうと言っていた。
数年かかるシステムっていうのはつまりスキルがないと言う事と判断
せざるを得ないね。PHPマスターだけどCマスターじゃないんじゃね?
穿った見方すれば、お友達ってCの大規模案件経験ないんじゃね?
Cって、結局経験でしか判断できないからね。
もしくは経験があるがゆえに修辞的に“数年かかる”っていったかもな(w。
3200万の案件で何人月のシステムなの? ありえないだろうけど、ソレ1人でやったら同じく数年かかる気がしなくもないが。
どろろろろろろって何を比喩してるの? 表現が頭悪すぎて比喩できてないよ
145 :
仕様書無しさん :2006/07/27(木) 21:51:20
ブラウザでURLをたたく−>白いまま その状態がどろろろろろろろろろろろろろろろっと続くさま
>>138 IBMの意向を結構無視してひたすらアセンブラやCOBOLやCLやRPGとかで
Javaは普及率低いんですが。
iServerにデフォでJavaが入っているのはありがたいんだが、
使える人間、劇すくねぇよ。(w
147 :
仕様書無しさん :2006/07/27(木) 21:54:08
おじゃばさまってリスナ周りは弱いみたいだな。
おじゃばさまってもしかしてSOAPで作ったこと無いとか?
たぶんひいき目に見ても「SOAPを扱うライブラリ」のインタフェース叩いたことしかないんじゃないか? .NETプログラマでもそうだろうけどな。
自作の糞重いSwingアプリをマスタングで動かしたら、 すんげー早くてうんこ漏れそうになった。 おかげで、チューニングする気が失せた。
おじゃばさまはソープが好きみたい
152 :
仕様書無しさん :2006/07/28(金) 00:53:38
あげ
153 :
仕様書無しさん :2006/07/28(金) 00:55:25
>>85 おまえ?javaしかできないの?
ださっ
154 :
仕様書無しさん :2006/07/28(金) 00:58:34
swingは速くて最強なんだぞ!
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をアドインした程度じゃないの?
mod_oc4jというのが入ってると思った
161 :
仕様書無しさん :2006/07/28(金) 13:09:31
.soじゃなくて.dllばかりだよねOracleのApache
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 どちらかと言うと、泡より休憩の方が好き。
>Cのスキル的に言えばそいつはDBすら自作出来るような化け物だよ。 ↑どれだけ笑えばいいの?
166 :
仕様書無しさん :2006/07/28(金) 21:48:28
プッ Java厨って悲しい生き物だな。
Cで100人って・・・。 漏れの認識だとよほど段取りしないと 逝けないと思うんだけど。
>>164 やっぱお前レベル低いよ
添付ファイル程度で「すら」とか使わないって
でSOAPって、どんな局面で使うの?
170 :
仕様書無しさん :2006/07/29(土) 00:15:35
Java厨だからレベルが高いわけがないのだ。
>WebLogicのSOAPで添付ファイル(バイナリ)すら扱ったことがあるぞ。 >相手のスキルを予想する時は、少し探りを入れてからの方がいいんじゃないか? WeblogicWorkshop使ったなら誰でもできると思うぞ SOAPエンベロープで送る場合は結局テキストにシリアライズすることになるけどな シリアライズ化処理を自作したとしていてもそれは大したスキルじゃない 10年前はSOAP直に叩くしかなかったのでその頃からやってたやつなら当たり前の芸当だ まぁ、今時だとそんなとこ自作してたら、ただの馬鹿だけどな('A`) おかげで良い探りができたということで
バイナリのシリアライズ…? Base64のクラス流用すりゃそれで終了だろ。大抵の場合はよー。 スキルとすら呼べねぇ。
173 :
仕様書無しさん :2006/07/29(土) 01:17:51
おじゃばんはいつもひまなの?
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と何か難しさが変わるの?
>>175 何も変わらない。
Javaやってる人達って、仰々しい名前が付いてるだけで何故か大喜びするんですよ。
本質が分かってないっていうか、基礎が無いっていうか。
基礎がないというのは事実だな
>>176 >これってGETとか送って通信するHTTPと何か難しさが変わるの?
これに対して何のツッコミも入れられないお前っていったい・・・
>>178 HyperText Transfer ProtocolとSimple Object Access Protocolの両者を理解することに対して、
難易度が変わるのか?っつー話だ。どこに突っ込むところがあるんだ?別に両者自身を比較してるわけじゃねーし。
わざわざ略語分解しても程度は変わらないからw
馬鹿だなあ HTTPで、と言われたときとSOAPで、と言われたときでは 良く分かってない奴に与えるインパクトが全然違うんだよ。 お前らJava厨の計算高さを少しは見習え。
182 :
仕様書無しさん :2006/07/29(土) 09:32:39
9すれまではSOAP,WSDLあたりの話題は3日レス付かなかったけど 自発的に出してくるようになっただけJava厨も蚤の身長程度 成長しているということだ。
いやSOAP=風俗としか認識してないのがJAVA房
このスレってPHP厨がやたら連投するだけのスレだな
自分の痛さにまるで気づいてないようだな
もうSOAPも下火だから勉強しても仕方ないよね?
188 :
仕様書無しさん :2006/07/29(土) 13:43:28
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をなげれば処理してくれんの?
>少しは知っているようだが、「テキストにせずにバイナリのまま送る」から書いたんだよ。 >ましてやBase64で送るなら、わざわざそんなこと書かないよな。 >詳しく聞きたい? それSOAPの規格はずれてるしw 俺様仕様を詳しく聞いてもしょうがない この分だと作ったって言うDBも俺様仕様だったのかなーと勘ぐっちゃうよ
>>190 > へーDB簡単に自作できるんだ?
> そいつはPostgres並のを一人で自作していたぞ。
RDBMSの理論なら情報工学系の大学ではまず間違いなく学んでいるだろうし、
実際に簡単なRDBMSを実習で作ってみることもある。
簡易SQLみたいなのも、構文解析器使えば簡単に実装可能。
> 一般的にはかなり出来る部類になるんじゃないか?
情報系大卒であれば、ちゃんと真面目に講義を受けましたね、って程度だな。
まあ、高卒やら三流文系大卒やらが大量に居る日本のIT業界を基準にすれば、
出来る部類に入るだろうけど。
194 :
仕様書無しさん :2006/07/29(土) 19:44:32
>>193 >構文解析器使えば簡単に実装可能。
ライブラリに頼るんじゃ意味ないじゃん
こういう文脈で言ってる構文解析器って ライブラリを使うんじゃなくてコーディングすることだと思うけど?
196 :
仕様書無しさん :2006/07/29(土) 19:54:35
構文解析器ってツールに頼ることじゃねーの?
LL構文解析プログラムくらいなら情報系の学生はみんな作ったことがあるだろうけど、 それはあくまで理論を学ぶためであって、実用的なツールを作るために 構文解析器から全て実装するような面倒臭いことは普通しないだろ。 クイックソートのアルゴリズムを知っていても、実際に書くコードでは qsort(3)を使うってのと同じだ。 # libcが信用できないから全て自前で実装するっていう変人を除けばね。
198 :
仕様書無しさん :2006/07/29(土) 20:12:12
>LL構文解析プログラムくらいなら情報系の学生はみんな作ったことがあるだろうけど、 夢見すぎ
>>196 が正解だろ
パーサやレキサを生成してくれるジェネレータに食わせて
構文解析のソースを生成する
あとはそのソースに実際の処理コードを追加して完成
Cだとyacc/lexやbison/flexなど、JavaだとJavaCCあたりが定番かな
手間は文法定義のところだが、SQLなど広く広まっている
構文の文法定義は、そこらへんさがせばいくらでも落ちてる
>>198 そうか?
LL構文解析器なんて、情報系では定番の課題だと思うんだがなあ。
少なくともおいらが学生の頃は、必修の実験科目での課題の一つに挙げられていたんだが。
> libcが信用できないから全て自前で実装するっていう変人 djbのことか〜
>へーDB簡単に自作できるんだ? >そいつはPostgres並のを一人で自作していたぞ。一般的にはかなり出来る部類になるんじゃないか? >今はフリーのが出すぎてやめたらしいが。 今時の情報系の大学生ならめずらしくないな・・・。 授業レベルだけど。 Postgres並っつーのはむりぽだけど。 別に構造としてはそんなムズイもんじゃねーからな。 問題はクライアントとの通信やロック処理や安定性なんだけどな〜。 スレッド起動が失敗したとかロックに失敗したとかそーいった レベルの作りこみやそれに付随するテストとか耐久テストとかどうよ。 Postgres並ってそういうレベルでしょ? まあ最低限想定レベルでのテストに耐えられる又は実働しているから お友達は"Postgres並のを一人で自作していたぞ"っていったんだよね?
高卒SEの漏れからすると大卒SEがそんなにレベル高いなら、 苦労しないんだけどなぁ。
俺は情報系の大卒だけど アセンブラとエディタは演習で作らされた
205 :
仕様書無しさん :2006/07/29(土) 22:19:50
まあ、なんだ、構文解析機つくれつやつも、DM作れるやつも(多くは)いらんのですよ。 情報工学系って、大学で学ぶ知識・技術と、実際社会に出てから必要なそれに結構乖離がある。 大学での定番は以下くらいか? ・計算機アーキテクチャ ・OS論 ・コンパイラ論 ・データベース論(オレのところはなかったなぁ) ・ソフトウェア工学 ・文字・画像・動画・音声とかの認識系 ・人工知能 あんま約に立たないよね。まあ、無駄とは言わないけど。 オレは情報系だったから、他は知らないけど、
>>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
ソフトウェア工学は、まあ訳にたつか。 トレンドの移り変わり早すぎだけどな。
トレンドとかいってiとmとsとかがいろんなでかいところが 提唱する〇〇が今流行りだとか信じてデスマするのが この業界のトレンドだからなぁまぁ技術なんて80年の時点で ほとんど完成されていた。ただあのころは非力なマシンしか なくできなかったことができるようになったただそれだけなんだよな
>>206 >情報系大卒が高卒の香具師と一緒に単価の安いSEやプログラマをやるわけないじゃん。
つまり、漏れの知っている大卒SEは学歴詐称ってFA
いや、頭がいいし、文章書くのは慣れてるのは解るけど、
プロジェクトまとめるの素直に下手だし、夢と現実の区別の
つかない設計してたりして、大変なんだが。
そいつのプロジェクトがデスマしていたので、同じ部署の漏れが
手伝いにいった程度だけどサ。
大卒たたきするとあほうがわくよ
>>212 ああ、漏れは本当はSEなんて人生設計になかったんだが、
現場の人間でタマタマ機械の扱いが上手で、
会社が情報処理の資格をとったら報奨金をくれると言うから、
資格をとったらなんでか、プログラマーにされて(w)ついでに
客先にいかされるようになって、知らない間に営業スキルを
身に付けつつ、色々仕事していたらSEになったクチなんで、
大卒はともかく、現場経験のないSEはドリーマーだよな、と思う次第。
214 :
仕様書無しさん :2006/07/29(土) 23:19:18
>>210 >80年の時点でほとんど完成されていた
そうかな?
工学の世界でソフトウェアだけだぜ?こんなに不良率。
機械(冷蔵庫)、電子(AV機器、プロセッサ)、建築(橋、ビル)、そんなに不良無いだろ?
特に致命的なのは、少ない。
それはソフトウェア工学がまだまだ完成していないから。
完成できるかどうかは知らん。
年間300万台近い自動車がリコールになってることは まったく考慮されてないの?
216 :
仕様書無しさん :2006/07/29(土) 23:48:38
>>215 ソフトウェアなんてその比じゃないだろwww
>>215 世界でいくつかどうしているか検討もつかないようなWindowsに毎週バグが見つかるわけだが。
累計、何兆じゃきかないんじゃね?
バグ数×出荷数=?
218 :
おじゃばさま :2006/07/30(日) 00:10:27
>192 残念だったな、WEBサービスではバイナリを送る仕様があるんだよ。少しだけ勉強が足りなかったな。 WebLogicの仕様書があるなら、WEBサービスの「添付ファイル」で調べてみな。 でも192がそれなりにWEBサービス知っている事は認めてやるよ。 バイナリが無理って言う段階で一般知識はあることが分かる。 普通の奴は「SOAPなにそれ?」ってレベルだからな。 ただ普通の人は、SOAPなんて頑張って勉強する必要はないぞ。きっと流行らないから、 なんだかんだいってPostgres並のを自作ってのは、出来るレベルって事でいいだろう。 別に友達のことだから自慢する意味もないが、評価は正しくやらないとな。 だから笑うなら、それなりの事を書いて欲しいな。 引用して「どれだけ笑えばいいの?」みたいな書き込みは、恥ずかしさを通り越して情けないよ。
そのこてやめれ
220 :
仕様書無しさん :2006/07/30(日) 00:22:27
そうそう、WebLogicで思い出したけど、国内のJ2EEサーバのシェアしってた? 1位:IBM 2位:富士通、日立 (毎年入れ替わる。どっこいどっこい) 4位:WebLogic なんだぜ?以外だろ?
WebLogicだけ製品名だったな。。orz
BEAってあまり社名は耳にしないな WebLogicと結びついてるのかさえあやしい
情報系の大卒がそんなにちゃんとできるやつばっかりだったら世の中幸せです。
224 :
仕様書無しさん :2006/07/30(日) 00:40:10
ビジネスロジック
>>218 そりゃ知らなかったな
でもWebServiceの仕様って、BEA、IBM、Microsoftでそれぞれ独自拡張してるよな
例えばWebLogicのみの仕様だとSOAPの標準仕様に沿ってはいないことになる
今時の業務じゃこの三者が入り乱れる構成ってのは考えにくいからかまわんと言えばかまわんけど
SOAPの標準仕様に沿っているのかを確認したいところだ
特にWebLogicはバックエンドのT-Engineとの連携ためにバイナリ型を用意してる可能性もある
T-Engineまで使ってるやつがそうそういるとは思えないけど
>なんだかんだいって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まで来たか。オラクルのバージョンを超えて しまうのは凄いな。
Java厨よりレベル低い奴とJava厨との狂演だからな まあ前者は.NET厨なだけだから当然といえば当然だが
未だにSOAPとかいってる時点でレベルが低い WSDLあればそれ以降はなんだっていいという ことに気がつけないバカの集まりだな
レイヤーの違いでレベルが低いとか言ってる奴ほどレベルが低い奴は居ないな HTTPに対してTCP/IPであればなんだっていいと言ってるのと変わらない
233 :
おじゃばさま :2006/07/30(日) 09:23:06
ちがうだろう。Javaのソケットにはポートは使わないんだよ。糞ども。
↑騙り、イクナイ
235 :
仕様書無しさん :2006/07/30(日) 11:46:35
なにかあるとすぐ再起動。 とりあえず再起動。 それがwebLogic
それは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
大規模開発ですから
>>239 確かに開発は大規模。その割りにできあがりはしょぼい。
242 :
仕様書無しさん :2006/07/30(日) 12:22:20
なんだよひとつぐらいまともなAP鯖ってないの?
お前らがそうレッテル貼ってるだけなのに何がまともになるんだろうか
いやAPが100%落ちないようになることは無いんだよね JVMがもっとまともなものにならない限りムリなんだよね
JVMが原因で落ちた経験ないし まともじゃないのはお前らの知識
246 :
仕様書無しさん :2006/07/30(日) 12:26:37
それじゃあ VMがソース公開されたのは 優秀な誰かに直してほしかったのが公開の真相なの?
それじゃあ とか 真相 とか痛いレスしかできないのか
248 :
仕様書無しさん :2006/07/30(日) 12:30:51
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厨とかに勝てないからって他を持ち出してるだけだろ
>>250 おまえ学生だろ?C屋はPERLすら使えない奴でごろごろしてるぞ
>>252 このスレで負けまくって何を言ってるんだ?w
255 :
仕様書無しさん :2006/07/30(日) 12:38:45
あははJava厨がマジになってる。 C屋は69式のおっさんみたいにそれ一本で需要があるんだよ。
256 :
仕様書無しさん :2006/07/30(日) 12:40:43
Java厨さんよ、たまには自腹で ソフトを購入してみろよ。
日曜なのに盛り上がんなよ...
>>255 は自分の馬鹿レスに気づけない。おわっとる。
259 :
仕様書無しさん :2006/07/30(日) 12:42:04
Java厨は永遠に仏滅。
C屋からすれば自腹でソフト買う奴は馬鹿なんだが・・・
261 :
仕様書無しさん :2006/07/30(日) 12:43:12
ちょっと書いとけばすぐにくいつくからjava様たち
>>253 以降すぐレス来ただろw
煽るのが目的であって自分が無知であっても気にしない そんなのばっかJavaを仮想的にしてる
263 :
仕様書無しさん :2006/07/30(日) 12:45:20
仮想マシンだから 仮想敵にされる。
だれが上手いこと言えと言った。
煽り目的にされちゃった
265 名前:仕様書無しさん [↓] :2006/07/30(日) 12:46:55 煽り目的にされちゃった 一度も高尚なレスがつけられないのにw
↑のレスは実に高尚ですね
どこが?国語力皆無だな
269 :
仕様書無しさん :2006/07/30(日) 12:51:08
登場から10年もたつのに、VMって安定しないの?
270 :
仕様書無しさん :2006/07/30(日) 12:52:02
あせだけでつくってりゃいいんだよ
271 :
仕様書無しさん :2006/07/30(日) 13:00:25
272 :
仕様書無しさん :2006/07/30(日) 13:02:18
上記から引用 >また,C++ではテンプレート引数が特定のメソッドや演算子を >定義していることを前提としていても,実際にそれが呼び出されない >限り実装する必要がない。ところがJavaの場合,実際に呼び出すか >どうかにかかわらずすべてのメソッドを実装する必要がある >(空でもよいが)。 メモリ食いの基本仕様
>>244 そうだね。JVMがAbortするのはよくあること。
>>245 > JVMが原因で落ちた経験ないし
> まともじゃないのはお前らの知識
おまいが小規模開発しかやってないから。
まともじゃないのはお前の経験ってことになる。ってもしかして新人か?
274 :
仕様書無しさん :2006/07/30(日) 13:04:43
使う必要のないものをごたごた実装して メモリ負荷を高めてごちゃごちゃ素人がいじくるのがJava。
やっぱjavaに比べたらc++難度高いからなんだろうな 使いやすい方に流れるわけ 良いか悪いかは知らん
CPUとメモリを優先的に食いつぶすのがJavaの仕様ですか。
> C++のテンプレートに相当するジェネリック(Generics)をサポートしたこと この記者馬鹿だろ?
VirtualMachineだから、OSのリソースを全部奪い取ってVMだけでマシンのリソースを全て管理するっていう思想なんじゃないかなー
>>273 >おまいが小規模開発しかやってないから。
>まともじゃないのはお前の経験ってことになる。ってもしかして新人か?
まったくもって的外れだな
281 :
仕様書無しさん :2006/07/30(日) 13:12:22
JVMは自分がわるくてもJava厨の書いたコードが 悪いように例外処理のスタックを表示するからな。
"DOT NET" Abortと件数一緒なのが面白いな
.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分以内に粋なレスが出ることを期待してたのに。とまっちゃった。
それそのものが逃げレスなんだが
>>282 内容は違うがな。"DOT NET" AbortはAbort()メソッドも含まれている。
"DOT NET" Crash の検索結果 約 599,000 件中 1 - 10 件目 (0.04 秒)
Java Crash の検索結果 約 18,900,000 件中 1 - 10 件目 (0.43 秒)
".NET" Crash おまえらはこっちだろw
290 :
仕様書無しさん :2006/07/30(日) 13:34:33
291 :
仕様書無しさん :2006/07/30(日) 13:39:06
実装によりけりだから
293 :
仕様書無しさん :2006/07/30(日) 13:41:03
しかし、Javaは美しい。
294 :
仕様書無しさん :2006/07/30(日) 13:41:47
Java村 Perl村 (w
perlに比べりゃな javaが美しいとまでいか泣けど
>>291 さすがに酷いな
Javaでも50万仕事だと思う
297 :
仕様書無しさん :2006/07/30(日) 13:50:14
>>292 それは簡潔な理由なのかな?
SUNのVM限定という前提でいいよ。
SUNそのもので変わってるだろ セマフォ以外になんと言えばいいんだ
299 :
仕様書無しさん :2006/07/30(日) 13:53:12
え!ほんとにセマフォでいいの?
?の意味が分からん
301 :
仕様書無しさん :2006/07/30(日) 13:56:27
ソースみた?
見てない
303 :
仕様書無しさん :2006/07/30(日) 14:01:39
見てないで断定できるんだね。すげえな。神だな。
mutexだろうがなんだろうが結局カウント1のセマフォだしな ワイルドカードで答えてるだけだ
Java神登場か
306 :
仕様書無しさん :2006/07/30(日) 14:05:20
うむ。>302は新時代のJava厨神だな。 あがめようではないか。
神とか言ってるが何で書けばセマフォじゃなくなるんだ?
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の変わりにセマフォだ。 ソース公開されてるんだから、見ればいいやん。
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==セマフォの機能限定版
JVMは、C/C++の実装は得意じゃないし制御厳しいから 中途半端に実装してるね。どこもかしこも限定限定、最小機能ばかり
そらWindowsでkqueueは使えん罠
317 :
おじゃばさま :2006/07/30(日) 18:53:14
>226 少しだけ頑張ったようだが、その程度の説明か。しかも論点ずらしてるし。まあいいや。 俺のおめでたさを笑う所なんだ。 へー、笑うほど面白いのかね。リンク厨の思考原理は難しいね。 ちなみに、202はその説明だけでも俺の言いたいことを大体理解しているみたいだけどね。
EPを目指すときの保証を極めようとするとすぐにレベルが上がる。 マルチスレッドにしてもそうだ細かいチューニングや保証は理論以外にも 経験則も必要だし厳しいそれは言語というレベルではなく現実的なクリティカルな 問題として難しいんだよ でもね、JAVAはこのクリティカルな問題をやるには不向きだよ
EPって衛星放送?
>>317 すまんが大爆笑だ。
202=226なんだすまん。
Postgres並って言うんでどうせこんな
もんだろって206で指標書いてんで
最低限何台クライアントが接続できるかとか
どれ位の耐久性があるのかとか
”それなりの”返答するとおもったら
>なんだかんだいってPostgres並のを自作ってのは、出来るレベルって事でいいだろう。
をいをい、こんな適当以前の台詞吐いたら、
>ここ笑う所
って書くしかないだろ?
もれどういう返答したら言いの?
納得したって引き下がれば良いの?
釣ったつまり毛頭ないんだが、Webロジック改め幸せロジックに多いに笑わせて
貰った。
釣ったつまり毛頭ってなんだ?
つまり毛が頭にない、禿ってことだろ
323 :
仕様書無しさん :2006/07/30(日) 21:19:53
しかし、Javaは美しい。
けど使い物にならん
325 :
仕様書無しさん :2006/07/30(日) 22:40:37
君が使いこなせないだけ。
Javaやってる人って、すごい人と使えない人との両極端で、中間層が薄い気がする。
>>325 みたいなのが使えない人
おじゃばさまが中間層かもね
時代のツールだから使ってるだけってのもあるしな
329 :
仕様書無しさん :2006/07/30(日) 22:50:25
せっかく、synchronizedの実装がどうなっているとかそういう話になりかけてたのに、 また醜い煽りあいですかwwwwwwww だからダメなんだよ
.NET厨の酷さは今に始まったことじゃないって
synchronizedをどう実装しろって決まってるわけではないんじゃないの?
昔はCやっててJavaがやりたいといって転職したら.NETをやらされた俺が来ましたよ
HotSpotで実装変わってるしな
334 :
仕様書無しさん :2006/07/30(日) 23:14:14
>>331 外部使用は当然決まっているが、どう実装しようが自由。とうぜんだろ
C#かjavaやてたらどっちもいけるから無問題
PGで言語厨が出てくるのは、複数の習得が難しいからなのかな? どの言語も、他人の掘った穴にすぎないが。
・信者体質である ・生活がかかっている ・実運用に入って酷い目にあった 他にもあるかも
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
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再起動
念のため明日の朝も再起動
ネットワーク系の学科なので、 大学で一回生からjavaしかやらないんですが大丈夫ですか?
大丈夫。 講義のレベルなんて何の役にもたたん。
初心者と五十歩百歩。どんぐりの背比べ。
むしろ初心者の方が、教えたこと素直に吸収してくれる。
>>350-352 レスありがとうございます。
なんか講義って言うより、適当にヒント出されて、
こういう動きをするプログラム書けって授業です。
無意味だから、必修じゃないなら出なくていいよ
>>349 Javaは別にやっといて損は無い。ただそれだけではダメだ。
LispかPrologもやっておくべき(今ならHaskellも候補?)
理由は、これらが広く使われているということではなく、
別種の言語を学んでおいた方が他の言語の理解が深まるからだ
(Java厨じゃない人には分かるよな?)
あと、アセンブラかBrainfuckをかじっておくとなお良い。
コンピュータがどのように動くかを見るのにもってこい。
ネットワーク系を理解するなら、C言語でテキストブラウザを作るという課題が俺的に最高。
フレームワークに隠されて見えない部分が見えるようになり、
フレームワークの理解が更に深まる。
訂正。 > ネットワーク系を理解するなら、C言語でテキストブラウザを作るという課題が俺的に最高。 「C言語で」は脳内消去してくれ。別に言語は何でも構わん。ただしTCP Socketを直接使うことが条件。
357 :
仕様書無しさん :2006/08/01(火) 01:05:36
Java厨じゃないが C++を勉強するほうがいいとおもうぞ。 Javaをほしがるのは三流ビジネスロジック会社だけ。偽装派遣系。 C++はメーカーの研究室などで使われる。
358 :
仕様書無しさん :2006/08/01(火) 01:08:18
ネットワーク系を理解するならば DNSのパケットダンプを解析するとめちゃ勉強になるぞ。
とりあえず、勉強の成果として基本情報は取っとけ。
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が時代を席巻するのはいつごろですか?
おじゃばちゃんは今日はマダ?
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しかできない。 やっぱり嘘はつけないな。
おじゃばさまはトリップ付けろよ! と今から言ってもいろんなトリップのおじゃばさまが出てくるわけだな。
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
はいよ。 これで文句ないな?
バカ1人
なんだよ俺のことかよー! じゃあお前はアホだ! アホバカコンビでも組もうぜ
376 :
仕様書無しさん :2006/08/02(水) 01:23:57
おそらくJavaエンジニアの多くが、HTMLベースのおなじみのWebアプリケーション開発の現場で、 ある種の“カベ”に直面しているのではないだろうか。顧客のニーズを満たすために、 HTMLの制約と 格闘する苦労。データベースとHTML間のバケツリレーに終始する中で生じる、 「なぜPHPではなくJavaなのか」という疑問。
SUN Java Desktop これほど笑えるデスクトップもねえよw
ふつーのGNOMEデスクトップに見えたので 笑いのツボを教えていただけると嬉しい
ただのGNOMEデスクトップにJavaと冠する必死具合が笑いどころ。
俺、このJavaのデスマが終わったら、PHPで開発するんだ
ちょ、それ死亡フラグ
382 :
仕様書無しさん :2006/08/02(水) 13:57:33
うっせーハゲ
>>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しか出来ねんだもん。
別にJavaはGUI作るの面倒じゃないぞ .NETってかMFC+VCフォームエディタくらい速度で作れる あとC++とかはJava専門で入った俺より雑魚い奴多くて引く時あるから 多言語にあまり夢見ん方がいいぞ 選り好みせず満遍なく抑えとくってのはいいことだけどね
391 :
仕様書無しさん :2006/08/02(水) 23:04:39
393 :
仕様書無しさん :2006/08/02(水) 23:11:22
よかったね ファン・ランダエタの勝利だって
397 :
仕様書無しさん :2006/08/03(木) 17:30:38
ファイティング原田は?
モスクワはもうすくわれないな
>>389 あぁ、GUI使うショボイのだったら.netだろうな。
でもな、基幹業務やってるような人は.netなんか最初から相手にしないんだよ。
いや基幹業務だったらついでにJavaも相手にしたくないがw
やはりCOBOLか。
MQだ時代はMQだってさこれから30年ご見据えた技術それがMQ
MQの旬は既に終わってると思うが。 非同期蓄積型通信のメリットはわかるが、MQに絞って使う必要性は感じない。
MQは既にJ2EEの1パーツとして定義されてるじゃん だからJ2EEまんせーというわけじゃないが、MQが主役にはならんよ
MQってトランザクション処理に使えねーじゃん。 分散が広がらない根本的な理由がトランザクションなのに何言ってんだ。
>>405 分散が広がらない根本的な理由がトランザクションなのに何言ってんだ。
日本語OK?
>>407 MQと分散と根本的につながりは無いんだが。
J2EEは分散だけとかどこのDQN上がりだ?
409 :
おじゃばさま :2006/08/08(火) 20:27:16
分散って処理分散?データ分散?
410 :
仕様書無しさん :2006/08/08(火) 20:50:59
はいはい亀があるくようなWebサービスをJavaで公開しないでね
>>410 亀とは…
おまいやさしいんだな
なめくじでいいのに
いや、塩かけられたなめくじでいい
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が提供される方がマシだと思うが。
( ゚д゚)
416 :
仕様書無しさん :2006/08/09(水) 19:49:20
はあ? クライアントはなんでもいいのがWebサービスじゃないの?
>>416 まあまあ、相手はJava厨なんですから・・・
418 :
仕様書無しさん :2006/08/09(水) 21:22:07
おじゃばさまってスキル低いんだね
419 :
仕様書無しさん :2006/08/09(水) 21:32:23
なんかネタっぽいなぁ・・・
いや、マジでSOAPやWSDLの部分は知らずにJavaのラッパーでお手軽関数コールしてるのかもしれない。 .NETもそんな感じだけど。
421 :
仕様書無しさん :2006/08/09(水) 21:43:10
Java厨ってさ、観念的というか素人っぽいんだよな。
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
遅いもんは遅いから
富永一○ってまだ生きてるんだっけ?
レバノンで爆死しなかったっけ?
グゴォー フガフガフガフガフガフガフガフガ
スキルで言ったらJavaやってる奴らより .NET の奴らが最悪だろ。 あいつらは言う事だけはいっちょ前で 実はプログラマーじゃないな。 IDEの性能の良さや、便利なタグライブラリを 自分のスキルだと勘違いしてる激痛なやつら多すぎ。 まぁJavaやってる奴らも、せめてOOPぐらい 分かれば?って奴ら多いけど。 .NETの奴らがOOPをまっ・・・・・たく!分かってないのは 言うまでもない。 データを渡してデータを戻すだけの関数の集合体 勘弁してくれよ。。。
まぁ、そんな奴らでも動くシステム作れる .NET は素晴らしいね
ブッ○ュって未だ生きてるんだっけ?
シンスケキモイw
タモ○って未だ生きてるんだっけ?
434 :
仕様書無しさん :2006/08/09(水) 23:35:08
いやいや屑でシンプルさのかけらもないAPIを覚えても明日がない。 再利用性もない。つうか推奨されないものだらけ。 こんな夢の島のような環境で生きていられるJava厨は凄いよ。マジで ハゲるわけだよw
435 :
仕様書無しさん :2006/08/09(水) 23:36:48
あれからなー API作ってから「ありゃ遅いねこりゃだめだな」 よーし内緒で推奨しないマークつけちゃえってやってるのかな?
>>429 それはそれでデータ中心型のアプローチになってるなら、OOPにないメリットとかはあるかも。
437 :
仕様書無しさん :2006/08/09(水) 23:38:06
Javaデバッグってすげえとろくて待たされてイライラしてハゲちゃうよね
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はどの程度できますか?」 私(フッサフッサ)「ええ、まあそこそこには」 面接官(ピカピカ)「では開発の現場を見学してください」 私(フッサフッサ)「はっはい」 面接官(ピカピカ)「ここが開発第一部です」 ・・・頭がすだれ、バーコード、てっぺんはげ、生え際危険 ほとんどがハゲだった。。。
ちゃんと組めばJavaは、もう言う程遅くはないだろ。 時間のかかる処理の大半がDBアクセスだ。 テーブル設計、インデックス設計、SQLをきちんと書けば 普通には動くぜ。 処理時間のほとんどがロジックにかかるとか普通ない。 Javaのデメリットをパフォーマンスとしか言えない奴らは お前らがへちょいだけ。 最大のデメリットは何と言っても工数かかりすぎ、めんどくさい、 フレームワークとAPI多すぎのため勉強してもキリがない。 これに尽きる。
>MVCのコントローラテストサーバ 意味不明w
ふぉがぐふぁふぇふぃうひゃー眠い
ザ低脳
モデルビューコガコガフガフガ・・・
MVCモデルって不毛だよな。 同士のBEAには弱点指摘されて勝手に改良されちゃったし。 その改良も弱点をちょっと補強しただけだし。
転職天国
正直、新しい物は変な設計が多いからな。
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
デブは?
短足は? メガネは?
結局さ、食ってくには何がいいのよ? お前らがいいって言うものを勉強するからよ。
農業かな
456 :
仕様書無しさん :2006/08/10(木) 03:05:24
WIN系はパソコン&エロゲオタクばかりけどな〜
458 :
ハゲ厨 :2006/08/10(木) 09:38:47
いいんだよ、ハゲなヅラボクサーにも毛が生えたんだし
459 :
おじゃばさま :2006/08/10(木) 09:53:25
>415-420 WSDLだけあれば、自動生成で作ったAPIで必ずつながるって言っているのかな? それとも自動生成のAPIを手動で修正して動くように出来ないのはスキルが低いって言っているのかな?
WIN系というかマはオタク
半角キモイ
C臭がする
>>459 そう気を揉むな。お前には何も言ってない。
465 :
仕様書無しさん :2006/08/10(木) 12:24:05
はーげーはーげー つるっぱげw
466 :
仕様書無しさん :2006/08/10(木) 15:12:09
Javaよくしらないんだけど、そんなに再起動が必要なの?
http://naoya.g.hatena.ne.jp/naoya/20060513/1147489425 # takuya 『藤田社長のブログから来たけど、このはてなって会社大丈夫?
この方法では、小規模な開発しかできない。
また、組織として開発することもできない。
数人の非常に優秀なプログラマーでの開発にのみ適用できる方法だ。
独りよがり、世間知らずの考えから抜けた方がいいですよ。
コミュニケーションなくても仕事するような人は、そもそも少数派。少数派を中心に考えてはならない。会議に出さないって、どうやって目的を伝えるの?
大規模システムにおいては、仕様・要件の文書化、コミュニケーションは必須です。
また、それなりの人数の会社組織を破綻させない為には、上記のような生産性は高いが好きなときに仕事する人は、非難されなければなりません。
また、それらをスピードを損なわずに行うことは可能です。
なぜ、はてなのサービスが伸びないかもここに根ざしてると思います。
独りよがりな雰囲気がするんだよ。解らなければ、使わなくていいよみたいなさ。ふつうの人はそれだけで、バイバイだよ。一生懸命作った便利な機能について、認知しようともしない。
こんな見当はずれのコメント出す前に、自分を良く見つめ直してほしいものです。』
禿禿って、Javaやってる人には禿が多いのか?
469 :
仕様書無しさん :2006/08/10(木) 16:19:02
そうなのよー
470 :
仕様書無しさん :2006/08/10(木) 17:17:14
体育会系は少ない。 酒も煙草もやらない知性のある人が多いな。 大酒飲みのDQNはCOBOLとかCしか出来ない爺。
人を見下す奴とはやらねぇよ。 やってて不愉快、無理。 こっちが気を使ってりゃ調子にのって上から物を言うようになる。 コミュニケーション取れないのはどっちだか。
問題の全てはキミの自信のなさにある。 能力があろうが無かろうがその挙動じゃ無いように見えるし、 調子にのられて詐欺にあいやすい。 恐怖を倒せばきっと本来の力が発揮できる筈。 己との戦いだ・・・・。
473 :
おじゃばさま :2006/08/10(木) 19:52:34
JavaとCじゃ、Cの方がハゲが多いだろう。 ただそれは言語のせいじゃなくて、年齢のせいだろう。
. . . . . . . . . . . ∧_∧ . . . . . . . . . . (. .・∀・). . \ . .‐=≡t─‐/ヽ、_つ). .__s) ‐=≡(ニニ(. . ..)../\\-.\ . .‐=≡(. .(ニ:(. ./oz|. .(O)T . .‐=≡ヽ、__,ノ ̄. . ヽ、_,ノ
Java系の使えない奴は自分が使えないと分かってていつもびくびくしてる C系の使えない奴は自分の無理解を切れてごまかそうとする どっちも救えなさ加減はおなじもんだが
チッ、ブッ○ュは生きてたか
mission failed...
9.11.. 8.11.. 7.11....
tikajika omaewo biku biku sosite ang saseteyaruyo
480 :
仕様書無しさん :2006/08/10(木) 21:47:42
Racial discrimination
To cyber terrorist
重い重いと騒いでるのは禿げたおっさんか。
483 :
仕様書無しさん :2006/08/10(木) 23:00:08
サーバの処理性能が上がってるから今ならそんなに重くなくね? よっぽどクソなプログラム組んでるか1秒未満の処理時間の差すら感じられるスーパーPGなら別だが。
一秒未満の処理速度の差って割と分かると思うがw 感じるか感じないかじゃなくて、気になるか気にならないかだな
なんかJava厨の痛いのが騒いでるな。 おじゃばさまが恋しくなってくるぜ。
486 :
仕様書無しさん :2006/08/11(金) 00:45:51
どうしてプログラマは仲が悪いんですか?
487 :
仕様書無しさん :2006/08/11(金) 06:37:13
組み込み分野では1ms以下の世界を考えなければならないんだが
典型的な馬鹿レス登場w
ロジックの組じゃなくて同期処理等を突き詰めると、 数百ms単位で早くなる場合があるんだが。
490 :
仕様書無しさん :2006/08/11(金) 11:34:58
Java厨の視点−>サーバを利用する側での視点しか持てない
Java は難いよな。
492 :
仕様書無しさん :2006/08/11(金) 16:37:47
ショップブランドPCを買おうと思っているのですが 秋葉原のお店でどこがおすすめですか?
マハーポーシャとグレイスフルと・・・・あとどこだっけ?
494 :
おじゃばさま :2006/08/11(金) 21:01:24
まあ分野によるだろう。 WEB屋なら1秒ぐらい大したことないかもしれんが、電話や動画屋だと500msぐらいからヤバイ。 ルーター組み込み屋とかだと487の言う通り、1ms以下の世界だしな。 でもJavaで出来るのは電話や動画以上だから、1ms以下の話は意味ないな。 ただ電話屋にとっては1秒は長すぎるぞ。WEBと電話で分けて話した方がいい。
組み込みJavaは実際にあるし何とも言えんな まあランタイム系ならエンドポイントの精度は期待できん ミリ秒で処理出来る出来ないの話だけならできるがね
496 :
69式フリーPG ◆hND3Lufios :2006/08/11(金) 22:32:00
Javaがブレイクした2000年頃というのはCPUのクロックが1GHz越えを目指した頃で、 半年毎にバンバン上がっていってた。 で、2003年頃から3GHz前後で停滞期に入るんだな。 Javaが広まり、停滞した理由はこの辺にもあったり。
Core2 3GHzが普通にノートに載るような時代が来れば 俺はJavaだけでいいかなと思ったりもする。
498 :
仕様書無しさん :2006/08/11(金) 22:49:22
/⌒ヽ ∩ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ / ´_ゝ`)/<先生!アウトローSTOP115です!w _ / / / \____________ \⊂ノ ̄ ̄ ̄ ̄\ ||\ \ ||\|| ̄ ̄ ̄ ̄ ̄|| || || ̄ ̄ ̄ ̄ ̄|| テイノウイミナシバカスレバカレス
>>494 電話って言われると携帯からJTAPIまで幅広く上げられるがどーいうレベル?
おじゃばさまだと、SIPのServletとか挙げるだけで精一杯だろう。 あんまりいじめるなよ。
501 :
仕様書無しさん :2006/08/12(土) 10:49:09
javaは変なUIを改善して欲しいし、 変なフォントも辞めて欲しいし、 IDEが軽くして欲しい バージョンをまとめて欲しいし、 JDBCドライバもフレームワークも優秀なのを1個にしてほしい
502 :
仕様書無しさん :2006/08/12(土) 11:29:22
Eclipseなんか捨ててemacsを使おう。
emacsつかうとなにかいいことあんノ?
504 :
仕様書無しさん :2006/08/12(土) 11:41:45
軽い
コピペがマウスを使わずに素早くできる
Ctrlボタンが禿げる
507 :
仕様書無しさん :2006/08/12(土) 13:50:03
ESCもハゲるまるでJava厨
ビジネスロジック
結局、重いのか重くないのか
その昔はemacsといったら重量級ソフトの代名詞だったのにw
重くねぇっつってんだろ
513 :
仕様書無しさん :2006/08/14(月) 23:07:36
515 :
仕様書無しさん :2006/08/15(火) 00:35:50
じゃあ私は、乙女
# emacsは起動以外重いとは感じない。 それで、Javaは結局 起動時も起動時以外も常に重いの?
>>517 重くないと思うよ、128ノードのクラスタ使ってるけど
遅いとかいってるやつの脳みそどうなってるか本当に知りたくなるよ
519 :
仕様書無しさん :2006/08/15(火) 03:50:54
>>497 そのころはJavaがもっと重くなってる
>>517 > それで、Javaは結局 起動時も起動時以外も常に重いの?
重いね。重いというほどひどくはなく、もっさりしているという感じ。
それでも多言語で作ったアプリを触ってからだと重さが際立つね。
多言語→他言語
518の脳味噌覗いて見るか
レスありがとうございました。 私のPCがどこか格別おかしいってわけじゃないらしいことが なんとなく分かりました。 ただ、私はそのもっさりにストレスを感じずにいられません。 # ストレスを感じないコツってありますかね? Javaに期待している人達って、H/Wの処理能力が将来 画期的に向上することを想定しているんですかね。 # OOであることがその次世代の何かと親和性があるなら # Javaはそういった将来で結実するのかな。 今は重いですけど。 私は1ノードで開発しなければなりません。 Javaの良さがいまいち分かりません。 現状の重さを犠牲にしてJavaは何を優先させていますか?
ふ〜んすごいね そんなに自身の生産性が高いならそれを活かせるシステムを新たに作れば良いだけじゃないの? どうせ奴隷の様に働くしかないんだからゆったり仕事すれば良いのに
おじゃばちゃんは最近来ないね。 自殺したのか?
だからお前ら何度も言わせるな。 Javaのデメリットをパフォーマンスとしか言えない奴らは お前らがへちょいだけ。 最大のデメリットは何と言っても工数かかりすぎ、めんどくさい、 フレームワークとAPI多すぎのため勉強してもキリがない。 これに尽きる。 分かったか?
すれ停滞してるからってわざわざねたふらんでもいいよ
>>526 じゃ、フレームワーク使わなきゃえぇやん。
APIもそんなにたくさん使うか?
SEが使うAPIなんてたかがしれてるだろ?
工数掛かりすぎってどこの雑魚だよw
>>526 おまえは一生こつこつ車輪の再発明でもやってろ。
>>528 自社で受託開発をしてれば、フレームワークを使わんでもええとか
言ってられるかもしれんが、
現場に出てたらそんな事言える訳ないだろが。
その会社独自フレームワークを使ってたりしたら、派遣相手でも
講習会とか研修あるぐらいやぞ。
struts, O/Rマッピング, DIコンテナ を押さえてれば
どこ行っても似たようなもんだが、それでもその会社が作った
リファレンス見ながらの作業は明らかに非効率だぜ。
>>529 >>530 はいはい、お前らはちょっとかじって出来る気になってる
痛い奴らやから黙ってろ。
実際にJavaの開発現場を何箇所も踏んでて、実状を知ってる奴らなら
そんな事絶対言わんからな。
200 〜 300 人規模のプロジェクトで 1 〜 2 年かかってんのは
工数かかりすぎじゃないのかよ。
10 人程度の小規模プロジェクトで半年とか、かかってんのは
工数かかりすぎじゃないのかよ?
それに人件費だけでどんだけかかると思ってんだ?
Javaの案件が減少してて、.Net なんかの案件が増加してきてる傾向が
全てを物語ってるだろうが。
200〜300人規模の.NET案件が増加しているという強引な論調にワロス
>>532 それはJavaの案件の話で、.NET の事は良く知らん。
逆に.NET でもそんな大人数でやるプロジェクトとかあんの?
>>531 > どこ行っても似たようなもんだが、それでもその会社が作った
> リファレンス見ながらの作業は明らかに非効率だぜ。
お前にとってはそうかもしれないが、会社側からすれば保守やメンテなどがあるからな。
一部の作業が非効率だろうが、全体を通して効率があがればよい。
とはいうものの、できてない現場のほうが多いが・・・。
管理側からしてみれば、俺の作ったフレームワークで俺が思うとおりに書いてくれ。
インデントすらも俺の好みにあわせろ!ってかんじだろ。
派遣なんて使い捨てだからな。
後、フレームワークやAPIが多くて勉強してもキリがないとか言っているが、
こんなもん、どの言語でも一緒だろ。
どの言語でも、会社による独自APIや、ライブラリがあるだろ。
CやC++の独自ライブラリにはひどいものが山ほどあったぞ。
.Netはまだ普及ぐあいが中途半端なので、独自なんちゃら〜ができてないだけで
普及しだすと山ほどふえるだろ。
> 200 〜 300 人規模のプロジェクトで 1 〜 2 年かかってんのは
> 工数かかりすぎじゃないのかよ。
PMなどがへぼすぎるだけ。
これが、C++だろうが、.Netだろうが同じくらいの工数がかかる。
それより今の時代、半年以上かかってモノ作って間に合うのか?
>>535 間に合わないんじゃないかな。
1年以上かかってるのは破綻したプロジェクトじゃないの?
やめるにやめられず、追加予算をどんどん投入してるうちに、
2年がたってしまったとか。
Javaはさぁ、あの xml 地獄が俺は嫌いなんだよ。
機能を作るのに掛かる工数と、言語と環境による制約から来る 制限を回避する工数とをごちゃごちゃにしないできちんとわけてから 話せ
>>531 PMにフレームワークを使うデメリットをきちっと説明できれば受け入れてもらえるかもよ。
まぁ、使うメリットが大きいから採用してるはずだがな。
大手にいる奴なら
>>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のタグ壊すの知ってるか?
>>542 >・多種多様なOSで動作する。
確かにプラットフォームを選ばないのは一番(唯一?)の利点と言える。
>・膨大な無料のライブラリが使える。
これがデメリットに成り得るんだよ。
一見、多様な選択肢があって嬉しいように思うが
開発者を惑わす事がほとんどだ。
一部の有名どころだけ押さえておけば良い。
>工数は場合によるが、一般的にJavaよりCの方がかかるぞ。
組み込みとWebを一緒にするんじゃねぇよ。
Webシステム如きに半年とか1年とかかけてる所がやばいんだろが。
いや、マルチプラットフォームなのはあくまでC製の「JavaVM」であって、 Javaのバイトコード自体は唯一無二の仕様のJavaVMという1つのプラットフォームでしか動かない。 と屁理屈でもこねてみるか。
おじゃばんには理解不能だろう
547 :
仕様書無しさん :2006/08/22(火) 00:25:55
つうか、なんであんなアホみたいになんでもかんでもxmlなの? パーサがまた重いんだ。
当時は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を使っている。 まあ今の段階では、各種自動生成ツールを使うのが妥当だろう。
SQLでえぇやん
iniファイルでええやん
552 :
仕様書無しさん :2006/08/22(火) 22:52:49
>>549 真面目に質問だが、その調査に半年かかるのでは?
JAVAがマルチプラットフォームを主張するが、
もともとCはシンプルを吉とする、移植性の高い言語である。
プラットホームの違いが関係しない部分は、Cで書いても簡単に移植できる。
そして、UIは手間でも、そのプラットホーム専用を作るべきではないか?
JAVA側の意見は、なんでも人のせいにする言い訳にしか聞こえない。
XML< 複雑なデータ構造なら「バイナリ」で扱えばいいだけ
単純ならCSVで問題なし。
マルチプラットフォームは幻想
>>549 >WindowsのJVMとLinuxのJVMは違う物な訳だから、マルチプラットフォームとは言えないだろう。
Javaが出てくる前はマルチプラットフォームと言えばそういうもんだったよ。
おじゃばさまはJavaができてから技術者になったクチ?
で、プラットフォーム依存の部分は基底ライブラリ化してすげ替えてたもんだ。
その部分を思い切って単独アプリにしちゃったのがJavaVMという位置づけ。
昔とやってることは基本的に変わらない。
それゆえ本当のプラットフォーム依存のおいしい処理が全くできずに単なるウェブ言語に成り下がった
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は自分の設定ファイルと言うより、データの受け渡しに使用する。 画像データや音声ファイルならともかく、テキストに出来るデータをバイナリで扱うとは... 時代逆行が流行っているのか?
XDRとかBERとか知らないうちに結構使ってるものですよ
UIはOS依存の方が全然使いやすいと思うわ 使いにくい共通より100倍まし
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)); // 関数型の変数からローカル関数を実行
}
JavaでもCollectionにdoやselectやcollectが実装されるのか〜
565 :
仕様書無しさん :2006/08/23(水) 22:11:20
>>556 組み込み屋です。
「本」ってどういう単位?
>>558 そういや昔見たJava屋はクラスライブラリのリファレンスを見ただけでは何も作れないやつだった。
デザインパターンとかサンプルソースとかそういうのがないとどう組み合わせて使えばいいのか自分で発想できないらしい。しかも参考にすると言うよりほとんどコピペしてた。
そして自分の思い通りに動かなかったらまず「クラスの設計がおかしい」と言っていた。
あれじゃ、Java以外を書かせても、自分では何も応用できないだろうなと思った。
>>566 それってJava屋がどうとか言う以前の問題だな。
568 :
仕様書無しさん :2006/08/23(水) 23:50:38
>>565 業務系って「本」っていう便利な単位が使えていいよね。
「マスタ○本、エントリ△本、照会□本、帳票×本」とか。
本単位を基準にすると見積もりが楽。
でもそういう単純な見積もりが可能なところが
業務系って単純ドカタ作業ってことを示している気がする。
569 :
仕様書無しさん :2006/08/24(木) 00:34:59
hoge.cで一本じゃないのん?
1本2本…は業務系ドカタさんたちが数えるときに使う単位
571 :
仕様書無しさん :2006/08/24(木) 00:59:27
業務系ドカタはステップ数でつよ
1本っていったら百万のことだろ?
573 :
おじゃばさま :2006/08/24(木) 09:47:58
>554 ああ、そういう時代もあったな。 確かに原理的には大きく違わないとも言えるが、実質的にはかなり違うぞ。 それは「コンパイルが必要ない」って事だ。実際に移植しようとすると、コンパイルオプション地獄や リンク地獄に陥るだろう。あの無駄な作業から解放されるだけでも大変な違いと言えるだろう。 >561 マルチプラットフォームとUIの話が混ざってきて分かりにくくなっているが、 Windowsでしか動かさないプログラムにJavaのUIを使えと言っている訳ではない。 Windowsクライアント用ならVBなどでも使えばいいわけで、共通化は必要ない。 マルチプラットフォームからの話なので、WindowsサーバやLinux、Solarisなどでも同じプログラムを使う 必要がある場合に、共通IFを使った方がいいと言っている訳だ。 WEBシステムを馬鹿にする奴もいるが、WEBシステムの特徴を分かって言っているのかと気になる時がある。 たとえば、画面をまたがってトランザクションが発生するような設計をする奴とか、 サーバイベント駆動型の設計をする奴とか、ブラウザ使用のくせに表崩れを認めない奴とか。 できなくはないが、そんな仕様のために作業者が苦労するのを見て、当の設計者は 「これだからWEB屋はダメだ」とか言う奴がいるからな。
Javaにいもうとクロージャとかいってる糞スラの人間を 見ても2chの糞JAVA房見ても思うが JAVAのやつって本当に使えない死んだほうがいいやつばかりだよな
JAVAを使ってるやつは何のために生きてるんだ?毎度毎度BUG出して 挙句の果てには、火事を出す。お前らは技術者ヤメロ、お前らは無能なんだよ 口ではできます。できます。なんていってるけど頭の中じゃいつ逃げようか いつ死のうかそれしか考えてないだろ。もう消えろよ
そんなにストレス溜める前に Javaと激安派遣JavaPG使うの やめればいいのに
それでは解決しない、クズを根絶やしにしないとダメだ? チョンやシナを見たら解るだろ?増殖するとやっかいんだよ
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達は「クライアントツール」の話をしていたのかな。
つーか >マルチプラットフォームからの話なので、WindowsサーバやLinux、Solarisなどでも同じプログラムを使う >必要がある場合に、共通IFを使った方がいいと言っている訳だ。 という考えがJavaありきで、嫌。 まあ、それはともかく、WindowsやLinuxやSolarisで同じプログラムが動いてるのって (Javaでも)稀なケースでしか無い様な気がするんだが。 そーでもないの?おせーて。
ツールとかならメリットあるからJavaでもいいかとおもうけど クライアントアプリはOS依存UIのほうがよいに決まってる
やはりWFCだね
585 :
仕様書無しさん :2006/08/25(金) 02:21:59
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
まあ、.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
最新の物も初代からの物も全て悪いのがだろ
>>590 見積もったんじゃなくて、既存のものに手を入れる時のことじゃないかと
ドキュメント枚数まで見積もり時に決めるとこrもあるから ありえなくはないけど
少なくともファイル数に何の意味もないことは明かだな 1行のファイルも100000行のファイルも一本なんだろ
595 :
仕様書無しさん :2006/08/25(金) 22:04:02
ボタンとテキストボックス数個のUIの互換性を優先する為に、JAVAを選択するなら本末転倒だ。 複雑なUIの互換性が出来てこそ意味がある。 馬鹿みたいな工数をかけて「得たいの知れない互換性を保つ為に」JAVAで作るなら、 1人のプロのマニュアル書きに、OSに特化したアプリ用の綺麗なマニュアルを作ってもらったほうが良い。
>>563 もうJAVAでなくていいんでないのか…
JDK7からJava VMのセキュア性能がちょっと落ちるらしいな スクリプト対応のためにも関数型の実装は必要だったし Java VMとJavaを分けて考えようという動きはあるらしい
JVMはオプソになればすぐに高速化するし問題も解決する。 実際IntelがJVMを構築するためのミドルウェアを既に開発済みだ ではどこが悪いのか考えてみよう、糞仕様連発する太陽のせいで JAVAは複雑かつ糞になってきた
うえーんいたいよう…
顧客要求に振り回されて糞仕様になっていくのはJava本体も同じということか。
javaを無理矢理使いたいんだろうな
マルチプラットフォームといいつつ、バージョン間の互換性がだめだめ
603 :
仕様書無しさん :2006/08/26(土) 19:08:14
100000行のソースファイルですかw
605 :
仕様書無しさん :2006/08/26(土) 20:27:33
ああ、例の枝番の件?
そんなもん選ばんよ
607 :
仕様書無しさん :2006/08/26(土) 20:29:53
あのさあ、この先糞な新仕様が続々でてくるだろう。 新仕様も皆VMのメモリに読み込んでから実行。 この先も無駄なメモリを使い続ける。 それに過去の推奨されない機能の分も読み込むわけでこれもまた無駄だねえ。
Javaの得意分野に代替言語なんて無いけどな
javaの得意分野って何?
610 :
仕様書無しさん :2006/08/26(土) 21:09:41
Webアプリ+ビジネスロジック
perlでいいいじゃん。軽いし早いし互換性高いし。
ビジネスロジックが外だし出来ないだろ ネットモールレベルの最適言語ならPHPとか.NETと競合してるし
使い分けでJavaを使うってことで、得意分野(?)に特化した仕様だけに意固地に拘って洗練していくのが良いと思うのだが、現状は逆ってことか。 JavaありきでなんでもJavaでできるようにという使う側の都合に振り回されて仕様拡張していくのはあまりうまくないと思うが、誰が得をするんだろうね。 JavaはJavaVMが1台マシンを乗っ取ってJavaVM以外への効率的なリソース配分を邪魔するから、1つでもJava製のアプリを入れると他は全部Java製にしないと自慢のスループットも出ない、というのが現状でそこからこの流れなのかな、と勘ぐってみた。
Sunは既にJVMのJavaからの卒業を意識してるよ JavaがJavaじゃなくなる日は無いだろうが、 JVMを動かす言語がJavaじゃなくなる可能性はある
おいおい、JVMがJavaを動かしてんだぜ?仕組みわかってる?
知ってるよ、コンパイル元がjavacじゃなくなるって意味だ
つまりMSのCLR(CommonLanguageRuntime)と同じ方向ってことかな。 SQLServerのストアドプロシージャでVB.NETが動くってのをうらやましく思ったとかが動機の方針なら寒いが。w
618 :
仕様書無しさん :2006/08/26(土) 22:44:54
>>613 スレッドストレスツールを作った
こいつを動作させてJavaを動かすと笑える
>>617 OracleでJavaをストアドプロシージャに使えたような・・・
これがまた使えないんだ。 OracleにはPL/SQL.
使えるよ、無知って恥ずかしいよな
OracleでJavaストアドって何年前の話してんだ 話題フル杉
OracleにJavaストアドが導入されたのは8iからだよ
真のストプロ書きはJavaなんか使わないよ。
OracleもVB.NETでストアドプロシージャ書けたような?
PL/SQLは互換性高いからね。 少なくとも過去のヴァージョンで書かれたものがその後のもので 動かないって事例は聞いたこともない。
>>627 たぶんJDK1.0系
時代が1.2になろうとしてる時にOracleインストーラが1.0.7を
勝手に入れてトラブル発生しまくりだったからな
631 :
仕様書無しさん :2006/08/27(日) 00:02:31
ストプロではできることが制限されていることが望ましい。 DB上で動作するという特性上、制限されていないと困るのだ。 これは、javaがC言語と異なりメモリやレジスタ、それにI/Oを直接扱えないことと同じだ。
ストアドで何でもできないと困るような糞設計には幸い今のところ出くわしたことはない。
>>632 ぶっちゃけたところトリガすらまず使わないことが多いしな
oracleでスカトロ使えるのかすげぇぇぇぇぇ
ところがどっこい データとメソッドを常にひとまとめにしなければ納得がいかないオブジェクト指向基地害が設計すると・・・・・
637 :
おじゃばさま :2006/08/29(火) 09:15:32
>595 サーバツールの話でいいんだよな。馬鹿みたいな工数かけてJavaで作る? なんでJavaで1つ作るのと、各OS用に複数作るのとで、1つ作る方が「馬鹿みたいに工数かかる」のか? Javaで作る方は素人で、各OSの方は熟練者なのかな?同じ熟練者で考えてくれよ。 595がJava知らないから、上手く作れないってだけじゃないか? あとサーバツールの操作マニュアルなんて基本的に初心者に書かせるようなものだから、 そんな所にスキルの高い者を使う事を想定してはだめだろう。
Javaはバージョン毎に調整・テストしなきゃいけないから1つで済むとは限らん。 Java以外ならマルチプラットフォームGUIライブラリを使うんだから各OS用に作る必要無し。
>>638 そういうものがあると実際使えるは全然違うぞ
ちゃんと働いてからもの言おうな
プロパにJMeter使えといわれたよ。。。。 マジで鬱・・・orz
鬱の原因は何よ?
サーバもJMeterも同じノート(128MB)で試せといわれたに違いない
例えば彼女からの別れの電話がかかってきたとき JMeterでテストをしていてトラウマになったというのはどうか
「オレのぶっといテスト計画でお前のウブなサーバを溢れさせてやるぜ」 みたいなセクハラ発言かな?
>>639 >
>>638 > そういうものがあると実際使えるは全然違うぞ
> ちゃんと働いてからもの言おうな
C++/wxWidgets製の製品をリリースしてますが?
パフォーマンスも良いし、OSネイティブなGUIになるため親和性が高い。
ソースファイルも一つで済むから一度書けばどこでも動く。
Java/Swing版もあったがOS毎に挙動が違って使い物にならず配布中止。
元々異なるものを一つに統一しようなんて所詮無理なんだと思った。
646 :
おじゃばさま :2006/08/30(水) 20:43:48
>645 ほう、なかなか良さそうだな。時間が出来た時に試してみるか。 ところで「Solaris64ビット版」と「HP-UX」でもちゃんと動くか? 最近Solaris見捨てられたのか、まともに動かないのが多いんだよな。 特にSunStudio11のC++とか使ったりすると。そこが気がかりだ。
>>647 あからさまに寒すぎて既に痛いよ
もっと上手にぼけろ
650 :
仕様書無しさん :2006/08/30(水) 23:43:34
大学の演習でviでC言語組まされてるんだけど 実際現場でもviなの?教授が言うにはviで組むと超速く書けるらしいが・・・
>>650 Unix上でviな
viだけではまだだめ
別に超速くかけても出来上がるソースはバグって無いかはわかりません マウスカチカチ野郎やコピペでご丁寧にぺちぺちぺちぺち様とかだったら ちんでくださいとぶん殴れる許可がもらえる程度(まじ見てるといらついてくるから)
653 :
650 :2006/08/30(水) 23:55:43
>>652 自分そのスタイルなんですが・・・CTRL+X,C,Vは一応使ってる
さてどうしませう
ネットワーク管理者ならviでokだが、PGならemacsを使えないとね。
プッ
656 :
仕様書無しさん :2006/08/31(木) 00:06:27
おれemacsはおわらせかたしかしらねw
それでいい
ESC-x help-with-tutorialでおじさんと勉強しよう
それなら人差し指だけタイピングでな
わるいけどおれこゆびないんだ・・・
人差し指だけあればいい
663 :
仕様書無しさん :2006/08/31(木) 12:06:09
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 ・リークしない ・不振な挙動しない ・糞プラグインが無用
668 :
おじゃばさま :2006/09/04(月) 09:06:30
>666 逆に言うと、スピードは変わらんって事か?
669 :
仕様書無しさん :2006/09/04(月) 11:39:48
Javaより遅いものはこの世に存在しません
671 :
仕様書無しさん :2006/09/04(月) 22:56:08
swingは目にもとまらない速さなんだぞ!!!!!!!!!!
673 :
仕様書無しさん :2006/09/04(月) 23:03:06
なんだとおらswingをなめんじゃえーよ javaの最高峰なんだぞ!!!!
javaの最高峰w
韓国で最強、とかそんなものか?
駄目だ・・・社長がJava(アプレット)でやる気だ・・・ 組むのは俺なのに。。。 orz...
カワイソス
>>677 そういうときこそくそ重いプロトタイプを作って計画を変更させれ
なぜに今時アプレット?
アプレットってあったなぁそういえば
10年くらい前だったっけ? もう忘却の彼方だ。
今ならJavaプラグインでSwing使ってもそこそこ使えるかも 未だ証券会社のチャート描画AppletでもMS Javaで間に合ってるけど
684 :
おじゃばさま :2006/09/05(火) 20:05:42
マシンが早くなったせいか、社内システムやサーバ設定ツールではアプレットが復活して来てるよ。 WEBのクライアント側では、FlashやAjaxになってるけどな。 ところでC#はどうなってんだ?C#よりむしろC++の方が話があるんだが。
C#はテスト用のテキトーツールとかを作るのにめちゃ便利。
686 :
677 :2006/09/05(火) 21:19:41
DB鯖との通信をやると(アプレかアプリか) PHPじゃ駄目なのかと聞いたらタグやらのパケ量が勿体無いと。 まず何のためにやるのか言ってくれよ。。。
設定ツールのGUI部分をそこまで作り込む意味はあるのか? HTML吐くCGIでも事足りると思うが
689 :
仕様書無しさん :2006/09/06(水) 18:00:15
>>670 あんがいポケコンBASICのほうが速いかもしれんぞw
690 :
おじゃばさま :2006/09/06(水) 20:22:58
>687 測定ツールだとリアルタイム表示とか、グラフ表示とかあるのがあるからな。
ハードの成長が停滞してきたのに、まだまだ遅いJavaに未来はあるのかと 不安になる今日このごろ。
簡単なプログラムのベンチマークは素晴らしい成績なんだけどね。 ある程度の規模になるとズタボロになるよね。
693 :
仕様書無しさん :2006/09/07(木) 10:29:57
簡単なプログラムのベンチマークは、 C使ったほうがほぼ最高のパフォーマンス出せるだろ
アプレットは1.4の関数使ったりしたら動かない、とか言われたりして面倒。 MSが載せるのやめた時点で、使えない代物になってしまった。
iアプリのiMona(タグ無し+gzip圧縮でパケ代助かってる)しか使ってないが iMonaの鯖側ってperl(cgi)だし、直にソケット使わなくてもいいかも
697 :
677 :2006/09/08(金) 00:11:10
>>694 2週間ぐらい前にやったよ >PHPでソケット
403認証を済ませるのに
けど、受けはJavaアプレットだと思う
HTMLを吐く時点でコード増えるから
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でわざと遅くしてるんだから 本気で組んでもやっぱり遅いと思うよ
>>699 JavaだとどうしてもApache前提になるぞ。
まあ小中規模ならゲーム鯖でも問題なく動くが。
702 :
仕様書無しさん :2006/09/09(土) 20:20:52
F1 の速度測定のシステムはアプレットで出来てるらしいな。
704 :
おじゃばさま :2006/09/13(水) 20:12:15
VC++のSTLってみんな使ってるか? 基本的な質問なんだけど、文字列はstring使ってる?char[]使ってる?
>>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
山手線を歩いて一周するみたいなもんだな
>>705 メソッドからオブジェクトをcreateするときどうすんの?
newなしじゃデストラクタが動くと思うんだけど
709 :
仕様書無しさん :2006/09/15(金) 03:45:06
Javaなんて同時アクセスが3人ぐらいまでのシステムしか組めないだろwwww mixiもperlらしいね
>>708 静的変数。
基底のクラスで宣言。
ユーザーインターフェーススレッドで宣言。
関数内で使い捨て。
無論無駄が多いけどね。
711 :
おじゃばさま :2006/09/15(金) 23:49:37
>705 JavaのプログラムをそのままC++に移植したら、どのぐらい早くなるのか見ようかと思っているのだが、 C++のstringってnewしたらdeleteしなきゃならないのかな?
>>711 newはデストラクタのきっかけをdeleteに委譲すると考えればOK
>>711 newしたらdeleteしなきゃならんし、
newしなければdeleteする必要はない。
最近の C++ は new はしても、自分で delete する機会はほとんどないだろ。 標準ライブラリや boost のスマポもあるし。
715 :
677 :2006/09/17(日) 01:32:49
コンストラクタを書いた後にデストラクタを書くのは普通じゃないのか
なんというソフト・・・ 起動させるだけでイライラしてしまった このソフトの言語は間違いなくJava / ̄\ | ^o^ | \_/
Java重すぎるうえに規格がいろいろだめだね。 これからは.NET。C#万歳。
>>645 C++/wxWidgetsで
> バージョン毎に調整・テスト
が必要ない理由がわからん。スタティックリンクだからとか言う話?
> ソースファイルも一つで済むから
コンパイラとバイナリはターゲットごとに必要だよな。
ネイティブAPI使えばできるのに、っていうようなことは結局ifdefになるし
wxWidgetの機能だけでやろうとすると全OSで共通化されてる部分しか使えない。
> OS毎に挙動が違って
これはwxWidgets使ってても変わらなくね?
>>718 御託を並べる前に一回使ってみて。マジで考え方変わると思うよ。
721 :
おじゃばさま :2006/09/19(火) 11:21:44
じゃstringでもnewしたらdeleteしなきゃならないのか。 それだとJavaソースをそのまま移植は無理だな。 C++の説明にスコープを抜けると自動的に解放されるような事が書いてあるが、どうなんだ? フィールド変数のnewしたstringだけは、deleteしなきゃならならないって事じゃないのか?
移植したいJavaソースを抜粋して晒したら C++ の達人が教えてくれるかも
723 :
仕様書無しさん :2006/09/19(火) 17:12:57
>>721 それは自動変数でオブジェクトを宣言したときだ
値型ってやつだっけ?
ー>じゃなくて.でアクセスする
つ スマートポインタ。 つーかどういう経緯でstringをnewするの? 普通に宣言して突っ込めば勝手に拡張するし、 後始末もしてくれるだけど。
つ コピーコンストラクタ string hoge() { string str = "hogehoge"; return str; } newなんてつかわんでもいいの
今までC++を知らずに叩いていたのが露呈した
>>725 こんなことしてるからJavaより遅くなるんだよ
そういやC++も最近はGCライブラリ使ってるとこあるしな
D言語のとこの会社も使ってたし
コピコン使ってても速いとか思ってるほうが異常 単に無知なだけか
そいつには無理
JavaだけじゃなくC++すら知らないのか。 コピコン使ってたらどう足掻いてもJavaより早くならねーよ。
サンプル書いて比較してみればいいのに
コピーコンストラクタでひとくくりにするよーなやつがC++を語るのか?
そうです
では見本をお願い
まんまだろ、どこまで馬鹿なんだ
では次のネタをお願い
んーとねぇ、じゃあ何故 727, 730, 738, 740 は何故こんなにも阿呆なのか?
744 :
仕様書無しさん :2006/09/23(土) 20:22:43
ちがうよおまいらに問題を出したんだよ
Java 使いが C++ の RVO を知らなくてもまあしょうがないだろうけど、
735 や 739 が実測してみろと助言しているのにそれを無視して
>>740 のようなレスを返すこいつはプログラマには向いていないとおもわれ。
748 :
仕様書無しさん :2006/09/23(土) 21:48:58
馬鹿どもが も前らまとめてビジネスロジックやってろ!!
と、ビジネスロジックという単語にコンプレックスを持つ 748 が吠えてます。
750 :
仕様書無しさん :2006/09/23(土) 21:55:58
大規模開発
751 :
仕様書無しさん :2006/09/23(土) 21:59:09
ポーリングするマルチスレッド
752 :
仕様書無しさん :2006/09/23(土) 22:00:09
リークしてクラスを読み込まないテスト環境
>>747 助言ってのは参考なって始めて助言なんだぜ
>>753 助言を求めてもな理解できない奴は理解できないんだよな。
答えが目の前にあっても理解でき無い奴は珍しくない。
>>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); } }
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; }
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); }
配列コピー対参照渡しなんだから ベンチマークしてみろって言ってる時点でプログラマじゃないよな
734 名前:仕様書無しさん [↓] :2006/09/22(金) 00:13:11 JavaだけじゃなくC++すら知らないのか。 コピコン使ってたらどう足掻いてもJavaより早くならねーよ。 ここで思いっきり説明されてるのに・・・
VC++ 2005ってRVOサポートしてるだろ でも生成時点で差がついてちゃ意味ないね
これだけ差があるとコピコン以前の問題だな C++捨ててもいいですか
速い作り方すりゃ速いんだから捨てる必要は無いだろ。 単にこのスレのお客様が最近のC++屋もGC使ってるって事実を知らないだけ。
実行オプションまったくつけなくても差はないな クライアントVMも最近は優秀らしい
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
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
どうでもいいけどそれってsprintfとDecimalFormatのベンチでは?
771 :
仕様書無しさん :2006/09/24(日) 00:53:18
doubleの計算を再帰でやるベンチをたのむ
Javaは高速なはずなのにJavaでつくられたアプリを動かすと糞重たいのは何故なんだぜ?
Javaは長い時間をかけてコンパイルをするためです。 環境情報とコードの使われ方を計測して最適化するためサーバ用途に偏ります。 別に俺の使ってるJavaアプリは重くないんだけどね。
その用途ではC++のクラス使わないでCで書けばいいんじゃね? オブジェクト指向使う必要ない規模だろ? と思ってしまう実用一辺倒な俺。
C++はCのみで書くという芸当はできるがJavaではどうあがいても代替案はないな
まあC#でもいんじゃね。HP-UXとか使うから俺はJavaをやめられんけど。
>>777 Javaにはstaticメソッドだけで書くという技もあるな
もはやオブジェクト指向じゃないが
普通に整数の再帰演算(フィナボッチ数の算出)をやらせてみたが 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); } }
>>780 C++の書き方というか最適化の方法知らない無知なんだな。
おもしれーよ。
学生ならJAVAメインの企業で生涯終わらせるべき、C++やCには絶対近づかないほうがいい。
PGかSEならJAVAだけの案件やる以前の問題だから市ぬか、中国にでも消えろ
何にせよ、ソースだけじゃなく、とりあえず、コンパイルオプションくらいは 書いてほしいけどな。デフォルト生成コードで比較したいってことなのかもし れんけど。
なんかC++厨が必死になってるスレですね
>>782 じゃあルール決めろよ何使ってもいいか不明だし
出したら出したでそれは違うからダメとか言うんだろ?お前らのその手には
釣られねーよボケwwww
longに変更してfb(45)計算してみろよめちゃくちゃおせーだろ?
でもな俺の書くたいしたことの無いC++ならfb(30)もfb(45)もほぼ等速で終わるぞ
これが脳内ベンチと言うヤツですかw
まずは
>>785 に「fb(30)もfb(45)もほぼ等速で終わる」C++ソースをさらしてもらって
それをもとにベンチを考えたらどうだろ?
788 :
仕様書無しさん :2006/09/24(日) 13:06:07
プログラマってアグレッシブですね
実業務のコードとかけ離れたコードを何万回とか実行するベンチなんかやって意味があるのか? 科学技術計算ならFORTRANでもつかっとけ。
ベンチといえばモモベンチだ。 それ以外は認めない。
人生のベンチマークをするにこのスレでぎゃあぎゃあ騒ぐことが無駄だと判明した。
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; }
コンパイルする時計算終わってるから意味ねーだろって 答えになるぐらいの糞の話しだから次の話題にいくべ
>>792 コピペ乙
だがfactorialをfbに直し忘れてるよ
たしかにこれじゃベンチにはならんわな
・Java厨はC++のコンパイル時コード生成を知らない。 ・オブジェクト指向じゃないコードにすれば書けばJavaも速い。 でFA?
便利っちゃ便利だが定数しか渡せないようじゃあまり使い道なさそう ちょっと複雑な定数計算に使うくらいだな
このスレって煽ってる奴よりJava厨のがレベル高くて悲しくなるな
>>796 C++ のテンプレートは理論上チューリング完全な言語内言語だ。
Java の Generics とは違うのだよ。
>>797 そう感じられるのはお前がJava厨のレベルにも達していないからさ。
>>798 チューリング完全な言語内言語かぁ
でもコンパイル時コード生成ってことは定数しか渡せないわけだろ
>>798 定数以外渡したくてJavaの方が早い事例を
出せよ話はそれからだ
801 :
仕様書無しさん :2006/09/24(日) 18:50:45
>>797 実際さんざん煽ってソース出されてダンマリってのを
何度もこのスレで繰り返してるからな
802 :
仕様書無しさん :2006/09/24(日) 19:02:03
なんだなんだ、不毛な議論はやめなよ。 ジャバは糞だよ。 ある定常負荷を超えた点から、マルチスレッドのコンテキストスイッチが 遅延しだす。それから後は寝ぼけたような動作に入り、再起動。 コンパクトなコードはメモリにキャッシュされて扱われるから 時としてC/C++より速いスペックを出すようがだ、それなりのサイズ になったらクラスを読み込むだけで明日になるぐらい遅くなる。
ちょっとしたサンプルレベルだといいんだけど、本格的に使い出すと破綻するんだよね。
JAVA坊お前たちはサンプルレベルでしか話ができないのか? それとも、あれか何億回も実行するような極端な例しか出せないのか?
>コンパクトなコードはメモリにキャッシュされて扱われるから だったらC/C++ももっと速くなるのでは? 定常負荷が具体的にナニをさすのか知らんけど、 メモリが足りない場合は…、とか言うなら微妙な感じだが。 まあ、漏れも最初から負荷が高いと解っている処理は Javaではやらんけどサ。
806 :
仕様書無しさん :2006/09/24(日) 19:25:16
喫煙者の吐いた息を毎日吸い込んでるとかなり体に悪いらしいよ。 会社とかで向かい側や両隣に座ってる人達は要注意だって。 子供も学校の先生が喫煙者の場合は、前の方に座ってるとやばいんだって。
吸ってない人の隣に吸う人がいて肺が吸ってる人になってる人居たな
>>806 じゃあ無人島にでも行って健康に暮らせ。
誰も止めない。
つーかたばこなんか吸ってるやつってアホだろ?
Javaのスレッドってさー
811 :
仕様書無しさん :2006/09/25(月) 00:28:47
実行速度だけで言えばC++よりJavaの方が速かったっちゅーレポートあったよね? メモリはJavaの方が2倍喰ってたけど。 これをどう評価する?限られたハード資源を前提にすればダメだけど、 「メモリ?足りなきゃ足せよ」みたいな状況を前提にすれば"あり"だし…。
早く作れて実行速度も遅くない。ただしメモリは犠牲になる。 それがJavaのこれまでの、そしてこれからも続く特徴だろ。 業務サーバーでJavaの需要が減らないのは、 実際に先に悲鳴を上げるのはいつもDBだからだしね。
813 :
仕様書無しさん :2006/09/25(月) 00:33:13
だからさ、C++のSTLは標準ライブラリよりも70%程度の パフォーマンスしかでないのよ。プログラミング作法 Brain W.Kernighan 読め。予想だけど、JVMは巨大マッピングメモリ上でmem系の関数で データ処理してるんじゃないのかな。だからANSI Cで同等の処理をすれば それよりは絶対速いはずだろ。
えー。メモリ2倍も喰うの? せっかく計算が速くても、キャッシュミスが頻発するような気が。 まー、サーバーみたく、贅沢なバンド幅を使えるなら問題ないかもしれないけど。
ねーなんで
>>811-813 のような思い込みだけで書いた文章信じるの?
ベンチとればいいじゃん
上の方でstring系の処理で固定文字列を違う文字列にしたら、 C++の方が早くなったろ?最近のstring系は同じ文字列は 同じメモリ領域を参照するようにしている場合がある。 つまり、全然メモリ確保しない状態でやってた可能性があると 思うんだが。 そもそも単純な数値計算じゃ、Javaの方が早いケースもあるって前の スレで結果出ていると思うんだが。で、少しでもややこしい ファクターが入るとあっという間に速度が遅くなると。
>>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のコードの方も、配列を確保する必要なんかないはず。
>>780 CPUが実行するコード貼ってみたら? Javaじゃ難しいのかね?
おなじCPU同士ならどっちがなぜ速いのか、あるいは遅いのか
一発で理由が分ろうが。
Javaがメモリ倍食うとか言いながらも携帯アプリって Javaが多いらしいけどなんか矛盾してね?
>>819 PCのJavaと携帯のJavaは別物だよ
別物っていうほど言われるシロモノでもないと思う
誰かJavaでJavaVM書いて、その上で同じバイトコード走らせて比べればいいんじゃね?
gcj はネイティブコードにコンパイルできるんだったっけ? それと C をgcc でコンパイルしたものとを比べてみるとか。
824 :
おじゃばさま :2006/09/27(水) 20:11:27
C++でCORBAやろうとしているんだが、いつものごとくコンパイルが通らない。 付属のサンプル全く手を入れず、付属のMakefileを使っているのにエラーが出る。 どういう事だ?コンパイラのバージョンか? Net探してもレビューは見つからないし、付属のドキュメントとサンプルファイル構成が微妙に違うし。 やっぱC++は、終わってるな。
825 :
仕様書無しさん :2006/09/27(水) 21:30:41
つうかCORBAが終わっているんだよ
827 :
仕様書無しさん :2006/09/27(水) 22:18:00
>いつものごとくコンパイルが通らない そんなのおまえだけだろうw
828 :
仕様書無しさん :2006/09/27(水) 22:21:22
みんなひどいな、他人の努力は応援するもんだぞ。 頑張れの一言位言えよ。 頑張れ。
830 :
仕様書無しさん :2006/09/27(水) 23:26:10
うむ。うまい焼き鳥をおごってくれれば 1H程度のプレミアム研修をしてやるぞ。
CORBAでスケルトン吐かせないでひたすらサンプル通り直打ちしてたらワロスだが。 あと、CORBAはC++Onlyのものではない。 JavaCORBAやらCOBOLCORBAやらいろんな言語に対応してる。 ってかそのための仕組みだし。
832 :
仕様書無しさん :2006/09/27(水) 23:38:25
CORBAやるならWebサービス(C++)やったほうがいいと思うよ。
CORBAやるならMQのほうが絶対いいよ I、N、MといろんなところがこれからはMQが来るって いってるからねぇ
こーぼらーるるるるるー こーぼらーるるるるる〜
俺の中では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"); ...
Orb が毛を逆立てて威嚇している猫に見えてしまう漏れ。 もうダメぽ。
844 :
仕様書無しさん :2006/09/28(木) 21:49:53
なあーんかダサくてやるき無くすのがCORBA
845 :
仕様書無しさん :2006/09/28(木) 22:30:31
なんで高齢童貞、アニオタ、ロリコンはネット右翼になるの?
な、何でわかった?
類友だから
思想にすがるようなのは大体からして電波で負け犬だから
いやいや思想は大事だよ 思想がないということは単なる馬鹿ってことだろ
いや、思想だけの馬鹿もいる。 実行力が伴わないと成果は出ないからな。 オレモナー
思想というか、自我だな
852 :
仕様書無しさん :2006/09/29(金) 09:17:39
それをいうなら超自我だろ?
853 :
仕様書無しさん :2006/09/29(金) 11:17:47
マルチプラットフォームで コーディング楽で 超軽量で・・・・ そんな言語ねぇよ
C#.NETがあるじゃないか。
855 :
仕様書無しさん :2006/09/29(金) 11:38:25
VB6は全関数、全イベント、実行環境のバグ等々全部暗記してるから個人的には最強。 C#.NETはいろいろ知恵絞ってるのはわかるけど、 全部暗記するのはきついだろ。 結果的にVB6の方がコーディングも早い。 C#って実行時はネイティブコードにコンパイルしてるって言うけど、本当かよ?
856 :
おじゃばさま :2006/09/29(金) 19:42:42
awkがあるじゃないか。
>>853 Perl とか Ruby とか、スクリプト系はいい線行ってると思うが。
>C#って実行時はネイティブコードにコンパイルしてるって言うけど、本当かよ? わりいあれうそだ。
Perlコンパイラってどうしてないの?
現状javaってどういう場面でよく使われてる? 何に強いと思う?
サーバだけでしょ、
携帯
携帯Javaってゲーム以外なんかあんのか
ゲームでも立派な商売だし
日本のソフトで世界に通用するのはゲームしかないだろ
ゲームが通用するのはシナリオ、グラフィック、音が優秀なだけ。 プログラムは典型的なドカタコード
じゃあどんなのが素晴らしいコードなんだよ
868 :
仕様書無しさん :2006/09/30(土) 20:05:06
おまいにとってすばらしいコードとはグラフィックや音がすばらしいものなのか
シナリオ? シナリオのあるゲームって何だ?
ゲームのソースって依然見たことあるけどありゃひどいな。 1メソッド数千行とかあるw
871 :
仕様書無しさん :2006/09/30(土) 20:43:09
おいおいジャワでゲーム作ったひにゃ、電源いれてから 30分またないと遊べないものになっちゃうぞw
10年くらい前のパソコンの持ち主なのかな・・・
じゃないかな 携帯も持ってないみたいだしね
昔のゲームはハードが貧相だったから高度なテクニックも駆使してたけど、 携帯JavaのゲームはAPI呼ぶコードをフレームワークの隙間に埋めてるだけでしょ?
876 :
仕様書無しさん :2006/10/01(日) 08:29:56
ゲームって開発費はかさむ一方なのに全然売れなくなったね。 ゲーム自体が終わってると思う。
まぁ20年ぐらいもった隙間産業だったてことじゃね
Javaなんか使うからだろ
ハードをギリギリまで使うのがゲームプログラミング。 普通マルチスレッド使う理由は平行動作の為だが、 ゲームの場合は計算速度上げるためという理由だからな。
>>875 と思って作るとサイズとメモリと速度が足りなくなる罠
携帯JAVAは、まずオブジェクト思考をやめることからはじまる
変数もスタティックにしてさらに使い回す
メソットを増やすと容量がかさむからまとめる
まともなコーディングなんてしたら、作れない代物だよ
携帯Javaはやったことないけど、 変数とかの使いまわしとかメソッドの辺りは普通にクラス設計の段階の話だと思うが。 まともなコーティングをナニを刺すのか知らんが、 まともにクラス設計できない人間が、泥くさいコーディング してるのはタマに見る。
そもそもクラスなんて使わないよ
プリミティブな変数しか使わないのが鉄則
それだとc使うのと大差ないと思うが。
おいおい、java使うのはサンドボックスのためだよ
extern "C"{}とかでCのコード埋め込めるJavaとかあったら最強じゃね?
888 :
仕様書無しさん :2006/10/01(日) 12:45:29
携帯JavaはJavaしか選べないでしょ。 誰もあんな糞言語でやりたいとおもってないよ。 ソースも全然ooじゃないし。 そもそもそんなことしてたらメモリ足りない。処理速度追い付かない。
つまり携帯に適した言語で最高なのはマシン語(懐かしい響きだな)でFA
はいはい頭が20年前の人は大変だね
しかし、最近の携帯はファミコン以上ではあるだろw
892 :
仕様書無しさん :2006/10/01(日) 17:22:43
携帯Javaのゲームなんて20年前のゲームの復刻版か焼き直しみたいな屑しかないからそれでいいんだよ。 つか、そもそもその程度しか出来ない。
PSPでナムコミュージアムばかりで遊んでいる漏れが言うのもアレだが、 ゲームに関しては昔のゲームの方が楽しいと感じるけど。 892は携帯アプリがC#ならもっと高度な事が出来るといいたいんだろうか?
894 :
仕様書無しさん :2006/10/01(日) 18:02:22
どこをどう読んだらそういう解釈が湧いてくるんだろうか。
892の文書は Javaなんてとか、昔のゲームは屑 と明確に発言してるが。 あ、894=892か。
携帯でC#が使えるとはしらなかった。
897 :
仕様書無しさん :2006/10/01(日) 22:38:57
Javaだと20年前のゲームしか出来ないのね。
899 :
おじゃばさま :2006/10/02(月) 20:07:35
ゲーム開発でCのコードを書くのは全体からすると少しだけだろう。 実際にはそのゲーム開発用のツールを使って作業する訳だから、 JavaやCより、VBやフォトショップに近いんじゃないか? ところで最近、C++でSTL使って組んでいるんだけど、これ本当にすごいのか? どのあたりが優れているんだ?
900 :
仕様書無しさん :2006/10/02(月) 22:08:38
なにを持って凄いというのかな。 比較する対象がないとすごいともへぼいとも言えない。 少なくとも対象がジャワだったら、ものすげえ良いよ。全てにおいてね。
>>899 CからC++に移行した人はまずSTLコンテナの便利さにはまるんだけど
Javaからだとむしろハッシュテーブルがまだ非標準なのかよって感じかもな。
とりあえず algorithm のソート関連を眺めてみると sort とか stable_sort
とか partial_sort とか partition とか nth_element とか充実してる。
こいつらを自由に使える、しかも評価関数をファンクタにすればインライン展開される、
というところで俺はSTLにはまったのだが、もちろんSTLの真価はそんな浅いものじゃない。
まずは定番の「Effective STL」を一通り読んで後はいろいろ使い込んでみるといいよ。
そうしてSTLはC++の一部というよりむしろ独立したひとつのプログラミングパラダイム
なんだってわかってくるとSTLがすごく面白くなってくるから。
あとゲーム開発についての発言はあまりにも無知すぎる。ちょっとは自分で調べろ。
そおいや、X68000でgccでゲーム作ってたなぁ。 ナツカシス
>>903 740 とかその同類のコピーコンストラクタと型変換コンストラクタの区別も付かない
***よりは数等まともだと思うが。アウェイのおっさんスレでもがんばってるしな。
>>904 その台詞は世のマトモなC++プログラマーに対する侮辱だな。
newの使い方知らんでああだこうだ言われてたわけだったんだよなぁ。
メモリ資源の乏しい携帯電話でメモリ馬鹿食いするをJava使おうってのがそもそも間違いな気がする。 オブジェクト指向を全然活かさない書き方しないといけなくなるし。
馬鹿だな 携帯でやろうと思った時点でGUI周りをひっくるめて言語仕様として機能を全て持ってたのがJavaしかなかったからだろ いちいちアセンブラでSH用、MIPS用、PowerPC用、ARM用とか書けってのかよ そんなのめんどくさくて誰もやらねえよ そもそもOO言語だからってOOPしろだなんて誰も言ってねえよ
ARMとPowerPCは素直で良い子だからアセンブラでガリガリと書く気になる。 別に難しいことは何もないし。
いちいちアセンブラでSH用、MIPS用、PowerPC用、ARM用のVM作ってる身にもなれよ。
そんなことは知るはずもないおじゃばさまどもは
911 :
おじゃばさま :2006/10/04(水) 09:40:37
>901 mapもvectorも、それらのソートもjavaの方が豊富だろう。 それよりstring関係の弱さがが気になる。トリムやトークン切り出しが見つからない。 しかしそれが真価じゃないのか。その本を読んでみるよ。 確かにSTLを使うのと使わないのでは、全然違うな。 >905 悔しいがまだnewが良く分からない。 この前聞いた結果をまとめると、 ・newしたらdeleteは必要 ・そもそもnewする必要はない ネットで調べたのをまとめると ・^しておけばdeleteは不要 ・gcがあるのでスコープ外れると勝手にdeleteされる ・やってはいけないnewがある(コンストラクタ内でのnew禁止) など、いろいろあって検証しきれていない。
new/deleteを再定義してデバッガで追うか、Purify/BoundsCheckerみたいな メモリチェックツールつかえば分かるデスよ。 フリーのメモリチェックツールもあるらしいけど(Electric Fenceとか)知らん。
>>911 空気を読まずにマジレス
> ・そもそもnewする必要はない
メンバ変数かauto変数で事が足りる場合が多いという意味じゃないの?
> ・^しておけばdeleteは不要
知らん
> ・gcがあるのでスコープ外れると勝手にdeleteされる
誤解があるような気がする
> ・やってはいけないnewがある(コンストラクタ内でのnew禁止)
コンストラクタでnewするくらいなら、メンバ変数にするという意味じゃないの?
>>909 ゲーム作るたびにVM作るわけじゃないだろ低脳
苦労するのはごく一部だけで良いんだよ
>>911 >それよりstring関係の弱さがが気になる。トリムやトークン切り出しが見つからない。
そういう贅沢な機能は非標準ライブラリを使えってことになっている。
例えば boost::regex とか boost::tokenizer とか boost::format とか。
>・^しておけばdeleteは不要
それは C++ じゃなくて C++/CLI だ。.net framework が必要になるぞ。
携帯アプリでアセンブラやC使わせたらウイルスだらけになるだろ?
>>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
きみらの話はネタだよな?
なんかそれ、もう見飽きた。
>>918 C/C++ を「Java らしく」書いたら、そら不自然になる罠。
COBOLer の書いた Java プログラムが妙ちくりんなのと同じ。
923 :
おじゃばさま :2006/10/06(金) 20:09:56
いやC++のSTL使用は、Cより遥かにJavaに近いって事が分かった。 C++知っている人ならJava文法の良さは身に染みて分かると思う。速度は別にして。 C++/STLは早い訳じゃ無くて、技術があれば早くできるだけって事が分かった。 良く知らずに使えば、速度の問題どころかまともの動作しないって事も分かった。 EffectiveSTL読んでいるが、C++を業務で使うのはかなり厳しいのではないかと思っている。 コンパイラによって動きが違ったり、見えにくいバグが多かったり、いくらでも凝れたり。 この言語は人を選ぶよ。開発者全員にこれをマスターさせるのは不可能だと思う。 ところでgetMutexFor()がないんだけど、何使えばいい?
>ところでgetMutexFor()がないんだけど、何使えばいい? STL は一応マルチスレッド環境に配慮して作られてはいるんだけど C/C++ 標準ライブラリにスレッドという概念はないのでそれは開発環境に依る。 Windows なら win32api に含まれているし、UNIX系なら pthread がある。 ポータビリティを求めるなら boost::thread があるが日本語の資料は少ない。 後は知らんのでそれ以外の開発環境ならム板の環境依存OKスレにでも聞いてくれ。
925 :
仕様書無しさん :2006/10/06(金) 21:47:17
>C++知っている人ならJava文法の良さは身に染みて分かると思う 全くそうは思わないが インラインスタイルでしか書けないのはうざいよ
逆に聞くが、hとCPPに分けて書くスタイルってどー思った。
>>923 STL(や boost)をそれらしく使えば使うほど、Java よりはむしろ
Lisp とかのほうに似てくる罠。
まあ正直、Java の文法の C++ を意識した感じとかはあまり良いとは
思わんけどな。まああくまで文法そのものがだが。
928 :
68式オサン :2006/10/06(金) 23:09:33
>コンパイラによって動きが違ったり、見えにくいバグが多かったり、いくらでも凝れたり。 JAVAは環境(バージョン)によって動きがちがったり、見えにくいバグもある。 そして幾らでも冗長性がある。(回りくどい) どっちがいい?w
結局バカでもできるJAVAだと 虫けら学徒がバグを大量に出してくれるからノウハウは はっきりいってJAVAの方が積まれるぞ 神格化した今のC++では誰も手が出せないからノウハウ貯まらないかなぁ
肥大化して手を付けられないのがJavaだろうに
SGML への反省から XML が生まれても結局複雑怪奇になったのと同じ道を Java はたどりつつあるよな。
それを言ったら長く使われているプログラミング言語は みんな同じ道をたどってしまうとも言えるな
確かに多くの人に使われている言語はそういう道をたどるしかないよな。
Cはもう30年。COBOLにいたっては・・・
935 :
仕様書無しさん :2006/10/07(土) 20:38:28
JavaってLinuxと同じ進化をしているな。 Linuxは初期のバージョンはWindowsよりリソースが少ない環境でX-Winも 使えるというのが売りだった。ところが今じゃDVDじゃなきゃ配布できない ぐらい巨大化してしまった。 Javaもきっとメモリがテラオーダつめるサーバ以外は動作しなくなるのだろう。
別に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++のネームスペースは破綻しているからな。
サーバ側はマルチスレッドよりマルチプロセスの方がアーキテクチャ的に有利らしいが、 サーバ側がJavaじゃ無理か?
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で囲わなければいけないのか?
LinuxではJavaでマルチスレッドのコードを書いてもマルチプロセスになるぞ。 おじゃばさまはpsコマンドって知っているか?
そりゃpsコマンドがスレッド単位で表示しているという落ちだった気がする
つーか、マルチプロセスの方が有利って言うのは ステートレスなプログラムを作った方が処理が分散できるって意味だろが。 重要なのはC++でもJavaでもスケーラビリティの高いプログラムを作る事。 PHPとか、ステートをそもそも上手く持ちにくいという制約が逆にスケーラビリティを 高める事になったりしてるしね。 そーゆー背景を理解せずに 「psで見てみろよ。マルチプロセスだぜ」 「psはスレッド単位だぜ」 とか、単なる要素にしか過ぎないものに深入りする時点でお前ら終わってるよ
>>941 スレッドのオーバヘッドって考慮していっているの?
それに、メモリは有限だぉ。
ところでプロセス間通信の事考えて発言している?
948 :
仕様書無しさん :2006/10/11(水) 23:22:17
linuxのスレッドはプロセスのcloneだよ。java厨はOSのこと全然わかってないんだな
マルチプロセスの方が有利なのは、プロセス単位でリーク等を始末できるからだよ。 スケーラビリティはマルチスレッドのほうが出る。Javaで組んでも出ないけど。
なかなかNPTL普及せえへんな
951 :
946 :2006/10/11(水) 23:48:12
>>949 お前の言うスケーラビリティって、1CPU,1サーバーで目指すスケーラビリティじゃねぇ?
俺が言ってるのは複CPU,複サーバーの環境での話。
もっとも、最終的には言語やアプリのボトルネックよか、
DBとかIO周りのボトルネックに行き着くのは間違いないのだが。
javaもlinuxもsmpじゃダメダメ
メモリ有限とかいってるやつって何時代って問い詰めたくなる バカ言うのもほどほどにしておけて ここ5年ぐらいは、少なくとも俺の関わるプロジェクト(利用者500万人規模のシステム) 128GBとか当たり前だぞ。 マルチプロセスなんていみねーし、スレッドだけありゃいい
おまえどこの未来から来たんだよwww
>>953 そういう点では、MS-DOS ってシングルタスクだし超最先端だったんだなw
ちゃんと 64 ビット対応させれば今でもいけるんじゃね?www
え? スレッド? そんなもん config.sys でドライバ読み込めば(ry
>>953 そこまでの御大尽を一般人に求めるのは酷かと。
>>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に言っているのではなく、俺に言っているのかな? 俺に言っているとすると、 プロセスの方が使用メモリが少なく、プロセスの方が同期も簡単って意味になるが、 そう言いたいのかな?
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++と同じはず。
それ以前にアプリケーション鯖が不安定すぎるよ。
>>962 >C++はこれでも早いのかなと疑問に思ったが、いろいろ調査を進めるうちにやはり遅いと言うのが分かった。
あんた、こういっちゃ何だけど毎回急ぎ結論出しているけど、過程を言わんので正当性を疑う以前に
信用できないんだよ。チラシのウラにそこまで書けっていうのは酷かもしれんが一行でも良いから信用に
足る技術的な事を書け。
>つまり、C++で速くするのは、vectorやmapやstringを使うなら、適切な初期領域を設定しろと言う事だ。
逆説的だが、C知らんで別言語から入ってきた人間はこういう考え方をするという典型ですな。
点として30点位かな?
>そんな面倒な事が出来るかと思ったが、ふと思った。
>JavaでもListやMapやStringの初期領域を設定すれば速くなるのかなと。
JavaとかC++という点をとりあえず置いて聞いてくれ、あんたのプログラミングの技量を上げる方法として
学校のコンピュータとプログラミングの授業の初級・中級の授業を受ければよいと思う。
コンピュータとプログラミングの基礎から勉強しなおしてくれ。
マジで。
車輪の再生産は確かに馬鹿だと思う。だけど車輪作れないどころか仕組みもしらない奴にそんなこといわれたくないよ。マジで。
Java厨ってさ、バイナリサーチも知らないんだね。 あらかじめソートされたコレクションに1要素追加するのに、最後尾に追加して 全ソートしてるの。大爆笑だった。
966 :
仕様書無しさん :2006/10/13(金) 22:38:06
>>965 Collectionになかったっけ?Arraysかな
幾らなんでもそんなへぼいことはしないだろw
968 :
仕様書無しさん :2006/10/13(金) 22:48:05
>965 馬鹿じゃないのかw binary searchぐらいで得意気に語っているお前の方が笑えるんだがwww 死んだ方がいいんじゃない?それにそういうデータならどういう方法が最適なのかも しらないのか?binary searchが最適だと思っている時点で小学校からやり直せよwww ちなみに小2でbinary searchぐらいしっていたぞw お前のその脳味噌の中に入っているソートアルゴリズムをあげてみろよwww それぐらいで得意になってプログラマをやっているお前が心底笑えるよ まぁがんばれよ。先はながくはないとは思うけどwww
恥ずかしくて顔が煮えたぎってしまった人↑
次の文章考え中かな?
binary searchで得意になっているところをみると本当に低レベルだよな このスレの住人はwww
>964 JavaがCよりも早いという研究論文はかなり出てきているよ。 もちろん特殊なケースなんだけど 今は昔はMPI(並列処理をさせるライブラリ)はCやC++のみだったが Javaもすでに開発されている。実行速度を気にする並列処理でだ。 Java以前の問題としてプログラマでありながら本当に基本的なアルゴリズム をしらない人間が5万といる。 また世界的に有名なACMのプログラミングコンテストの世界大会 でも問題読解能力とともに実行速度を気にする上位参加者がJavaを使うことも よく見られるしなぁ・・・ ちなみにJavaで書かれた3Dレンダリングエンジン(Java3Dではない)もかなり のスピードなんだよ
でもクライアントPCにもメモリ馬鹿積みしてJVMは-serverオプション必須なんだろ? JavaはうまくいけばWindowsみたいな立ち位置には着けるかもね 糞だ糞だと言われ続けるが、結局それが速く走る環境がもてはやされるという図式
コスト増大を狙ってるからね
>>972 論文持ち出さなくても、Javaが早いケースは、過去スレや関連スレで
簡単なテストを何度もされている。
ループでstringに追加するとかいう簡単なテストでJavaが早いけど
追加する文字をランダムにするとC++が早いとか無かったっけ?
とりあえず、JavaがC++より早いってそんなもんでしょ?
>973 自分はCやC++でMPI使って並列処理など色々やってきたけど 最近はまるで書いていないし、JavaのMPIで書いたことはないので正確なことはいえないんだが 恐らくそうかも知れない。 ただメモリを馬鹿積みしたから(その方が確かに早くなる確率は高いが)といって並列処理 が早くなるとは言えないしノード(PC)の数やデータのshapeそしてにも処理が異質のものなのか 同質なものなのかにもよるからね。 5年ぐらい前まではもっぱらCやC++でやっていたが今は訳あってJavaで組んでいる。 アルゴリズムの知識さえあれば、致命的な遅さは自分からすると感じられない んだが・・・それもかなり大規模なコードを書いてみたんだけど。ソフトの設計が悪かったり アルゴリズムが悪かったりするからじゃないのかなぁ・・・と個人的には思うけど。 CやC++が嫌いなわけでもないんだけど、Javaはかなり改善されているとおもうけどな >975 いやString等のそういったケースではない。科学技術計算の分野なんだが・・・ちょっとかなり前に 読んだ論文なんでなんとも言えないんだけど。ただ自分もすべてにおいてJavaが早いとは思っていないが、 ただ自分もJavaで組んでいて致命的に遅いなとはあまり感じなかったから。ただそれだけ。
ここを見てると、おおかたJavaが致命的に遅いと言う人と 問題視するほど遅くないと言う人の二つに意見が分かれるね 意見が違う原因は何なんだろう?やっぱり好き嫌いの問題?
俺のパソコンだと致命的に遅いぞ
アプリケーションサーバを使うかどうかだったり
JAVAは全然遅くないよ 今128ノードで稼動しているデータセンターで 仕事してるけど別にJAVAだろうがCだろうが大して 差が感じられないよ。昔はJAVAなんて遅くて使えないと 思ったけどそんなことないよ全然ねぇ。
そりゃデータセンター側はDBボトルネックでわからんだけとかいう落ちでは。
982 :
仕様書無しさん :2006/10/14(土) 04:21:06
Javaやってるとデータ構造の使い方は覚えても作り方は覚えない。
作り方なんて覚える必要ないもん
今のJava Swingはネイティブに頼っているSWTよりも高速なんだよね
( ゚д゚)
swingははやいんだぞ 保存する時すら一瞬なので操作不能になることなんて無いんだぞ!!!!!!!!!!!!!!!!
つまらん演技じゃ。 ネイティブにすれば高速化すると妄信して作られたSWTはもう遅いし 最適化技術をなめちゃいかんよ
>>987 そうだね、アセンブラを使って最適化するのは基本だよね。
はんともほほえましい意見ですな。 いつの時代の基本でしょうかねえ
ume
992 :
仕様書無しさん :2006/10/15(日) 19:54:47
993 :
仕様書無しさん :2006/10/15(日) 20:30:32
なんというソフト・・・ バグだらけでまともに動作しない しかも認証に30秒かかる このソフトの言語は間違いなくJava そして作ったのはジャワ厨 / ̄\ | ^o^ | \_/
Windows Vistaって重くね埋め
結局managed C++って何だったのか埋め
996 :
仕様書無しさん :2006/10/15(日) 22:28:16
__gcしてりゃ幸せでいいよな
徹夜してまでmalloc()とfree()を必死に使い回してれば 幸せで言いよなw
999 :
仕様書無しさん :2006/10/16(月) 02:32:07
999
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。