- GCは失敗。メモリは自分で管理せよ！
356 ：デフォルトの名無しさん[]：2014/10/22(水) 00:52:57.74 ID:OtEE3/Y/ - 右辺値参照があればGCの必要が無くなる。
|
- GCは失敗。メモリは自分で管理せよ！
358 ：デフォルトの名無しさん[]：2014/10/22(水) 00:59:41.65 ID:OtEE3/Y/ - >>357
Javaには有りません。
|
- GCは失敗。メモリは自分で管理せよ！
360 ：デフォルトの名無しさん[]：2014/10/22(水) 01:03:20.78 ID:OtEE3/Y/ - >>359
作れば有ると言いたいのかもしれませんが、作ってもありません。
勉強しましょう。
|
- GCは失敗。メモリは自分で管理せよ！
363 ：デフォルトの名無しさん[]：2014/10/22(水) 01:13:51.01 ID:OtEE3/Y/ - >>361
OOPは実はスコープが非常に重要だったってことですかね。
寿命のハッキリしないオブジェクトは実はとても邪悪なものだったのです。
これは実際に使ってみるまで判りませんでした。
GCはとても良いもののように思えるかもしれませんが、実は本質的に間違ったもの、
邪悪なものです。
C#は、構造体とクラスが有るので、もしかすると右辺値参照を取り入れることが
出来るのかもしれません。
Javaは絶望的です。
おそらく、右辺値参照の概念が広まるとともに、GCがJavaの欠点と知られるように
なるでしょう。
使ってみるとわかる種類の問題です。
|
- GCは失敗。メモリは自分で管理せよ！
367 ：デフォルトの名無しさん[]：2014/10/22(水) 01:36:44.78 ID:OtEE3/Y/ - これは在る種のパラダイムシフトを引き起こすかもしれません。
設計のマナーが変わると思います。
「Javaを使うやつは設計ができない」と言われる日が来るかもしれません。
Javaを使っていたというと「is a」「has a」と言われるようになるかもしれません。
OOPの基本中の基本だったはずのことが、なぜかできていなかったのです。
自分でも驚きです。
相互参照のほとんどすべては、設計上引き起こされるのではなく、パフォーマンス上
起きていたのです。
本当に驚きです。
もちろん、すべての事象がOOPで片付くわけではありません。
しかし、適用範囲は意外と広く、基本に忠実に設計できるのです。
そう、右辺値参照が有れば。
|
- GCは失敗。メモリは自分で管理せよ！
370 ：デフォルトの名無しさん[]：2014/10/22(水) 01:55:08.30 ID:OtEE3/Y/ - 右辺値参照は目から鱗でした。
|
- GCは失敗。メモリは自分で管理せよ！
384 ：デフォルトの名無しさん[]：2014/10/22(水) 22:53:08.64 ID:OtEE3/Y/ - 一太郎Arkが実行できなかった時、すべてを悟った。
|
- VBScriptについて必死に話し合うスレ
837 ：デフォルトの名無しさん[]：2014/10/22(水) 23:04:12.24 ID:OtEE3/Y/ - Tcl/Tkを思い出せば、なるほどVBSが使われるのも当然。
|