トップページ > プログラム > 2014年10月20日 > 4QGk34Ml

書き込み順位&時間帯一覧

12 位/186 ID中時間01234567891011121314151617181920212223Total
書き込み数0000000000003000000100004



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん
Git 10
Rubyの設計上の欠点とは何か?
mallocの後にfree不要と言うバカいるの?Part2
GCは失敗。メモリは自分で管理せよ!

書き込みレス一覧

Git 10
780 :デフォルトの名無しさん[sage]:2014/10/20(月) 12:12:25.60 ID:4QGk34Ml
ジャンプなんか400ページ超えてて
300円しないというのに。
Rubyの設計上の欠点とは何か?
77 :デフォルトの名無しさん[sage]:2014/10/20(月) 12:44:15.82 ID:4QGk34Ml
>>76
スレ違いだけど、クイックアクセスツールバーに
戻るを追加すれば見れるように鳴るよ。
mallocの後にfree不要と言うバカいるの?Part2
526 :デフォルトの名無しさん[sage]:2014/10/20(月) 12:45:42.29 ID:4QGk34Ml
たぶんメモリリークしてもプロセス終了時に
全部解放されるんだから大丈夫だと思ってるんじゃない?
GCは失敗。メモリは自分で管理せよ!
313 :デフォルトの名無しさん[sage]:2014/10/20(月) 19:43:44.01 ID:4QGk34Ml
>>309-310
だから、"閉じる"処理とオブジェクト削除処理は
分けて考えないとダメなんだよ。

閉じるにかからわず、処理ってのはエラーを返すことがある。
そのエラーに対応するためにC++であってもデストラクタは使えない。

オブジェクト削除処理はエラーにならない。もう使わないとされたものを
削除するだけだからね。

オブジェクト削除時(つまりC++のデストラクタやファイナライズ)で閉じる処理を
するのは構わないし、その処理に依存しても構わないんだが、
それは、オブジェクト削除時のエラーを無視してもいい時だけ。

閉じる処理のエラーやその他、ユーザーへのレスポンスが必要なときは
明示的に閉じるを行うのが常識。

オブジェクトっていうのは閉じている(リソースは解放されている)が
インスタンスは生きているという状態を持たないといけないんだよ。


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。