Javaはもう死んだの？

**デフォルトの名無しさん** · 2018/04/29(日) 04:48:48.62

どうなのよ

**デフォルトの名無しさん** · 2019/07/31(水) 22:36:56.86

Javaだから遅いということはない
遅くなる書き方をしているから遅くなっているわけで
そんなに計算量が大きいアルゴリズムを動かしているわけでもあるまい

**デフォルトの名無しさん** · 2019/07/31(水) 23:23:37.19

初期のjavaはバイトコードを実行コードに変換するのにやたら時間かかったからな
起動がクッソ遅かった

**デフォルトの名無しさん** · 2019/08/01(木) 07:12:52.69

>>690
えー？　ガチ最近java始めました素人君？　すごく有名な話だよ。
だからオールJava製GUIアプリが全くないでしょ。

**デフォルトの名無しさん** · 2019/08/01(木) 07:26:50.19

M I N E C R A F T

**デフォルトの名無しさん** · 2019/08/01(木) 08:24:44.84

初期(1.2の頃か)のそれ自体がJavaで出来てるIDEが激重でこりゃGUI無理ですわとなったな。
後Oracleのインストーラ関連でダイアログが裏にいっちゃったのに気がつかなくて無駄に待ったことがよくあった

**デフォルトの名無しさん** · 2019/08/01(木) 10:33:16.21

EclipseやJetBrains系IDEは今もJavaで書かれてる

**デフォルトの名無しさん** · 2019/08/01(木) 11:23:15.29

うーん、もう少しJavaの仕組みを理解してからレスしたほうがいいよ。
今はライブラリ群がC/C++で書き直されてるから速度が出てるんだよ。
オールJava製はもう存在しないんだよ。

**デフォルトの名無しさん** · 2019/08/01(木) 11:42:08.03

Netbeans
サクサクやぞ

**デフォルトの名無しさん** · 2019/08/01(木) 17:27:03.42

>>695
ってオイオーイ！オールJavaで書けるかーい！
LWJGL使ってるでしょ

**デフォルトの名無しさん** · 2019/08/01(木) 17:27:18.58

700get

**デフォルトの名無しさん** · 2019/08/01(木) 18:25:41.33

そんなん言い出したらオールJavaなんて最初から存在しないじゃん

**デフォルトの名無しさん** · 2019/08/01(木) 19:00:57.62

そういやJavaチップなんてもんがあったな

**デフォルトの名無しさん** · 2019/08/01(木) 22:37:43.91

SwingやJavaFXで一から書いたアプリケーションが有れば立派な純正Javaアプリ
実際そんな事をするのは多方面から見て無駄なので学生以外誰も書かない

**デフォルトの名無しさん** · 2019/08/01(木) 22:43:52.02

Javaチップｗｗ有ったなそんなん
詳しく知らないんだけどあれまだ有るん？

**デフォルトの名無しさん** · 2019/08/01(木) 22:58:21.26

>>694
お前さん、何が目的でデタラメばらまいてるの？
JavaのGUIが遅かったことじゃなくてデスマのほうな

**デフォルトの名無しさん** · 2019/08/01(木) 23:10:53.20

デスマってなんか格好いいよね

**デフォルトの名無しさん** · 2019/08/02(金) 06:15:58.69

実際人が死ぬしな

**デフォルトの名無しさん** · 2019/08/02(金) 06:21:24.09

来年５Gだろ？組み込み系でJAVAより使い勝手のいいLot向け言語ってなにさ？

**デフォルトの名無しさん** · 2019/08/02(金) 06:23:45.03

そらもうbrainfu*kよ

**デフォルトの名無しさん** · 2019/08/03(土) 08:30:09.31

>>705
マジレスすると2013年ごろになくなった。

**デフォルトの名無しさん** · 2019/08/03(土) 23:21:53.96

LWJGLはつかいずれーな
まともなフレームワーク誰も作らない不思議

**デフォルトの名無しさん** · 2019/08/04(日) 00:49:33.17

>>706
Javaブームの頃は、ほぼJava案件=デスマーチ。大手SIerはみんな騙された。
MSが訴えられて、爆速MS製JVMがWindowsから削除されて、死ぬほど糞遅いSun製JVMしか使えなくなった。
そんなこともすら知らないとかキミはまだ生まれてないんじゃないの？w　ゆとりでしょw

