JavaやるとC++は有害に感じる int 2
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2007/02/11(日) 14:53:43私はオブジェクト指向という言葉を発明したが、C++のことなんて全く念頭になかったね。
-- アラン・ケイ
C++の進化の歴史は文字列の抽象化を漏れを塞ごうと試行錯誤するものである。
なぜ彼らが単にネイティブ文字列を追加しないのかわからない。
-- ジョエル・スプロウスキー
C++は見栄えをよくしたCOBOLとして現在使われている唯一の言語だ。
-- バートランド・メイヤー
もしBjarneがCとの互換性にこだわる必要がなかったとしたら、Javaを開発していたろうね。
-- ビル・ジョイ
C++言語のデザイナーたちは、同じ問題を解決するアイディアが二つあると、いつも「よし、両方ともやろう」と言う。
だからこの言語は私の感覚ではかなり奇怪(baroque)なものになっている。
-- ドナルド・クヌース
歴史的に、他人に使ってもらえるようにデザインされた言語は出来が悪い：COBOL, PL/I, Pascal, Ada, C++.
良い言語はクリエイターが自身が使うためにデザインしたものである：C, Perl, Smalltalk, Lsip.
-- ポール・グレアム
C++なぞ問題外. ^^;;;
-- まつもとゆきひろ
0153デフォルトの名無しさん
2007/02/13(火) 00:40:09> >>139
> 完全にとっては代わることはないだろうが、JavaがどんどんC#に
> その役割と立場を喰われているのは事実だろう。
C#がまだベータ版だった頃(2001年)からそういう発言をしている某学生派遣会社の営業が
いたことを思い出すよ。
Javaが遅いからという理由で嫌いになりPHPとC#をしきりに勧めていた彼は今頃どうしているかな。
0154デフォルトの名無しさん
2007/02/13(火) 00:41:50つーかOOPLで型無し言語ってあるのか？
オブジェクトがクラス情報（かそれに近いシステム）持ってなきゃ
ポリモル出来ない気がするんだが。
0155デフォルトの名無しさん
2007/02/13(火) 00:47:54まずはなにをもって型があるとするかだろ。
まぁ、型の強弱はあっても全く型の無い言語なんてそれこそ少数派だろ。
0156デフォルトの名無しさん
2007/02/13(火) 01:02:520157デフォルトの名無しさん
2007/02/13(火) 01:11:58内部ではどう扱っていたんだかわからんが
0158デフォルトの名無しさん
2007/02/13(火) 01:22:16それは所謂、強い型付けってことでしょう。
Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。
まあ、そもそも型安全でないC/C++よりはマシですどね。
0159デフォルトの名無しさん
2007/02/13(火) 01:37:53アップキャストとダウンキャストの区別が㌧㌦
言語 基本クラスへの型変換失敗 派生クラスへの型変換失敗
スクリプト系 実行時検出 実行時検出
Java コンパイル時検出 実行時検出
C++ コンパイル時検出 プログラマ任せ
0160はっさく
2007/02/13(火) 01:57:290161デフォルトの名無しさん
2007/02/13(火) 02:09:160162デフォルトの名無しさん
2007/02/13(火) 02:15:44> Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。
全然違うだろ。↓がコンパイル通るなら一緒だがｗ
import javax.swing.*;
public class Test001 {
void myMethod(int i) {}
public static void main(args) {
"".getThreadGroup();
myMethod(new JButton());
}
}
ちなみに、変数に型の無い言語なら
int i なんて指定出来ないから何でも入る。
昔のVectorの状態を全ての変数や引数でやるワケだ。
0163デフォルトの名無しさん
2007/02/13(火) 02:29:24寝ぼけているのではなく、本気で言ってるのなら、基本から勉強しなおすと良いよ。
016472
2007/02/13(火) 02:33:21そりゃ、Javaアーキテクトは土方じゃないよ。
コーダーが土方っていってる。
うちは、主要なインターフェースを全部作っておいてあげて、
実装はコーダーさんに任せるってやり方をしてる。
実装にもノウハウは必要だけれど、
こういうやり方をしていると、新人もベテランも、
他の言語ほどあんまり差がつかないんだよね。
まぁ、Javaがよくできた言語だということだと思うけど。
多くのJavaのコーダーさんは、言われた通りにしかやらない人が多い。
言語に罪はないが、自主性のない人間を増やしている気がする。
0165デフォルトの名無しさん
2007/02/13(火) 02:41:57>Javaのアップキャスト検出は状況次第じゃないか
アップキャスト検出ではないが、Javaのダウンキャスト検出は状況次第だわ。
ダウンキャスト先が継承関係に無い場合はコンパイル時エラーだな。
俺も基礎からやり直すよorz
0166デフォルトの名無しさん
2007/02/13(火) 02:51:481秒に何百というオーダーがくる、金融系や、OpSなんかでは、
JavaのGCがかなりネックになってしまう。
GCの走るタイミングが読めないし、完了する時間もわからない。
Javaでメモリリークのおこらないシステムにするには、
プログラムの設計だけではだめで、ハードの増強や、
負荷分散の仕組みに金がかかってしまう。
通常の処理をしている分には、Javaは優れているけど、
リアルタイム性がないんだよね。。
0167デフォルトの名無しさん
2007/02/13(火) 03:05:490168デフォルトの名無しさん
2007/02/13(火) 03:11:16感じたが、現実は厳しかったなぁ。
0169デフォルトの名無しさん
2007/02/13(火) 03:27:19まあ段々とそう見なせる状況は広がって行くと思う。
0170デフォルトの名無しさん
2007/02/13(火) 03:56:22じゃぁ、GC用に一個、コアを予約しておくか。
0171デフォルトの名無しさん
2007/02/13(火) 04:21:12GCのない言語だとメモリリークを防ぐには、腕の立つプログラマと長い検証期間が必要だ。
そんなの信用ならん。
0172デフォルトの名無しさん
2007/02/13(火) 04:34:300173デフォルトの名無しさん
2007/02/13(火) 05:01:38パソコンショップで売ってるWindows用のソフト，例えば画像編集，デジカメ写真整理，年賀状作成，動画編集，シューティングゲーム，etc みたいな
ソフトは C++/MFC で組まれてるんじゃないの？
Windows 用のネイティブアプリをまともに作れる言語ってこれしかないような。
生 Win32 API だけで作るのは大変だし。
.NET Framework は相変わらずもっさりだし。
0174デフォルトの名無しさん
2007/02/13(火) 05:12:150175デフォルトの名無しさん
2007/02/13(火) 05:18:24ttp://www.tiobe.com/tiobe_index/index.htm
今後のトレンドを予想してみたい。
ttp://www.tiobe.com/tiobe_index/images/tpci_trends.png
0176デフォルトの名無しさん
2007/02/13(火) 05:25:40徹夜は効率悪いよ。
0177デフォルトの名無しさん
2007/02/13(火) 05:25:55つVB、Delphi、Macromedia Director
あと、MFCとか言い出すと標準C++じゃないから話がややこしくなってくる。
Windows環境はC++コミュニティからも冷めた目で観られてる。
0178デフォルトの名無しさん
2007/02/13(火) 06:40:570179デフォルトの名無しさん
2007/02/13(火) 06:47:10>デジカメ写真整理，年賀状作成，動画編集，シューティングゲーム，
>etc みたいなソフトは C++/MFC で組まれてるんじゃないの？
その通りだよ。そんな実態をすべて忘れてJava最高！といい続ける
妄想宗教スレなわけだ。
0180デフォルトの名無しさん
2007/02/13(火) 06:55:18> Delphi、Macromedia Director
!? !? !?
なあ、Delphiが生き残ってるって初めて聞いたんだが。
0181デフォルトの名無しさん
2007/02/13(火) 08:34:42アプリ系ってもう負け組じゃん。C++は負け組言語と言いたいわけですか。
0182デフォルトの名無しさん
2007/02/13(火) 08:50:04ﾌﾟ
0183デフォルトの名無しさん
2007/02/13(火) 10:24:32（前スレ）JavaやったらC++はきもく感じるとは直接関係ないけど
#include <～>
なんで拡張子hを消したんだろう。
中途半端なこと変えやがって
そのくせboostみたいに他の言語並みの使いやすさに
近づけてくれるものはなかなか標準にならない。
HTTP通信とかスレッドとか標準ライブラリや言語仕様にして
他のOSでも移植しやすいようにしろよ。
事実上よく使われるとかデファクトとかじゃなくて
標準装備になっていると大違い。
0184デフォルトの名無しさん
2007/02/13(火) 12:08:27> >>139
> 完全にとっては代わることはないだろうが、JavaがどんどんC#に
> その役割と立場を喰われているのは事実だろう。
そんなソース無いな。
そもそもライブラリの豊富さですでにJavaに劣っている。
0185デフォルトの名無しさん
2007/02/13(火) 12:10:04> 型の甘い言語って、JavaやC++もどっちもそんなに型に厳しいわけじゃないだろ。
お前みたいに大嘘ツク奴は(ry
> どちらも暗黙のキャストするし、コンパイラが賢い型推論もってるわけでもない。
暗黙のキャストといってもPerlやPHPなどのようなスクリプト言語ほど暗黙の
キャストをする言語ではないが。C++の場合はJavaよりもやたらと暗黙のキャストをするが。
それに、型推論持っていれば型に厳しくなるとは限らないのだが。
0186デフォルトの名無しさん
2007/02/13(火) 12:10:56そのときそのときに案件でしか判断できないとは痛々しいな。
C#の立場はクライアントサイドのみでしか発揮されないよ。
サーバサイドではどうみてもJavaやPHPには勝てない。
0187デフォルトの名無しさん
2007/02/13(火) 12:11:59デーベースと言えば、Javaも Java SE 6(Mustang)
からApache Derbyが標準搭載され、100%PureJavaデータベースが
Java SE 6に取り込まれた。
0188デフォルトの名無しさん
2007/02/13(火) 12:15:04JavaとJavaScriptとを勘違いしていないか？
それとも「明示的な型キャスト」をしてもキャストをできないケースがあるという
意味を勘違いしていないか？
Javaの明示的な型キャストは、プリミティブ型やスーパークラスからサブクラスへのキャスト(ナローイング変換)のときだけ。
暗黙の型キャストはその逆でスーパークラスへのアップキャスト(ワイデニング変換)だけ。
Genericsが出てから、余計な明示的ダウンキャストをしなくて良くなった
というものもあるが。
0189デフォルトの名無しさん
2007/02/13(火) 12:15:35PHP, Perl, JavaScriptなどなど
0190デフォルトの名無しさん
2007/02/13(火) 12:21:17それはオートボクシングのことか。
今でも別れているが。
C#やC++と違い、どんなことがあってもJavaのオブジェクトはすべて参照型。
プリミティブ型もすべて値型。
オートボクシングを使うときは、何かに代入するときに暗黙のうちにボクシングされるだけであって、
C#のように、その値型を持った変数がプリミティブラッパークラスのオブジェクトに変化する「可変」ではない。
そもそもJavaのプリミティブラッパークラスは「不変(イミュータブル)クラス」だ。
「不変」であるという点から、依然として型には厳しい。
値型と参照型両方をもつことができるC#のボクシング&アンボクシング変換とはまったく仕様が違う。
0191デフォルトの名無しさん
2007/02/13(火) 12:24:01> >>151
> Javaも結局、実行時しか型変換失敗を検出できないからスクリプト系と一緒ですよ。
なんか、トンデモ発言だな。
まともにJavaプログラミングしたことがあるのかと
0192デフォルトの名無しさん
2007/02/13(火) 12:26:21> >>85
> まぁ、Javaがよくできた言語だということだと思うけど。
> 多くのJavaのコーダーさんは、言われた通りにしかやらない人が多い。
> 言語に罪はないが、自主性のない人間を増やしている気がする。
Java質問スレで質問しまくってる厨房どもだろ。
大学でJavaの宿題やってる奴が多いから、そっからお前が見かけるような
厨房が産まれる。
しかしそれは真のJavaアーキテクトじゃないな。
Javaの氷山の一角だけを見ている奴がそうなる。
0193デフォルトの名無しさん
2007/02/13(火) 12:34:52> >>127
> 1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
> JavaのGCがかなりネックになってしまう。
> GCの走るタイミングが読めないし、完了する時間もわからない。
> Javaでメモリリークのおこらないシステムにするには、
> プログラムの設計だけではだめで、ハードの増強や、
> 負荷分散の仕組みに金がかかってしまう。
いつの時代の話をしているのだろうと耳(目)を疑う。
少しはjava.lang.ref.SoftReferenceを使って改善しようとは思ったことが
ないのかね？
GCのタイミングを調整するには、java.lang.refパッケージを使って
ネックになりそうなオブジェクトをプロファイラで検出して
そのオブジェクトを見つけたら、そのオブジェクトの到達可能性レベルを
SoftReferenceでカプセル化して変更しろ。
間違っても都市伝説を信じている時代遅れな連中のように意図的にnull代入やSystemgc()なんか使うなよ。
JavaがC++より速いケースは、ファイルI/O処理、メモリ解放確保のタイミングだ。
このことから、Javaの最適化がかなり進んでいるので、GCについてはまず問題ないし、
むしろC++の手動メモリ管理に依存した方が遅くなってしまうぞ。
C++が速度面で勝っているのは今のところは、三角法の計算や数値演算くらいだ。
0194デフォルトの名無しさん
2007/02/13(火) 12:36:10まさにその通り、昔は人間がやっていたことを
今では簡単に機械が実行できる時代。
それを認めたくない香具師がたまにいるみたいだが。
0195デフォルトの名無しさん
2007/02/13(火) 12:39:26C#も忘れている。デスクトップではJavaより進んでいるとマイクロソフトの関係者は主張している。
VistaのようなOSを手がける彼らが自信を持って言わなくちゃならない当然の発言だろうけど。
JavaもSwingが強くなってくるから、今後、どうなるか解らないだろうねえ。
Linux方面もFedora Coreのデスクトップが徐々に進化してVistaに対抗して
右食ったと思われる派手な視覚効果も追加されている。
となると、クロスプラットフォームという強みを持つJavaも再び見逃せなくなる。
なにせ、Java Web Startがあるし
0196デフォルトの名無しさん
2007/02/13(火) 12:41:14C言語の人気は相変わらずだ。
RubyがRuby on Railsの影響で注目され始めていることがわかるが
結局Javaが圧倒している。
0197デフォルトの名無しさん
2007/02/13(火) 12:44:12だから、それは過去の遺産がC++で作られているから
Javaに移行するとスイッチングコストが高く付くから
C++のままで開発しているだけだよ。
JavaがC++よりも速くなるケースが出てきたのは
最近だし。Swingの高速化についてはまだまだ知られていないみたいだね。
JavaはファイルI/Oやメモリ管理速度がC++よりも速くなっているので
そろそろリプレースしてもいいころだろうけど、
Java SwingはGUIコンポーネントがWindowsに付属するものと
比べると劣るものが多いから移行を躊躇う企業が多いのだと思う。
それにVistaも出ているし
0198デフォルトの名無しさん
2007/02/13(火) 12:44:48C言語時代の名残だろ。伝統的と揶揄されるがシガラミでしかない
0199デフォルトの名無しさん
2007/02/13(火) 12:51:41あったとしてもほとんどない。
この分野はCおよびC++の独壇場でしょ？
多数人の手で大規模なシステム開発をやるならともかく、
一人または少数人で計算速度重視のプログラムを組む場合、
Javaなんて度外視されてるのが現状じゃない？
0200デフォルトの名無しさん
2007/02/13(火) 14:21:50> 聞きたいんだけど、Javaで数値計算のライブラリってあるの？
> あったとしてもほとんどない。
Jakarta Commons Math
> この分野はCおよびC++の独壇場でしょ？
そりゃCは20年くらい先行して現れた言語だからねえ。
> 多数人の手で大規模なシステム開発をやるならともかく、
> 一人または少数人で計算速度重視のプログラムを組む場合、
> Javaなんて度外視されてるのが現状じゃない？
10年前なら真っ先にそうだったね。
だが、もうそんな時代は終わってるよ。
JavaはC++よりもメモリの管理速度やファイル操作が速いので
C++よりも巨大なデータを扱うことに向いている。
0201デフォルトの名無しさん
2007/02/13(火) 15:16:140202デフォルトの名無しさん
2007/02/13(火) 15:21:52じゃあ携帯Javaももう天国になったんだな
うらやましいぜ
0203デフォルトの名無しさん
2007/02/13(火) 15:30:330204デフォルトの名無しさん
2007/02/13(火) 15:32:14C -> C++ の失敗に良く似ているね
こういうケースでは新言語作るべきなんだよ
0205デフォルトの名無しさん
2007/02/13(火) 15:49:28> JavaはC++よりもメモリの管理速度やファイル操作が速いので
JavaVMはC++で作られたアプリケーションだから、
C++より速いメモリ管理やファイル操作がC++によって実現されていることになる。
0206デフォルトの名無しさん
2007/02/13(火) 16:04:23メモリが少なすぎてまだまだ
0207デフォルトの名無しさん
2007/02/13(火) 16:17:01だったらさ、C++はなぜそこだけJavaより遅くなるのかな？
0208デフォルトの名無しさん
2007/02/13(火) 16:37:25実際に遅いかどうかは別として、こまめにメモリを確保・解放して
メモリの使用量を抑制するか、十分なメモリを確保したままにして
速度を重視するかでトレードオフの関係が成り立つから、
速度を犠牲にしてメモリの使用量を減らすことを優先することもできる。
JavaでもSUNが速度を重視する設計を選択しただけで、逆に速度を犠牲にして
メモリの使用量を抑制する実装もあり得る。
根本的なところだと、C++の速度とかJavaの速度というのは奇妙な表現で、
同じソースからコンパイルしたネイティブコード／クラスファイルでも、
コンパイラやライブラリ等の実装次第で実行速度はいくらでも変わってくる。
コンパイラやライブラリの実装の良し悪しと言語の良し悪しとは、別の問題。
0209デフォルトの名無しさん
2007/02/13(火) 16:44:54ではどうやってJavaより遅いそのC++でJVMを実装していると考えているのだろうか
0210デフォルトの名無しさん
2007/02/13(火) 17:50:53>JavaはC++よりもメモリの管理速度やファイル操作が速いので
とかぬかしてるだけな気がするんだが。
確かに C++ の処理系で実行時最適化できる実装はないし
標準のストリーム I/O は糞以下だが。
0211デフォルトの名無しさん
2007/02/13(火) 20:12:14javaの配列はどんな感じ？
1.1倍？
0212デフォルトの名無しさん
2007/02/13(火) 22:32:13>1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
>JavaのGCがかなりネックになってしまう。
>GCの走るタイミングが読めないし、完了する時間もわからない。
某UFJ銀行関連はJava使ってたような・・・。
あと、WebSphereとかの商用APサーバなんかは、そこそこの
チューナーがいればJavaだから遅いなんて思う事はまずないが。
金融系を語る奴に限って金融系の開発をしたことあるのか激しく疑問なんだが。
0213デフォルトの名無しさん
2007/02/13(火) 23:24:17言語はそれぞれ得意分野があるもんだ。
C/C++はハード側の関心事により最適化できるようになってるし、
Javaはよりユーザ側の関心事に最適化できるようになっている。
ハードの足かせのない世界を指向するJavaを、より「ソフトウェア」と
呼べる分、一プログラマとしてはJavaを支持する。
組み込みソフト業界も良く知ってるけど、やっぱりハード側の仕様に
振り回されるだけの便利屋的な存在になりさがってるしね。
Javaの「WriteOnece,RunAnywhere」の思想とその実現への姿勢は、
最近は余り取り上げられなくなったけど、やはり革命的だと思ってる。
「立てよ国民。我々にとって地球は狭過ぎた！」
0214デフォルトの名無しさん
2007/02/14(水) 00:36:10VB用に帳票印刷を手作りしたときには役に立った。
C++は言語としてはいまだに一番好きだけど、これだけでアプリケーションを組む
のは、化学実験室に連れて行かれて試薬でクッキー作れといわれるぐらい嫌。
0215デフォルトの名無しさん
2007/02/14(水) 00:37:41ときどきC言語は移植性が高いというのを見つけるけどさ
BASICなどに比べると方言が少ないとかぐらいでしょ。
処理系依存たっぷり
昔から進歩していない標準ライブラリ
そんなC言語と互換を持たせたC++
0216デフォルトの名無しさん
2007/02/14(水) 00:39:14>化学実験室に連れて行かれて試薬でクッキー作れといわれるぐらい嫌。
いや、それ面白そうじゃん？ ちょーやりてー
0217デフォルトの名無しさん
2007/02/14(水) 00:41:39ANSI C に準拠してるヤツはかなり互換性いいぞ。
てか、C++の互換性の無さにはウンザリ。
あれじゃ、標準規格があって無いようなもんだ。
0218デフォルトの名無しさん
2007/02/14(水) 00:44:40特にJavaの奴は誤差が頻繁に出るからクレーム付けたら「1円くらいどうでもいいだら」なんて言うし。
最低。
0219デフォルトの名無しさん
2007/02/14(水) 00:47:55それはお前のまわりだけだろ？
得意としてる言語に関わらず、そんなヤツには合ったことないぞ。
で、まわりにそんなヤツが多いってことは、お前もどうせその同類だろ。
0220デフォルトの名無しさん
2007/02/14(水) 00:49:280221デフォルトの名無しさん
2007/02/14(水) 00:51:27COBOLが最も得意とする分野なのですが。＞事務計算
0222デフォルトの名無しさん
2007/02/14(水) 00:56:48>>218がコボラだつったの。
俺はよく事務計算については知らないんだけど、COBOLは他の言語に対して
事務計算の分野においてどういうアドバンテージがあるのか教えてくれない？
0223デフォルトの名無しさん
2007/02/14(水) 01:00:40事務計算くらいしかできん。と言うならわからんでもないが。
0224デフォルトの名無しさん
2007/02/14(水) 01:04:07C の環境依存部分は、ほとんどの場合利用できる関数(とヘッダ)なので
環境依存部分をファイルに分離して Win/Mac/Unix 対応くらいならできる。
これが QB/VB/N88 に対応しろって言われたら頭抱えて途方にくれるよ。
そのくらい違う。
Java はそもそもどこでも動くはず。と言うか動くべき。
0225デフォルトの名無しさん
2007/02/14(水) 01:07:08>Java はそもそもどこでも動くはず。と言うか動くべき。
でも、動かない。プッ
0226デフォルトの名無しさん
2007/02/14(水) 01:11:26あらゆる環境で完璧に動くよ。
0227デフォルトの名無しさん
2007/02/14(水) 01:34:25０点。もう少し頭を使いましょう。
0228デフォルトの名無しさん
2007/02/14(水) 02:02:56だからC++プログラマの技術力が
ロボットの技術力に追いつかないということだよ。
わかりやすい例に喩えると、
ファクトリーオートメーションを導入している工場と
そうでない工場との違いだよ。
Javaというものは、人間が行えばミスがおかしいものを
ロボットに任せて自動化させたようなもの。
それによって効率が向上しているというものだ。
C++はBoostを使わないときは、人間がやらなくても
いいことをわざわざやろうとするからJavaの最適化技術に勝てず
ある分野ではJavaに最強の座を奪われている。
そこでBoostを導入しようとするけれども、言語仕様に
もとから欠陥がありシガラミがあるため限界がある。
それに、Boostは数十人の優秀な技術者を集めて作った
JavaコンパイラやJVMの技術力には勝てずにいるということも
大きな特徴。
ここでC++が再び、全ての分野でJavaより高速化できるかどうかは、
Boostのようなライブラリの強化にかかっていると思うね。
Javaも Java SE 6になってからソースコードが公開されGPL2.0になったから
今頃、Boost開発者は一生懸命Java SE 6のソースコードを解析して
最適化技術をリバースエンジニアリングしているところじゃないかな？
0229デフォルトの名無しさん
2007/02/14(水) 02:09:17> つか、>>200 が勝手に
> >JavaはC++よりもメモリの管理速度やファイル操作が速いので
> とかぬかしてるだけな気がするんだが。
それにはソースがあるよ。
Comparison of Java and C++
http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Performance
* pointers make optimization difficult since they may point to arbitrary data or code
* newly allocated memory is close together because garbage collection compacts memory and allocations are thus sequential in memory; and hence more likely to be 'in the cache'
* run-time compilation can do a better job because it knows what processor it is running on and what code is running - the hot spots
One comprehensive study of microbenchmarks shows quite a large variation in results
but indicates that, in general, Java outperforms C++ in operations such as memory
allocation and file I/O while C++ outperforms Java in arithmetic and trigonometric operations.[3]
For numerical processing, Java has shown significant gains with each new version but
still lags C++ and Fortran, in part due to the requirement for reproducibility of floating-point
results across all platforms.[4]
[3]のソース
# ^ "Microbenchmarking C++, C# and Java" by Thomas Bruckschlegel, Dr. Dobbs, June 17, 2005
http://www.ddj.com/184401976
[4]のソース
# ^ "Java and Numerical Computing" by Ronald F. Boisvert, Jose Moreira, Michael Philippsen and Roldan Pozo, NIST, Dec 2000
http://www.javagrande.org/leapforward/cacm-ron.pdf
0230デフォルトの名無しさん
2007/02/14(水) 02:14:19知ったか厨なんてこの程度だな。
>>229
中々面白い。
0231デフォルトの名無しさん
2007/02/14(水) 02:17:02Javaは配列自体Javaより遅いからねえ。
今なら、配列の替わりにBufferのサブクラスとChannelクラスを使うことでCの配列のと
同じくらいの高速化を実現できるといえばできるけど。
それと、Java版Vectorは中途半端に同期をとる古い仕様で使われていない。
かわりに、java.util.ArrayListとjava.util.LinkedListが使われている。
それぞれ、読みこみ速度、書込速度に違いがあるのは、アルゴリズムとデータ構造を
大学で教わっているなら変わると思う。
それと、Iteratorに変換すると遅くなるケースもあるようだ。
RandomAccessインタフェースを使って高速化するケースもあるので
配列よりどれだけ遅いか速いかは厳密にはわからない。
http://d.hatena.ne.jp/t_yano/20070128/1170006946
get()を使うかnext()を使うかなどで速度も変わってしまう。
0232デフォルトの名無しさん
2007/02/14(水) 02:20:11> >>166
> >1秒に何百というオーダーがくる、金融系や、OpSなんかでは、
> >JavaのGCがかなりネックになってしまう。
> >GCの走るタイミングが読めないし、完了する時間もわからない。
> 某UFJ銀行関連はJava使ってたような・・・。
拡張子がdoになっているので、UFJダイレクトはフロントエンド付近に
Apache Strutsを使っているようだね。
というか銀行の「ダイレクト」系はどこもJavaばっかだね。
三井住友もイーバンクもそうだし。
証券会社もそう。楽天証券、イートレード証券なども。しかもローソク足表示にはJavaAppletを使ってる。
最近じゃ、YahooでもJavaを使っているところがある。
お金が絡むところは何かしらJavaが関与しているみたいだ。
0233デフォルトの名無しさん
2007/02/14(水) 02:22:25昔の言語とくらべると「できないことは無い」
というだけで「移植性が高い」と言っているだけだろうね。
Javaの移植性とはまた違う。今なら、Javaのほうが移植性が高く見える
ことは間違いないけど。
0234デフォルトの名無しさん
2007/02/14(水) 02:23:34> 数値計算というか事務計算をやらせようとするとC++厨もJava厨もろくでもない物しか作れない。
> 特にJavaの奴は誤差が頻繁に出るからクレーム付けたら「1円くらいどうでもいいだら」なんて言うし。
> 最低。
たまたまそいつがBigDecimalやBigIntegerの使い方知らなかっただけだろ。
はっきりいってそいつのスキルの問題だな。言語の問題じゃないな。
0235デフォルトの名無しさん
2007/02/14(水) 02:25:1910進数演算が得意なだけだろう。
日立のCOBOLerがJavaよりも優位な点は、
メソッドを使わず演算子だけでBihIntegerのようなクラスを
使うことができると主張していたな。
たかがそれだけがJavaに対するアドバンテージかよと思った。
過去の遺産が残っているから仕方が無くCOBOLを使ってるだけってのが
殆どだろうがな
0236デフォルトの名無しさん
2007/02/14(水) 02:26:55よほど、Sunに知られていないOSや、Java SEやJavaMEが入らない
リソースが小さい古臭いOSじゃない限りそういうことはないだろう。
0237デフォルトの名無しさん
2007/02/14(水) 02:27:36知ったか厨？
言っておくが、>>228と>>229は両方とも俺が書いたんだが。
0238デフォルトの名無しさん
2007/02/14(水) 02:29:020239デフォルトの名無しさん
2007/02/14(水) 02:34:24>229 の引用先の内容まで君が書いたわけじゃないんだろう?
0240デフォルトの名無しさん
2007/02/14(水) 02:37:03だからWikiで信用できないなら
この大元のソースを見ればいいだろう。
[3]のソース
# ^ "Microbenchmarking C++, C# and Java" by Thomas Bruckschlegel, Dr. Dobbs, June 17, 2005
http://www.ddj.com/184401976
[4]のソース
# ^ "Java and Numerical Computing" by Ronald F. Boisvert, Jose Moreira, Michael Philippsen and Roldan Pozo, NIST, Dec 2000
http://www.javagrande.org/leapforward/cacm-ron.pdf
0241デフォルトの名無しさん
2007/02/14(水) 02:39:280242デフォルトの名無しさん
2007/02/14(水) 02:41:55いやだから、>239 で引用されている内容は中々面白いとおもうが、
>238 は全然そうではない。それだけの話。
0243デフォルトの名無しさん
2007/02/14(水) 02:42:55×>238、 >239
○>228、 >229
0244デフォルトの名無しさん
2007/02/14(水) 03:13:08wikipediaが閉鎖の危機になったというニュースを聞きつけて
ニュー速に集まってそういう勘違いをする厨とは違うよ。
Wikipediaに使われているものはWikiだから即座に編集可能だから
ぱっと見ただけでは信用できないという話だけだね。
Wikipediaの仕組みは管理者がコントロールをしているので
だいたいわかってる。管理者にDQNなやつもいるみたいだけどさ。
日本語版Wikipediaは創始者が腐女子みたいな馬鹿女で感情的になりやすく人の話を
ろくに聞かないヤバイ奴だってってことも知ってる。
>>242
そりゃWikipediaにも載っていないことも書いているが。
Javaの歯車製造機械はC++が製造した歯車を動力の一部に動いているが
それがJavaを動かす上で特に問題だと言うことは無い、という意味に喩えればわかるかな？
住んでいる土地が違うだけだよ。
0245デフォルトの名無しさん
2007/02/14(水) 03:46:20>日本語版Wikipediaは創始者が腐女子みたいな馬鹿女で感情的になりやすく人の話を
>ろくに聞かないヤバイ奴だってってことも知ってる。
（・∀・）
なるほど、つまりそいつに追い出されたのか。m9（^Д^）ﾌﾟｷﾞｬー
0246デフォルトの名無しさん
2007/02/14(水) 03:49:59追い出されてないがw
だが、奴が日本版Wikipediaの印象を悪くしているのは確かだ。
0247デフォルトの名無しさん
2007/02/14(水) 06:06:370248デフォルトの名無しさん
2007/02/14(水) 06:15:20Strutsとか使ってる部分は、金融系のプログラムっていうのとは違うでしょうが。。
>>193
プロファイラってOptimizeitとかだね。
SoftReferenceを使うのは当然だけれども。
8way CPU とか何台も買ってくれるような顧客はなかなかいないし、
リアルタイム性を確保するのは結構大変だよ。
最近はJavaでもいけるかな、って案件も増えてきたけど。
いい方向に進んでいるとは思う。
0249デフォルトの名無しさん
2007/02/14(水) 07:32:27周辺に結論も書いてあるというのに
0250デフォルトの名無しさん
2007/02/14(水) 11:56:12> プロファイラってOptimizeitとかだね。
Java標準のでもいけるけど。
Eclipseのでもいけるし。
> SoftReferenceを使うのは当然だけれども。
> 8way CPU とか何台も買ってくれるような顧客はなかなかいないし、
プロファイラやSoftReferenceと8way CPUとは直接関係ないと思うんだけど。
> リアルタイム性を確保するのは結構大変だよ。
組み込みじゃないのにリアルタイムに拘ってどうするのだろう。
マルチスレッドじゃ不満？
0251デフォルトの名無しさん
2007/02/14(水) 12:39:100252デフォルトの名無しさん
2007/02/14(水) 13:42:56マニピュレータでも使うのか？
スレッドだけで解決できないのかね？
■ このスレッドは過去ログ倉庫に格納されています