[過去ログ] GCは失敗。メモリは自分で管理せよ! その2©2ch.net (720レス)
前次1-
抽出解除 レス栞

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
18: デフォルトの名無しさん [] 2015/11/21(土) 19:18:42.53 ID:iOucF00Z(2/2) AAS
>>16
16(1): デフォルトの名無しさん [sage] 2015/11/21(土) 17:40:45.99 ID:7nxNhgSu(2/2) AAS
横文字じゃなくてマイクロソフトの用語なんだが?
涙ふけよwwww
82
(1): デフォルトの名無しさん [sage] 2015/11/28(土) 20:16:46.53 ID:Fi4wDTmy(2/2) AAS
勝手にnullを代入するとか、そんな変なコンパイラは困る
156: デフォルトの名無しさん [sage] 2015/12/04(金) 23:45:19.53 ID:j6MEWqDN(1) AAS
>>154
154(2): デフォルトの名無しさん [] 2015/12/04(金) 20:05:33.81 ID:SAJ9n/s7(1) AAS
>>137これって何が言いたいの?OSやライブラリ自体にミスがあるって言いたいの?
wikiより
>メモリリーク (Memory leak) とは、プログラミングにおけるバグの一種。
>プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。
>プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。

>>137みたいなこと言う奴って、電磁波からデータが盗まれる!対応しないと!とか言い出すタイプ?
開放コードを忘れずに書いたのに開放されないという怪奇現象がマルチスレッド状況ではしばしばあるんじゃー!
マルチコア時代になってこれはますます危険になった
見ただけで正しさがわかる系のスレッド安全策はクロックサイクルを糞のごとく消費するし…

こういうのは専門家が徹底的にデバッグしたGCで面倒を見て欲しいと思う反面、
やっぱプロセス全体のごみ処理を選任モジュールにやらせるのはクロックサイクルをドブに捨てるがごとき
センス無い設計なキモス、、
214: デフォルトの名無しさん [] 2015/12/06(日) 19:31:56.53 ID:bkfT5adp(1) AAS
>>213
213(1): デフォルトの名無しさん [] 2015/12/06(日) 19:25:02.74 ID:XJADMoL5(2/2) AAS
今日一日なんでFormがGCされないのか調べてて大変な思いしたわ
よくそこまで調べたな。( ・∀・)つ旦 お茶ドゾー
234
(1): デフォルトの名無しさん [] 2015/12/07(月) 20:05:22.53 ID:W4QZalq7(1) AAS
メモリ意識した時点で雑魚プログラマ決定だろ。
JavaScriptもPascalも使えないんじゃ話にならないよ。
おちんぽ見られることを意識しすぎて温泉に入れないようなもの。
癒やしのない人生に刺激なんてない。←これ名言
263
(1): デフォルトの名無しさん [] 2015/12/12(土) 10:36:13.53 ID:mXWFWn5f(1) AAS
freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなw
freeしきれないとかwwww
269: 名無しさん@そうだ選挙に行こう [] 2015/12/14(月) 08:16:09.53 ID:hn3965Zz(1/4) AAS
>>264
264(1): デフォルトの名無しさん [] 2015/12/12(土) 11:52:29.69 ID:v/VbuB+R(1) AAS
>>263
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。
いや、下手って一言で片付けられるよ。
よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り
327: デフォルトの名無しさん [sage] 2015/12/20(日) 19:44:06.53 ID:9YX+2XWA(1) AAS
>>323
323(1): デフォルトの名無しさん [sage] 2015/12/20(日) 17:21:31.86 ID:ZDEpjFBd(2/3) AAS
なんか参照カウントの話とマルチスレッドの話がごっちゃになってね?
(Rust信者で)すまんな。
外部リンク:smallcultfollowing.com
マルチスレッドで起きるデータ競合といった問題も、シングルスレッドで起きうるdangling pointerなどの問題も、
どっちも所有権を持つオブジェクトが無闇にいたり、変な参照関係があるから起きるんじゃないか?って言う人がおる。
根っこが同じ、あるいは近しい問題なんで、横滑りに見えても堪忍な。
368: デフォルトの名無しさん [sage] 2016/01/27(水) 18:56:08.53 ID:VDkVQpP+(1) AAS
最近VB.NETを使い始めたんだけど
new したオブジェクトが不要になった時にDispose()よんだり参照にNothing代入する必要ってない(やってもいいが無意味・無駄)なのかな?
493
(1): デフォルトの名無しさん [sage] 2016/04/20(水) 13:09:41.53 ID:DLw9rf+F(1) AAS
>>486
486(1): デフォルトの名無しさん [sage] 2016/04/18(月) 21:49:39.41 ID:9yQABY6F(3/3) AAS
>>482
GTAみたいなゲーム考えてみ?
あれ全てオブジェクトの寿命を事前に決められると思う?
原理的には不可能じゃないだろうがそんな職人的な作りしてたら開発に10年かかるわw
ああいうFPSのオブジェクトは全部管理されてるし
gcなんか使ってないよ
532: デフォルトの名無しさん [] 2016/04/24(日) 14:59:36.53 ID:ynYywbEh(3/8) AAS
俺が作ったのはウェブソケットによってサービスを提供するプログラムだ。
エンジンエックスをリバースプロキシとした。
このプログラムは常時数千の接続から大量のリクエストを受け付ける。
接続してくるクライアントは専用に作られQtで書かれている。
大量のリクエストはそれぞれ複数のデータベース検索を引き起こす。