今度はgoogle訴えてgoogleもjava排除中だし。

**デフォルトの名無しさん** · 2019/08/04(日) 01:15:58.19

>>713
Java案件デスマがあったことなんか疑ってないわ。逃げるなよ。

ソース出してみな。
「Javaが遅いからデスマになった」のな

**デフォルトの名無しさん** · 2019/08/04(日) 01:16:20.17

でもライセンスフリーは魔法の言葉だったな
遅いSUM製JVMでも新規案件が山ほど有った
大手メガバンクもCOBOL捨ててJavaに移行した
ほとんどのメガバンクが移行してからOracleはライセンスフリーを捨てた
ライセンスフリーで使い続けるにはいつどうなるか分からないサードパーティーJDK使え、となった
サードパーティーJDK使うのは中小企業だけ

**デフォルトの名無しさん** · 2019/08/04(日) 01:17:05.42

>>715
SUN製ね、訂正

**デフォルトの名無しさん** · 2019/08/04(日) 01:36:01.22

>>714
無職にもほどがあるぞ。ここでいちいち個別に案件の名前なんか出せるわけないだろ。
IBMでもNTTデータでもhpでもNECでも日立でも富士通でも大手SIerに一人もSEの知り合いすらおらんのか、無職め。

**デフォルトの名無しさん** · 2019/08/04(日) 01:44:29.66

具体案件名なんて要らん
常識ならあなたじゃない他者の言及がどっかにある筈でしょ

**デフォルトの名無しさん** · 2019/08/04(日) 01:54:47.43

>>718
リアル低学歴か。自分で何一つウラも取らずになに捏造認定してんだ？
ここでそのてめぇちぃせえマスかいてる暇があったら当時のスペックのサーバ調達して
SUNのJVMインストールして解析なり逆アセすりゃ済む話じゃねーのか、チンカス君。

大先輩が経験したことを語ってやってんのに何も調べもせずになにが捏造だよ？　てめーは何様だ。
ネットに有り触れてる高速化テクニックはおれたちが解析した結果なんだよ、能無しゆとり君。

**デフォルトの名無しさん** · 2019/08/04(日) 02:02:04.01

喧嘩ならよそでやれよ。
JavaにだまされSiにだまされ人生棒に振ったｵｼﾞｻﾝ達

**デフォルトの名無しさん** · 2019/08/04(日) 02:40:29.33

ますます低能だったんだなあと確信に至る

**デフォルトの名無しさん** · 2019/08/04(日) 02:45:35.08

大先輩は人生苦労してそう

**デフォルトの名無しさん** · 2019/08/04(日) 04:37:33.82

COBOLから移行しただけでも功績でしょー

**デフォルトの名無しさん** · 2019/08/04(日) 05:11:32.88

引き継ぎの際に
「自分はJavaをよく分かってないまま作ってしまった。まじスマンかったm(_ _)m」
って言われたことあった。
元々家電用だったのにね

**デフォルトの名無しさん** · 2019/08/04(日) 15:03:00.19

>>719
そこまで丁寧に謝ってくるなら許してやるよｗ

**デフォルトの名無しさん** · 2019/08/04(日) 15:04:18.70

>>725
どの辺が誤ってんの？

**デフォルトの名無しさん** · 2019/08/04(日) 21:30:34.39

COBOLからの移行だと、たとえば、どんなところが、デスマ要因なんですか？
画面系？
バッチ系？

**デフォルトの名無しさん** · 2019/08/04(日) 21:38:15.89

COBOLはphpでいうとrequireでいろんなファイルを読み込みまくるだけで読み込み元が推測でしかわからないから全部知らないと更新できない
だから一部分だけを直すために非常に努力が必要ですぐデスマ化するらしい

**デフォルトの名無しさん** · 2019/08/04(日) 21:44:15.18

答えになってませんね
すみません

**デフォルトの名無しさん** · 2019/08/04(日) 21:54:09.57

>>728
phpが出てくるということは、webアプリなんですか？

**デフォルトの名無しさん** · 2019/08/04(日) 22:09:57.05

