JavaはC,C++の後継言語となりうるのか
1 ：デフォルトの名無しさん：
Javaマンセーな方には申し訳ないですが、僕にはどうしても
Javaが次世代の主力汎用言語になりうるとは思えません。
確かに言語仕様は先祖たるCやC++よりも洗練されているのは
理解できます。ですが、実用にたるプログラムの記述という
面でははなはだ実力不足と思えます。
Javaマンセー派・Javaだめぽ派それぞれの意見をお願いします。
私個人が考えるJavaの罪状要旨を以下のレスに列挙していきます。
Javaが次世代の主力汎用言語になりうるとは思えません。
確かに言語仕様は先祖たるCやC++よりも洗練されているのは
理解できます。ですが、実用にたるプログラムの記述という
面でははなはだ実力不足と思えます。
Javaマンセー派・Javaだめぽ派それぞれの意見をお願いします。
私個人が考えるJavaの罪状要旨を以下のレスに列挙していきます。
|
|
|
2 ：デフォルトの名無しさん：03/04/09 23:56
・インタプリターでしか動かせない
これでは Basic といっしょです。システム記述言語としては
明らかに実力不足でしょう。個人的にも、ネイティブコンパイル
のできるJavaがあれば、非常に魅力的に感じます。
確かに当初の「write once, run every where」という思想は
なくなってしまうでしょう。しかしどっちみち現状ではこの崇高
な Java の理想は絵に描いたもちです。
「write once, debug every where」なんだから、そろそろまともな
コンパイラの処理系という方向性を模索しても良いのではないでしょ
うか。そうでなければ、いつまでたってもおもちゃです。
これでは Basic といっしょです。システム記述言語としては
明らかに実力不足でしょう。個人的にも、ネイティブコンパイル
のできるJavaがあれば、非常に魅力的に感じます。
確かに当初の「write once, run every where」という思想は
なくなってしまうでしょう。しかしどっちみち現状ではこの崇高
な Java の理想は絵に描いたもちです。
「write once, debug every where」なんだから、そろそろまともな
コンパイラの処理系という方向性を模索しても良いのではないでしょ
うか。そうでなければ、いつまでたってもおもちゃです。
3 ：デフォルトの名無しさん：03/04/09 23:57
・サーバ系、携帯電話ではすでに地位が確立しているという意見
こんなものは言い訳です。COBOLだって汎用機では地位が確立してますし、
VBだって業務アプリ・ホビー分野では相当の支持を得ています。しかし
だれも「汎用」言語としては認めていないでしょう。
システム記述・コンパイラ・アプリケーション等々あらゆる分野の
プログラムを生成することが出来てこそ「汎用」言語足りうるはず。
特定分野で秀でているのは結構、しかしそれでCやC++の現在の地位を
取って代われるとは思えません。
昔はHotJavaなんてのもありましたが、いま、Javaマンセーのかたで、
「JavaでできたOSで」「Javaでできたブラウザ」で２ちゃんねるを
見てる方います？「Javaで書かれたエディタ・スプレッドシート・
メーラ」ですべて固めている方がおられます？
結局自分自身も記述できない言語では半人前です。
こんなものは言い訳です。COBOLだって汎用機では地位が確立してますし、
VBだって業務アプリ・ホビー分野では相当の支持を得ています。しかし
だれも「汎用」言語としては認めていないでしょう。
システム記述・コンパイラ・アプリケーション等々あらゆる分野の
プログラムを生成することが出来てこそ「汎用」言語足りうるはず。
特定分野で秀でているのは結構、しかしそれでCやC++の現在の地位を
取って代われるとは思えません。
昔はHotJavaなんてのもありましたが、いま、Javaマンセーのかたで、
「JavaでできたOSで」「Javaでできたブラウザ」で２ちゃんねるを
見てる方います？「Javaで書かれたエディタ・スプレッドシート・
メーラ」ですべて固めている方がおられます？
結局自分自身も記述できない言語では半人前です。
4 ：デフォルトの名無しさん：03/04/09 23:57
・やっぱり遅い
実行速度は昨今のPC環境もあってか、特に不満はありません。
しかし起動はやはり遅い。Oracle 9iのコンソールなんか、別に
Javaじゃなくてもいいものを、インストールも起動もなにもかも
犠牲になっている。普通にCやC++で書けばもっとパフォーマンスが
でるのになんでわざわざJavaにするのか。
実行速度は昨今のPC環境もあってか、特に不満はありません。
しかし起動はやはり遅い。Oracle 9iのコンソールなんか、別に
Javaじゃなくてもいいものを、インストールも起動もなにもかも
犠牲になっている。普通にCやC++で書けばもっとパフォーマンスが
でるのになんでわざわざJavaにするのか。
5 ：デフォルトの名無しさん：03/04/09 23:57
6あたり？
6 ：デフォルトの名無しさん：03/04/09 23:57
・Pascalの方がましじゃないの？
カーニハンの有名なあれをそのままもじらせてもらいます。
この言語は不十分であるのに境界線が引かれているため、制約から
逃れることが出来ない。必要な時にローカルファイルを好きなように
アクセスできないし、「標準クラス」を定義するバーチャルマシンを
コントロールしない限り、欠陥のある実行環境を実用的な環境に交換
する手段も無い。この言語は閉じているのだ。
Javaをまともなプログラミングに使う人々はどうしようもない落し穴
にはまる。この言語は無能なので、拡張されなければならない。ところが
勝手にJavaを拡張すると、SunからJavaでは無いといわれ、以後処理系
のリリースもままならない。
Javaを何であれ当初の目的以外のものに使うのは間違いだと思う。純粋な
Javaはおもちゃ言語であり、教育用には適しているが実際のプログラミング
には不向きなのだ。
カーニハンの有名なあれをそのままもじらせてもらいます。
この言語は不十分であるのに境界線が引かれているため、制約から
逃れることが出来ない。必要な時にローカルファイルを好きなように
アクセスできないし、「標準クラス」を定義するバーチャルマシンを
コントロールしない限り、欠陥のある実行環境を実用的な環境に交換
する手段も無い。この言語は閉じているのだ。
Javaをまともなプログラミングに使う人々はどうしようもない落し穴
にはまる。この言語は無能なので、拡張されなければならない。ところが
勝手にJavaを拡張すると、SunからJavaでは無いといわれ、以後処理系
のリリースもままならない。
Javaを何であれ当初の目的以外のものに使うのは間違いだと思う。純粋な
Javaはおもちゃ言語であり、教育用には適しているが実際のプログラミング
には不向きなのだ。
7 ：デフォルトの名無しさん：03/04/09 23:57
・最後に
確かに、現状使えるオブジェクト指向言語が、ひどくバロック調の、やたらと
約束事の多い C++ しかないことを考えれば(SmalltalkやEiffelなんてみんな
討ち死にですもんね)、言語仕様の綺麗な Java が注目されたのもわかる。
でも、じゃ、いったい何ができるの？といえば、特定の適用業務しか使えない。
こんな言語がなんでこんなに支持されるのか、理解できないんです。
「その通り」でもいいですし「おまえわかっていない。実は...」でも結構。
ご意見どうぞ。
確かに、現状使えるオブジェクト指向言語が、ひどくバロック調の、やたらと
約束事の多い C++ しかないことを考えれば(SmalltalkやEiffelなんてみんな
討ち死にですもんね)、言語仕様の綺麗な Java が注目されたのもわかる。
でも、じゃ、いったい何ができるの？といえば、特定の適用業務しか使えない。
こんな言語がなんでこんなに支持されるのか、理解できないんです。
「その通り」でもいいですし「おまえわかっていない。実は...」でも結構。
ご意見どうぞ。
8 ：デフォルトの名無しさん：03/04/09 23:58
恋愛板住人で場違いなんですが。
9 ：デフォルトの名無しさん：03/04/10 01:05
良スレage
10 ：デフォルトの名無しさん：03/04/10 01:06
1のオナニー？
11 ：デフォルトの名無しさん：03/04/10 01:09
食い込み ｱｾ、Ｃ
うぇｂ Ｊａｗａ
金融 ＫＯＢＯＬ
おなにー ぃすｐ
うぇｂ Ｊａｗａ
金融 ＫＯＢＯＬ
おなにー ぃすｐ
12 ：デフォルトの名無しさん：03/04/10 01:10
>>1
その通り
その通り
（ ・∀・）＜ こんなのみつけたっち♪
http://muryou.gasuki.com/hankaku/hankaku03.html
http://muryou.gasuki.com/hankaku/hankaku04.html
http://muryou.gasuki.com/hankaku/hankaku02.html
http://muryou.gasuki.com/hankaku/hankaku01.html
http://muryou.gasuki.com/hankaku/hankaku10.html
http://muryou.gasuki.com/hankaku/hankaku09.html
http://muryou.gasuki.com/hankaku/hankaku08.html
http://muryou.gasuki.com/hankaku/hankaku07.html
http://muryou.gasuki.com/hankaku/hankaku05.html
http://muryou.gasuki.com/hankaku/hankaku06.html
http://muryou.gasuki.com/hankaku/hankaku03.html
http://muryou.gasuki.com/hankaku/hankaku04.html
http://muryou.gasuki.com/hankaku/hankaku02.html
http://muryou.gasuki.com/hankaku/hankaku01.html
http://muryou.gasuki.com/hankaku/hankaku10.html
http://muryou.gasuki.com/hankaku/hankaku09.html
http://muryou.gasuki.com/hankaku/hankaku08.html
http://muryou.gasuki.com/hankaku/hankaku07.html
http://muryou.gasuki.com/hankaku/hankaku05.html
http://muryou.gasuki.com/hankaku/hankaku06.html
＿＿＿＿_＿
／＿ |
/. ＼￣￣￣￣|
/ ／ ― ― |
| / - - |
||| (5 > |
| | | ┏━┓| ／￣￣￣￣￣￣￣￣￣￣
| | | | ┃─┃| ＜ こんなサイトを見つけた
|| | | | ＼ ┃ ┃/ ＼ 正直、スマンカッタ
| || | | ￣ ＼＿＿＿＿＿＿＿＿＿
http://saitama.gasuki.com/kensuke/
／＿ |
/. ＼￣￣￣￣|
/ ／ ― ― |
| / - - |
||| (5 > |
| | | ┏━┓| ／￣￣￣￣￣￣￣￣￣￣
| | | | ┃─┃| ＜ こんなサイトを見つけた
|| | | | ＼ ┃ ┃/ ＼ 正直、スマンカッタ
| || | | ￣ ＼＿＿＿＿＿＿＿＿＿
http://saitama.gasuki.com/kensuke/
あぼーん
16 ：デフォルトの名無しさん：03/04/10 01:13
＞JavaはC,C++の後継言語
っていう位置付けはどこから来たの？sunが言ってるのかな。
Javaの思想のひとつに「実行速度が遅くてもいいからプログラマのミスをできるかぎり言語側でカバーする」とかいう感じのやつがあるんだけど、そこが好きだな。
っていう位置付けはどこから来たの？sunが言ってるのかな。
Javaの思想のひとつに「実行速度が遅くてもいいからプログラマのミスをできるかぎり言語側でカバーする」とかいう感じのやつがあるんだけど、そこが好きだな。
17 ：デフォルトの名無しさん：03/04/10 01:16
>>1
JavaがCやC++に取って代わる言語になることは無いだろう。
また、１つの言語が全ての用途に適用できるということもこれ
からはないだろう。
目的に合った言語を選択していけばいいだけの話だ。
昔は、選択肢が無かっただけである。
現実的に考えても、起動の遅いJavaでは一般のユーザが使うア
プリケーションには、たしかに不向きである。
しかし、一度起動してしまえば再起動はそれほど必要ないサー
バサイドでは十分使えるし、J2EEなどサーバサイド向けの仕組
みが用意されているという強みがCやC++などに比べたらある。
JavaがCやC++に取って代わる言語になることは無いだろう。
また、１つの言語が全ての用途に適用できるということもこれ
からはないだろう。
目的に合った言語を選択していけばいいだけの話だ。
昔は、選択肢が無かっただけである。
現実的に考えても、起動の遅いJavaでは一般のユーザが使うア
プリケーションには、たしかに不向きである。
しかし、一度起動してしまえば再起動はそれほど必要ないサー
バサイドでは十分使えるし、J2EEなどサーバサイド向けの仕組
みが用意されているという強みがCやC++などに比べたらある。
http://www.saitama.gasuki.com/kaorin/
こんなのございま−す♪
￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣
〜oノハヽo〜
,.-''"¨￣●`' ‐（＾▽＾）
(,,●i,,,i,,,,,,,,i,,,,●),,)⊂ ）
） （ |｜ |
（ ＾▽＾） （_（＿_）
~~~~~ ￣￣ ~~~~~ ~~~~~
こんなのございま−す♪
￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣
〜oノハヽo〜
,.-''"¨￣●`' ‐（＾▽＾）
(,,●i,,,i,,,,,,,,i,,,,●),,)⊂ ）
） （ |｜ |
（ ＾▽＾） （_（＿_）
~~~~~ ￣￣ ~~~~~ ~~~~~
19 ：デフォルトの名無しさん：03/04/10 01:21
>確かに言語仕様は先祖たるCやC++よりも洗練されているのは
>理解できます。ですが、実用にたるプログラムの記述という
>面でははなはだ実力不足と思えます。
おいおい、ソースコードの記述能力は互角かそれ以上でしょう…
実行環境が現状ネイティブな実行ファイルの実行に比べて実力不足
という話なら同意してもいいが。
ただ、HotSpotVMは君が思っているような単純なインタプリタじゃないぞ。
実行時にJITコンパイラでネイティブコンパイルした後に、実行時情報を
集めながら実行速度が上がるように最適化をするという、笑っちゃうよ
うな機能がついている。どの程度有効なのかｼﾗﾝｹﾄﾞ、うまく最適化すれ
ばネイティブな実行ファイルの実行速度を上回ることも可能、とい
うことだ。そして、幾つかのテストケースでそれを実証できたらしい。
（Sun自身の報告だから、眉唾かもしれんけどね）
Javaが死ぬほど遅いのは、画面描画関係。ただここもJREVer1.4になっ
てから激しく改善されつづけているから、あんまり気にならない程度に
なることは、期待できるでしょう。
最後はメモリ消費かな？ｺﾚばっかりはどうしようもないと思われ。
ヒープもスレッドスタックフレームも、物凄い贅沢な使いかたしてる
から。
>理解できます。ですが、実用にたるプログラムの記述という
>面でははなはだ実力不足と思えます。
おいおい、ソースコードの記述能力は互角かそれ以上でしょう…
実行環境が現状ネイティブな実行ファイルの実行に比べて実力不足
という話なら同意してもいいが。
ただ、HotSpotVMは君が思っているような単純なインタプリタじゃないぞ。
実行時にJITコンパイラでネイティブコンパイルした後に、実行時情報を
集めながら実行速度が上がるように最適化をするという、笑っちゃうよ
うな機能がついている。どの程度有効なのかｼﾗﾝｹﾄﾞ、うまく最適化すれ
ばネイティブな実行ファイルの実行速度を上回ることも可能、とい
うことだ。そして、幾つかのテストケースでそれを実証できたらしい。
（Sun自身の報告だから、眉唾かもしれんけどね）
Javaが死ぬほど遅いのは、画面描画関係。ただここもJREVer1.4になっ
てから激しく改善されつづけているから、あんまり気にならない程度に
なることは、期待できるでしょう。
最後はメモリ消費かな？ｺﾚばっかりはどうしようもないと思われ。
ヒープもスレッドスタックフレームも、物凄い贅沢な使いかたしてる
から。
20 ：デフォルトの名無しさん：03/04/10 01:23
JavaはOSごとに挙動が異なるという致命的欠陥があるからなあ
21 ：デフォルトの名無しさん：03/04/10 01:25
つーかJavaはインタプリタという認識からおかしい・・
どうせネタだし、削除依頼してくる。
どうせネタだし、削除依頼してくる。
22 ：1：03/04/10 01:35
>>16
後継言語云々はどこから、という話ではなく、Javaの適用範囲として
CやC++が現在占めている分野をカバーできるのか？という問いかけです。
「実行速度が遅くてもいいからプログラマのミスをできるかぎり言語側でカバーする」
これって、典型的なbondage-and-discipline languageですよね。
PascalやAdaなんかと同じで批判も多いっちゅうか。
僕もこういう思想はキライではないですが、教育用にとどまっちゃいますよね。
後継言語云々はどこから、という話ではなく、Javaの適用範囲として
CやC++が現在占めている分野をカバーできるのか？という問いかけです。
「実行速度が遅くてもいいからプログラマのミスをできるかぎり言語側でカバーする」
これって、典型的なbondage-and-discipline languageですよね。
PascalやAdaなんかと同じで批判も多いっちゅうか。
僕もこういう思想はキライではないですが、教育用にとどまっちゃいますよね。
23 ：1：03/04/10 01:38
>>17
割りきれ、っちゅうことですかね。
プロ(システム開発者という意味での)が使う言語としては選択されるが、
個人の趣味のプログラムとしてはともかく、エンドユーザ向けの一般的な
アプリケーションを書くのには適さない、と。
しかし、これってCOBOLと似た境遇ではあるな。
COBOLは趣味の個人ベースでやってる人は変態っぽいですが。
割りきれ、っちゅうことですかね。
プロ(システム開発者という意味での)が使う言語としては選択されるが、
個人の趣味のプログラムとしてはともかく、エンドユーザ向けの一般的な
アプリケーションを書くのには適さない、と。
しかし、これってCOBOLと似た境遇ではあるな。
COBOLは趣味の個人ベースでやってる人は変態っぽいですが。
24 ：デフォルトの名無しさん：03/04/10 01:41
Javaは正直メジャーになるのが早すぎたんだと
思うけどね。
1.4で描画が速くなったって言っても、昔のイメージが
強すぎて試そうと思えないっすよ。
1.02〜1.2までは使ったけど、「将来的〜」っという
うたい文句がずっと続いて正直萎えました。
思うけどね。
1.4で描画が速くなったって言っても、昔のイメージが
強すぎて試そうと思えないっすよ。
1.02〜1.2までは使ったけど、「将来的〜」っという
うたい文句がずっと続いて正直萎えました。
25 ：1：03/04/10 01:44
>>19
ソースコードの記述能力云々は「言語仕様が洗練されている」と
同義と思いますが。なんか読み違いされてます？
HotSpotVMについての説明はありがとうございます。
しかし、実行時にコンパイルするのであれば、それは実行速度の速い
インタプリタにすぎず(良い悪いは別として)、たとえばOSやコンパイラ
を記述するなどといった分野では不利ですよね。
それに(SUNの主張をそのまま受け取るとして)、そこまですごい実行環境
であるにもかかわらず、>>17の言うように一般向けアプリケーションで
Javaのキラーアプリが出てこないのはなぜなのでしょうか？
>>19さんの後半の論旨のように、今後改善され、いずれはそういうものも出てくる？
やはりサーバサイドにとどまる？
ソースコードの記述能力云々は「言語仕様が洗練されている」と
同義と思いますが。なんか読み違いされてます？
HotSpotVMについての説明はありがとうございます。
しかし、実行時にコンパイルするのであれば、それは実行速度の速い
インタプリタにすぎず(良い悪いは別として)、たとえばOSやコンパイラ
を記述するなどといった分野では不利ですよね。
それに(SUNの主張をそのまま受け取るとして)、そこまですごい実行環境
であるにもかかわらず、>>17の言うように一般向けアプリケーションで
Javaのキラーアプリが出てこないのはなぜなのでしょうか？
>>19さんの後半の論旨のように、今後改善され、いずれはそういうものも出てくる？
やはりサーバサイドにとどまる？
26 ：デフォルトの名無しさん：03/04/10 01:45
Javaは、完全な実行時リンクの仕組み（必要になる度に必要なクラス
ファイルをロードし、しかも実行時にコンパイルまでしやがる）なの
で、初期化の作業が遅い。でも初期化以降はそんな遅くないよ。
…つうか、藻前らは試してみた上で発言してるのか？
ファイルをロードし、しかも実行時にコンパイルまでしやがる）なの
で、初期化の作業が遅い。でも初期化以降はそんな遅くないよ。
…つうか、藻前らは試してみた上で発言してるのか？
27 ：1：03/04/10 01:45
28 ：1：03/04/10 01:47
>>26
>>4でも書いたとおり、起動時以外は私も問題は無いのではという
感想を持っています。むしろ「単体のプログラムを生成する能力」
「完成品としてのプログラムを生成する能力」が欠けるがゆえ、
どこか中途半端になっている印象がある、というのが私の論旨です。
>>4でも書いたとおり、起動時以外は私も問題は無いのではという
感想を持っています。むしろ「単体のプログラムを生成する能力」
「完成品としてのプログラムを生成する能力」が欠けるがゆえ、
どこか中途半端になっている印象がある、というのが私の論旨です。
29 ：デフォルトの名無しさん：03/04/10 01:50
>>25
JavaでOSを書くのは難しくないと思うぞ。VMの上でOSを書くことに
意味があるのかどうかわからんが。
あと、JavaのスレッドモデルはOSモドキを行うにはいい加減すぎる
ので、困るだろうな。
あと、今のJavaコンパイラはJava製です。
JavaでOSを書くのは難しくないと思うぞ。VMの上でOSを書くことに
意味があるのかどうかわからんが。
あと、JavaのスレッドモデルはOSモドキを行うにはいい加減すぎる
ので、困るだろうな。
あと、今のJavaコンパイラはJava製です。
30 ：デフォルトの名無しさん：03/04/10 01:51
>>28
VMとアプリのライフタイムを一緒にすると、初期化で困るわな。
VMをデーモンのように一個あげておいて、プラグインみたいに機能を
呼び出す仕組みにすると、初期化のハンデを解決できると思うぞ。
Eclipseなんかがいい例ではないかな。
VMとアプリのライフタイムを一緒にすると、初期化で困るわな。
VMをデーモンのように一個あげておいて、プラグインみたいに機能を
呼び出す仕組みにすると、初期化のハンデを解決できると思うぞ。
Eclipseなんかがいい例ではないかな。
31 ：1：03/04/10 01:52
>>24
あと、SUNの調整能力というか、統率力のなさも指摘されてますよね。
言語仕様には口をはさむが、実行環境・処理系の提供が遅いというか。
SUNの調整能力とJava自体の能力とは無関係といえば無関係ですが、
CやC++(あるいはUnix)みたいにある程度醸成されるまでは自由に
拡張されて、「これでは良くない方向に拡散する」という一歩手前で
標準化される、という流れであればもっと違う発展もあったかもしれ
ないなあ。
あと、SUNの調整能力というか、統率力のなさも指摘されてますよね。
言語仕様には口をはさむが、実行環境・処理系の提供が遅いというか。
SUNの調整能力とJava自体の能力とは無関係といえば無関係ですが、
CやC++(あるいはUnix)みたいにある程度醸成されるまでは自由に
拡張されて、「これでは良くない方向に拡散する」という一歩手前で
標準化される、という流れであればもっと違う発展もあったかもしれ
ないなあ。
32 ：デフォルトの名無しさん：03/04/10 01:57
33 ：デフォルトの名無しさん：03/04/10 01:57
つーかSunが関わってる時点でもうだめぽ
34 ：1：03/04/10 01:58
>>29
「VM上で動くOSを作ることに意味があるのか」これがまさにJavaの抱える
弱点かと。素のネイティブコンパイラがあれば、もっと魅力的な言語に
なると思うんですが。
>>あと、今のJavaコンパイラはJava製です。
ご指摘サンクスです。
Javaに関してはこんな程度の知識なので、思い違い・認識違いも多いと思います。
しかし、Java製なのに、SDKはOSごとの提供なんですね。
「VM上で動くOSを作ることに意味があるのか」これがまさにJavaの抱える
弱点かと。素のネイティブコンパイラがあれば、もっと魅力的な言語に
なると思うんですが。
>>あと、今のJavaコンパイラはJava製です。
ご指摘サンクスです。
Javaに関してはこんな程度の知識なので、思い違い・認識違いも多いと思います。
しかし、Java製なのに、SDKはOSごとの提供なんですね。
35 ：デフォルトの名無しさん：03/04/10 01:59
何だかなあ。もう少し調べてから書いてくれ。
36 ：デフォルトの名無しさん：03/04/10 02:00
37 ：1：03/04/10 02:00
やはり良スレだったようだな
39 ：1：03/04/10 02:02
>>35
そういわれると申し訳ないです。
Java信者を増やすつもりでご指摘・教授していただければありがたい。
とはいえ、今のところ、ネイティブな実行ファイルを生成できないデメリット
以上のメリットが見出せない、そして、僕が一番つっかえているのがこの点
なんですが。
そういわれると申し訳ないです。
Java信者を増やすつもりでご指摘・教授していただければありがたい。
とはいえ、今のところ、ネイティブな実行ファイルを生成できないデメリット
以上のメリットが見出せない、そして、僕が一番つっかえているのがこの点
なんですが。
40 ：デフォルトの名無しさん：03/04/10 02:08
>>37
それなら言語の発展が遅いのであって、提供が遅いとは言わない。
あと JCP は知ってる？
http://www.jcp.org/ja/home/index
>>39
開発しやすい。これが圧倒的なメリット。
でなきゃこれだけ使われていない。
それなら言語の発展が遅いのであって、提供が遅いとは言わない。
あと JCP は知ってる？
http://www.jcp.org/ja/home/index
>>39
開発しやすい。これが圧倒的なメリット。
でなきゃこれだけ使われていない。
41 ：デフォルトの名無しさん：03/04/10 02:12
>>37
JRE1.4RIは、最早Sunだけで作ってるんじゃなかったよ。
>>39
バイトコードをサーバに置いといて、クライアントのOSに関係なく
バイトコードをコンパイラナシでダウンロード即実行できます。
だからなんだ、そんなのスクリプトと一緒じゃん、という反論が
あるかもしれませんが、バイトコードはすでにJavaコンパイラの
チェックを受けている＋バイトコードのVM上の実行には、
VMがもつセキュリティチェック機構の洗礼があるので、わけわからん
スクリプトをダウンロード実行するより、ずっと安全です。
バイトコードであるクラスファイルの書庫がデジタル署名されて
いて、クライアントがその署名に承認しないと、ダウンロードした
クライアントのローカル環境へのアクセスが禁止されたりします。
勝手にファイル消したりバックドア仕込んだりは出来ません。
便利でしょ。
JRE1.4RIは、最早Sunだけで作ってるんじゃなかったよ。
>>39
バイトコードをサーバに置いといて、クライアントのOSに関係なく
バイトコードをコンパイラナシでダウンロード即実行できます。
だからなんだ、そんなのスクリプトと一緒じゃん、という反論が
あるかもしれませんが、バイトコードはすでにJavaコンパイラの
チェックを受けている＋バイトコードのVM上の実行には、
VMがもつセキュリティチェック機構の洗礼があるので、わけわからん
スクリプトをダウンロード実行するより、ずっと安全です。
バイトコードであるクラスファイルの書庫がデジタル署名されて
いて、クライアントがその署名に承認しないと、ダウンロードした
クライアントのローカル環境へのアクセスが禁止されたりします。
勝手にファイル消したりバックドア仕込んだりは出来ません。
便利でしょ。
42 ：デフォルトの名無しさん：03/04/10 02:56
こりゃまた痛い>>1がきたもんだなぁ。
痛すぎてマジレスする気にもならん。
痛すぎてマジレスする気にもならん。
43 ：デフォルトの名無しさん：03/04/10 02:57
44 ：デフォルトの名無しさん：03/04/10 03:06
遅いのが嫌ならwindows使うなや
45 ：デフォルトの名無しさん：03/04/10 03:07
46 ：デフォルトの名無しさん：03/04/10 03:35
おおむね間違ってないじゃん。
47 ：デフォルトの名無しさん：03/04/10 04:18
AOTコンパイラなら、GCJとか商用ベンダの奴とかありますが。
48 ：デフォルトの名無しさん：03/04/10 04:55
「OSが書けない」なんてねぇ…
大昔のJava死滅スレの煽り文句じゃあるまいし…
大昔のJava死滅スレの煽り文句じゃあるまいし…
49 ：デフォルトの名無しさん：03/04/10 07:18
C++、Java、C#天下三分
どらかひとつの言語がすべての範囲をカバーする時代は終わった。
どらかひとつの言語がすべての範囲をカバーする時代は終わった。
だいたい、一つの言語ですべてをまかなえないと駄目みたいな
発想自身が旧石器時代の考えだね。
油絵を水彩絵の具で描く馬鹿はいない。
ところでいつJavaを「汎用」言語としてSUNはセールスしたっけ？ >>1
俺は「マルチプラットホーム」「セキュリティ」のセールス文句しか
しらないけどね。
発想自身が旧石器時代の考えだね。
油絵を水彩絵の具で描く馬鹿はいない。
ところでいつJavaを「汎用」言語としてSUNはセールスしたっけ？ >>1
俺は「マルチプラットホーム」「セキュリティ」のセールス文句しか
しらないけどね。
51 ：デフォルトの名無しさん：03/04/10 12:31
馬鹿->C++、Java、C#天下三分
普通の人->C++、C、C#天下三分
普通の人->C++、C、C#天下三分
52 ：デフォルトの名無しさん：03/04/10 12:31
少なくともJavaのUIは糞だな.。
53 ：デフォルトの名無しさん：03/04/10 12:36
PerlやPHPでOSが書けないからってクソ扱いする奴はいないし、
CやC++でWebアプリ書く奴も（あんまり）いない。
世の中適材適所なんだよ。
Javaが得意なのは上位層の中〜大規模なソフトウェア。
CやC++でWebアプリ書く奴も（あんまり）いない。
世の中適材適所なんだよ。
Javaが得意なのは上位層の中〜大規模なソフトウェア。
54 ：デフォルトの名無しさん：03/04/10 13:10
組込み系は物にもよるけど、動画、静止画、音声処理の
要求が多くなってきたから、Javaは使う気になりません。
そういえば、MEのfloatサポートって今はどうなんだろうか？
要求が多くなってきたから、Javaは使う気になりません。
そういえば、MEのfloatサポートって今はどうなんだろうか？
55 ：デフォルトの名無しさん：03/04/10 13:15
結局のところ｢汎用言語」の意味する所が問題なのか？
Javaはそもそもシステム記述言語ではない。OSやドライバは作れないのが当然だ。
→じゃあ汎用言語じゃないね。
→そういったシステムに近い部分はC言語の領域だ。
→システムも記述できなきゃ汎用言語じゃない。
→それは昔のC言語とアセンブラの関係と同じだ。アセンブラでないと書けないことが
あるからといってC言語が汎用言語でないとは言わないだろ？
→それならC言語は汎用言語と認めてやるよ。でもJavaは認めんぞ。
Javaはデスクトップアプリが作れる
→GUIの遅さや起動の遅さが致命的だ。実用性がない。
→オレにとっては実用的だ。
→それはオマエの感覚が麻痺してるのさ。一般ユーザーが耐えられないのなら
実用性がないのと同じだ。
→でもオレにとっては実用的だ。。。
Javaは美しいオブジェクト指向言語だ
→だからどうした？ オマエの趣味には付き合ってられない。
→プログラミング言語は言語仕様が洗練されている方がいいに決まってるだろ？
→じゃあ、教育用、研究用の言語だね。汎用言語とは呼ばないよ。
→だからJavaはオブジェクト指向だから。。。オブジェクト指向だから。。。
Javaの強みはサーバサイドにある。
→それなら汎用言語ではない、と認めたのか？
→いやJavaでもOSを書けるし、デスクトップアプリも書けるし。。。
→実用性がないじゃん。オマエは高木浩光か？ 無理してないか？
ループだね。。。。
Javaはそもそもシステム記述言語ではない。OSやドライバは作れないのが当然だ。
→じゃあ汎用言語じゃないね。
→そういったシステムに近い部分はC言語の領域だ。
→システムも記述できなきゃ汎用言語じゃない。
→それは昔のC言語とアセンブラの関係と同じだ。アセンブラでないと書けないことが
あるからといってC言語が汎用言語でないとは言わないだろ？
→それならC言語は汎用言語と認めてやるよ。でもJavaは認めんぞ。
Javaはデスクトップアプリが作れる
→GUIの遅さや起動の遅さが致命的だ。実用性がない。
→オレにとっては実用的だ。
→それはオマエの感覚が麻痺してるのさ。一般ユーザーが耐えられないのなら
実用性がないのと同じだ。
→でもオレにとっては実用的だ。。。
Javaは美しいオブジェクト指向言語だ
→だからどうした？ オマエの趣味には付き合ってられない。
→プログラミング言語は言語仕様が洗練されている方がいいに決まってるだろ？
→じゃあ、教育用、研究用の言語だね。汎用言語とは呼ばないよ。
→だからJavaはオブジェクト指向だから。。。オブジェクト指向だから。。。
Javaの強みはサーバサイドにある。
→それなら汎用言語ではない、と認めたのか？
→いやJavaでもOSを書けるし、デスクトップアプリも書けるし。。。
→実用性がないじゃん。オマエは高木浩光か？ 無理してないか？
ループだね。。。。
56 ：デフォルトの名無しさん：03/04/10 13:21
後継というより棲み分けだね。
57 ：デフォルトの名無しさん：03/04/10 13:31
>>55
ひろみちゅと喧嘩して負けたのが余程悔しかったんだね…
ひろみちゅと喧嘩して負けたのが余程悔しかったんだね…
58 ：デフォルトの名無しさん：03/04/10 14:22
>>50
汎用とは言ってないですね。あらゆるプラットフォーム
でっとは言ってが(もう忘れた)
でも、Sunは Java vs .net の方向で行こうとしている
訳だから、ドライバとかは置いておくとしても、クライ
アントサイドもある程度使い物にならないと辛いんじゃ
ない？
汎用とは言ってないですね。あらゆるプラットフォーム
でっとは言ってが(もう忘れた)
でも、Sunは Java vs .net の方向で行こうとしている
訳だから、ドライバとかは置いておくとしても、クライ
アントサイドもある程度使い物にならないと辛いんじゃ
ない？
59 ：デフォルトの名無しさん：03/04/10 14:36
クライアントサイドのJavaがダメなのは、Javaが悪いと言うより、
Swingが悪い。
特に初期のSwingは確かに使い物にならなかった。
言語仕様だけ見れば、Javaはクライアントアプリケーションくらい
楽々こなせるよ。
解決策は「SWT使え」
Swingが悪い。
特に初期のSwingは確かに使い物にならなかった。
言語仕様だけ見れば、Javaはクライアントアプリケーションくらい
楽々こなせるよ。
解決策は「SWT使え」
60 ：デフォルトの名無しさん：03/04/10 16:11
そういやJavaOSとかJavaChipなんてネタもあったな。
ネタで終わったけど。
なんでもかんでも１つでやりたいならアセンブラでも
使えばいい。何でもできるぞ（ｗ
労力さえいとわなければな。
ネタで終わったけど。
なんでもかんでも１つでやりたいならアセンブラでも
使えばいい。何でもできるぞ（ｗ
労力さえいとわなければな。
1です。
だいたいの世間の評価(というか2chの評価)はわかりました。
・そもそも現在は適材適所で言語を選ぶのが吉。
・Javaはデスクトップアプリケーションには向いていないのは確か。
・とはいえ、サーバサイドでは構築のしやすさから主流たりうる。
・そもそも汎用言語じゃない。
納得できることもあったし、勉強にもなりました。
あとは名無しに戻ります。
ききたいことがあるとすれば、みなさんはJavaを(仕事以外で)なにに
使っておられるのでしょうか。
だいたいの世間の評価(というか2chの評価)はわかりました。
・そもそも現在は適材適所で言語を選ぶのが吉。
・Javaはデスクトップアプリケーションには向いていないのは確か。
・とはいえ、サーバサイドでは構築のしやすさから主流たりうる。
・そもそも汎用言語じゃない。
納得できることもあったし、勉強にもなりました。
あとは名無しに戻ります。
ききたいことがあるとすれば、みなさんはJavaを(仕事以外で)なにに
使っておられるのでしょうか。
62 ：デフォルトの名無しさん：03/04/11 01:02
>>2
実行時にJITでコンパイルした方が高速になるという研究成果もしらないで何を言うか
JETという、exeに変換できるコンパイラを知らんのかね？
>>3
>結局自分自身も記述できない言語では半人前です。
意味不明
>>4
長時間にわたる開発、再利用性を高めた開発効率を持つJavaは設計思想がC/C++とは違うのだよ。
>>6
その意見、古い。署名すればローカルファイルにアクセスできるぞお前。
Appletの三度ボックスモデルと何か近藤してないか。
土台部分の拡張はJCP(JavaCommunityProcess)でやってることも知らんでおいて。
その意見はJCPがでる以前の話だなこりゃ。
実行時にJITでコンパイルした方が高速になるという研究成果もしらないで何を言うか
JETという、exeに変換できるコンパイラを知らんのかね？
>>3
>結局自分自身も記述できない言語では半人前です。
意味不明
>>4
長時間にわたる開発、再利用性を高めた開発効率を持つJavaは設計思想がC/C++とは違うのだよ。
>>6
その意見、古い。署名すればローカルファイルにアクセスできるぞお前。
Appletの三度ボックスモデルと何か近藤してないか。
土台部分の拡張はJCP(JavaCommunityProcess)でやってることも知らんでおいて。
その意見はJCPがでる以前の話だなこりゃ。
63 ：デフォルトの名無しさん：03/04/11 01:13
>>25
すでにキラーアプリはでてるだろううが。
サーバサイドという分野そのものがまさしくキラーアプリだ。
将来、サーバとクライアントとの区別がつかなくなればサーバにとどまるという言葉も
変になるだろう。
>>55
Jiniによってドライバつくれるってよ
すでにキラーアプリはでてるだろううが。
サーバサイドという分野そのものがまさしくキラーアプリだ。
将来、サーバとクライアントとの区別がつかなくなればサーバにとどまるという言葉も
変になるだろう。
>>55
Jiniによってドライバつくれるってよ
64 ：デフォルトの名無しさん：03/04/11 01:25
65 ：デフォルトの名無しさん：03/04/11 01:40
66 ：デフォルトの名無しさん：03/04/11 05:33
JavaをCやC++と比べてる時点で間違い。
あれはLISPを理解出来ない頭の悪い人の
ための言語です。
あれはLISPを理解出来ない頭の悪い人の
ための言語です。
67 ：デフォルトの名無しさん：03/04/11 07:12
頭が良いから使うってだけじゃ、
使う理由がないのと同じなんだがねぇ。
ねぇ、煽り厨さん。
使う理由がないのと同じなんだがねぇ。
ねぇ、煽り厨さん。
68 ：デフォルトの名無しさん：03/04/11 10:08
java=21性器のcobol
69 ：デフォルトの名無しさん：03/04/11 11:29
70 ：デフォルトの名無しさん：03/04/11 12:29
71 ：デフォルトの名無しさん：03/04/11 12:43
Java(M$はJ#と呼んでいる）は、緻密・厳格なライブラリを持ったＣ言語
Ｃ＋＋の拡張じゃなくＣの拡張。Ｃ＋＋とＪａｖａが対等な比較対象
なんじゃ？
プラットフォームに依存しないアプリのプロトタイプ・仕様書作成の為
の言語であり、移植・保守の際に仕様書代わりにこの言語で書かれたソ
ースを読む。そういう使い方がベストで、携帯とかの小規模システム以
外は仮想マシン実装なんで重い、遅いで使いにくい。逆に言えばそうい
う実装を取るのは、プロトタイプ作業用の言語だということを示してい
るようなもの。
Ｃ＋＋の場合は実装が重視されている感じ。Windowsの場合、ライブラリ
の複雑さに対してはＣ＋＋仕様じゃとてもじゃないが対応していけないやから、
Ｃ＋＋とＪａｖａの中間のＣ＃を実装用ソース記述言語とするみたいだが。
Ｃ＋＋の拡張じゃなくＣの拡張。Ｃ＋＋とＪａｖａが対等な比較対象
なんじゃ？
プラットフォームに依存しないアプリのプロトタイプ・仕様書作成の為
の言語であり、移植・保守の際に仕様書代わりにこの言語で書かれたソ
ースを読む。そういう使い方がベストで、携帯とかの小規模システム以
外は仮想マシン実装なんで重い、遅いで使いにくい。逆に言えばそうい
う実装を取るのは、プロトタイプ作業用の言語だということを示してい
るようなもの。
Ｃ＋＋の場合は実装が重視されている感じ。Windowsの場合、ライブラリ
の複雑さに対してはＣ＋＋仕様じゃとてもじゃないが対応していけないやから、
Ｃ＋＋とＪａｖａの中間のＣ＃を実装用ソース記述言語とするみたいだが。
72 ：デフォルトの名無しさん：03/04/11 13:02
C++の特殊化だと思うぞ。
プロトタイプ用言語を目指しているのなら、もっと多機能していると思う。
（プロトタイプ用って銘打っているのってpythonぐらい？）
言語屋がC++を特殊化するとJavaになって、
コンパイラ屋がC++を特殊化するとC#になるってイメージを持ってたりする。
プロトタイプ用言語を目指しているのなら、もっと多機能していると思う。
（プロトタイプ用って銘打っているのってpythonぐらい？）
言語屋がC++を特殊化するとJavaになって、
コンパイラ屋がC++を特殊化するとC#になるってイメージを持ってたりする。
73 ：デフォルトの名無しさん：03/04/11 13:21
>>72
俺も近いけど、どちらかというと
理想主義者->Java
現実主義者->C#
って感じかな。
まぁ、理想主義者=言語屋に近い感じだけど、
言語として洗練してったらJavaだと思う。
structやWindows.Formsなど汚らしいけど使いやすい必要悪も入れたのがC#だと思う。
当時周りにまだ敵がいなかったJavaは理想を追求することができたけど、
後出しのC#は遠くの理想より目先の現実に目を向けざるを得なかったんだろうと思うよ。
俺も近いけど、どちらかというと
理想主義者->Java
現実主義者->C#
って感じかな。
まぁ、理想主義者=言語屋に近い感じだけど、
言語として洗練してったらJavaだと思う。
structやWindows.Formsなど汚らしいけど使いやすい必要悪も入れたのがC#だと思う。
当時周りにまだ敵がいなかったJavaは理想を追求することができたけど、
後出しのC#は遠くの理想より目先の現実に目を向けざるを得なかったんだろうと思うよ。
74 ：デフォルトの名無しさん：03/04/11 13:25
UNIX板ですが
Ｃ＋＋って使わないの？？
http://pc.2ch.net/test/read.cgi/unix/1004227343/
という面白いスレがあります。
C++が中心テーマですが、Javaにもかなり言及しています。
この板とはまた違った視点があって興味を惹かれます。
Ｃ＋＋って使わないの？？
http://pc.2ch.net/test/read.cgi/unix/1004227343/
という面白いスレがあります。
C++が中心テーマですが、Javaにもかなり言及しています。
この板とはまた違った視点があって興味を惹かれます。
75 ：デフォルトの名無しさん：03/04/11 14:00
別にJavaをC/C++の後継にする必然性はないでしょ。適材適所。
Javaって基本的にリッチなリソースがある環境下で使うものだし。
組み込みとかならCだし、パッケージソフトならC/C++だし。
Javaって基本的にリッチなリソースがある環境下で使うものだし。
組み込みとかならCだし、パッケージソフトならC/C++だし。
76 ：デフォルトの名無しさん：03/04/11 14:08
ｳﾆ板はperler、rubyist擬きが、しったかでプログラミングを語るので話にもならないっす
未だに<locale>すら付いてないような糞バージョンのコンパイラの方を、安定版とか称して使ってる連中に何言われてもね・・・
所詮、EmacsとかMozillaで日本語通れば、平気で「日本語通りますが何か？」とかほざくような連中だってことっす
Javaにしても
> SWT=WinならMFC、Unix系ならQt、GTKを使用した時と大して速度は変わらん
こういう↑バカがいなくならない限り、Java厨はいつまでもバカにされ続けるっす
ごちゃごちゃと能書きをたれる前に SWT製の2chブラウザでも作って、Del灰製の2chブラウザとどちらが軽快に動作するのか
ソ板辺りでアンケートしてもらいたいもんっす
Del灰製より明らかに速いという結果が出てから
> SWT=WinならMFC、Unix系ならQt、GTKを使用した時と大して速度は変わらん
こんな↑能書きをたれてくらさい
Java厨っていつも能書きと妄想ばかりだね（ﾌﾟ
ヤバくなったら適材適所で逃げ？ 生きていて恥ずかしくないの？（ﾌﾟﾌﾟ
未だに<locale>すら付いてないような糞バージョンのコンパイラの方を、安定版とか称して使ってる連中に何言われてもね・・・
所詮、EmacsとかMozillaで日本語通れば、平気で「日本語通りますが何か？」とかほざくような連中だってことっす
Javaにしても
> SWT=WinならMFC、Unix系ならQt、GTKを使用した時と大して速度は変わらん
こういう↑バカがいなくならない限り、Java厨はいつまでもバカにされ続けるっす
ごちゃごちゃと能書きをたれる前に SWT製の2chブラウザでも作って、Del灰製の2chブラウザとどちらが軽快に動作するのか
ソ板辺りでアンケートしてもらいたいもんっす
Del灰製より明らかに速いという結果が出てから
> SWT=WinならMFC、Unix系ならQt、GTKを使用した時と大して速度は変わらん
こんな↑能書きをたれてくらさい
Java厨っていつも能書きと妄想ばかりだね（ﾌﾟ
ヤバくなったら適材適所で逃げ？ 生きていて恥ずかしくないの？（ﾌﾟﾌﾟ
あぁゴメン。
俺はこのスレの1とは無関係だ。
俺はこのスレの1とは無関係だ。
79 ：24 & 70：03/04/11 16:08
>>76
> 未だに<locale>すら付いてないような糞バージョンのコンパイラ
Javaコンパイラはlocale対応してなかったか？
日本語っという所だけみると使いにくかったが。。
> > SWT=WinならMFC、Unix系ならQt、GTKを使用した時と大して速度は変わらん
>こういう↑バカがいなくならない限り、Java厨はいつまでもバカにされ続けるっす
>>24で言った理由により、実際にJava開発はやめているので
現状のJavaがどんなもんか、聞いただけだが？
Swingはマダマダだけど、SWTならOK！って言っているから
MFC、QT、GTK等の既存ライブラリと較べても、それほど
遜色ないのか？っと思って聞いたんだよ
> Del灰製より明らかに速いという結果が出てから
Del灰は16bit版の頃にやっただけです。
なので、現状はJavaより知らない(^^;
> 未だに<locale>すら付いてないような糞バージョンのコンパイラ
Javaコンパイラはlocale対応してなかったか？
日本語っという所だけみると使いにくかったが。。
> > SWT=WinならMFC、Unix系ならQt、GTKを使用した時と大して速度は変わらん
>こういう↑バカがいなくならない限り、Java厨はいつまでもバカにされ続けるっす
>>24で言った理由により、実際にJava開発はやめているので
現状のJavaがどんなもんか、聞いただけだが？
Swingはマダマダだけど、SWTならOK！って言っているから
MFC、QT、GTK等の既存ライブラリと較べても、それほど
遜色ないのか？っと思って聞いたんだよ
> Del灰製より明らかに速いという結果が出てから
Del灰は16bit版の頃にやっただけです。
なので、現状はJavaより知らない(^^;
80 ：デフォルトの名無しさん：03/04/11 16:14
81 ：デフォルトの名無しさん：03/04/12 02:04
>>72-73
その割りにアンチC#の煽り文句が決まって「案件が無い」なんてやたら現実的なのはなぜだろう？
その割りにアンチC#の煽り文句が決まって「案件が無い」なんてやたら現実的なのはなぜだろう？
82 ：デフォルトの名無しさん：03/04/12 20:45
>>81
最近は、そこそこでてきました。実際に案件にくるのは
ある程度枯れてからっす。そこんとこよろしく
最近は、IBMがらみの仕事が増えてきた（これは会社に
もよるけど、全体的に）ので、自社製品固めが多いです。
そうなると仕事はＪａｖａになりまつ。。。。
# N、Ｆ製のわけのわからんやつを押し付けられるより
# 万倍ましだが
あとは日本の会社の経営陣は言語にも口出しするから
ビジネス誌でＪａｖａマンセーって記事が載ったのを
そのまま鵜呑みにしているからです。
上のなんか奇麗事を並べたやつが有利なので、Ｊａｖａ
の案件がおおいの
最近は、そこそこでてきました。実際に案件にくるのは
ある程度枯れてからっす。そこんとこよろしく
最近は、IBMがらみの仕事が増えてきた（これは会社に
もよるけど、全体的に）ので、自社製品固めが多いです。
そうなると仕事はＪａｖａになりまつ。。。。
# N、Ｆ製のわけのわからんやつを押し付けられるより
# 万倍ましだが
あとは日本の会社の経営陣は言語にも口出しするから
ビジネス誌でＪａｖａマンセーって記事が載ったのを
そのまま鵜呑みにしているからです。
上のなんか奇麗事を並べたやつが有利なので、Ｊａｖａ
の案件がおおいの
83 ：デフォルトの名無しさん：03/04/12 21:02
84 ：プロの逝って良しの１ ◆MvRbZL6NeQ ：03/04/12 23:44
Ｊａｖａ使ってるうちにＶＣの組み方忘れた。
Ｃなら組めるんだが
Ｃなら組めるんだが
85 ：デフォルトの名無しさん：03/04/13 00:14
↑結局OO要らないとかほざいているくせにJava使っててVC忘れたときたか、、、
86 ：1：03/04/13 01:25
「VCの組み方」だと、>>84がVCの開発者みたいだな。
87 ：デフォルトの名無しさん：03/04/13 18:14
インタープリタ嫌い。
Cでいいじゃん。
Cでいいじゃん。
88 ：デフォルトの名無しさん：03/04/13 18:38
Javaがいまだにインタプリタだと思ってるような輩は死んでください
89 ：デフォルトの名無しさん：03/04/13 18:46
>>88
駄目だこりゃ
駄目だこりゃ
90 ：デフォルトの名無しさん：03/04/13 19:31
エミュレータがインタプリタ呼ばわりされるインターネットはここですか？
91 ：デフォルトの名無しさん：03/04/13 19:36
>>90
実際にインタプリタだにょ
実際にインタプリタだにょ
92 ：デフォルトの名無しさん：03/04/13 20:02
VBや.NETモナー
ネイティブなのはDelphiだけ
中間コードを逐次実行するからインタプリタってのも乱暴な気がするが
ネイティブなのはDelphiだけ
中間コードを逐次実行するからインタプリタってのも乱暴な気がするが
93 ：デフォルトの名無しさん：03/04/13 20:27
94 ：デフォルトの名無しさん：03/04/13 21:15
95 ：デフォルトの名無しさん：03/04/14 00:22
なんつーか、文末に「何か」を付ける場合、一文だけにした方がいいと思うんだよね。
複数付けると無理矢理揃えてる感じがして、それが必死な感じのように思えてしまう。
あと、「何か」の後に続けてしまうと、せっかく煽ったのを冷静に戻してしまう。
複数付けると無理矢理揃えてる感じがして、それが必死な感じのように思えてしまう。
あと、「何か」の後に続けてしまうと、せっかく煽ったのを冷静に戻してしまう。
96 ：デフォルトの名無しさん：03/04/14 00:46
へぇーマイクロコードに変換できちゃうんだ、はじめて知った。86でいうjavaがらみのdllってなんでしょうね？.classの中がまさかネイティブなコードになってるとか言わないでね
97 ：デフォルトの名無しさん：03/04/14 00:51
>>96
誰も言って無いのにマイクロコードと言い出す馬鹿は氏んでください。
誰も言って無いのにマイクロコードと言い出す馬鹿は氏んでください。
98 ：デフォルトの名無しさん：03/04/14 00:56
> 86でいうjavaがらみのdllってなんでしょうね？
ぐはは。わけわかんね。
ぐはは。わけわかんね。
99 ：デフォルトの名無しさん：03/04/14 02:10
100 ：デフォルトの名無しさん：03/04/14 10:10
非ネイティブコードを実行するのがインタプリタ？
その解釈は頭悪すぎ
その解釈は頭悪すぎ
101 ：デフォルトの名無しさん：03/04/14 10:14
Java厨必死だな(ﾜﾗﾜﾗ
102 ：デフォルトの名無しさん：03/04/14 10:29
別に仕組みはわかってるんだから、今更呼び方なんかうんこ
103 ：デフォルトの名無しさん：03/04/14 10:29
(Visual)C/C++の後継はC#だろ（一部領域除く）
JavaはCOBOLの後継、良かったな
JavaはCOBOLの後継、良かったな
104 ：デフォルトの名無しさん：03/04/14 10:42
105 ：デフォルトの名無しさん：03/04/14 10:57
106 ：デフォルトの名無しさん：03/04/14 11:03
107 ：デフォルトの名無しさん：03/04/14 11:04
>>89
オマエモナー
オマエモナー
108 ：デフォルトの名無しさん：03/04/14 11:05
109 ：デフォルトの名無しさん：03/04/14 11:07
110 ：デフォルトの名無しさん：03/04/14 11:14
>>73
> 俺も近いけど、どちらかというと
> 理想主義者->Java
> 現実主義者->C#
> structやWindows.Formsなど汚らしいけど使いやすい必要悪も入れたのがC#だと思う。
速度重視の世界ではそれが成り立つが、拡張性重視の世界ではそれ(理想-現実)が逆転する。
strutsは速度問題や、古い言語との互換性を保つためにあえて付けられたものであるという認識が
強いが。C#が現実主義だと言い張るのは古くからC/C++を使ってきてC/C++こそが最高の
言語であるという妄想を持っている者にたいしては説得力があるが、大規模プログラミングで
C/C++のstructの欠点を知ってしまった人にしてみれば、継承もできないものは現実的とは
誰も思わない。
> 当時周りにまだ敵がいなかったJavaは理想を追求することができたけど、
> 後出しのC#は遠くの理想より目先の現実に目を向けざるを得なかったんだろうと思うよ。
その目先の現実というものがどういうものをさしているかにもよるが。
長くプログラムを使うことを想定するならC#よりJavaのほうが現実的
JavaのAPIやフレームワークはC#のそれよりもしっかりしており洗練されている。
> 俺も近いけど、どちらかというと
> 理想主義者->Java
> 現実主義者->C#
> structやWindows.Formsなど汚らしいけど使いやすい必要悪も入れたのがC#だと思う。
速度重視の世界ではそれが成り立つが、拡張性重視の世界ではそれ(理想-現実)が逆転する。
strutsは速度問題や、古い言語との互換性を保つためにあえて付けられたものであるという認識が
強いが。C#が現実主義だと言い張るのは古くからC/C++を使ってきてC/C++こそが最高の
言語であるという妄想を持っている者にたいしては説得力があるが、大規模プログラミングで
C/C++のstructの欠点を知ってしまった人にしてみれば、継承もできないものは現実的とは
誰も思わない。
> 当時周りにまだ敵がいなかったJavaは理想を追求することができたけど、
> 後出しのC#は遠くの理想より目先の現実に目を向けざるを得なかったんだろうと思うよ。
その目先の現実というものがどういうものをさしているかにもよるが。
長くプログラムを使うことを想定するならC#よりJavaのほうが現実的
JavaのAPIやフレームワークはC#のそれよりもしっかりしており洗練されている。
111 ：デフォルトの名無しさん：03/04/14 11:18
>>76
Javaを馬鹿にする前に
お前のようなDel厨使っているマシンのスペックと
お前のいう体感速度というものがどれくらいなのか説明してからにしろ。
J2SE1.4.2になってから速度も上昇し
使い方次第ではCの速度を超越するという結果も出ている。
お前こそ生きてて恥ずかしくないの？(ﾌﾟ
Javaを馬鹿にする前に
お前のようなDel厨使っているマシンのスペックと
お前のいう体感速度というものがどれくらいなのか説明してからにしろ。
J2SE1.4.2になってから速度も上昇し
使い方次第ではCの速度を超越するという結果も出ている。
お前こそ生きてて恥ずかしくないの？(ﾌﾟ
112 ：デフォルトの名無しさん：03/04/14 11:29
113 ：デフォルトの名無しさん：03/04/14 11:35
114 ：デフォルトの名無しさん：03/04/14 11:35
115 ：デフォルトの名無しさん：03/04/14 11:36
Javaは知らない間に高速化しているよ。
C++より速くなる事だってある。
C++より速くなる事だってある。
116 ：デフォルトの名無しさん：03/04/14 11:40
＞長くプログラムを使うことを想定するならC#よりJavaのほうが現実的
21世紀のCOBOLといわれる理由はこのあたり
21世紀のCOBOLといわれる理由はこのあたり
117 ：デフォルトの名無しさん：03/04/14 13:10
118 ：デフォルトの名無しさん：03/04/15 02:45
>>94>>111>>115
JavaがC/C++より優れていることは良くわかりました。
というわけで、Javaで最初っからネイティブコンパイルされたという
アプリケーションをなんか紹介してください。
VMとかもいらんのですよね。いるんならVB並ですもんね。
JavaがC/C++より優れていることは良くわかりました。
というわけで、Javaで最初っからネイティブコンパイルされたという
アプリケーションをなんか紹介してください。
VMとかもいらんのですよね。いるんならVB並ですもんね。
119 ：デフォルトの名無しさん：03/04/15 03:14
>>110
>strutsは速度問題や、古い言語との互換性を保つためにあえて付けられたものであるという認識が
なんでそうなるのかなー
structは値型を表現するためにある。速度なんてかえって遅くなる
>大規模プログラミングで C/C++のstructの欠点を知ってしまった人
いったい何が欠点なのか。よく知らないことを長文で書くもんじゃないよ
>strutsは速度問題や、古い言語との互換性を保つためにあえて付けられたものであるという認識が
なんでそうなるのかなー
structは値型を表現するためにある。速度なんてかえって遅くなる
>大規模プログラミングで C/C++のstructの欠点を知ってしまった人
いったい何が欠点なのか。よく知らないことを長文で書くもんじゃないよ
120 ：デフォルトの名無しさん：03/04/15 08:49
∧＿∧
（ ´∀｀）＜0x82ca, 0x82e9, 0x82db
（ ´∀｀）＜0x82ca, 0x82e9, 0x82db
121 ：デフォルトの名無しさん：03/04/15 11:10
最近の学校は、Java厨の先生が多いのか？
122 ：デフォルトの名無しさん：03/04/15 13:59
123 ：デフォルトの名無しさん：03/04/15 16:31
>>119
structは遅くなる場合も速くなる場合もあるかと。
structは遅くなる場合も速くなる場合もあるかと。
124 ：デフォルトの名無しさん：03/04/15 20:30
>>118
>JavaがC/C++より優れていることは良くわかりました
あなたが何も分かってないということがよく分かりました。
もう一度このスレを頭から舐めるように全部読んだ上で首吊ってください。さようなら。
>JavaがC/C++より優れていることは良くわかりました
あなたが何も分かってないということがよく分かりました。
もう一度このスレを頭から舐めるように全部読んだ上で首吊ってください。さようなら。
125 ：デフォルトの名無しさん：03/04/15 21:02
Ｊａｖａ自信はＣで書いてるのかな？
ＵＮＩＸやｗｉｎｄｏｗｓ系のＯＳターゲットなら
Ｃが一番てっとりばやいのでは？
ＵＮＩＸやｗｉｎｄｏｗｓ系のＯＳターゲットなら
Ｃが一番てっとりばやいのでは？
126 ：デフォルトの名無しさん：03/04/15 21:16
>大規模プログラミングで C/C++のstructの欠点を知ってしまった人
C++ではclassもstructもさして変わらないという面白い事実
C++ではclassもstructもさして変わらないという面白い事実
127 ：デフォルトの名無しさん：03/04/15 22:14
>>119が言ってるように、struct=値型オブジェクト、の欠点という意味だろう。
128 ：デフォルトの名無しさん：03/04/15 23:06
129 ：デフォルトの名無しさん：03/04/16 04:46
SunのJ2SDKがバイトコード以外にプラットフォームネイティブのバイナリも
吐くことができて、ランタイムもスタティックリンクしてくれたら便利なのにと
思うことは多いな。
吐くことができて、ランタイムもスタティックリンクしてくれたら便利なのにと
思うことは多いな。
130 ：デフォルトの名無しさん：03/04/16 10:06
JAVAはTOMCATと合わさって初めて動くのだ！
131 ：デフォルトの名無しさん：03/04/16 12:51
はぁ？
132 ：デフォルトの名無しさん：03/04/16 13:00
>>129
それだとかなりでかいサイズになりそうだ。
ネイティブコンパイラは期待はずれになると思われ
>>125
ソース互換ならCも結構なものでつ
面倒さけどね
Javaのバイナリ互換ってそんなに大事かね？
それだとかなりでかいサイズになりそうだ。
ネイティブコンパイラは期待はずれになると思われ
>>125
ソース互換ならCも結構なものでつ
面倒さけどね
Javaのバイナリ互換ってそんなに大事かね？
133 ：デフォルトの名無しさん：03/04/16 13:59
134 ：デフォルトの名無しさん：03/04/16 15:38
C でソース互換を意識したコードって
Javaの場合と同じかそれ以上に大きくなるんだよね…
#ifdef とかやってると特に。
Javaの場合と同じかそれ以上に大きくなるんだよね…
#ifdef とかやってると特に。
135 ：デフォルトの名無しさん：03/04/17 01:30
>>134
そう？コマンドラインアプリならそれ程いらないと思うけど
# GUIは。。。。。
WinとUNIXとの互換だとPOSIX APIの部分がキツイ
NT系だとPOSIXのサブシステムが使えたと思うけど
やったことないから使えるか謎。。
Service for UNIXかCgywin使えればそれ程でもないん
ですけどね。。限定環境になっちゃう。
そう？コマンドラインアプリならそれ程いらないと思うけど
# GUIは。。。。。
WinとUNIXとの互換だとPOSIX APIの部分がキツイ
NT系だとPOSIXのサブシステムが使えたと思うけど
やったことないから使えるか謎。。
Service for UNIXかCgywin使えればそれ程でもないん
ですけどね。。限定環境になっちゃう。
136 ：デフォルトの名無しさん：03/04/17 02:06
>>122
利用目的を知らないお前がｱﾌｫかと。
数値計算、科学技術計算ライブラリではFortranは未だにトップクラスなわけだが。
とある数値計算ｍ科学技術計算では、CでもC++でもJavaでもFortranにはまだまだ勝てない。
利用目的を知らないお前がｱﾌｫかと。
数値計算、科学技術計算ライブラリではFortranは未だにトップクラスなわけだが。
とある数値計算ｍ科学技術計算では、CでもC++でもJavaでもFortranにはまだまだ勝てない。
137 ：デフォルトの名無しさん：03/04/17 02:19
138 ：デフォルトの名無しさん：03/04/17 02:23
>>136
適材適所ってのは同意
ちろっと質問なんだけど、Fortranって普通どのシステムで
使うもんなの？
スパコン？汎用？
漏れのイメージだとＩＢＭのスパコン、汎用のイメージが
強いんだけど
後、最近(?)は科学技術計算とかは分散システムが主流だと
思うんですが、分散でも簡単にできるようになっているの？
適材適所ってのは同意
ちろっと質問なんだけど、Fortranって普通どのシステムで
使うもんなの？
スパコン？汎用？
漏れのイメージだとＩＢＭのスパコン、汎用のイメージが
強いんだけど
後、最近(?)は科学技術計算とかは分散システムが主流だと
思うんですが、分散でも簡単にできるようになっているの？
139 ：デフォルトの名無しさん：03/04/17 02:29
140 ：デフォルトの名無しさん：03/04/17 04:07
>>1-1000 今週の漫談スレはここでつか？
141 ：デフォルトの名無しさん：03/04/17 13:04
>>138
Fortran用のライブラリを最新言語用に書き換えないことには
Fortran用のライブラリを最新言語用に書き換えないことには
（＾＾）
143 ：デフォルトの名無しさん：03/04/17 19:04
ageage
144 ： ：03/04/19 21:27
電気はガソリンの代わりになるが、牛乳はガソリンにはなれない。
だから、javaもＣにはなれない。
だから、javaもＣにはなれない。
145 ：デフォルトの名無しさん：03/04/19 21:42
>>137
感触的にはFortranというより流体力学の計算という特殊技術が稼げているのだと感じるな。
今はもうプログラム技術じゃ稼げないからね、いかに安く作るかとみんな研究するものだから
一番手っ取り早いのは給料下げろになってしまってる、やってられんよ。
オブジェクト指向その他ソフト工学は勉強しても金にならなんです。
感触的にはFortranというより流体力学の計算という特殊技術が稼げているのだと感じるな。
今はもうプログラム技術じゃ稼げないからね、いかに安く作るかとみんな研究するものだから
一番手っ取り早いのは給料下げろになってしまってる、やってられんよ。
オブジェクト指向その他ソフト工学は勉強しても金にならなんです。
146 ：デフォルトの名無しさん：03/04/19 21:44
>>145
うちの会社は給料は絶対下げないと明言してくれました。ビバ。
うちの会社は給料は絶対下げないと明言してくれました。ビバ。
147 ：デフォルトの名無しさん：03/04/19 22:11
>>144
そんな大きな違いじゃないよ。
せいぜい顕微鏡の視点、人間の視点、望遠鏡の視点くらいのもの。
顕微鏡の視点でなきゃできないことはたくさんある。
でも顕微鏡の視点で山ほど観測して必死に切り貼りして
人間や望遠鏡の視点の代わりにできるかもしれんがそりゃ大変すぎる。誰もやりたくない。
普通は人間の視点で十分だ。
でも人間個人の視点では誤った方向に進んでしまったり、
大きなシステムで協調が取れなかったりなどの問題もある。
望遠鏡の視点なら大きな範囲を大まかに観測できる。
でも細かな部分は見えない。
結局、コンピュータ主導ではなく人間様の目的主導で、
状況に合わせて人間様が必要十分を満たす言語を選べばいい、ただそんだけ。
望遠鏡が無限に性能がよく、いくら拡大しても詳細に観測できるなら・・・・・・
-> CPUの性能が無限にいいなら・・・・・・
の話は現実に不可能だしねぇ。
そんな大きな違いじゃないよ。
せいぜい顕微鏡の視点、人間の視点、望遠鏡の視点くらいのもの。
顕微鏡の視点でなきゃできないことはたくさんある。
でも顕微鏡の視点で山ほど観測して必死に切り貼りして
人間や望遠鏡の視点の代わりにできるかもしれんがそりゃ大変すぎる。誰もやりたくない。
普通は人間の視点で十分だ。
でも人間個人の視点では誤った方向に進んでしまったり、
大きなシステムで協調が取れなかったりなどの問題もある。
望遠鏡の視点なら大きな範囲を大まかに観測できる。
でも細かな部分は見えない。
結局、コンピュータ主導ではなく人間様の目的主導で、
状況に合わせて人間様が必要十分を満たす言語を選べばいい、ただそんだけ。
望遠鏡が無限に性能がよく、いくら拡大しても詳細に観測できるなら・・・・・・
-> CPUの性能が無限にいいなら・・・・・・
の話は現実に不可能だしねぇ。
148 ：デフォルトの名無しさん：03/04/19 22:22
美人のねーちゃんが言いました。
「子供が欲しいんですがどうすればいいですか」
ASM人：
まず原子が結合して分子を・・・・・・
C人：
それではあなたから卵子をいただきまして、それを受精させて培養・・・・・・
Java人：
・・・・・・(突如ズボンを脱ぎだす)
「子供が欲しいんですがどうすればいいですか」
ASM人：
まず原子が結合して分子を・・・・・・
C人：
それではあなたから卵子をいただきまして、それを受精させて培養・・・・・・
Java人：
・・・・・・(突如ズボンを脱ぎだす)
149 ：デフォルトの名無しさん：03/04/19 22:23
JAVAのコンパイラー及びVMをＣの代わりにJavaで書くことは
あり得ない。
そこにＣの居場所がある。
あり得ない。
そこにＣの居場所がある。
150 ：デフォルトの名無しさん：03/04/19 22:23
Java人：
・・・・・・(突如ズボンを脱ぎだす)
しかしチンコの立ち上がりは遅っ
・・・・・・(突如ズボンを脱ぎだす)
しかしチンコの立ち上がりは遅っ
151 ：デフォルトの名無しさん：03/04/19 22:48
VMはともかくコンパイラはJavaでかけるだろ。普通に。
152 ：デフォルトの名無しさん：03/04/19 22:56
＞＞VMはともかくコンパイラはJavaでかけるだろ。普通に
実行速度遅すぎだろ。普通に。
実行速度遅すぎだろ。普通に。
153 ：デフォルトの名無しさん：03/04/19 23:00
つか、javac は Java で…
154 ：デフォルトの名無しさん：03/04/20 00:20
155 ：デフォルトの名無しさん：03/04/20 00:26
>>153
じゃあJavacはいったい何で？
じゃあJavacはいったい何で？
156 ：デフォルトの名無しさん：03/04/20 00:36
アンチjava厨はjavacがjavaで書かれていることを知らないアホばっかりだったとは！
157 ：デフォルトの名無しさん：03/04/20 00:43
158 ：デフォルトの名無しさん：03/04/20 01:03
最近のCPUはCPUが設計しとるで〜ってのは有名な話ですなぁ。ところで・・・・・・
>>157
残念ながらあなたは何も理解してない厨です。理解するまで世間様に顔見せしないことをオススメします。
アンチjava軍団もあなたみたいな奴は受け入れないでしょう。
>>157
残念ながらあなたは何も理解してない厨です。理解するまで世間様に顔見せしないことをオススメします。
アンチjava軍団もあなたみたいな奴は受け入れないでしょう。
159 ：デフォルトの名無しさん：03/04/20 01:23
>>158
わざわざブーツストラップまでして低速なコンパイラ作る必要もないと思って。
わざわざブーツストラップまでして低速なコンパイラ作る必要もないと思って。
160 ：デフォルトの名無しさん：03/04/20 01:34
∧＿∧
（ ＾＾ ）＜ ぬるぽ（＾＾）
（ ＾＾ ）＜ ぬるぽ（＾＾）
162 ：デフォルトの名無しさん：03/04/20 03:32
>>146
そのかわり即クビなのかも。
そのかわり即クビなのかも。
∧＿∧
（ ＾＾ ）＜ ぬるぽ（＾＾）
（ ＾＾ ）＜ ぬるぽ（＾＾）
164 ：デフォルトの名無しさん：03/04/20 05:16
いーかげん、JDK の build に同じバージョンの JDK を必要とする
ってのどーにかならんのですかね？
ってのどーにかならんのですかね？
165 ：デフォルトの名無しさん：03/04/20 09:55
166 ：デフォルトの名無しさん：03/04/20 15:07
>>164
意味がわかりません
意味がわかりません
167 ：デフォルトの名無しさん：03/04/20 17:34
168 ：デフォルトの名無しさん：03/04/21 23:30
>160
>COBOL人：
>「恋愛感情における子作りの意義というのはすなわち...」
>と饒舌だが何いってんのかさっぱりわからず、やることも大したことがなく・・・
爆）
いるよいるよ、メインフレーム上がりの55歳！
団塊の世代よ、早く死ね！
>COBOL人：
>「恋愛感情における子作りの意義というのはすなわち...」
>と饒舌だが何いってんのかさっぱりわからず、やることも大したことがなく・・・
爆）
いるよいるよ、メインフレーム上がりの55歳！
団塊の世代よ、早く死ね！
169 ：デフォルトの名無しさん：03/04/21 23:31
この掲示板の右下のパスワードを当てようｗhttp://jbbs.shitaraba.com/anime/231/
170 ：デフォルトの名無しさん：03/04/21 23:59
>>160
SQL人：
美人「子供がほしいんですがどうすればいいですか?」
SQL人「INSERT INTO 社会
SELECT 美人.卵子 + SQL人.精子 AS 子供 FROM 美人,SQL人」
美人「ろ、ROWNUMの条件が抜けて……きゃあぁぁぁぁ〜」
SQL人「……ROLLBACK」
SQL人：
美人「子供がほしいんですがどうすればいいですか?」
SQL人「INSERT INTO 社会
SELECT 美人.卵子 + SQL人.精子 AS 子供 FROM 美人,SQL人」
美人「ろ、ROWNUMの条件が抜けて……きゃあぁぁぁぁ〜」
SQL人「……ROLLBACK」
171 ：デフォルトの名無しさん：03/04/22 00:05
172 ：デフォルトの名無しさん：03/04/22 00:06
CREATEVIEW
・・・ﾊｧﾊｧ
・・・ﾊｧﾊｧ
173 ：デフォルトの名無しさん：03/04/22 00:19
BASIC人：
他人からは頭が悪い以外、何を言ってるのかさっぱりわからず、
もちろん美人のねーちゃんと結合することも出来ないが、
オナニーさせたら右に出るものはいない。
他人からは頭が悪い以外、何を言ってるのかさっぱりわからず、
もちろん美人のねーちゃんと結合することも出来ないが、
オナニーさせたら右に出るものはいない。
174 ：デフォルトの名無しさん：03/04/22 13:02
冴子先生ﾊｧﾊｧ
175 ：デフォルトの名無しさん：03/04/28 04:35
∧＿∧
ﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
ﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
177 ：デフォルトの名無しさん：03/06/21 01:22
AOTコンパイラなら、GCJとか商用ベンダの奴とかありますが。
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
__∧＿∧_
|（ ＾＾ ）| ＜寝るぽ（＾＾）
|＼⌒⌒⌒＼
＼ |⌒⌒⌒~| 山崎渉
~￣￣￣￣
（＾＾）
(⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
182 ：デフォルトの名無しさん：03/10/08 03:40
Javaは「汎用」言語にはなりません。
これは定説です。(あたりまえです。そのように設計されていません)
C++の後継ってのはあからさまに違うと思うが、
シェアの一部は奪うかもね。
以上。
これは定説です。(あたりまえです。そのように設計されていません)
C++の後継ってのはあからさまに違うと思うが、
シェアの一部は奪うかもね。
以上。
183 ：デフォルトの名無しさん：03/11/16 19:53
184 ：デフォルトの名無しさん：03/11/16 20:21
IT業界にアージャイル開発とデザインパターンを広めよう！
C言語を使ってかなり苦労したので
その苦労を最小限におさえるために
アージャイル開発、デザインパターンを
多くのプログラマに使って欲しいと思うことがある。
一種の挨拶みたいなものだね。
「なるべく挨拶を心がけましょう。」
「なるべき綺麗な字で書きましょう。」
のように
デザインパターンを使うこと、アージャイル開発することが
プログラマの習慣、常識になってほしい。
なんとか、デザインパターン文化、アージャイル開発文化を押し広げられたら・・・。
IT業界の将来はオブジェクト指向とアージャイル開発が握っています！
C言語を使ってかなり苦労したので
その苦労を最小限におさえるために
アージャイル開発、デザインパターンを
多くのプログラマに使って欲しいと思うことがある。
一種の挨拶みたいなものだね。
「なるべく挨拶を心がけましょう。」
「なるべき綺麗な字で書きましょう。」
のように
デザインパターンを使うこと、アージャイル開発することが
プログラマの習慣、常識になってほしい。
なんとか、デザインパターン文化、アージャイル開発文化を押し広げられたら・・・。
IT業界の将来はオブジェクト指向とアージャイル開発が握っています！
185 ：デフォルトの名無しさん：03/11/16 20:55
186 ：デフォルトの名無しさん：04/04/09 18:00
C++の機能的後継はD言語
主要プログラミング言語としての座はしっかりとC++からJavaに後継される。
主要プログラミング言語としての座はしっかりとC++からJavaに後継される。
187 ：デフォルトの名無しさん：04/04/09 18:01
C++はいつから主要プログラミング言語になったんだ？
188 ：デフォルトの名無しさん：04/04/09 18:07
事務なんかは知らんけど、
ベンチマーク取るようなソフトではC++が多い。
過去の資産を含めるとC++をCが圧倒するが、
最近はミドルウェアやライブラリの関係で
C++以外に選択肢がない状況もある。
ベンチマーク取るようなソフトではC++が多い。
過去の資産を含めるとC++をCが圧倒するが、
最近はミドルウェアやライブラリの関係で
C++以外に選択肢がない状況もある。
189 ：デフォルトの名無しさん：04/04/09 18:37
JavaとC++は比較できない。
用途と実力を鑑みるとPerlが好敵手となるでしょう。
用途と実力を鑑みるとPerlが好敵手となるでしょう。
190 ：デフォルトの名無しさん：04/04/09 19:14
C++がPerlのライバルか
191 ：デフォルトの名無しさん：04/04/09 19:28
PerlでDirectX
Perlでスーパーπ
Perlでスーパーπ
192 ：デフォルトの名無しさん：04/04/09 19:56
PerlでDirectXできるんですか！？
193 ：デフォルトの名無しさん：04/04/09 19:59
どうしても、JavaがPerl以下だと認められないようですね。
ここに在る現実をみつめてください。
ここに在る現実をみつめてください。
194 ：デフォルトの名無しさん：04/04/10 01:07
そしてC++がJava以下であるという現実も
195 ：デフォルトの名無しさん：04/04/10 03:24
悟れません。
配列のアクセスだけでも5倍の性能を持つC++が
JVMにかなわないのは精神の問題ですか？
配列のアクセスだけでも5倍の性能を持つC++が
JVMにかなわないのは精神の問題ですか？
196 ：デフォルトの名無しさん：04/04/10 03:40
Ｐｅｒｌまででてきてんのか？ｗ
じゃもひとつ加えとけや、Ｒｕｂｙ
じゃもひとつ加えとけや、Ｒｕｂｙ
197 ：デフォルトの名無しさん：04/04/10 13:37
>>195
いつ頃の話なんだろうか
いつ頃の話なんだろうか
198 ：デフォルトの名無しさん：04/04/10 20:26
>>197
相変わらずだよ。特定の条件下では改善されたようだけど。
相変わらずだよ。特定の条件下では改善されたようだけど。
199 ：デフォルトの名無しさん：04/04/10 20:36
そのネックとなるコード書いて比較してここにあげてみそ
200 ：デフォルトの名無しさん：04/04/17 02:12
200get
201 ：デフォルトの名無しさん：04/04/17 10:39
バブルソートの例ではCよりもJavaのほうが速いって例があったよな
202 ：デフォルトの名無しさん：04/04/17 12:40
速度の面から言えば、マシンに合わせてチューニングできる自由
を持つC/C++の方がどう考えても有利だろ。
を持つC/C++の方がどう考えても有利だろ。
203 ：デフォルトの名無しさん：04/04/17 14:09
javaに限らずだが中間言語系はvmが各CPUにあわせた最適化と
統計取っていく最適化方式で差はほとんど無い
統計取るＣなどのネイティブ系の最適化は非常に協力なのだが
同じ環境で実行出来ない場合もあるし非現実的である
たとえばデータベースなんて日々の売り上げなんかでどんどん変わってくるよね
それに対応できるのが中間言語系で対応できないのがネイティブコード系
MSが中間言語への思い切った方針転換はhotspot技術が
現実的になることを知ってのことだし
実際のところ細かいCPUにあわせたVMはでてないけど、アプリはそのままで
自動的にSSE対応で最適化されて高速化されていたりするのを見ると
今はまだ速度的にやや弱いのがこれからもどんどん最適化されていくだろう
また、hotspotや並列GCなどはSMPなどのスループット系環境で効果が大きいね
マルチコア化が今後のトレンドになるだろうし、それらも後押しするかも
Ｃの土壌は高級アセンブラとして依然残るだろうがアプリレベルではjavaが
今後どうなるかは分からないが中間言語系になってくるのはまず間違いない
統計取っていく最適化方式で差はほとんど無い
統計取るＣなどのネイティブ系の最適化は非常に協力なのだが
同じ環境で実行出来ない場合もあるし非現実的である
たとえばデータベースなんて日々の売り上げなんかでどんどん変わってくるよね
それに対応できるのが中間言語系で対応できないのがネイティブコード系
MSが中間言語への思い切った方針転換はhotspot技術が
現実的になることを知ってのことだし
実際のところ細かいCPUにあわせたVMはでてないけど、アプリはそのままで
自動的にSSE対応で最適化されて高速化されていたりするのを見ると
今はまだ速度的にやや弱いのがこれからもどんどん最適化されていくだろう
また、hotspotや並列GCなどはSMPなどのスループット系環境で効果が大きいね
マルチコア化が今後のトレンドになるだろうし、それらも後押しするかも
Ｃの土壌は高級アセンブラとして依然残るだろうがアプリレベルではjavaが
今後どうなるかは分からないが中間言語系になってくるのはまず間違いない
204 ：デフォルトの名無しさん：04/04/20 01:53
今ネット回ってJava調べてたんだけれども、Javaにはテンプレが無いってほんと？
これから作られるの？
これから作られるの？
205 ：デフォルトの名無しさん：04/04/23 23:28
>>204
Genericsで検索して、またおいで。
Genericsで検索して、またおいで。
206 ：デフォルトの名無しさん：04/04/28 22:55
207 ：デフォルトの名無しさん：04/09/08 11:53
age
208 ：デフォルトの名無しさん：04/09/13 04:59:04
半年近くほったらかしのスレをいまさらあげるなボケ、氏ね
209 ：デフォルトの名無しさん：04/09/13 23:54:16
正直いって、JAVAの一番嫌いな点は、
ずばり、「識別子が長いこと」だ！！
ずばり、「識別子が長いこと」だ！！
210 ：デフォルトの名無しさん：04/09/13 23:58:41
isDisplayChangeSupportedなんて長い上に意味がわかりづらい
211 ：デフォルトの名無しさん：04/09/14 00:10:01
これからの時代、識別子はどんどん長くなるに違いない
212 ：デフォルトの名無しさん：04/09/14 00:37:38
Win32とかの時点で長いのはもうどうでもいいやというきになったよ
当時と違ってＩＤＥで補完前提なのですべて打ち込むことないし
X68方面は短いのが多くてよかった・・・
当時と違ってＩＤＥで補完前提なのですべて打ち込むことないし
X68方面は短いのが多くてよかった・・・
213 ：デフォルトの名無しさん：04/09/16 22:54:12
結論：C#が後継でした。
214 ：デフォルトの名無しさん：04/09/17 16:37:14
>>148
おいおい、これ↓パクんなよ
コンピュータジョーク - 自分の足を撃つには
http://hp.vector.co.jp/authors/VA000092/jokes/
と１年前の人間に突っ込んでみる。
どうせだったらこいつのJava、C#、Ｄ版を考えてくれよ
おいおい、これ↓パクんなよ
コンピュータジョーク - 自分の足を撃つには
http://hp.vector.co.jp/authors/VA000092/jokes/
と１年前の人間に突っ込んでみる。
どうせだったらこいつのJava、C#、Ｄ版を考えてくれよ
215 ：デフォルトの名無しさん：04/09/19 13:15:50
216 ：デフォルトの名無しさん：04/09/19 16:08:34
217 ：デフォルトの名無しさん：04/09/20 11:59:39
>>216
今の時代のベンチ出してから言え
今の時代のベンチ出してから言え
218 ：いなむらきよし：04/09/20 13:28:43
キケー！
219 ：デフォルトの名無しさん：04/09/20 15:14:55
今のところ、携帯端末にJavaはソフト開発側からしたら明らかな失敗だったな。
容量問題がネックになり、クラス創れない。
これまた容量問題でfinal変数も宣言できず、
C言語などのマクロ展開プリプロセスを使用しないと開発にならない。
VMが機種間の差異を吸収できず、これまたプリプロセスが必要。
#define _MAX_VAR_INT 3
#define var1 var[0]
#define var2 var[1]
#define var3 var[2]
int var[] = new int[_MAX_VAR_INT];
こんなこともしたっけな。
容量問題がネックになり、クラス創れない。
これまた容量問題でfinal変数も宣言できず、
C言語などのマクロ展開プリプロセスを使用しないと開発にならない。
VMが機種間の差異を吸収できず、これまたプリプロセスが必要。
#define _MAX_VAR_INT 3
#define var1 var[0]
#define var2 var[1]
#define var3 var[2]
int var[] = new int[_MAX_VAR_INT];
こんなこともしたっけな。
220 ：デフォルトの名無しさん：04/09/20 16:43:57
221 ：デフォルトの名無しさん：04/09/20 16:46:38
>>219
> #define var1 var[0]
> #define var2 var[1]
> #define var3 var[2]
ゼロオリジンだと混乱する厨ですか
そういう厨はプログラマ向いてないから辞めていいですよ
> #define var1 var[0]
> #define var2 var[1]
> #define var3 var[2]
ゼロオリジンだと混乱する厨ですか
そういう厨はプログラマ向いてないから辞めていいですよ
222 ：デフォルトの名無しさん：04/09/20 17:27:17
ゼロオリジンに疑問を抱かないのはデジタルドカタ
223 ：デフォルトの名無しさん：04/09/20 19:36:31
>>217
http://www.geocities.jp/toshio16369/column/021103a.html
http://www.geocities.jp/toshio16369/column/021108a.html
ちなみにこれらも２年近く前で今はさらに早くなってるぞ
ダイナミックな最適化ってのは非常に面白いテーマでCPUを判別して
自動的にSSEとかMMX使うコードが生成されたりしてる
バイナリは数年前のものであっても最新のVMで動かすと
マシンパワーがそのままでも恐ろしく早くなってたりするわけだ
http://www.geocities.jp/toshio16369/column/021103a.html
http://www.geocities.jp/toshio16369/column/021108a.html
ちなみにこれらも２年近く前で今はさらに早くなってるぞ
ダイナミックな最適化ってのは非常に面白いテーマでCPUを判別して
自動的にSSEとかMMX使うコードが生成されたりしてる
バイナリは数年前のものであっても最新のVMで動かすと
マシンパワーがそのままでも恐ろしく早くなってたりするわけだ
224 ：デフォルトの名無しさん：04/09/20 20:07:01
225 ：デフォルトの名無しさん：04/09/20 20:13:11
メモリ使用量が恐ろしいな・・・
226 ：デフォルトの名無しさん：04/09/20 20:13:59
D言語の普及と発展ｷﾎﾞﾝﾇ
227 ：デフォルトの名無しさん：04/09/20 20:20:12
ちなみにサーバーVMはたしかに早いが最適化が強いので
クラスロード時とか時間が結構かかる
クライアントのソフトはサーバーＶＭは実用的にならない場合も多いよ
そしてＲＣのJ2SE5はクライアントＶＭでもサーバーＶＭにだいぶ近い最適化しているっぽ
あきらかに１．４系より実行までの待ち時間は多少増加している
でもたしかに早いし、１．４のサーバーＶＭのようながたつきはすくない
あとアクセラレーションにOpenGL使ってるというらしいのだがこれは未チェック
とくにLinuxでおそらく恐ろしい速度改善されてると思う
クラスロード時とか時間が結構かかる
クライアントのソフトはサーバーＶＭは実用的にならない場合も多いよ
そしてＲＣのJ2SE5はクライアントＶＭでもサーバーＶＭにだいぶ近い最適化しているっぽ
あきらかに１．４系より実行までの待ち時間は多少増加している
でもたしかに早いし、１．４のサーバーＶＭのようながたつきはすくない
あとアクセラレーションにOpenGL使ってるというらしいのだがこれは未チェック
とくにLinuxでおそらく恐ろしい速度改善されてると思う
228 ：デフォルトの名無しさん：04/09/20 20:26:49
>>220
Javaだって。
これをC/C++用のプリプロセッサで展開してから、javacかけるんだよ。
携帯でのアプリ開発では必須知識。
int a, b, c;
とかすると
int x[] = new int[3];
とするより、クラスファイルサイズがでかくなるからね。
Javaだって。
これをC/C++用のプリプロセッサで展開してから、javacかけるんだよ。
携帯でのアプリ開発では必須知識。
int a, b, c;
とかすると
int x[] = new int[3];
とするより、クラスファイルサイズがでかくなるからね。
229 ：デフォルトの名無しさん：04/09/20 20:43:29
でも実行時にはメモリ喰いそうだな
速度的にもインデックスや範囲チェックとかあるし
まぁ、サイズ画きついのは確かだが初期の携帯用を切り捨てれれば
かなりらくだけどなぁ
速度的にもインデックスや範囲チェックとかあるし
まぁ、サイズ画きついのは確かだが初期の携帯用を切り捨てれれば
かなりらくだけどなぁ
230 ：デフォルトの名無しさん：04/09/21 00:15:36
>>223
> http://www.geocities.jp/toshio16369/column/021108a.html
これ試してみました ※ gcc-3.3.2, java version "1.4.2"
$ make test
time ./021108a1 50000
メモリを取得しています。
初期値を代入しています。
並べ替えています。
終わりました。
3.14user 0.00system 0:03.14elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (202major+67minor)pagefaults 0swaps
time java Baburu 50000
メモリを取得しています。
初期値を代入しています。
並べ替えています。
終わりました。
10.31user 0.00system 0:10.36elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1318major+640minor)pagefaults 0swaps
time java -server Baburu 50000
メモリを取得しています。
初期値を代入しています。
並べ替えています。
終わりました。
6.07user 0.02system 0:06.14elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1662major+710minor)pagefaults 0swaps
> http://www.geocities.jp/toshio16369/column/021108a.html
これ試してみました ※ gcc-3.3.2, java version "1.4.2"
$ make test
time ./021108a1 50000
メモリを取得しています。
初期値を代入しています。
並べ替えています。
終わりました。
3.14user 0.00system 0:03.14elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (202major+67minor)pagefaults 0swaps
time java Baburu 50000
メモリを取得しています。
初期値を代入しています。
並べ替えています。
終わりました。
10.31user 0.00system 0:10.36elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1318major+640minor)pagefaults 0swaps
time java -server Baburu 50000
メモリを取得しています。
初期値を代入しています。
並べ替えています。
終わりました。
6.07user 0.02system 0:06.14elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1662major+710minor)pagefaults 0swaps
231 ：デフォルトの名無しさん：04/09/21 00:24:16
Java厨がよく言うセリフ
「Javaは昔より速くなったんだぞ。昔のデータを持ち出して遅いと言うな」
しかし持ち出してくるベンチマーク情報は
古いgccを使って比較しているから滑稽
「Javaは昔より速くなったんだぞ。昔のデータを持ち出して遅いと言うな」
しかし持ち出してくるベンチマーク情報は
古いgccを使って比較しているから滑稽
232 ：デフォルトの名無しさん：04/09/21 00:52:53
>>231
それいったらJavaは実行時最適化なもんだから実行時にオプションで調節しないとな
>>223のサイトのはgccは最適化オプションいれてるくせにJavaのほうは実行時になんの調節もしてないわけだが
それいったらJavaは実行時最適化なもんだから実行時にオプションで調節しないとな
>>223のサイトのはgccは最適化オプションいれてるくせにJavaのほうは実行時になんの調節もしてないわけだが
233 ：デフォルトの名無しさん：04/09/21 01:21:00
OS:Windows PentiumM/1GHz mem768M
50000件
JavaClientVM 25秒
JavaServerVM 4秒
BCB 6秒
という結果になってたしかにＣより早くて驚いた
Javaは1.4.2_03でBCBは５だけどＢＣＢ６になって高速化したと聞いてないのであまりかわらんかな
.NETとか古い1.3とか1.5RCとかDelphiとかいろいろ試してみるかのう
50000件
JavaClientVM 25秒
JavaServerVM 4秒
BCB 6秒
という結果になってたしかにＣより早くて驚いた
Javaは1.4.2_03でBCBは５だけどＢＣＢ６になって高速化したと聞いてないのであまりかわらんかな
.NETとか古い1.3とか1.5RCとかDelphiとかいろいろ試してみるかのう
ちなみに同じ環境で
Java -Xint(インタプリタモード)
はさすがに１５０秒ですた・・・・
Java -Xint(インタプリタモード)
はさすがに１５０秒ですた・・・・
235 ：デフォルトの名無しさん：04/09/21 01:44:53
>>233
CPU時間？実時間？
CPU時間？実時間？
実時間
マシンスペックは同じ
J2SE1.3.1
ClientVM 26秒
ServerVM 12秒
インタプリタ 160秒
hotspot実装したのがこの1.3でちょうどJavaが業務系に使われ始めただけあって
演算系ならそれなりの速度だが、サーバーＶＭでは１．４系と大きな差がある模様
J2SE1.3.1
ClientVM 26秒
ServerVM 12秒
インタプリタ 160秒
hotspot実装したのがこの1.3でちょうどJavaが業務系に使われ始めただけあって
演算系ならそれなりの速度だが、サーバーＶＭでは１．４系と大きな差がある模様
238 ：デフォルトの名無しさん：04/09/21 10:25:50
この-serverって、tomcatとかは普通にデフォルトで入ってる、ってことでいいのかなあ・・・？
今、catalina.batを開いてみたら、server=y、見たいなの以外は、とくに入ってなさそうだけど・・・。
これは違うよな・・・？
今、catalina.batを開いてみたら、server=y、見たいなの以外は、とくに入ってなさそうだけど・・・。
これは違うよな・・・？
239 ：デフォルトの名無しさん：04/09/21 10:49:43
serverVMは標準JREには入っていないからデフォルトで入っているとは考えにくいな
SDKには入っていてServerVMは再配布可能なので自分でアプリ配布する場合は
JREの中に組み込んで配布するがよろし
SDKには入っていてServerVMは再配布可能なので自分でアプリ配布する場合は
JREの中に組み込んで配布するがよろし
240 ：デフォルトの名無しさん：04/09/21 11:07:16
Tomcat5で、管理ツール開いてみたら、Java VMのところのパスがこうなってた。
C:\j2sdk1.4.2_04\jre\bin\server\jvm.dll
これは多分使ってる、ってことでよさそうじゃない？
＞serverVMは標準JREには入っていないからデフォルトで入っているとは考えにくいな
まじだね。Java\j2re\binの中見てみたら、clientしかなかった。知らなかったよ。
C:\j2sdk1.4.2_04\jre\bin\server\jvm.dll
これは多分使ってる、ってことでよさそうじゃない？
＞serverVMは標準JREには入っていないからデフォルトで入っているとは考えにくいな
まじだね。Java\j2re\binの中見てみたら、clientしかなかった。知らなかったよ。
241 ：デフォルトの名無しさん：04/09/21 11:57:05
>>240
ということは環境判断してServerVM使うかどうかきめてるのかな
ということは環境判断してServerVM使うかどうかきめてるのかな
242 ：デフォルトの名無しさん：04/09/24 10:41:11
ServerVMって起動に嘘くさいほど時間かかるよな。
あと、嘘くさいほどメモリ喰うよな。
あと、嘘くさいほどメモリ喰うよな。
243 ：デフォルトの名無しさん：04/09/24 12:34:57
嘘じゃなくて本当だろ
最適化の度合いが強いってことは準備がかなり喰うのだ
それにしてもなんかガキっぽいしゃべりかただな
最適化の度合いが強いってことは準備がかなり喰うのだ
それにしてもなんかガキっぽいしゃべりかただな
244 ：デフォルトの名無しさん：04/09/24 21:50:09
それにしてもじじくさいしゃべりかただな。
245 ：デフォルトの名無しさん：04/09/25 01:22:50
C言語厨はなぜオブジェクト指向が理解できないのか
http://pc5.2ch.net/test/read.cgi/prog/1096039623/
C++使えると豪語する奴=本当はCしかできない低脳
http://pc5.2ch.net/test/read.cgi/prog/1094445966/
C++しか使えない奴はプログラマとは認められず3
http://pc5.2ch.net/test/read.cgi/prog/1090160842/
ＩＴ業界の癌たるC言言語厨をいかにしてｸﾋﾞにするか
http://pc5.2ch.net/test/read.cgi/prog/1095924333/
C厨がこの先生きのこるには…
http://pc5.2ch.net/test/read.cgi/prog/1090145602/
★C言語開発者を一斉逮捕へ 京都府警★
http://pc5.2ch.net/test/read.cgi/prog/1084280872/
C厨がいくら糞でも、普及してしまえば発注者の勝ち
http://pc5.2ch.net/test/read.cgi/prog/1094127625/
C++使えない奴はプログラマとは認められず2
http://pc5.2ch.net/test/read.cgi/prog/1061940405/
C++は時代遅れの糞言語
http://pc5.2ch.net/test/read.cgi/prog/1094443579/
JavaをなめてかかっているC/C++厨は頭が悪いpart2
http://pc5.2ch.net/test/read.cgi/prog/1091643618/
低レベルなＣ言語厨を逮捕する方法
http://pc5.2ch.net/test/read.cgi/prog/1096038785/
C言語厨ってこんなに叩かれるほどスキルが下がってしまったんだね。
C言語の時代に陰りが見えてきたね。
http://pc5.2ch.net/test/read.cgi/prog/1096039623/
C++使えると豪語する奴=本当はCしかできない低脳
http://pc5.2ch.net/test/read.cgi/prog/1094445966/
C++しか使えない奴はプログラマとは認められず3
http://pc5.2ch.net/test/read.cgi/prog/1090160842/
ＩＴ業界の癌たるC言言語厨をいかにしてｸﾋﾞにするか
http://pc5.2ch.net/test/read.cgi/prog/1095924333/
C厨がこの先生きのこるには…
http://pc5.2ch.net/test/read.cgi/prog/1090145602/
★C言語開発者を一斉逮捕へ 京都府警★
http://pc5.2ch.net/test/read.cgi/prog/1084280872/
C厨がいくら糞でも、普及してしまえば発注者の勝ち
http://pc5.2ch.net/test/read.cgi/prog/1094127625/
C++使えない奴はプログラマとは認められず2
http://pc5.2ch.net/test/read.cgi/prog/1061940405/
C++は時代遅れの糞言語
http://pc5.2ch.net/test/read.cgi/prog/1094443579/
JavaをなめてかかっているC/C++厨は頭が悪いpart2
http://pc5.2ch.net/test/read.cgi/prog/1091643618/
低レベルなＣ言語厨を逮捕する方法
http://pc5.2ch.net/test/read.cgi/prog/1096038785/
C言語厨ってこんなに叩かれるほどスキルが下がってしまったんだね。
C言語の時代に陰りが見えてきたね。
246 ：デフォルトの名無しさん：04/09/25 01:26:40
ＣはＣの良さが、JavaはJavaの良さがある
ただ、マシンスペックに余裕が出てきたことで
開発効率や安全なコードといったところが重要視されていって
．ｎｅｔやJavaといったＶＭ系が主流になっただけ
アセンブラからＣへの流れと同じだな
全体が見渡しやすくなって保守性があがり、移植性もよくなったと
ただ、マシンスペックに余裕が出てきたことで
開発効率や安全なコードといったところが重要視されていって
．ｎｅｔやJavaといったＶＭ系が主流になっただけ
アセンブラからＣへの流れと同じだな
全体が見渡しやすくなって保守性があがり、移植性もよくなったと
247 ：デフォルトの名無しさん：04/09/25 01:51:50
コピペに反応すんなよ
248 ：デフォルトの名無しさん：04/09/25 02:45:58
BASICの時代はあったけど、アセンブラの時代なんか一度も無かった。
249 ：デフォルトの名無しさん：04/09/25 03:17:38
250 ：デフォルトの名無しさん：04/09/25 08:11:32
251 ：デフォルトの名無しさん：04/09/25 08:49:32
>>250
いや、格段に楽で保守性があがったわけなんだが。
いや、格段に楽で保守性があがったわけなんだが。
252 ：デフォルトの名無しさん：04/09/25 14:11:44
Javaは関数オブジェクト使える？
253 ：デフォルトの名無しさん：04/09/25 19:25:18
そのまえに関数ベースって考えを何とかしろ
254 ：デフォルトの名無しさん：04/09/25 19:30:05
255 ：デフォルトの名無しさん：04/09/25 19:31:24
>>253
誰にいってんの？
誰にいってんの？
256 ：デフォルトの名無しさん：04/09/25 19:58:11
かんすうべえすぅ？
またアホの新語ですかー
またアホの新語ですかー
257 ：デフォルトの名無しさん：04/09/26 01:46:09
ホワイトベースの仲間かな
258 ：デフォルトの名無しさん：04/09/26 02:32:52
259 ：デフォルトの名無しさん：04/09/26 04:41:28
Javaってconst修飾ないんですか？
260 ：デフォルトの名無しさん：04/09/26 07:01:13
マクロもないな
261 ：デフォルトの名無しさん：04/09/26 07:20:16
少なくとも、C#よりはJavaのほうがいいよね？
262 ：デフォルトの名無しさん：04/09/26 09:07:44
微妙
263 ：デフォルトの名無しさん：04/10/01 16:04:54
javaはこの先実行速度が改善される見込みはあるの？
264 ：デフォルトの名無しさん：04/10/01 16:20:44
改善されてるじゃん
ポストCは難しいけど
これはこれで生き残るんだろう
ポストCは難しいけど
これはこれで生き残るんだろう
265 ：デフォルトの名無しさん：04/10/01 16:53:05
266 ：デフォルトの名無しさん：04/10/01 18:33:28
GC言語である以上は、メモリ管理のプログラムがかけないからねぇ。
267 ：デフォルトの名無しさん：04/10/01 20:56:40
JavaとC言語は補完しあう関係
268 ：デフォルトの名無しさん：04/10/01 21:14:28
そこにスクリプト言語Groovyも参加ですよ。
269 ：デフォルトの名無しさん：04/10/02 00:05:51
おまけにLythonですよ
270 ：デフォルトの名無しさん：04/10/02 00:38:34
ＧＣはやくなってる・・・ガクブル
271 ：デフォルトの名無しさん：04/10/16 14:41:55
で、一体何時になったら
#ifdef
に類する仕組みを取り入れてくれますか？
#ifdef
に類する仕組みを取り入れてくれますか？
272 ：デフォルトの名無しさん：04/10/16 14:50:59
当分無いと思われ。
Java使う人で どーしても必要ならプリプロセッサ使うか作るかしてるだろうし。
D言語とか見ても #ifdef みたいのは減ってく傾向にあるのではないかと。
Java使う人で どーしても必要ならプリプロセッサ使うか作るかしてるだろうし。
D言語とか見ても #ifdef みたいのは減ってく傾向にあるのではないかと。
273 ：デフォルトの名無しさん：04/11/06 02:29:39
ていうか、VM用にコンパイルしたら、元の言語がなんだろうが
一緒だと思うんだが。Javaにこだわる理由もない。
一緒だと思うんだが。Javaにこだわる理由もない。
274 ：デフォルトの名無しさん：04/11/13 12:26:56
そこで.NETですよ。
275 ：デフォルトの名無しさん：04/11/22 16:02:12
276 ：デフォルトの名無しさん：04/11/23 22:01:40
277 ：デフォルトの名無しさん：04/11/23 22:47:48
そこでBREWですよ
278 ：デフォルトの名無しさん：04/12/23 03:24:25
D言語は…とても流行りそうには無いな。
279 ：デフォルトの名無しさん：04/12/23 03:44:53
C＋＋とJavaって、どんどん違う方向に進化してるじゃん。
Javaは、とことんランタイムの動的解決にこだわるけど、
C＋＋は、テンプレートライブラリとかオペレータのオーバーロードとか、
プリプロセッサによるコンパイル時の静的解決マンセーな風潮になってる。
どっちがどっちを駆逐するとかいう話じゃなくて、
全く逆の方向にどんどん突っ走ってる感じ。
Javaは、とことんランタイムの動的解決にこだわるけど、
C＋＋は、テンプレートライブラリとかオペレータのオーバーロードとか、
プリプロセッサによるコンパイル時の静的解決マンセーな風潮になってる。
どっちがどっちを駆逐するとかいう話じゃなくて、
全く逆の方向にどんどん突っ走ってる感じ。
280 ：デフォルトの名無しさん：04/12/23 08:11:05
そこでc#ですよ
281 ：デフォルトの名無しさん：04/12/23 11:31:26
ネイティブコンパイルができるjavaコンパイラが存在することを知らないのかC厨は
282 ：デフォルトの名無しさん：04/12/23 11:32:22
GCJはまだ使い物になる段階じゃない
283 ：デフォルトの名無しさん：04/12/23 18:07:39
284 ：デフォルトの名無しさん：04/12/24 05:26:56
C言語はもともとアセンブラで記述されていたUNIXの移植性を高めるために生まれた言語だよね
だから高級言語としては特異な言語だと思う
OSの記述からアプリケーションプログラムの記述まで、ここまで汎用的に使われる高級言語はC言語以外にないよ
だから高級言語としては特異な言語だと思う
OSの記述からアプリケーションプログラムの記述まで、ここまで汎用的に使われる高級言語はC言語以外にないよ
285 ：デフォルトの名無しさん：04/12/24 06:17:22
複雑なアプリケーションプログラムの記述にはC言語はどんどん使われなくなってるわけだが。
散々既出だがJava:Cの関係は、アセンブラ:Cの関係と一緒。
今でもアセンブラでしか書けないコンポーネントが残っているのと同様に
Cでしか書けないコンポーネントもずっと存在し続けるだろう。だがCで書くべき範囲はどんどん狭くなる。
Windows全盛だからWindowsアプリは.NETだろうけどね。同じこと。
散々既出だがJava:Cの関係は、アセンブラ:Cの関係と一緒。
今でもアセンブラでしか書けないコンポーネントが残っているのと同様に
Cでしか書けないコンポーネントもずっと存在し続けるだろう。だがCで書くべき範囲はどんどん狭くなる。
Windows全盛だからWindowsアプリは.NETだろうけどね。同じこと。
286 ：デフォルトの名無しさん：04/12/24 06:27:59
日本が誇る電気電子は組み込み系プログラマが不足気味
Cやasmが一番待遇いいんだよ、きっと
Cやasmが一番待遇いいんだよ、きっと
287 ：デフォルトの名無しさん：04/12/24 17:55:40
>>284
そこでD言語がくるのですよ。
そこでD言語がくるのですよ。
288 ：デフォルトの名無しさん：04/12/24 18:57:40
「OSの記述」が特別すぎてｿﾚを元に「様々な」っていわれても狐に包まれたみたいだ。
289 ：デフォルトの名無しさん：04/12/24 20:35:28
290 ：デフォルトの名無しさん：04/12/24 23:35:03
291 ：デフォルトの名無しさん：04/12/26 07:03:03
JavaがネイティブでC/C++と勝負しても仕方無いんじゃないかと。
JavaにはJavaの道がある。でかい業務システム開発のメインと
なる言語だろう。Javaは裏方的なC/C++に支えられて、その道を
歩むのであって、C/C++の後継なんて目指したらおしまいだ。
JavaにはJavaの道がある。でかい業務システム開発のメインと
なる言語だろう。Javaは裏方的なC/C++に支えられて、その道を
歩むのであって、C/C++の後継なんて目指したらおしまいだ。
292 ：デフォルトの名無しさん：04/12/27 02:29:34
COBOL・汎用機（ホスト系）の代わりに、
Java ・分散環境（オープン系）で活躍しそうだな、Javaは。
ただし、J2EE環境（サーバサイド）くらいしか使い道がないんじゃないの、
Javaって。
汎用機の代わりくらいじゃない、あとは教育用としてJavaは使えるな。
デカイところの汎用機はもうしばらくCOBOLでやっていくと思うが、
普通の所は、汎用機は廃棄して、分散コンピューティングでのJavaにしちまうよ。
JavaはCOBOLよりも機能が多いし。
あと、教育用ね。Javaはホント、学んでいて面白いから！
CやC++なんかよりも楽しいよ。
素人へのプログラム教育用として、Javaは最適だと思う、、、俺の個人的意見ではね。
Java ・分散環境（オープン系）で活躍しそうだな、Javaは。
ただし、J2EE環境（サーバサイド）くらいしか使い道がないんじゃないの、
Javaって。
汎用機の代わりくらいじゃない、あとは教育用としてJavaは使えるな。
デカイところの汎用機はもうしばらくCOBOLでやっていくと思うが、
普通の所は、汎用機は廃棄して、分散コンピューティングでのJavaにしちまうよ。
JavaはCOBOLよりも機能が多いし。
あと、教育用ね。Javaはホント、学んでいて面白いから！
CやC++なんかよりも楽しいよ。
素人へのプログラム教育用として、Javaは最適だと思う、、、俺の個人的意見ではね。
293 ：デフォルトの名無しさん：04/12/27 05:32:13
UML厨の仮想実装言語として
294 ：デフォルトの名無しさん：04/12/27 09:40:43
本当に楽しくなるのはその初心者の領域こえてからなんだがね
Cは残る
高級アセンブラとして組み込み用としてもダイレクトに伝わりやすいところだから
C++が中途半端
Javaや.NETやってるとオブジェクト指向で業務ロジックだけ考えていればいいという
言語ではないから
この領域はDあたりがいてくれるといい
Javaや.NETはこれらとは目指すところが違いすぎる
結果としてC++の領域を一部（といってもアプリのほとんど）はかわる
すでに取って代わってるしね
Cが普及したのはやはりBASICと比較しての高級言語で高速性であって
当時のマシンパワーが今とは比べ物にならないこともあって
マシンパワーに余裕が出てきた今となってはスクリプト系含めての
ロジックに注目するだけの言語系への移行が加速する希ガス
Cは残る
高級アセンブラとして組み込み用としてもダイレクトに伝わりやすいところだから
C++が中途半端
Javaや.NETやってるとオブジェクト指向で業務ロジックだけ考えていればいいという
言語ではないから
この領域はDあたりがいてくれるといい
Javaや.NETはこれらとは目指すところが違いすぎる
結果としてC++の領域を一部（といってもアプリのほとんど）はかわる
すでに取って代わってるしね
Cが普及したのはやはりBASICと比較しての高級言語で高速性であって
当時のマシンパワーが今とは比べ物にならないこともあって
マシンパワーに余裕が出てきた今となってはスクリプト系含めての
ロジックに注目するだけの言語系への移行が加速する希ガス
295 ：デフォルトの名無しさん：05/01/06 17:45:13
JavaってVM誰も作らなくなったらどうするんだろ？
EXEも作れるらしいけどVMから独立してるんだろうか？
EXEも作れるらしいけどVMから独立してるんだろうか？
296 ：デフォルトの名無しさん：05/02/07 02:31:03
今から勉強するならC言語勉強した方がいいの？
297 ：デフォルトの名無しさん：05/02/07 07:32:42
Cは基本。モグリでないなら知ってて当たり前。
298 ：デフォルトの名無しさん：05/02/07 13:05:59
>>295
CってOS誰も作らなくなったら〜ってのと同じ。
CってOS誰も作らなくなったら〜ってのと同じ。
299 ：デフォルトの名無しさん：05/02/13 02:06:38
需要さえあれば特別な事情でもないかぎり誰かが作る
300 ：デフォルトの名無しさん：2005/04/08(金) 08:58:20
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣＼
| 300GETしていいですか？ . |
＼＿＿＿＿ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
／||ミ Ｖ
／ ::::||
／:::::::::::||＿＿＿＿
|:::::::::::::::|| ||
|:::::::::::::::||│ ／ ||
|:::::::::::::::||￣＼ ｶﾞﾁｬｯ
|:::::::::::::::||ﾟ ∀ﾟ） ||
|:::::::::::::::||＿／ ||
|:::::::::::::::||│ ＼ ||
|:::::::::::::::||∧ ∧∩ ..||
|:::::::::::::::|| ﾟ∀ﾟ）/ .||
|:::::::::::::::||∧ ∧∩ ..||
|:::::::::::::::|| ﾟ∀ﾟ）/ . ||
|:::::::::::::::|| 〈......||
|:::::::::::::::||,,／＼」......||
＼:::::::::::||￣￣￣￣
＼ ::::||
＼||
301 ：デフォルトの名無しさん：2005/04/29(金) 01:10:46
Java はだめだ。
Java環境はまあよいとして、
Java言語は、(特にJava5 の取って付けた様な generics は)
しょぼいというか、つかえんというか．．．
ありゃみらいがないねぇ...
Java環境はまあよいとして、
Java言語は、(特にJava5 の取って付けた様な generics は)
しょぼいというか、つかえんというか．．．
ありゃみらいがないねぇ...
302 ：デフォルトの名無しさん：2005/04/29(金) 01:25:16
>>294
>>C++が中途半端
C++から最近Javaやり始めたんだけど
Java 5 の generics の 中途半端さは 最悪。
もともと言語設計思想自体が、保守的すぎなのだ。
いまさら generics 実装して、全然なじんでないし、
バイナリも"まぜるな危険"だし...
そもそも、Exception指向強すぎて...
Javaライブラリも、機能は多いが、押し付け感強いし...
ま、日本人が好きそうな言語設計なのは分かるけど...
今考えると、C++ってJava以上に言語ってものをよく考えて作られたんだなって思うよ。
良くも悪くもね。
>>C++が中途半端
C++から最近Javaやり始めたんだけど
Java 5 の generics の 中途半端さは 最悪。
もともと言語設計思想自体が、保守的すぎなのだ。
いまさら generics 実装して、全然なじんでないし、
バイナリも"まぜるな危険"だし...
そもそも、Exception指向強すぎて...
Javaライブラリも、機能は多いが、押し付け感強いし...
ま、日本人が好きそうな言語設計なのは分かるけど...
今考えると、C++ってJava以上に言語ってものをよく考えて作られたんだなって思うよ。
良くも悪くもね。
303 ：デフォルトの名無しさん：2005/04/29(金) 01:49:41
つりかね
genericsはテンプレートとは別の目的だよ
Cはずっとやってきたからわかるが力量によるコードの差が激しすぎ
そしてJavaやC#についていけないへっぽこCプログラマも多い
genericsはテンプレートとは別の目的だよ
Cはずっとやってきたからわかるが力量によるコードの差が激しすぎ
そしてJavaやC#についていけないへっぽこCプログラマも多い
304 ：デフォルトの名無しさん：2005/04/29(金) 02:25:51
305 ：デフォルトの名無しさん：2005/04/29(金) 10:50:01
つーか1.4までと互換性あるんだからかまわんと思うが
互換性がないのならアレだが
互換性がないのならアレだが
306 ：デフォルトの名無しさん：2005/05/02(月) 02:26:09
Java5 で、Map< T, V > で受けようと思っても、
Java 1.4 は あくまで Map は Object,Object
結局ストイックに交ぜたければ、Object,Objectで受けてキャストするか、
例外記述になっちまう。
てか、Javaってキャスト大杉。
(型) によるキャストは、Ｃ言語と大差ない弊害の多い記述と思われ...
SUNも自覚したためgenerics(なんて御大層な名前で)実装したんだろうが...
そもそもJavaが持つ言語特性とあいいいれにくいと思うよ...
いまさらあんな言語拡張が、世のため人のためだろうか...
Java は、C++ や C# のまねなぞする必要ないのに...
Java 1.4 は あくまで Map は Object,Object
結局ストイックに交ぜたければ、Object,Objectで受けてキャストするか、
例外記述になっちまう。
てか、Javaってキャスト大杉。
(型) によるキャストは、Ｃ言語と大差ない弊害の多い記述と思われ...
SUNも自覚したためgenerics(なんて御大層な名前で)実装したんだろうが...
そもそもJavaが持つ言語特性とあいいいれにくいと思うよ...
いまさらあんな言語拡張が、世のため人のためだろうか...
Java は、C++ や C# のまねなぞする必要ないのに...
307 ：デフォルトの名無しさん：2005/05/02(月) 11:26:11
いや、そういうときはコレクションそのままつかうのではなく自分で実装すればいいだけかと
混ぜる場合もそれらをパッケージングしたBeans作ってそれをいれるだけ
Objectありきで設計してる時点で間違ってるよ
どっちにしろGenericsは必須
テンプレートの真似事にみえるのは実装側だろうけど、そっちはたしかになくてもいい
混ぜる場合もそれらをパッケージングしたBeans作ってそれをいれるだけ
Objectありきで設計してる時点で間違ってるよ
どっちにしろGenericsは必須
テンプレートの真似事にみえるのは実装側だろうけど、そっちはたしかになくてもいい
308 ：デフォルトの名無しさん：2005/05/04(水) 03:24:26
genericsはどうも最初は頑なに拒んでたがC#の出現で渋々採用といった感じだよな
シンプルなOO言語であることにこだわる余りにキャストの嵐では本末転倒だからさっさと採用するべきだったんだろうけどなぁ
シンプルなOO言語であることにこだわる余りにキャストの嵐では本末転倒だからさっさと採用するべきだったんだろうけどなぁ
309 ：デフォルトの名無しさん：2005/05/04(水) 08:34:32
オートボクシングが採用されたからはじめて実用的になったともとれるからなぁ
310 ：デフォルトの名無しさん：2005/05/22(日) 14:17:22
Genericsなんて今までなかったのが不思議なくらい必須の機能。
Java(1.4以前)でもC#でも、たかがList使うだけでキャストの嵐になる。
馬鹿馬鹿しくてやってられない。
こんなことちょっと触ればすぐわかる。
Java(1.4以前)でもC#でも、たかがList使うだけでキャストの嵐になる。
馬鹿馬鹿しくてやってられない。
こんなことちょっと触ればすぐわかる。
311 ：デフォルトの名無しさん：2005/05/22(日) 14:33:33
つーか、コレクションの場合なんでもいれれるようにObject型にしてるだけだし
継承して使えというスタンスだったのでは？
継承して使えというスタンスだったのでは？
312 ：デフォルトの名無しさん：2005/05/22(日) 23:24:54
>>311
もしそういうスタンスなあらC#用には普通にある
型限定のコレクションクラスを自動生成するツールが
Javaでは全く出てこなかったのが不思議なんだよな
コピペとはいえいちいち作らなきゃいけないのは問題外だと思うが
Javaプログラマはコレクションなんてどうでもよかったのかな？
もしそういうスタンスなあらC#用には普通にある
型限定のコレクションクラスを自動生成するツールが
Javaでは全く出てこなかったのが不思議なんだよな
コピペとはいえいちいち作らなきゃいけないのは問題外だと思うが
Javaプログラマはコレクションなんてどうでもよかったのかな？
313 ：デフォルトの名無しさん：2005/05/22(日) 23:47:36
クラス指向が強かっただけかと
プリミティブなものを直に入れるよりは多態で扱うとか
匿名クラスでイベント扱うのがデフォな時点で気がつけ
それにJavaプログラマと一括りにすな、C#厨
プリミティブなものを直に入れるよりは多態で扱うとか
匿名クラスでイベント扱うのがデフォな時点で気がつけ
それにJavaプログラマと一括りにすな、C#厨
314 ：デフォルトの名無しさん：2005/05/23(月) 00:01:34
>>313
本当に見たことが無いんでみんなコレクションのキャスト問題なんてどうでもよかったんじゃないかと思ってさｗ
本当に見たことが無いんでみんなコレクションのキャスト問題なんてどうでもよかったんじゃないかと思ってさｗ
315 ：デフォルトの名無しさん：2005/05/23(月) 00:15:53
コレクション使ってないコードなんてあんまりきいたこともないが
新たに大量動員された業務プログラマの8割は多態理解しらなくて
困ったことはある
オブジェクト指向理解しているとかぬかすくせに
List list = new ArrayList();
がずっと理解できないやつがちらほらと
まぁ、今はgenerics導入で上記コードが警告でるのも便利
新たに大量動員された業務プログラマの8割は多態理解しらなくて
困ったことはある
オブジェクト指向理解しているとかぬかすくせに
List list = new ArrayList();
がずっと理解できないやつがちらほらと
まぁ、今はgenerics導入で上記コードが警告でるのも便利
316 ：デフォルトの名無しさん：2005/05/27(金) 20:45:02
まぁ、Java の generics なんて、ただのシンタックス・シュガーでしかないがな
317 ：デフォルトの名無しさん：2005/05/27(金) 21:27:03
型の安全性が増えていい結果になったな＞じぇねりくす
318 ：デフォルトの名無しさん：2005/05/27(金) 22:06:21
>>316
Javaの思想からすればむしろそのほうが都合がいい
Javaの思想からすればむしろそのほうが都合がいい
319 ：デフォルトの名無しさん：2005/06/12(日) 00:29:13
Javaにポインタとアドレスがあれば
もっと分かりやすい言語になるのにね
もっと分かりやすい言語になるのにね
320 ：デフォルトの名無しさん：2005/06/12(日) 01:00:14
このスレ釣りばっかかよ
321 ：デフォルトの名無しさん：2005/06/17(金) 16:24:32
assertの実装に笑った
322 ：デフォルトの名無しさん：2005/06/17(金) 17:13:55
詳細希望
323 ：デフォルトの名無しさん：2005/06/17(金) 17:17:41
NIOのDirectByteBufferは明らかにCで確保した領域をJavaで扱うために作ったとしか思えない
324 ：デフォルトの名無しさん：2005/06/17(金) 18:32:25
NIOもVolatileImageも1.4からは割り切ってパフォーマンス追求する動きにでてるからな
安全性はそれなりに確保できるしわるくないのでは
安全性はそれなりに確保できるしわるくないのでは
325 ：デフォルトの名無しさん：2005/07/25(月) 22:58:07
C++で書いて移植したほうが遥かに現実的だという事実。
326 ：デフォルトの名無しさん：2005/10/23(日) 23:31:52
まだ習い始めたばっかだけど、equalsに一貫性がないのが気持ち悪い。
327 ：デフォルトの名無しさん：2005/10/24(月) 00:19:00
クラスごとに判断基準違うものをどうしろと
328 ：デフォルトの名無しさん：2005/10/24(月) 02:50:24
デフォの動作がインスタンス変数全部比べてくれるってのが良くない？
それで困るときだけ変えればいいし。
このクラスのequalsは〜とかいちいち面倒くさいし、混乱の元じゃん。
toStringもデフォでインスタンス全部出力すりゃいいのに。
それで困るときだけ変えればいいし。
このクラスのequalsは〜とかいちいち面倒くさいし、混乱の元じゃん。
toStringもデフォでインスタンス全部出力すりゃいいのに。
329 ：デフォルトの名無しさん：2005/10/24(月) 02:58:46
＞toStringもデフォでインスタンス全部出力すりゃいいのに。
これどういうこと？
これどういうこと？
330 ：デフォルトの名無しさん：2005/10/24(月) 03:48:58
いや、toStringでオブジェクトの現在の状態を表す文字列が出力されるようにオーバーライドするだろ？
それをわざわざしなくても自動的にそうして欲しくない？
これもこれで困るときだけ変えればいいし。
それをわざわざしなくても自動的にそうして欲しくない？
これもこれで困るときだけ変えればいいし。
331 ：デフォルトの名無しさん：2005/10/24(月) 12:00:41
その状態ってクラスごとじゃないと結局わからんだろうに
デフォはObjectの動作あるんだしこれ普通だろ
デフォはObjectの動作あるんだしこれ普通だろ
332 ：デフォルトの名無しさん：2005/10/24(月) 17:55:09
＞その状態ってクラスごとじゃないと結局わからんだろうに
そりゃ分かんないよ。
ただJavaが元々そういう機能をサポートしてたら大丈夫じゃん。
機能って言うかただのコンパイル時のコードの補完？
全然難しくないでしょ。インスタンス変数読み取って、決まった形式の文字列作るくらい。
だって毎回
"[name="+name+〜+"]"
みたいなわかりきってること書くのだるくないの？
リフレクションで簡略化できるだろうけど、デフォでやってくれた方が楽だし。
これのデメリットが見つからない。
そりゃ分かんないよ。
ただJavaが元々そういう機能をサポートしてたら大丈夫じゃん。
機能って言うかただのコンパイル時のコードの補完？
全然難しくないでしょ。インスタンス変数読み取って、決まった形式の文字列作るくらい。
だって毎回
"[name="+name+〜+"]"
みたいなわかりきってること書くのだるくないの？
リフレクションで簡略化できるだろうけど、デフォでやってくれた方が楽だし。
これのデメリットが見つからない。
333 ：デフォルトの名無しさん：2005/10/24(月) 18:36:19
それが状態を表すと思ってるの？
Beansならそれなりにやれるけど、それ以外はムリ
Beansならそれなりにやれるけど、それ以外はムリ
334 ：デフォルトの名無しさん：2005/10/24(月) 19:01:48
＞それが状態を表すと思ってるの？
そう思ってるけど、もしかして違うの？
そう思ってるけど、もしかして違うの？
335 ：デフォルトの名無しさん：2005/10/24(月) 19:14:24
違う
だからBeans以外は[〜]って表記してないと思うが
だからBeans以外は[〜]って表記してないと思うが
336 ：デフォルトの名無しさん：2005/10/24(月) 19:43:17
マジ？俺の読んでるCoreJava2って本で推奨されてるよ。
普通はどうやるの？
普通はどうやるの？
337 ：デフォルトの名無しさん：2005/10/24(月) 20:02:18
toStringの使い方は異なる
［〜］と表記しなければならないってことはない
Swing使っていればtoString大量に出てくるからどう使えばいいか分かりそうだが
［〜］と表記しなければならないってことはない
Swing使っていればtoString大量に出てくるからどう使えばいいか分かりそうだが
338 ：デフォルトの名無しさん：2005/10/24(月) 20:46:53
んー、常にこう使うって訳じゃないのはわかるよ。
でも基本はデバッグに便利なようにインスタンス変数の状態を[〜]みたいに書くんじゃない？
＞Swing使っていればtoString大量に出てくるからどう使えばいいか分かりそうだが
良く分かんないけど、例えば、JLabelのtoStringはこうだったよ。
javax.swing.JLabel[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.0,〜省略〜,verticalTextPosition=CENTER]
見当違いなことしてたらわりぃ。
でも基本はデバッグに便利なようにインスタンス変数の状態を[〜]みたいに書くんじゃない？
＞Swing使っていればtoString大量に出てくるからどう使えばいいか分かりそうだが
良く分かんないけど、例えば、JLabelのtoStringはこうだったよ。
javax.swing.JLabel[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.0,〜省略〜,verticalTextPosition=CENTER]
見当違いなことしてたらわりぃ。
339 ：デフォルトの名無しさん：2005/10/24(月) 22:09:25
いや、リストとかテーブルとかのセルや各項目の表示方法などね
toStringを使うようになってるから
それにその表記はbeansだから可能な
toStringを使うようになってるから
それにその表記はbeansだから可能な
340 ：デフォルトの名無しさん：2006/01/01(日) 03:19:59
意味も無くage
341 ：デフォルトの名無しさん：2006/01/01(日) 04:44:33
長寿スレだなｗ
10/24付近のは、言語でやるんじゃなくてRefactoringの機能とかで
持ってればいんじゃね？
setter,getterを作るような感じで。
少なくともtoStringは決まった形式に言語で縛るのは危険。
10/24付近のは、言語でやるんじゃなくてRefactoringの機能とかで
持ってればいんじゃね？
setter,getterを作るような感じで。
少なくともtoStringは決まった形式に言語で縛るのは危険。
342 ：デフォルトの名無しさん：2006/03/21(火) 03:39:44
Java はプリミティブ型で参照を渡せないのがしんどい。
Tiger で踏み込んで欲しかったけど
C# の真似と言われたくなかったんだろうか。
ボクシング・アンボクシングなんて瑣末なものは後回しにして欲しかった。
(瑣末どころか曖昧さが増えてむしろ迷惑だ。)
Tiger で踏み込んで欲しかったけど
C# の真似と言われたくなかったんだろうか。
ボクシング・アンボクシングなんて瑣末なものは後回しにして欲しかった。
(瑣末どころか曖昧さが増えてむしろ迷惑だ。)
343 ：デフォルトの名無しさん：2006/03/25(土) 13:14:08
なんでプリミティブ型もObjectの派生物にしなかったんだろう
344 ：デフォルトの名無しさん：2006/03/26(日) 22:38:05
そこだけはパフォーマンス上妥協したとのと
生成コスト短縮したと見た。
生成コスト短縮したと見た。
345 ：デフォルトの名無しさん：2006/03/27(月) 00:34:55
プリミティブ型の参照渡しをサポートしなかったのって何故？
type* 相当はまぁ分からんでもないが
type& 相当あったところで、混乱起こすとは思えないんだが。
オブジェクト型は type& 相当のことやってるわけだし。
type* 相当はまぁ分からんでもないが
type& 相当あったところで、混乱起こすとは思えないんだが。
オブジェクト型は type& 相当のことやってるわけだし。
346 ：デフォルトの名無しさん：2006/03/27(月) 01:48:21
>プリミティブ型の参照渡しをサポートしなかったのって何故？
ラッパークラスがあるタメに不要だから。
ラッパークラスがあるタメに不要だから。
347 ：デフォルトの名無しさん：2006/03/27(月) 01:49:05
リフレクションのときの面倒を減らす効果があるから。
リファクタリングしやすいから。
リファクタリングしやすいから。
348 ：デフォルトの名無しさん：2006/03/27(月) 02:48:23
>346
プリミティブ型のラッパークラスは不変オブジェクトになってて
参照渡し的な使い方は一切出来ないんですが。。
>347
なるほど。
プリミティブ型のラッパークラスは不変オブジェクトになってて
参照渡し的な使い方は一切出来ないんですが。。
>347
なるほど。
349 ：デフォルトの名無しさん：2006/04/02(日) 23:42:21
mallocの本質はフリーチェーンと呼ばれる使用可能メモリブロックの長い連結リストだ。
mallocのパフォーマンスは決して速くなく、しかも、クリーンアップのために
ときどき予期できないタイミングで非常に遅くなる
Javaはガベージコレクションがあるから・・・なんてしたり顔で話すC++プログラマが、
デフォルトのメモリアロケータを平然と使っているなんてことは良くある。
頭のいいプログラマは、mallocによる処理の中断の可能性を最小化するために、
いつも2の累乗のサイズでメモリブロックを割り当てる。
この方法はフリーチェーンの中のヘンな断片化の量を最小化するのだ。
…尤も、Javaの世代別GCに比べれば余りに原始的だがな。
mallocのパフォーマンスは決して速くなく、しかも、クリーンアップのために
ときどき予期できないタイミングで非常に遅くなる
Javaはガベージコレクションがあるから・・・なんてしたり顔で話すC++プログラマが、
デフォルトのメモリアロケータを平然と使っているなんてことは良くある。
頭のいいプログラマは、mallocによる処理の中断の可能性を最小化するために、
いつも2の累乗のサイズでメモリブロックを割り当てる。
この方法はフリーチェーンの中のヘンな断片化の量を最小化するのだ。
…尤も、Javaの世代別GCに比べれば余りに原始的だがな。
350 ：デフォルトの名無しさん：2006/07/04(火) 21:26:31
時給１０００円でＪａｖａ教えてくださるかたを募集します
場所 所沢（池袋・高田馬場から直通）
ｉ−ｗａｎｔ−ｔｏ−ｓｔｕｄｙ−ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
（アドレスは全角で書いてあるので半角に直してください）
よろしくおねがいします
場所 所沢（池袋・高田馬場から直通）
ｉ−ｗａｎｔ−ｔｏ−ｓｔｕｄｙ−ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
（アドレスは全角で書いてあるので半角に直してください）
よろしくおねがいします
351 ：デフォルトの名無しさん：2006/07/04(火) 23:44:46
とりあえずc++0xがどうなるか様子見。
（永遠に様子見してしまいそうだが…）
（永遠に様子見してしまいそうだが…）
352 ：デフォルトの名無しさん：2006/08/20(日) 19:44:03
353 ：デフォルトの名無しさん：2006/08/20(日) 22:41:44
GCJ
ランタイム入れないと動かないとかカンベンシテくださいよ