こう書くと結構負荷が高そうなのだが、さすがC++、ほとんど塵程度の負荷しかなく、
当然のことながらリプライに遅延もない。
そこで案ずるよりも生むが易しというわけ。

Qtは出自からしてGUIのためのライブラリではあるのだが、GUIが無いと使えないというわけでもない。
むしろボリュームからすれば、GUI以外の方がより大きい。
そして、半年動きっぱなしで大丈夫ことからして、実は断片化は気にしなくても
良さそうだ。
572
(1): デフォルトの名無しさん [sage] 2016/07/16(土) 10:38:52.53 ID:6AR6MH2z(1) AAS
一般のグラフじゃなくてリスト構造の話だろ?
双方向リストはheadとtailへの参照があるが、単方向リストで循環参照は生じようがないが。
609: デフォルトの名無しさん [sage] 2016/11/15(火) 12:45:52.53 ID:LZ5unIkv(1) AAS
>>607
607(1): デフォルトの名無しさん [sage] 2016/11/15(火) 10:53:43.30 ID:PldPJ2O3(4/4) AAS
struct test
{
  std::shared_ptr<int> ptr;
  test(){ ptr = new int; }
};

上のコードはデストラクタを書く必要があるのかないのか
スマポを使えばデストラクタを書かなくてよい場合もあり得るということ
スマポを使わないのであれば当然デストラクタでdeleteをしなければならないだろう
なので、「スマポ」と「デストラクタを書く必要性」は、関係がある

ちなみにC#のDisposeはただのメソッドであるので
このような芋づる式にメンバ変数のDisposeを呼び出してくれる機能はないし
マークスイープなので原理上不可能である
他で使用中でないことをプログラマが保証しないとにはDisposeは呼べないので
自動化できない
それptr.reset()使うんじゃないの?
685: デフォルトの名無しさん [] 2017/09/17(日) 22:33:12.53 ID:S40DCpdn(19/20) AAS
で、アローケートが一回だけになるようにして、あとはリアロークで対応させた。
おかげでメモリの消費効率は異常なまでに効率よく使えるようになったよ。
あと、動的配列使う場合はいったんメモリをフォーマットするようにしたけどね。
697: デフォルトの名無しさん [] 2018/05/23(水) 21:27:23.53 ID:Au5e7VGg(1) AAS
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

3682F
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.034s