京都市はバッチの移行でトラブってたような
COBOLはメインフレームのOSと密結合で性能出してそうだから
汎用OSに載せ替えるってだけでも大変そう怖いわー

**デフォルトの名無しさん** · 2019/08/04(日) 22:11:15.64

先に書いたことはCOBOLの開発の難しさを聞かれたと読み間違えました
通信をしてATMで操作する部分はかなりWEB的になってきたと聞いたことがあります
javaへの書き換えだけなら簡単らしいとも聞いたことがあります
難所と思われたOOPにするところも予想よりもうまくいったらしいです

**デフォルトの名無しさん** · 2019/08/04(日) 22:24:38.44

>>731
レガシーだと、固定長ファイルの読み出しと、書き出しだから、JAVAだと、面倒くさいかな？

**デフォルトの名無しさん** · 2019/08/04(日) 23:14:53.67

よっぽど太古のシステムじゃない限りストレージはRDBになってて
固定長に見えるところは単なるスタブだからあんまり関係ないんじゃないかな
帳票なんかは工数かかるだろうな

**デフォルトの名無しさん** · 2019/08/04(日) 23:27:57.02

opencobolに変えるだけでもこえーわな。。

**デフォルトの名無しさん** · 2019/08/05(月) 00:22:56.78

>>731
京都市の件は現行COBOL仕様が不明確のまま、移行しようとしたから
それでテスト工数が京都市が許容した容量超えて金かかる、となったから裁判になった

**デフォルトの名無しさん** · 2019/08/05(月) 00:25:29.08

>>732
COBOL→Javaと言ってもオブジェクト指向なんて使ってないから

**デフォルトの名無しさん** · 2019/08/05(月) 00:29:20.35

>>733,734,735
プログラムから直接SQL発行する仕組みなんてしなければ、見た目固定長ファイルの様に扱う事は出来ると思う
帳票はPDF化前提だと面倒だろうね
OpenCOBOLでも基本的なCOBOL言語仕様はほぼ同じ
問題は現行システム仕様がドキュメントとして残ってるか、でしょう

**デフォルトの名無しさん** · 2019/08/05(月) 01:00:27.02

>>727
COBOLというか昔の汎用機はモノから仕様が読み取れない。

COBOLをJavaに置き換えるという発想が間違っている。COBOLの代替はリレーショナルデータベース。

Javaはデータ中心アプローチと相性が悪い。

**デフォルトの名無しさん** · 2019/08/05(月) 01:07:51.71

>>739
そういう事
COBOLをJavaに置き換えると言う発想そのものが間違い

**デフォルトの名無しさん** · 2019/08/05(月) 01:42:01.66

COBOLはCOBOLだけでシステムが作れてしまう奇跡の言語だった。

汎用機が高性能だったためにできた芸当。

日本でも業務システムのオープン化は、Oracle化でオラクル社製品で置き換えていた。

オラクル社自体がJavaを初めのころから推していたから、COBOLはJavaに置き換えるという誤った認識が広まった。

オラクル社がJavaアプレットでフロントエンドを作り、Oracleがバックエンドを担当した。ユーザーに見えている部分がJavaだったから、システムがJavaでできていると思うのは自然の流れだったな。

**デフォルトの名無しさん** · 2019/08/05(月) 21:43:29.86

COBOLの代替がRDBってどういうこっちゃ
RDBなら汎用機+COBOLでも使ってたでしょ
SQLって言いたいのかな？

**デフォルトの名無しさん** · 2019/08/05(月) 23:28:08.65

恐らくSQL(PL/SQL)
全てPL/SQLでカバー出来るとは思わんけど、ある程度は可能
ゆえにOracle導入したらCOBOLをPL/SQL+ProCOBOLへ移行する方が妥当だったと思う
それをOracleの売り文句に騙されてJavaに移行したのが運のツキ

**デフォルトの名無しさん** · 2019/08/05(月) 23:39:55.73

PL/SQLってエントリー・照会・帳票印刷みたいなアプリ作れるんだっけ？

**デフォルトの名無しさん** · 2019/08/05(月) 23:56:48.81

どういう売り文句をしたらPL/SQLとJavaを
間違える羽目になるんだ？

