GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。 http://peace.2ch.net/test/read.cgi/tech/1412986420/ なるべくスコープを狭くして長時間存在するオブジェクトを無くす
仮にmalloc/free型を長時間動かしてたらフラグメントが酷いことになるぞ
GCの無い時代のプログラムでフラグメントが問題になった例をあげてみろよゴミッカスｗ
>>3 519 ：名無し~3.EXE：2015/11/19(木) 21:49:08.84 ID:CEKgHuEl 525 ：名無し~3.EXE：2015/11/19(木) 22:13:05.49 ID:CEKgHuEl
メモリ管理は自分でやった方が漏れが出るでしょ
C#の基本は自動だけど部分的に手動にできるハイブリッドがいいと思うよ
>>10 調べてみたけどよくわからんな。
アンｗｗｗｗマネージｗｗｗｗ
c#が残念なんのはC++とデストラクタの呼ぶれるタイミングが違いすぎて移行が大変すぎることだ。
>>9 メモリ管理を楽にするためにあるわけで人間が全部面倒みんのとは違うだろ
やっぱりGCのほうがいいかな大規模になってくると
>>20 メモリ管理すらまともにできないやつが寿命や世代やら管理できるわけがない。
GCそのものではなく新人教育や解説書が最初のスタンス間違えたんだよ。
GCって完全なものだと思ってたから、C#案件でメモリリークの調査にえらく手間がかかった
C/C++はライブラリレベルでメモリリリークの検査もテストも書けるけど
メモリ管理できない人がお気楽で作れば、GCあっても・・・・
前スレでも書いたけど、C#のDisposeの問題を紹介しよう http://ufcpp.net/study/csharp/rm_disposable.html Formなんかも参照が亡くなったら強制的に殺すべきだったと思うわ
解放処理をしなくてもGCがやってくれる。
解放処理のタイミングが制御できないと、解放して欲しくないタイミングで解放されて
>>35 ＞解放して欲しくないタイミングで解放
空きメモリによって使用するアルゴリズム変えたりする。
メモリの解放漏れってさ、とどのつまり下手だからするんだよね
c++11のshared_ptrの参照カウンタってそもそも要るんだろうか？
リソースを共有する場合なんかは使うと楽だよ
最近のC++はdeleteを直接書かないだけでなく、最早newも直接書かない方向 >>30 で書いたような問題も起きないよ >>41 >>42 >>45 うーん質問がアバウトすぎたな。もう少し具体的に書くわ
IDisposableの問題はDisposeを呼ばなければリークするものとそうでないものの混在だろ
>>47 >>49 所有権って・・・・
shared_ptrで複数人が所有権を持っても良いんだぞ
そんなの分かってるんだが >>50 の人はどう考えてるのか >>51 一応言っとくと静的解析のくだりは新しい言語を
せっかくC#は新設計なのにいろいろ失敗が含まれてるよな。
大企業は、
メモリ管理テケトーなやつはその他のリソース管理もテケトー
そもそも自分のリソース管理がしっかり出来てる人は・・・
>>31 中の細かい実装まで知らないんだけど、
違うよ >>62 の例のnullの代入は無駄 いや無駄じゃないか
>>64 null代入なんていちいち書いていたら
null代入とか結局やってることc++以下なんだよなぁ
ダングリングポインタが出ないって利点は有るにはあるが
>>68 変数がどこで不要になるか明示しなきゃならんほど長い関数ばっかり書いてるのか
保守性より効率重視なんかでコード書くからメモリリークするんだよ。
どんな意味でnull代入をしてるのか他人に伝わらなきゃ保守性もクソも無いよね
a = null;
関数内ローカルな変数は
>>75 ,>>77 >>77 永続的な変数でもなきゃ、変数の寿命はコンパイラが把握しているから、null代入がどんな変数にも必要なら勝手に挿入するんじゃね。
勝手にnullを代入するとか、そんな変なコンパイラは困る
話は変わるんだがスマートポインタのメリットって何？
>>83 null 代入したら行数増えるじゃん…全部のローカル変数にやってんの？
>>82 >>84 >>87 信じて送り出した >>87 がわがままな顧客を✕✕して三面記事に載るなんて… マークスイープ型のGCが必要かどうかについて、もう少し建設的な会話をしようよ
そもそもc++においてメモリリークって対策も発見も
>>92 >>90 >>93 >>92 忘れるとか忘れないとか池沼レベルの話じゃん。
>>95 >>97 >>98 そもそも今時c++でgcならなんとかなる類いのメモリリーク起こすなんて、プログラマが屑なだけ。
>>100 >>102 お前ら派遣だろw
ほーら、自分の知能が一般人より低いと認めたくないがゆえにレッテル貼りが始まった。
>>100 >>107 100人で数年のシステムなら
>>108 >>110 >>112 なんかだんだん笑えて来たんだけど、ろくに理由も言わずに
メモリの解放すら管理できない奴が、複雑な仕様を管理できるとは到底思えない・・・。
やれやれw
>>116 人生の管理ができない奴が、メモリを管理できるとは到底思えない
そもそもLinuxカーネルもFreeBSDカーネルもC言語だろ
>>115 >>120 >>122 >>124 Guilty Crown?
GCが云々というより抽象的なプログラミングしたい時は基本的なメモリ管理を言語に任せたいという欲求
>>113 GCは関数型プログラミングでのみ正当化される
>GCは関数型プログラミングでのみ正当化される
関数型プログラミング好きだけど
>>128 ここでメモリ確保
メモリリークは開放忘れでなると思ってる低レベルがいるのか。
>>134 >>137 や>>139 みたいのが知識や技術に溺れて本質を見失い、 >>140 想像を絶するアホは居るもんだよ
カッコ先につけといたほうが 後々、都合がいいことも
アホな書き方といえば
別におかしくない
>>147 >>139 >>135 >>134 の言っていることは全く正しい ここ数日一気にレベルが下がったなw
つーか前スレと同じこと書いてる人多数
【 オンラインTCGエディター 】 >>1 http://wc2014.2ch.net/test/read.cgi/entrance2/1449039272/-18 >>149 >>134 は設計し直してから言うんだな。坊や。 >>137 これって何が言いたいの？OSやライブラリ自体にミスがあるって言いたいの？ >>137 みたいなこと言う奴って、電磁波からデータが盗まれる！対応しないと！とか言い出すタイプ？ >>151 >>154 >>154 >>158 >>159 詰めても無意味。 メモリの話とスレッドの話を混ぜ込んでしまうタイプは
>>158 >>161 だからメモリを自動開放してほしいときはスマートポインタを使えばよいだろ
むしろ議論すべきはshared_ptrのような参照カウンタ方式のスマポと
つまり、完璧なGCは無いということだ
このスレ論点が一致してないよね。
>>158 MSのサイトにfix分と調査中のものが全部公開されてる。他のOSもlog、mlみれば腐るほど出てくる。
C++でRAIIを徹底しておくのが一番いいよ
shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって
確保／解放を直に書くのはスピード的には一番速いだろうけど解放漏れバグの温床過ぎてネ
>>169 >>172 >>175 昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って
書き損じた
デメリットはblock_create〜で作成するものは全部ヒープに確保されること
C#でアンマネージドなメモリを扱えるのはわかった
>>180 C++にfinallyが無いのが気に食わない
>>183 むしろfinallyってデストラクタがない言語だから
98以前でもローカルクラス定義できるんだからすこし冗長なだけで同じだし
例外発生はバグ、というプログラミングしかしたことないからよくは知らんが、
ｽﾏﾝ
デストラクタの問題点は不可視なところだな
>>189 例外をロジックとして使うなってばっちゃんが言ってた
>>191 だから忘れる忘れないレベルをぶち込んでくるのは止めようやｗ
>>194 c++のデストラクタって後処理に失敗しても
そのクラスが管理してる範囲で後処理の失敗って何が起こるの？
現実的な確率で発生して無視出来ないリスクが有る解放処理はデストラクタでやるべきじゃない
具体的に何があるん？？？
どっか他のオブジェクトと共有してるものを解放しようとして失敗するとか？
>>202 >>200 バグ（リソースへのポインタやハンドルを壊しちゃったとか）以外で
>>206 fcloseに失敗してファイルに正常に書き込みされなくてもシカトしてるんだよね？
まあC++の例外を援護するつもりはないがそういう場合は
GCというよりライブラリとの関係だな
今日一日なんでFormがGCされないのか調べてて大変な思いしたわ
>>213 いまだにプログラマはアセンブリ言語を使えるべきだ派？
アセンブラ知ってると知らないとじゃスキルレベル全然違うからな。話にならないぐらいのレベル差。
まあ実際Java屋とかってコンパイラやメモリ意識できない奴多いよね
>>217 >>217 みたいにループ中で一個づつくっつける場合は別にして いちおう訂正しとこｗ
>>218 >>219 >>222 逆だろ？
>>219 こうやって、比較的プログラミングという行為を好きでいる・好きでやっている・興味を持っているという人ですらまともに言語仕様を理解出来ていない。
そもそもプログラマの大半にマネージリソース、アンマネージリソースとはなに？
結局いつ開放されるか分からないってのが曲者で
>>229 そういう事になる原因ってさ、構造がぐちゃぐちゃでオブジェクト間も依存しまくって、
ある意味メモリなんて一番扱いやすいリソースだからな。
メモリ意識した時点で雑魚プログラマ決定だろ。
>>231 >>234 JavaやC#ではリソースをプログラマが管理してはいけない
>>230 >>238 full GCが頻繁に生じちゃうのは明らかに設計ミスやな
RAIIで事足りる
むしろ短命なオブジェクトなんてスタックで十分だし
ライブラリ、アプリ、ユーザの三者で考えないと
>>243 Manager.Execute((res) => ...);
このスレでGCいらんて言ってる人たちは環境に恵まれてるんだなぁって思う
参照がなくなったタイミングで必ず開放してくれて
>>246 >>249 >>250 強参照、ソフト参照、弱参照、ファントム参照
Rustはどう？
rustの清貧さは好みだけどまだ触った事ないな
>>254 難しいのは難しいが、低レベルの世界に相応な難易度であって、理不尽さはあまり無いと思う。 https://doc.rust-lang.org/std/iter/trait.Iterator.html >>251 >>255 shared_ptrと恒等なものは無いけど、ポインタ的に使える型がBox, Rc, Cell(あるいはRefCell)とあって、 >>258 >>249 >>260 >>259 コピーしまくっているような変数の型をTからBox<T>に変えた場合、確かに面倒なことになる。 freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなｗ
>>263 shared_ptrって参照カウント式のGCじゃないの？
循環を綺麗に扱えるなら参照カウントの方が良いと思うけど
>>265 >>264 片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。
freeとか言ってる奴はC++使えよ。いつまでＣ使ってんだ。
>>270 >>272 それ中級者
このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。
>>275 スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww
スレッドがデッドロックしちゃってメモリ解放できない（泣）
まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない！」って言われたらソレは真実なんだろうけど・・・。
そもそも実務でスレッド使うＰＧなんてゴマンもいない
Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
>>282 javaってc++のconst参照に対応するものが無いのに、素人みたいなプログラマを大量にかき集めているのが怖すぎる。
>>283 C#はマルチスレッド使いまくりだけど事故の話はあまり聞かないな
Freeし忘れ
動的型言語
C#でcatchやfinally書くの嫌すぎる
COMのVariantとかJSとかリークしまくりだし
そういやVBScriptって参照カウンタ以外のGC積んでんのあれ
解放処理
開放処理を手動でやれって書いてある仕様書かw
ガベコレのあるPyObjectをラップするクラスをガベコレのあるDで書いたら
ガベージコレクションはたしかに便利だ
C#ではSafeHandleだけ作って後は放置
>>303 つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、
>>304 メモリ空間は無限であるべき
>>306 >>304 の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの？ >>306 的に良い設計なの？ >>308 >>309 >>308 のオブジェクトDのケースはどう解決すんのさ… 解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
>>311 >>314 だから同時に書く設計が悪いんだって
ていうか>>316 の言っていることはますます矛盾で、 >>315 >>318 >>319 >>308 を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について： >>308 のオブジェクトDのケースはどう解決すんのさ… >>308 のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない >>318 ﾌﾟﾁ訂正
読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
なんか参照カウントの話とマルチスレッドの話がごっちゃになってね？
>>322 おいおい、バージョン管理のマージの話にまで拡張したら収集つかなくなるぞw
>>324 メモリ管理もできないんだから
GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない
メインメモリに対するGC・・・MGC
GoogleChromeかsvchost.exeを使わなくなった理由・・・ページメモリGC制御が遅過ぎでお粗末だからか？
GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない
そろそろsvchost.exeを使うソフトは使用禁止なのかも？
svchost.exeを使わないことでGoogleChromeは確実に応答性能が速くなっている
残念だがスリープだ！ 京がお仕置き候補に??? http://gigazine.net/news/20130618-fastest-supercomputers/ 気づかないかISOは中国のためにある >>344 ただしChromeはプロセスが一杯できるから
64の時代だから、そろそろCore64ぐらいでイイのでは？ diginnos stickpc_02 VIDEO 723 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:24:00.06 ID:rlcuxF0A0
Vivaldiの起動が遅いのは
やっとこの気色の悪い仕組みにトドメが刺されたか
GCのすべてを否定するつもりはないけど・・・
謎だといったが、理由ははっきりしていて
もっと言えばC#でDisposeを実装する場合でも↑は問題になる
前から何度も言ってるがDisposeの実装はしていいが呼び出しは禁止
c#の欠点はデストラクタが呼び出されるタイミングが分からないこと。
最近VB.NETを使い始めたんだけど
c++のデストラクタは例外投げられないウンコ仕様
javaはファイナライザで発生した例外は握りつぶすことが仕様で決まっているな。
そら伝えたかったらやりようはいくらでもあるでしょう？C++に限らず
Javaは強制的に解放させることもできるようにすべきだったな。
Java(VM)は(すべてのプラットフォームで)強制的に解放させることもできるようにすべきだったな。
都度メモリ管理するよか、GCに任せた方がスループット的に有利な場合も多いでしょ。
GCはメモリ管理に関しては成功してる、
そうそう、メインメモリの管理に関しては100%成功している
簡単だよ
javaもsandy-bridge以降でSSDとかならそれほど重いってわけじゃないけど
フラッシュとJAVAは、システムに見つかり次第、速攻アンインストールしている
>>377 最近のPC環境でも贅沢が過ぎるプログラムは動かん。
GCがある言語でRAIIみたいな事したいのなら
リソースを共有した上で最後の参照が切れた時点で回収してほしい
しかし、言語側は、そういうダサい設計も許さないといけないので
循環参照なんて放置すればいいの
>>387 常識的に考えてカーネルの実装にはGCなんて使えないし
パフォーマンスが問題にならないGCが一つだけあって、それが参照カウンタ方式のGC
androidでもう何も判らん状態でプログラミングして
RAIIに必要なのはデストラクタが呼ばれることであって実際にメモリが解放されることじゃないから
RAIIに必要なのは適切なタイミングで確実に解放処理が呼ばれることであって
かつてStandard MLの実装で、GCじゃないメモリ管理方法をやってみたのがあったな。
>>396 この際、呼び名はどうでも良い
>>393 androidで原因不明のフリーズが発生、プロジェクトはデスマーチに突入した
>>401 マルチスレッド環境だと参照カウンタとかいうクソアルゴリズムは使い物にならない
>>407 使う側は少なくとも１つのポインタを持たなくちゃいけないんだからオーバーフローし得ないだろ
マルチスレッドでGCスレッド立ち上げて、再配置起こる可能性のある普通のGCだと、オブジェクト毎にLock,Unlockできる何らかの機構が必要だし、参照カウンタ増減するより高頻度でその機構使うよね。
例えばWindowsだとInterlocked系のAPIを使えば
C#なら参照のコピーはただのワード代入で済む
>>399 からの流れを見ればわかるがそういう話ではない >循環参照以外のGCは重いと言っている
>>413 前にも書いたが、RAIIとGCは直接の関係はないよ。
>>415 >ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
>そもそも不可視のコードでリソースを解放するのが愚行そのもの
極端な話
>>420 メモリとその他のリソースを混同して考えるからダメ
schemeにはdynamic-windみたいな他所に継続が飛んでも後処理が保証される仕掛けがあるし
>>424 >>426 >>423 >>424 C++で書けば
訂正
結局、C#のDisposeはどこまで行ってもどんなに進化しても手動で書かなければならない
>>428 ポインタがメンバ変数になってたら公開しちゃいかんでしょ
まずDisposeは生成できる
デストラクタで解放してはいけないリソースをデストラクタで解放しなければいいだけで、デストラクタで解放すればいいリソースはデストラクタで自動的に解放すべき。
>参照カウンタ方式＋デストラクタ
RAII信者の痛さは異常
グローバルインスタンスホルダーは明確にインスタンスの状態を把握したいときに積極的に使うべき
>「いつか」全員が所有権を手放したら「即座に」破棄される
>>440 メンバにDispose持たせる設計って大抵ダメだよね
>>440 {
>>447 >>447 schemeに何十年も前から存在するwith-xxxx 系を一般化した構文だね
アレを更にtypedefされたりされると
c++なら普通こうだな
GCがあるのになぜJavaはメモリリークしまくるソフトウェアを量産するのか
GC大好きっ子に聞きたいんだが
無い
つまりは、GCを使っていたとしても
そして無視されてしまうコピーGC君
＞リソース管理フリーというわけにはいかない
RAIIでも結局どのタイミングで解放されるか意識しなくてもいいってわけじゃないし
メモリ管理系のバグが顕在化しにくいだけで、そこら辺適当なまま中途半端にキャリアを積む開発者を量産するという害悪が大きい。
>メモリ管理系のバグが顕在化しにくいだけ
あと正確にはGCには含まれないけどメモリコンパクションをやってくれる処理系が多いのも
今どき意図的にやらない限りメモリフラグメンテーションで困るような場面があるか？
>>469 >>468 さんの経験してきたことなんです。 自前のメモリ管理が超下手くそなだけやろ
ゲームだとフラグメント問題になること多いよ
jemallocのようなモダンなmalloc実装使えば良かったのでは。
ゲーム専用機でフラグメンテーションおこすとか開発者としての適性を疑われても不思議ではない。
メモリのフラグメンテーションをC/C++でコントロールする方法ってあるの？
mallocの挙動がわかってれば、ある程度は・・・・
細かくメモリ要求するから、下回りで時間がかかる
>>475 寿命管理で解決できないとか、フラグメンテーションがどういう現象か分かっているの？
>>480 専用ゲーム機上のゲームだよ。
まぁテトリスとかならその程度の理解でいいんじゃない？w
>>482 普通のmallocで足りるならそれでもいいけど。
ゲームプログラムとかならメモリ確保は直接システムコール呼び出して
使用できるメモリのサイズも空きメモリのサイズも最初から分かってて、ユーザーからの入力も限られてて、
レーシングゲームは出てくる車が決まっていてコースも決まっているから。
昨今はレースゲームでも汎用的なゲームエンジン使うことが多いから
>>489 >>486 やり手のゲーム系の方たちに、逆らうようなことは・・・・
>>494 ゲーム機含む組み込み系は結果が不確定な動的メモリー確保なんかしないのが鉄板（しようとする奴は未熟な馬鹿）だったが >>497 やらってどういうGC使ってるの？ ゲームだって組込みだって今どき動的メモリー確保しないなんて化石みたいな発想が通るわけないだろ >>497 は「こんなすごい講演するぞ」って言う宣伝だけだけど中身はどこにあるの？ >>497 各ゲーム機の事情は知らないが
ただの物理メモリ不足の話がなんでと思ってしまった
論理アドレスが64bitだったらフラグメンテーション対策なんていらんということ？いや自分もそうは思うんだが。
>>500 >>488 で答え言ってたわけだけど >>503 用途ごとにセグメント分けて使い回すのが無難じゃないの
結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない
>>510 そもそも、ページサイズより粒度が細かいフラグメンテーションにはMMUはなんの効果もないしな。
autorelease()呼んだらコアダンプ糞osがｗｗｗ
小さな粒度のフラグメンテーションは気にする必要ない
>>512 >>516 ネイティブコードが必要な場面で中途半端に GC に頼るのが問題なのかもしれないが、もうネイティブコードが必要な戦場は限られた一部だけになってて、主戦場では GC は大前提の技術なんだから必要ないとか言われましてもですわ。
ページがスカスカになっても大丈夫
androidしか知りませんみたいな事言われてもな
物理アドレスはページサイズで切り売りされるので
実はQtでデーモン作って動かしてるのだが、もう半年以上動き続けてる。
Qtで作ったのは一日ででっち上げる為だったのだが、意外なことに堅牢に動き続けてる。
>>525 >>526 >>525 >>528 daemonじゃなくてdemonなんじゃない？
俺が作ったのはウェブソケットによってサービスを提供するプログラムだ。
ちなみにQt使ってなかったら一日でサービスを書き上げることは不可能だっただろう。
>>530 Windowsで書いてLinuxで動かすことに、systemdは大いに貢献した。
Qtのバグの多くは、複数の環境に対応するため、その差異によって引き起こされているという結論を得た。
更にもう一つヒントがある。
ねえ訳分かんないんだけど
むしろ、わからないのに何故、一生懸命主張していたのかと。
マークスイープでメモリリークってどうやって起きるんだ？
狭義の意味では起きない
言い換えればダングリングポインタが発生しない
マーク＆スイープでもポインタの型情報を記録してないとリークしまくる
>>10 C++/CLIはデストラクタが呼ばれるだけで、managedメモリの解放がGC任せなのは変わらんよ。
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、 https://twitter.com/Lyrise_al 良スレ発見した。Windowsは32bitで十分だな。32bitでもPAEで4GB超の
>>1 みたいなやつは 指摘してるレスがなかったので言っとくが
学生の頃は循環参照できないことに困ってたけど、今となっては何時
>>563 >>568 >>565 △: リストの要素
一般のグラフじゃなくてリスト構造の話だろ？
>>572 >>570 の単方向リストは正確には循環リストもしくは環状リストと呼んだ方が良いかも試練、 循環してるかは後付けでオブジェクトをマークすれば判るんだし
？
いまどきの子はブラウザアプリしか作れないから
現在のGCが不完全なだけであって、
潤沢なメモリを用意してGCしない戦略
プロセスを細かく分けて寿命を短くすればそんなの考えなくて済む
本当の意味での軽量プロセスをOSがサポートしてくれたら良いんだけどね
いつ無くなってしまうかわからんようなメモリのアクセスが簡単になってもほとんど使いみちないだろ。
結論から言うと、Windowsにforkが無いのが面倒すぎるってことなんだけどね
>>580 いやそんなもん、中断する手立てが用意されている方が珍しいだろ
元々はスレッドが軽量プロセスって呼ばれていたりしたんだがな（アドレス空間の切り替えが不要だからプロセスより切り替えが軽い）
メモリ空間がつながっていること自体はそれほど考慮してないんよ
GCもハードウェアに支援させれば全部解決するよ
固定領域として静的にグローバル変数化、バッファ化すればいいだろ、
例えばChromeとかFirefoxとかが静的にメモリアロケートしてたらどうなるか
そういう発想、嫌いじゃないよ
マークスイープ系GCはメモリ管理に関しては完璧かもしれないが
本当にC#で解放処理をまともに書こうと思うと
これがC++が未だにかたくなにマークスイープ系GCを搭載しない理由である
メンバーにdisposeしなければならないような設計が良くない。そんなものはメソッド内のローカル変数に止めるべき。
日本語おかしかった。
>>594 >>595 >>600-601 >>597 スタック変数の 0 クリアすら嫌がる C/C++ が GC 搭載とか夢見すぎ
struct test
>>606 >>607 グローバルが嫌われたのは
C#/C++よりRustだろ
>>612 >>613 >>614 >>615 ログファイルはログが確実に記録されるのが使命であって性能は二の次なのだよ
>>618 >>617 はもう少し経験積むまで黙ってた方がいいと思う >>620 とこのように、相手を互いに見当違いであると罵り合うのであった
スコープの話してるのに flush とか頭わいてるだろ
null安全をアピールしてる人間はObjCerから見ると補助輪付き自転車を渡してきてこれ安全だから絶対に乗れよと言ってくる頭おかしいおじさんにしか見えない
浜矩子・著
小規模ならGCのメリットは大きいのかもしれないが、大規模または大量にメモリを食うプログラムにはGCは向いてないのではないか。
GC周りに付いて書かれたネットの記事読んできたけど >>627 >>606 参照カウントは循環参照の問題が起こるだけじゃなくて
ストップ・ザ・ワールドの問題さえなくなればGCが最強ってこと？
>>634 バイオハザード7は28万行のC#コードでできててビルド10秒らしい。
>>638 内部的にC#をC++に変換してるからC#をスクリプト的に使ってるだけで実質C++だな。当然GC・メモリアロケータ周りも身内実装。
>>640 そこまでやって既存のフレームワーク使えるのって疑問が。
「メモリ」+「フラグメンテーション」で検索すると色々と詳しい話が出てくるね。
メモリのフラグメンテーションなど実質的には気にする必要は全くない
そうなん？
>>647 程度の問題であって
>>646 必ず来ると思った、その反論
MMU のお陰でふらぐめんてーしょんが起きない環境の方が希だと思うが
フラグメンテーションはアドレス空間や実メモリ量が限定される環境をどううまく使うかの話だから
そそ、複雑なプログラムって書こうと思えばいくらでも複雑化するからな。
でも実際スマホアプリ作ってんのにフラグメンテーションを防ぐ為に最初に使用する分全部確保しておいて、その中で割り当てするんだーとかいって、オレオレアロケーター作ろうとする頭の悪いやつがいて困る。
組み込みなんかでよくあるそういうのは、どっちかというと最初に確保したメモリ以上を
アロケータ置き換えるだけでは普通解決しないでしょ >>655 こそが置き換えて何するのか理解できてない気がする むしろ一定時間を保証する（なのでサイズは固定長とかが多い）もんだろ
いくら64bitあっても設計が雑ならメモリ枯渇するでしょ
MMUのアドレス変換コストもタダじゃない。
ツリー状のメモリ管理するとあっという間にメモリ無くなるな
こうするとさらにメモリが消えていくな
間違えた。
一回のメモリ取得で4KBってのが嘘だから意味が無い話だね
https://ja.wikipedia.org/wiki/ 動的メモリ確保 アホだなぁ
>>667 mallocやnewは
VC++2015での実行結果
MMUは多少以上の処理をすると簡単にフォールト返すのが困りもの
複雑なことをしていると、それがまるで正しいかのように思う点がアフォ
malloc,newの挙動の説明ってまんまMMUの説明なんだよな
たいがいのmalloc,newはMMU次第でいくらでも挙動が変化するからな
ID:S40DCpdn しったかしすぎ
malloc,newの挙動はハードとOSによって変化するという記述は見たことあるけどな
ヒープの管理しないでなんとかなるレベルのものはgc言語使えばいいんでは？
自分はメモリ対策プログラムを作って対応したけどな。
メモリの増減には現在のサイズで対応し、このサイズが必要以上に大きくなると
あと、動的配列ってのを作って、複数のメモリ取得に対応させた。 >>682 のデータを持たせた。 で、アローケートが一回だけになるようにして、あとはリアロークで対応させた。
それから、動的配列は入れ子構造にすれば色々と応用がきくようになってるけどな。
アセンブラできない馬鹿がC++使うことを想定するとGCは成功と言わざるをえない。
メモリを動かして処理すれば出来る事なのにな
誰へのレスかすらわからないというね
前日に連続して意味不明な独り言してるやつがいるからそれの続きだろ
malloc()関数の内部はOSからメモリをまとめて取ってくる処理と、
最近はjavascriptのレイヤーとかまで出来てさらに複雑面倒に
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
GCをルンバで例えたらどうだろう
それに加えてルンバが動けるように床は片付けておかないといけないとか
もういらないって明示的に書かなきゃならないのなら自前で管理するのと一緒だよな。
GCがある言語でも、shallow copy と deep copy のどちらにすべきかの判断が難しくて、結局、間違えてバグの原因になる可能性がかなり残る。
No GC派なんだけど、WebサーバーをC++とかで実装しても結局力持て余す感はあるよな
GCのメリットは言語の文法が簡単になること。
(destructor)()
#AuroraWaveTV 
#AuroraWaveTV 
#AuroraWaveTV 
#AuroraWaveTV 
#AuroraWaveTV 
#AuroraWaveTV 
#AuroraWaveTV 
