- GCは失敗。メモリは自分で管理せよ！
47 ：デフォルトの名無しさん[sage]：2014/10/12(日) 12:16:18.39 ID:K67PydJN - リソース掴むオブジェクトを扱う場面での
auto_ptr/unique_ptrと同じことをするのに
javaのtry with resourcesや
c#のusing,dのscope
どれも笑えるほど間抜けで間違いやすく
リソース掴むかどうかプログラマが
知っている必要があるとか
色々破綻しすぎ
|
- 【初心者歓迎】C/C++室 Ver.93【環境依存OK】
36 ：デフォルトの名無しさん[sage]：2014/10/12(日) 16:31:02.60 ID:K67PydJN - >>33
これが一番一般的で実際見やすくね？
変なところで切られたら
構造が把握しにくい。
何処かの条件に入ったら
それ以降の条件を見ないのが
if else if ...なのに
|
- 【初心者歓迎】C/C++室 Ver.93【環境依存OK】
41 ：デフォルトの名無しさん[sage]：2014/10/12(日) 17:02:37.95 ID:K67PydJN - なんで？
|
- 【初心者歓迎】C/C++室 Ver.93【環境依存OK】
42 ：デフォルトの名無しさん[sage]：2014/10/12(日) 17:09:37.61 ID:K67PydJN - lispのcondみたいに書ける構文があれば
良いのだけど。
|
- 【初心者歓迎】C/C++室 Ver.93【環境依存OK】
44 ：デフォルトの名無しさん[sage]：2014/10/12(日) 17:45:14.00 ID:K67PydJN - switchの制約が強すぎるんだよ。
本来単純なブロック構造で
switchとにたようなロジックを
if else if ...で書かせるから
無駄にわかりづらくなる。
|
- GCは失敗。メモリは自分で管理せよ！
80 ：デフォルトの名無しさん[sage]：2014/10/12(日) 21:45:20.46 ID:K67PydJN - 今時c++でdeleteを昔の意味で使う人間は
忘れるとかそれ以前の問題で
終わっているような。
|
- GCは失敗。メモリは自分で管理せよ！
82 ：デフォルトの名無しさん[sage]：2014/10/12(日) 22:01:17.22 ID:K67PydJN - c++でdelete freeでプログラム書けるし
全く同じやり方で、他のリソースの
解放も勝手にやってくれるようになる。
怖いのは循環参照だけ。
この場合GC言語だとメモリのリークは防げても、循環参照しているオブジェクトに
保持されているリソースの解放タイミングは
全く保証されない。
で、それの対策も考えたら結局
c++で弱参照、単なるポインタなど
駆使するのが一番効率的
|
- GCは失敗。メモリは自分で管理せよ！
89 ：デフォルトの名無しさん[sage]：2014/10/12(日) 23:19:48.88 ID:K67PydJN - >>87
いやまあ言いたいことは同じなんだけど。
ヒープみたいに、lazyに解放すればいい
リソースなんて少数派な位なのに
ヒープだけを特別扱いしてリークしづらく
しているのがGCで、逆に他のリソースの
解放に関しては糞の役にも立たない。
頑張って使いやすくしても
try with resourcesみたいなのが精々
|