**デフォルトの名無しさん** · 2019/08/06(火) 00:08:11.56

OracleはOracle Databaseだけで何でもできる。言語としてはほとんどPL/SQL。WebアプリケーションもOracleだけでできる。Application ExpressはロジックにPL/SQLを使う。昔はOracle FromsやOracle ReportsがJavaアプレットだったが、専用Javaアプレットを生成する言語はPL/SQL。

**デフォルトの名無しさん** · 2019/08/06(火) 00:15:28.83

>>745
オラクル社は1990年代からサン・マイクロシステムズのJavaに深く入りこんでいて、協力・補完関係だった。

Javaの最大の理解者、利用者がオラクル社で、Oracle製品群だった。

日本では国(IPA)がなぜかストアドプロシージャ等のRDBMSの機能を無視する(理解できていない？)ので、Javaとリレーショナルデータベースを切り離したがる。

欧米ではSQLインジェクション対策にストアドプロシージャの利用をあげるが、日本のIPAはそこをなぜか削っている。

**デフォルトの名無しさん** · 2019/08/06(火) 00:22:07.08

確かにOracleがJava推しだったのはJavaデスマーチ大量発生の背景にあるかもね
90年代後半～2000年代前半にこれからはJavaだ！EJBだ！みたいな流れになって
Javaなんてよく知らんようなSIerもこぞって参戦して死屍累々

**デフォルトの名無しさん** · 2019/08/06(火) 01:08:44.88

あれだけ世界的なJavaブームがありながらなぜサーバサイドしか残らなかったのか。

速度的に数キロバイトのhtmlテキスト吐く程度でやっとだったから。

PenII 200MHzで走らせてるのに体感的に1MHzの6502より遅い。AppleII以下の性能。

**デフォルトの名無しさん** · 2019/08/06(火) 01:47:16.45

>>749
それは的外れだな。昔のWindows上で仮想マシンを動かして、プログラムは中間コードだから、仮想マシンの起動するのに時間がかかり、マシン語でもないコードを実行しているのだから仕方ない。

いまでもマイクロソフトがプログラムを実行形式ファイルにしたがるのは、Windowsの評価が下がらないように気を使っているから。

実行ファイルにするとそのPCに最適なマシン語を用意できないから、.NET Frameworkで作ったものは、マシン語にコンパイルされたJavaコードよりも遅いことがある。

JavaもリレーショナルデータベースもPCの性能、ネットワークの速度が足らない状況で、理想を求めて時代を先走ったせいでコンピュータに疎い人間から叩かれた。

**デフォルトの名無しさん** · 2019/08/06(火) 01:55:05.34

あのsql文法が理想なのかと・・・

**デフォルトの名無しさん** · 2019/08/06(火) 01:58:39.86

今のPCならJVMは問題無く動く
まあ、昔は遅かったよ
ゆえにライセンスフリー以外でJava使う以外にはメリット無かったな
メインフレームデータベースをRDB(Oracle)に移行する作業でHI-UX(日立UNIX)でProCOBOLでプログラム作って盛大にバッチ処理してRDB更新してたな
当時はJavaなんか遅くて使えんかったわ
で、クライアントPCからはEXCELとAccessで画面作ってVBAで表示

COBOL→Javaってどういう理由で持て囃されたのか全く分からんかったな
JVMが早く動かせる様になってもProCOBOLにコンバートするのが効率良かったハズなのにね

**デフォルトの名無しさん** · 2019/08/06(火) 03:09:48.79

>>751
SQLの構文の元はIBMが考えたもので、オラクル社が発案したものではない。

オラクル社はビジネス優先なので、新しい言語をいちから作ったりしない。

SQLはIBM案から拝借、PL/SQLはAda言語から拝借した。

ちゃんと当時の時流にのっていて、オラクル社の選択眼は優秀。マイクロソフトはこの逆で選択眼がなく、独自に作り出して自ら首をしめる文化がある。マイクロソフトもビル・ゲイツを知っている世代がいなくなって、ようやくまともになってきた。

**デフォルトの名無しさん** · 2019/08/06(火) 09:48:33.00

>>753
>マイクロソフトもビル・ゲイツを知っている世代がいなくなって、ようやくまと>もになってきた。

というか、ナデラになってから高度技術の会社から Apple みたいな一般向け
の会社になった感じがする。

**デフォルトの名無しさん** · 2019/08/06(火) 11:34:34.73

？

**デフォルトの名無しさん** · 2019/08/06(火) 11:35:19.19

アップルとマイクロソフトでは比較にならない

◆QZaw55cn4c · 2019/08/06(火) 20:59:04.82

ということは、Java で書いてネイティヴを吐ければ万時OKなんでしすね！これは商機？

**デフォルトの名無しさん** · 2019/08/06(火) 21:29:03.82

>>749
JITコンパイラ最適化でCより速いとか持て囃されてたの知らんのか

**デフォルトの名無しさん** · 2019/08/06(火) 21:38:41.16

世界的にはJavaStoreがあるじゃないの？

**デフォルトの名無しさん** · 2019/08/06(火) 21:39:58.32

>>758
まあ色々怪しい条件でだけどね

**デフォルトの名無しさん** · 2019/08/06(火) 22:22:03.24

>>757
ずっと前からそうだよ。

**デフォルトの名無しさん** · 2019/08/06(火) 22:28:24.61

C言語が速いというのはいまでも希に聞くが、C言語が速いのではなくて、マシン語だから速いんだけどなw

CやC++で作ってしまうとむしろ遅いコードを作ってしまいかねない。ハードウェア、特にCPUは常人では理解できない世界になっているから、コンパイラが優秀、そのコンパイラがそのアーキテクチャを知り尽くしているかがカギ。

**デフォルトの名無しさん** · 2019/08/06(火) 22:31:23.42

JavaのVMはハードウェア、OSを作っている会社が作っている場合は最適化されるので、問題も起こりにくい。

**デフォルトの名無しさん** · 2019/08/06(火) 22:31:29.61

>>762
前半と後半が矛盾している

**デフォルトの名無しさん** · 2019/08/06(火) 22:39:23.01

配列のレンジチェックいちいちしないから早いんじゃないの？

**デフォルトの名無しさん** · 2019/08/06(火) 22:53:40.60

>>758
Javaブームの頃、JDKにまだJITコンパイラは入ってないぞw

**デフォルトの名無しさん** · 2019/08/06(火) 23:01:33.47

>>766
お前デタラメばっかり言って何がしたいんだよ
荒らしてるだけならNGすっぞ

**デフォルトの名無しさん** · 2019/08/06(火) 23:06:34.64

Ruby では、

JRuby(Java 実装系)のJIT は、百万回からコンパイルされる。
一千万回(実行時間で、1秒)では、なんと、MRI(C 実装系)よりも速くなる！

このように最適化では、Java は数十年も研究してるから、C よりも速くなる！

**デフォルトの名無しさん** · 2019/08/06(火) 23:11:32.43

>>767
wikipに書いてることはデタラメなのか。さすがJava信者。オカルトですw

しかもCより速いとか言ってる時点でIT音痴を露呈しているw

**デフォルトの名無しさん** · 2019/08/06(火) 23:18:00.63

>>768
jrubyってjava byte codeにJITコンパイルしてたりするんじゃね
c版もJITしないと不公平だろ

**デフォルトの名無しさん** · 2019/08/07(水) 00:04:28.53

>>769
お前、この前からデタラメ書いてる荒らしだろ
もう相手すんのやめるわ
勝手に勝利宣言してくれ

**デフォルトの名無しさん** · 2019/08/07(水) 00:42:19.23

JITコンパイラはJavaの思想に反している。
ネイティブ変換は既にVM上で走ってないし、Write once, run anywhere じゃなくなる。

つまり偽Java。

**デフォルトの名無しさん** · 2019/08/07(水) 01:03:25.80

>>769
wikipediaになんて書いてあんの？

J2SE 1.3 (2000年5月8日)
HotSpot Java仮想マシンが導入

**デフォルトの名無しさん** · 2019/08/07(水) 01:24:55.84

Sunが訴訟しまくったことにより、2000年には世界的に既にJavaブームは終わっており、
IT音痴の日本だけはなぜかこれからはJavaだ、Javaだと言ってる状況だった。

2000年頃にはPen4、2GHzにもなりCPUの速度は10倍以上速くなっている。
これでもまだJavaを走らすには遅すぎた。後のCoreアーキまで待たねばならなかった。

**デフォルトの名無しさん** · 2019/08/07(水) 01:29:12.70

キチガイのデタラメ続くな

**デフォルトの名無しさん** · 2019/08/07(水) 03:21:51.02

ハードの進化がJVMの欠点を隠した、と言う事
2005ぐらいまではJavaアプレットでお絵かきして遊んでたぐらいだった
ここ数年でJavaへ移行する大型プロジェクトが多かったが、一段落ついたらライセンス化された
無料で新規にプロジェクト組むのは色々有って増える事は無い
減るだけだろう

**デフォルトの名無しさん** · 2019/08/07(水) 03:39:24.56

みずほ銀行が合併3行の内紛でCOBOLからJavaへ移行がぐちゃぐちゃになって何とかシステム移行出来たのが、つい最近
と、同時にリストラ発表で人員削減
Javaになったシステムは稼働ライセンス契約が開始
そのみずほ銀行から天下りした社長の7Payはプログラムソース漏洩で個人情報漏洩発覚
安易に時流に乗って必要な分析怠ると色々事件発生するこの業界
おまけにみずほは韓国へ資金援助しており回収不能、今後も投資するとか言ってる
サグラダファミリアみたいなシステム作って無駄になる可能性出て来た

**デフォルトの名無しさん** · 2019/08/07(水) 07:25:21.69

>>765
C/C++コードが Java や C# より速いのは、配列のレンジチェックだけでなく、
GC を使ってないことがかなり大きい。

**デフォルトの名無しさん** · 2019/08/07(水) 07:32:40.22

>>778
もう一つは、ヒープを使わなくて済む場合には、(native)スタックや
構造体に直にオブジェクトや配列などを埋め込むから。
Javaなどは、一般オブジェクトや配列は new Txxx などのように
必ずヒープから確保するのでここにかなりのオーバーヘッドが発生する。

また、N 個のデータがある場合、C++で1回 delete すると、O(1)で済むが、
Java/C# で、参照型変数 = null; などとした場合には、最悪、O(N)位かかってしまう
事があるらしい。それは、GC が N 個のデータを全て walk してしまうことが
あるから。

だから、データの量が増えた場合でも C++ は速度低下が余り起きずに安定して速いのに
対し、Java/C# ではどんどん遅くなる場合がある。それは GC があるから。

>>757
上記の事があるので、Java/C# は、native binary に直しても速くならない。
なぜなら、O(1)とO(N)の違いは「速度のオーダーの違い」で、いくらバックエンドの
コードやCPU自体を高速化しても埋まらないから。

**デフォルトの名無しさん** · 2019/08/07(水) 07:43:20.47

>>779
O(x)という記号の意味を大体書いておくと、
O(1) = データ量Nが大きくなっても処理時間に変化が起きない。
O(N) = データ量Nが大きくなると、処理時間がNに比例して大きくなっていく。

もう少し厳密に書くと、delete pXxx や rXxx = null にかかる処理時間を f(N) と表した時、

O(1) : lim_{N->∞) ( f(N) ) < 一定値
O(N) : lim_{N->∞) ( f(N) / N ) < 一定値

ということです。これらは数学の解析学や微分積分学のランダウの記号といいます。

**デフォルトの名無しさん** · 2019/08/07(水) 09:14:38.12

モダンC++対マネｰジコｰド:パフォｰマンス対生産性
https://www.infoq.com/jp/news/2012/04/native_vs_jit/

まず､JITコンパイルは主要な問題ではありません｡根本原因はずっと基本的なことです｡マネｰジ言語は基本的にパフォｰマンス効率がぎりぎりの時でさえも､それを犠牲にして､プログラマｰの生産性を最適化するよう､意図的に設計上のトレｰドオフを行なっています｡

マネｰジ言語の設計者は､設計のためにパフォｰマンスよりも安全性の道を選びました｡例えば､配列の境界外の要素にアクセスするのは､無効な操作であり､プログラムの実行を終了させます｡クラッシュしたり､攻撃可能なセキュリティホｰルを作ることがないようにしています｡

2つ目に､たとえJITが唯一の大きな問題であったとしても､JITは普通に最適化するコンパイラｰ程良くなることはありません｡なぜならJITコンパイラｰには､速いことが重要であり､最適化したコｰドの生成を気にしていないからです｡

｢予防｣と｢治療｣にはいつも避けがたい､基本的な差があります｡パフォｰマンスの最適化となると､C++はいつも｢予防｣を選び､これまで述べた英雄的な努力とそれ以上によって､マネｰジ言語は｢治療｣を選びます｡
しかし､古くから諺である予防はいかなる治療にも勝るは､絶対です｡予防には勝てません(その理由の1つは､最初に予防した後に治療ができるからです｡しかし逆はできません)｡
もしパフォｰマンスとコントロｰルを一番大事にするなら､それを一番優先するように設計されている言語を使うべきです｡それだけです｡

**デフォルトの名無しさん** · 2019/08/07(水) 10:09:26.43

>>780
自己レス。厳密に言うと、記号に微妙な誤りがあって、N個のデータがあった時、
・C++ の delete pXxx の一回当たりの平均速度を f(N)
・Java/C# の rXxx = null; の一回当たりの平均速度を g(N)
とすると、O(1)、O(N)はなく、
f(N)～1 // 常に
g(N)～N // 最悪ケース
と書いたほうが良かった。

g(N)=O(N) と g(N)～N は、意味が違っていて、前者は、N が十分大きい場合に、
実行時間が最悪でも N に比例。後者は、実行時間が N が十分大きい場合に N に比例。
言い方を帰れば、=O(N)という記号は、(Nが大きい場合の)上限値、
～Nという記号は、Nが大きい場合の漸近値を表す。

**デフォルトの名無しさん** · 2019/08/07(水) 10:10:18.74

>>782
誤：とすると、O(1)、O(N)はなく、
正：とすると、O(1)、O(N)ではなく、

**デフォルトの名無しさん** · 2019/08/07(水) 10:18:39.48

>>780
したがって、こう書けます：
g(N)～1 = データ量Nが大きくなっても処理時間に変化が起きない。
g(N)～N = データ量Nが大きくなると、処理時間がNに比例して大きくなっていく。

**デフォルトの名無しさん** · 2019/08/07(水) 17:53:59.16

swing使ってる人って少ないんでしょうかね。
ラベルとかボタンの日本語フォントが汚すぎて泣きたい。

**デフォルトの名無しさん** · 2019/08/07(水) 17:55:00.63

>>785
以前、使ってたよ。

**デフォルトの名無しさん** · 2019/08/07(水) 18:45:40.88

Swingなんてまだ使ってる所有るんだなw
あのUIは個人的には凄い嫌だわw

**デフォルトの名無しさん** · 2019/08/07(水) 20:42:35.75

>>782
配列をソートするとき。中身がオブジェクトの場合、実際にメモリ交換が起きるのは、参照アドレスだけになるんですか？
C++の場合は、意識して、クラスの参照アドレスを配列にいれないと中身が移動するので遅くなるはず。

また、リスト、マップ、ベクター（C++では、STL）では、どうなんでしょうか？

**デフォルトの名無しさん** · 2019/08/07(水) 20:47:07.34

>>788
そういう場合普通indexだけソートしない？

**デフォルトの名無しさん** · 2019/08/07(水) 22:34:26.29

>>772
その現在では否定されているフレーズを使うのはJava信者の特徴

**デフォルトの名無しさん** · 2019/08/07(水) 23:10:43.71

>>788
Javaの場合は、原則的には実態ではなく参照だけの入れ替え(交換)になる。
実体の入れ替えは、同じメンバ同士の値を交換することによって
行えなくは無い。しかし、その場合でも Object 系のメンバについては
参照だけの交換が基本。ただし、実は Shallow Copy と Deep Copy の
違いなるものがあって、深く交換することも可能は可能。
今言ったメンバ同士の交換を、Object系のメンバについても「再帰的に」
繰り返せば、Deep Copy（今の場合は交換だけど）といって深い複製や
交換も可能は可能。