- 1 名前：デフォルトの名無しさん mailto:sageteoff [2015/11/18(水) 23:24:59.79 ID:BUQ68wTG.net]
- GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す
プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。
入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。
前スレ
GCは失敗。メモリは自分で管理せよ！
peace.2ch.net/test/read.cgi/tech/1412986420/
- 93 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 15:57:55.75 ID:Co3W2iFa.net]
- そもそもc++においてメモリリークって対策も発見も
大して難しい部類のバグではないんだよなぁ
GCの優位性をアピールするために過剰に恐怖心を煽ってる気がする
- 94 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:00:08.95 ID:sCmmZzWu.net]
- >>92
その程度の案件しか受けてないからだろう。
- 95 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:05:07.63 ID:QSPcxrGF.net]
- >>90
つ世代別GC
immutableオブジェクトをバンバンnewしまくる関数型プログラミングに慣れてると
やっぱGCないとキツイわ
- 96 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:15:05.64 ID:Co3W2iFa.net]
- >>93
いやいや普通難しいとされるバグってメモリ破壊とか同期周りだから
メモリリークなんてデバッガがチェックして丁寧なダンプ出してくれるし
組み込みとかの貧弱な環境なら専用のメモリ管理を用意して
いくらでも好きなチェックや情報出せるから
- 97 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:17:37.80 ID:AV0cYAnH.net]
- >>92
それな
メモリの確保と開放の対応すら管理できない奴は
なんかもう何をどうしたってダメな気がする
初歩の初歩の初歩の話題を何度も何度も何度も繰り返しすぎ
- 98 名前：デフォルトの名無しさん [2015/11/29(日) 16:20:05.34 ID:3h4H/kBH.net]
- 忘れるとか忘れないとか池沼レベルの話じゃん。
ゴミクズ。
メモリの解放が必要ならそれは必要な機能の実装ってことになる。
それを忘れるってことはプログラムを組んでいて必要な機能の実装を忘れるってことだ。
必要な機能の実装を忘れるということは、例えば通販サイトのシステム開発請け負っておきながら、決済システムを実装し忘れるのと同等。
ありえない。
プログラム云々以前に頭の問題だろう。
必要な機能の実装を忘れる可能性におびえる池沼プログラマ。
最近流行りのADHD？なんじゃねえの。
- 99 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:24:33.80 ID:sCmmZzWu.net]
- >>95
なるほど。経験の少なさがすぐ分るな。ログ出したらで数十ギガなんてよくあるよ。
ログから問題点をスクリプトで抽出するにも何時間とかかるとかいろいろ。
マルチスレッド絡んで特定のパターンだけだったりして再現性がなかったりする。
他システムの連携だと手が出せない部分の挙動がおかしい可能性もある。結局、oracleのバグだったとかね。
- 100 名前：デフォルトの名無しさん [2015/11/29(日) 16:25:01.11 ID:1uX74bCE.net]
- >>97
決済システムとメモリ解放は違うよ。
通販サイトのシステムをC言語で実装してみればわかるかと。
- 101 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:36:20.27 ID:Co3W2iFa.net]
- >>98
はあ？なんでリーク箇所ダンプするだけの話でログ全部吐き出すことになってんの
普通確保する際にヘッダにそのブロックの確保場所埋め込んでるし
アロケータで生存期間のスコープを切り分けといてすぐ分かるようにするけど？
お前の関わったプロジェクトが糞なだけじゃね？
- 102 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:42:54.34 ID:snjMtaUP.net]
- そもそも今時c++でgcならなんとかなる類いのメモリリーク起こすなんて、プログラマが屑なだけ。
リソースリークやその他の問題も確実に起こすこと請け合い。
GC言語でそのレベルのプログラマを使うような案件はGCによるメモリオーバーヘッドが気にならず、リソースリークも問題にならないような非常に緩い案件でしかない。
- 103 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:46:22.91 ID:sCmmZzWu.net]
- >>100
はぁ。話にならんな。扱ってる規模が違いすぎる。
- 104 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 16:52:06.50 ID:Co3W2iFa.net]
- >>102
おいおい反論できずに捨て台詞かよ
上でも書いたがコンシューマで開発してたから
100人*数年の規模でやってたんだけど
もしかしてC++みたいな危険な言語使ってて
今の今まで解析ツールなり自前のメモリ管理なり知らなかったの？
- 105 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 19:41:19.37 ID:GW0SCIDI.net]
- お前ら派遣だろw
全体規模とお前らが任されてる範囲を都合よく混ぜるな。
- 106 名前：デフォルトの名無しさん [2015/11/29(日) 22:07:37.11 ID:3h4H/kBH.net]
- ほーら、自分の知能が一般人より低いと認めたくないがゆえにレッテル貼りが始まった。
普通の人が当たり前にできることができないってかわいそうだな。
もしADHD？だったら治療法あるらしいから病院行ってみたら？
ここでレッテル貼りやってるよりよっぽど解決する可能性が高いぞ。
- 107 名前：デフォルトの名無しさん mailto:sage [2015/11/29(日) 22:12:02.58 ID:QSPcxrGF.net]
- レッテル貼りは2chの華
- 108 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 08:34:00.92 ID:qSWjFIuy.net]
- >>100
リーク箇所がわかってればログ出力の必要なくね？
ホントに開発したことあるのかな？
- 109 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 09:12:24.63 ID:UQyKbzCH.net]
- >>107
普通C++のプロジェクトは専用のメモリ管理を用意するから
リークしたメモリはそれを確保したクラスとその行数まで特定できるようにしてるよ
アロケーターも分離しとけばアプリケーション終了させなくても
管理オブジェクトを破棄した時点でリークの判定できるし
リーク箇所特定するのに全ログから解析とか複合的なバグでもない限りしない
そんな状況許してる時点で負け
- 110 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 12:11:48.62 ID:fg7tHWVi.net]
- 100人で数年のシステムなら
10人で一年でやるべきだな。
人を無駄に増やせば、意思疎通や連携に無駄に労力を割く。
開放云々より仕様レベルで齟齬が出やすくなるわ。
- 111 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 15:00:18.02 ID:Ee9Jt/HC.net]
- >>108
リークしたクラスが分ればリーク原因が分るとかお花畑杉w
- 112 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 19:23:16.25 ID:UQyKbzCH.net]
- >>110
誰もリークしたクラスの事なんて言ってないんだが…理解できてる？(笑)
解らないなら解るだけの情報埋めたら？
- 113 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 19:24:12.90 ID:Ee9Jt/HC.net]
- おいおいw
- 114 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 19:31:17.77 ID:UQyKbzCH.net]
- >>112
そもそもGCがあろうとコンテナに突っ込んで消し忘れれば
オブジェクト破棄するまでメモリ圧迫し続けるって理解できてる？
リーク単体ならC++はそれと同等のレベルまで分かりやすく出来るんだよ
C++が困難なのはそういった管理情報も簡単に破壊出来てしまう点
リーク単体なら怖くはない
- 115 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 19:47:37.41 ID:UQyKbzCH.net]
- なんかだんだん笑えて来たんだけど、ろくに理由も言わずに
「わかんないんですけど！？わかる奴はお花畑(怒)！！」って
なかなか面白い奴だな
- 116 名前：デフォルトの名無しさん [2015/11/30(月) 19:50:22.70 ID:isQX20zS.net]
- メモリの解放すら管理できない奴が、複雑な仕様を管理できるとは到底思えない・・・。
メモリの解放なんてなんの苦にもならんが・・・。
- 117 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 20:14:21.83 ID:Ee9Jt/HC.net]
- やれやれw
MSやLinuxやFreeBSDまでメモリリークやらかす理由が分らないのか。
- 118 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 20:30:16.55 ID:UQyKbzCH.net]
- >>116
また反論できずに逃走かよw
そもそも欧米は原因分かっててもバグ無視する連中だろうがw
ライセンスで守られてりゃ平気で放置するぞ
- 119 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 20:33:04.33 ID:V9s4KAVu.net]
- 人生の管理ができない奴が、メモリを管理できるとは到底思えない
- 120 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 20:49:26.08 ID:UQyKbzCH.net]
- そもそもLinuxカーネルもFreeBSDカーネルもC言語だろ
馬鹿丸出しだなw
- 121 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 21:16:22.39 ID:zT+q2mn+.net]
- >>115
それな
プログラミングにおいてメモリ周囲はまだ初歩だよな
そしてマルチスレッドはそれよりは大変だがこれも慣れると
結局大事なところをガッチリ排他処理するだけのことだしな
プログラミングって最後はインタフェース設計だけだから
使いやすくてコンパクトなインタフェースを求めていくだけ
これがプログラミング道の後半の道のり
- 122 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 21:18:50.76 ID:Ee9Jt/HC.net]
- >>120
で例外系の実装がないから破綻するんだよ。実務経験ないとすぐ短絡的になるのが分る。
- 123 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 21:25:49.32 ID:zT+q2mn+.net]
- 意味が不明すぐるｗ
- 124 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 21:28:33.92 ID:Ee9Jt/HC.net]
- うむ。まだおまえには早いかもしれない。
- 125 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 21:47:43.54 ID:UQyKbzCH.net]
- >>122
馬鹿相手にしても時間の無駄だぞ
こいつ具体的なこと何も言わんし
- 126 名前：デフォルトの名無しさん mailto:sage [2015/11/30(月) 22:07:34.86 ID:zT+q2mn+.net]
- >>124
そやね
一連のレスの意図すらよーわからんわ
- 127 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 00:23:09.00 ID:s1rcgCDh.net]
- Guilty Crown?
たしかに失敗作だったなあ…
- 128 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 01:24:29.91 ID:mVPa8mQr.net]
- GCが云々というより抽象的なプログラミングしたい時は基本的なメモリ管理を言語に任せたいという欲求
- 129 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 01:27:09.96 ID:mVPa8mQr.net]
- >>113
c++素人なんだけどリーク単体はともかくそれにメモリ破壊が合わさると頭がおかしくなって死ぬ
みたいな感じ？
- 130 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 01:30:32.01 ID:s1rcgCDh.net]
- GCは関数型プログラミングでのみ正当化される
命令型プログラミングでは全く正当化されない
命令型プログラミング（＝チューリングマシンに基づく計算モデル）は読み書きの「順序」こそがネ申なので
命令コードの「順序」を横断して存続するブツは善と悪の最終戦争で滅ぼされるであろう
つまり確保し、使ったら後開放する、これを明示的に書き下す姿勢こそが正しい
- 131 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 01:31:50.27 ID:s1rcgCDh.net]
- >GCは関数型プログラミングでのみ正当化される
ちな、これは処理系の裏方としての存在が許される、の意味
- 132 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 01:36:31.76 ID:mVPa8mQr.net]
- 関数型プログラミング好きだけど
代数型データ型と型クラスでモナドとかアプリカティブとかtraverse、free monadとかやってる時に
メモリ管理だの言われたら余裕で死ねるな
本物のhaskellプログラマはhaskellで低レイヤを書くらしいけど
- 133 名前：運用中（トリなしｗ mailto:アハ♪” uh huh [2015/12/01(火) 04:32:07.54 ID:79aHC4wo.net]
- 口 先 人 間 展 覧 会 。（ｱﾊ
- 134 名前：デフォルトの名無しさん mailto:sage [2015/12/01(火) 12:55:11.72 ID:S8usJREu.net]
- >>128
> メモリ破壊が合わさると
これが合わさるとなんでもありありなので何が起きても不思議はない
なので、ダングリングポインタの管理と配列のレンジチェックはちゃんとやるべし
- 135 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 12:20:09.85 ID:AuS7g0FI.net]
- ここでメモリ確保
ここでメモリ解放
たったこれだけが書けない管理できないとかw
- 136 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 12:23:19.04 ID:n26CULk9.net]
- 知らないでやるって幸せなことなんですね
- 137 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 13:19:32.39 ID:N5r0JkUz.net]
- >>134
下には下がいるんだよ
- 138 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 13:29:54.15 ID:JbiOZ/E3.net]
- メモリリークは開放忘れでなると思ってる低レベルがいるのか。
- 139 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 14:07:05.91 ID:n26CULk9.net]
- 低レベルなことを舐めるなよ
- 140 名前：デフォルトの名無しさん [2015/12/03(木) 16:32:54.69 ID:JraK7tKY.net]
- >>134
mallocでOSから確保したメモリはfreeで解放されないんだが、
「ここで解放」はどうやって書くんでしょう?
- 141 名前：デフォルトの名無しさん [2015/12/03(木) 19:43:25.89 ID:R/g8PPkY.net]
- >>137や>>139みたいのが知識や技術に溺れて本質を見失い、
人と会話ができなくなった人の見本なんだろうか
- 142 名前：デフォルトの名無しさん [2015/12/03(木) 19:47:17.15 ID:JraK7tKY.net]
- >>140
今まで正しいと信じきってた鰯の頭が迷信だと指摘され発狂中
- 143 名前：デフォルトの名無しさん [2015/12/03(木) 19:53:39.75 ID:R/g8PPkY.net]
- >>141おｗ おまえ会社で孤立してるだろ派遣ｗ
- 144 名前：デフォルトの名無しさん [2015/12/03(木) 20:32:35.32 ID:R04IP6VM.net]
- 確保したやつが解放するんだぞ。大丈夫か？
- 145 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 20:33:46.24 ID:cWTIfUD3.net]
- 想像を絶するアホは居るもんだよ
if (cond) exp; の場合も中カッコを必ず付ける流派ってのがあって
理由を聞くと
if (cond) {exp1; exp2;}とするはずが
if (cond) exp1; exp2;としてしまうのを防ぐための常に中カッコらしい
中カッコを書き忘れるくらいの意識レベルで書かれたコードって
他のとこももう全部ダメだろそれは
- 146 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 20:52:03.75 ID:s/TINiTx.net]
- >>144
お前がアホなｗｗｗ
- 147 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 21:25:03.70 ID:n26CULk9.net]
- カッコ先につけといたほうが 後々、都合がいいことも
- 148 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 21:30:08.65 ID:WeEbsZB7.net]
- アホな書き方といえば
if ( 1 == a ) {
って比較元と先を逆にしてる奴
- 149 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 21:41:57.39 ID:4rUKwdGH.net]
- 別におかしくない
基準値が先にあって、それと比べてaがどうなのか、と考えるか
aが先にあって、基準値と比べてどうなのか、と考えるかの違いでしか無いから
どっちでも良い
- 150 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 21:59:47.07 ID:/xqyH1ID.net]
- >>147
知ってて言ってると思うが、定数を==の左辺にするのは
if (a=1) { ...
と書き間違うのを恐れているらしい
>>139
free()から設計し直す、
まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ
>>135
スレッド安全に書かない奴が悪いていうかそれは別の話
シングルスレッド状況（またはそれと等価な状況）では>>134の言っていることは全く正しい
- 151 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 22:27:47.14 ID:zepIVOGi.net]
- ここ数日一気にレベルが下がったなw
ＧＣの話しろよw
- 152 名前：デフォルトの名無しさん mailto:sage [2015/12/03(木) 22:46:13.76 ID:srgQPG9D.net]
- つーか前スレと同じこと書いてる人多数
頼むから前スレ読んできて
- 153 名前：デフォルトの名無しさん [2015/12/04(金) 04:37:18.54 ID:HtuddwW0.net]
- 【 オンラインTCGエディター 】 >>1
デュエル・マスターズ的な非電源TCGの 《 オンライン化ツクール系ソフト 》 制作の企画。
例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト（エディター）。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーロー、シャーマン・キングなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。
設計思想は 《 RPGツクール 》 が良いかな？ 他に、優れたエディター有ったら挙げてみて。
個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。
↓
エディター群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。
↓
遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述３つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。
↓
各社TCGを再現するテストプレイ ⇒ 更に改良や修正。
↓
機能制限した下位版を５万円以上で発売 ＋ デュエリ−グ用に改造した上位版でサーバー稼動＝営業開始。
↑
下位版の改造および商用利用には、別途で当社との契約が必要。
さ〜て、製作ベンダー見つけよっと！ｗｗ（ｸｽ
wc2014.2ch.net/test/read.cgi/entrance2/1449039272/-18
- 154 名前：デフォルトの名無しさん mailto:sage [2015/12/04(金) 12:21:13.29 ID:GzeAUkqU.net]
- >>149
>free()から設計し直す、
>まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ
じゃ>>134は設計し直してから言うんだな。坊や。
って、事でオッケーね。
- 155 名前：デフォルトの名無しさん [2015/12/04(金) 20:05:33.81 ID:SAJ9n/s7.net]
- >>137これって何が言いたいの？OSやライブラリ自体にミスがあるって言いたいの？
wikiより
>メモリリーク (Memory leak) とは、プログラミングにおけるバグの一種。
>プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。
>プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。
>>137みたいなこと言う奴って、電磁波からデータが盗まれる！対応しないと！とか言い出すタイプ？
- 156 名前：デフォルトの名無しさん mailto:sage [2015/12/04(金) 21:16:45.71 ID:7W1HEY29.net]
- >>
- 157 名前：151
そもそも１５年ぐらい前から延々繰り返されてるんだが… []- [ここ壊れてます]
- 158 名前：デフォルトの名無しさん mailto:sage [2015/12/04(金) 23:45:19.53 ID:j6MEWqDN.net]
- >>154
開放コードを忘れずに書いたのに開放されないという怪奇現象がマルチスレッド状況ではしばしばあるんじゃー！
マルチコア時代になってこれはますます危険になった
見ただけで正しさがわかる系のスレッド安全策はクロックサイクルを糞のごとく消費するし…
こういうのは専門家が徹底的にデバッグしたGCで面倒を見て欲しいと思う反面、
やっぱプロセス全体のごみ処理を選任モジュールにやらせるのはクロックサイクルをドブに捨てるがごとき
センス無い設計なｷﾓｽ、、
- 159 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 00:08:28.41 ID:+HxrBEdK.net]
- それ単にメモリバリアの問題じゃ…
- 160 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 04:01:37.91 ID:2vAbbe+i.net]
- >>154
入門書に書いてるコードしか見たことないんだね。
スレッドプールみたいなテクニックは高速化のためにみな普通に使うんだよ。
OSやライブラリにもメモリリークなんてよくあることだし、それらのバグも開放忘れて起きてるイージーなバグじゃないよ。
他のバグやトラブルがメモリリークという形で表面化してるにすぎない。
- 161 名前：デフォルトの名無しさん [2015/12/05(土) 08:28:25.61 ID:Pfi54LUx.net]
- >>158
具体的にいつのどのバージョンのライブラリで起きてるの？
使い終わったらメモリを開放しろ。使い終わってないなら開放する必要はない。これとスレッドプールとどこに関連性があるの？
- 162 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 09:45:44.55 ID:P9ivIQ+p.net]
- >>159詰めても無意味。
こういう連中は、まず自分の考えややり方が絶対正しく絶対に曲げない。曲げないために無理やり理由を当てはめようとしている。
で、さもそれを自分はやってるように言っているが、実際は単に本に載ってることを言ってるだけ。
実装もできない。面前で詰めてやれば発狂して勝敗がハッキリつくけどネット上では無理だね。
- 163 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 09:48:00.71 ID:BOwcKS4A.net]
- メモリの話とスレッドの話を混ぜ込んでしまうタイプは
問題の切り分けがそもそも出来ないタイプ
だからメモリリーク（）に悩まされる
スレッド間の協調と、メモリのケアは直交する別の話題
- 164 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 10:18:00.14 ID:NRX1k+Is.net]
- >>158
ちょっ漏れが作ったわけでも漏れの使い方に問題があるわけでもない階層で起きるメモリリークの責任を漏れに負わされても困る…
それに他人が作ったモジュール内でのメモリリークも結局は開放が書かれていなかったか、書かれていても正しくなかったからリークしているはず…
>>161
全面同意だが同意したからと言ってメモリリークがゼロになるかっていうと以下略
単純にクリティカルセクションとかキューによるシリアライズ（Active Objectパターン）で排他して
マルチコアを活かさずパフォーマンスをドブに捨てて良ければ平和なんだが…
- 165 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 12:34:30.29 ID:eGerJrSR.net]
- だからメモリを自動開放してほしいときはスマートポインタを使えばよいだろ
循環参照が無い限りshared_ptrで問題ないだろ
循環参照がある場合はどちらかをweak_ptrにすれば済む話だろ
現実にshared_ptrの様な物が存在して無いなら、そういう議論も意味があるが
実際にはshared_ptrは現実に有るのだから、自動管理したい場合は使えばよいだけの話でしかない
- 166 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 12:38:09.16 ID:eGerJrSR.net]
- むしろ議論すべきはshared_ptrのような参照カウンタ方式のスマポと
言語ビルドインのマークスイープ系のGCとで
どちらが良いか、だろう
参照カウンタ方式は循環参照で問題を起こすし
マークスイープ系のGCはいつ実行されるか分からない
- 167 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 13:11:12.91 ID:eGerJrSR.net]
- つまり、完璧なGCは無いということだ
完璧なGCが無い以上、使う側が状況に合わせて選べた方が良いわけだが
そうなるとC++/CLIのような変体言語しかないのが残念だ
- 168 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 13:42:35.29 ID:FurPG6R/.net]
- 普通に言語を選べば良いだけの話では
- 169 名前：デフォルトの名無しさん [2015/12/05(土) 13:49:45.99 ID:Pfi54LUx.net]
- このスレ論点が一致してないよね。
freeやdeleteを記述すべきという論点で話をしている人
freeやdeleteしたところでメモリが解放されてるわけではないですがという論点の人
freeやdeleteは当然、さらにnull等を記述すべきという論点で話をしている人
GCの実装そのものを論点にしている人
論点がばらっばらだから咬み合わない
- 170 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 13:58:32.14 ID:wharPYQR.net]
- >>158
> OSやライブラリにもメモリリークなんてよくあることだし
よくあると言うなら１０個ぐらいすぐにあげられるよな
もちろん最新版でリークする奴ね
- 171 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:16:25.84 ID:2vAbbe+i.net]
- MSのサイトにfix分と調査中のものが全部公開されてる。他のOSもlog、mlみれば腐るほど出てくる。
10個上げろとか、ほんと幼稚園児かよ、おまえらは。頭悪すぎw
- 172 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:33:31.47 ID:9PUwCRa0.net]
- C++でRAIIを徹底しておくのが一番いいよ
解放タイミングのコントロールが必要になったら後からでも柔軟に対応できるし
GCは解放に係る少し変わった条件が発生した時に滅茶汚いことをしなきゃならなくなる
- 173 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:36:53.80 ID:NRX1k+Is.net]
- shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって
どんなシチュでもベストにフィットするような一押しの決定版ってほどでも無い…
参照カウンタの排他が不要で循環参照が無いことも保証できるまで設計が詰められているなら
スレッドごとに、メモリを確保して使って返す処理を直に書くのが一番良い
- 174 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:43:55.34 ID:9PUwCRa0.net]
- 確保／解放を直に書くのはスピード的には一番速いだろうけど解放漏れバグの温床過ぎてネ
特に例外が絡むとやってられない状況になる
- 175 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:45:23.69 ID:+HxrBEdK.net]
- >>167
null云々は別言語だ馬鹿
- 176 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:47:17.08 ID:wharPYQR.net]
- >>169
> もちろん最新版でリークする奴ね
早くあげてよね w
- 177 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:52:20.59 ID:NRX1k+Is.net]
- >>172
>特に例外が絡むとやってられない状況になる
そこだけはstd::unique_ptr<T>の一押し
これで例外状況でのRAIIが完成するので真にGCが要らんところまで逝く
ていうか大概のアプリなら、例外を生じたらFatal errorなことをユーザーに知らせて終了、でいいんじゃ…
- 178 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 14:59:01.89 ID:9PUwCRa0.net]
- >>175
いやーリソース獲得した状態でファイルI/Oとかネットワークとかが絡む場合は終了じゃすまん場合が多いでしょ
- 179 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:06:58.28 ID:MOG2PmhH.net]
- 昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って
{
block_handle h = block_enter(b)
object = block_create_object(h)
block_leave(h)
}
- 180 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:10:52.59 ID:MOG2PmhH.net]
- 書き損じた
昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って
func(b){
block_handle h = block_enter(b)
object = block_create_object(h)
block_leave(b, h)
}
というので例外にも対応したリソースマネージャ作った
block_leave(b, h)せずにスコープ抜けても上位のblock_leaveで開放が保証されたり
block_leave(b, 0)で全開放とかそんなの
- 181 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:15:45.24 ID:MOG2PmhH.net]
- デメリットはblock_create〜で作成するものは全部ヒープに確保されること
結局C言語でここまで必要な案件てのが回ってこなくてあんま使ってないけどリーク予防法の参考程度に
- 182 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:24:40.86 ID:4CEShJeO.net]
- 例外にも対応って？
- 183 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:29:31.41 ID:K
]
- [ここ壊れてます]
- 184 名前：dBqlpoa.net mailto: C#でアンマネージドなメモリを扱えるのはわかった
確保したメモリ領域にオブジェクトを配置する事は出来ない？
C++で言うところの配置newを再現したいんだ
メモリの確保解放はプログラマが特別に管理してその間は普通のオブジェクトと同じように透過的に扱いたい [] - [ここ壊れてます]
- 185 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:30:53.84 ID:MOG2PmhH.net]
- >>180
例外つってるのは具体的にはSEHの話
どっかで止めた時点のblock_leave(b, h)でそれまでの開放が保証されるってこと
- 186 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:39:23.63 ID:eGerJrSR.net]
- C++にfinallyが無いのが気に食わない
今はラムダが有るのでマクロでそれっぽいものを自作したが
標準で用意しておいてほしい
C++はリソースを自分で管理する傾向のある言語なのに
finallyが無いのは本来おかしいよな
ラッパー作ってRAIIを徹底しろってことなんだろうけど
すべてのリソースに対してラッパーを用意するのは面倒だよ
fainallyが有ったって邪魔になるわけでもないのに
最終的に使うかどうかは利用者が選べばよいことだし
C++ってそういう言語だろ
- 187 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 15:50:01.56 ID:9PUwCRa0.net]
- >>183
C++にはテンプレートがあるからリソースの型をテンプレート引数とするラッパーを作るのは
そんなに面倒なことじゃないと思う
あとC++でRAIIを徹底してればfainallyの必要性を感じたことはない
fainallyを書かなければいけない時点で危なっかしいコードだと思う
- 188 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 16:34:34.82 ID:+HxrBEdK.net]
- むしろfinallyってデストラクタがない言語だから
必要なものなんじゃ…
どうしても必要ならデストラクタで任意のラムダ呼ぶ
ユーティリティクラス作れば同じこと出来るし
- 189 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 16:50:13.74 ID:+HxrBEdK.net]
- 98以前でもローカルクラス定義できるんだからすこし冗長なだけで同じだし
- 190 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 16:59:06.52 ID:NRX1k+Is.net]
- 例外発生はバグ、というプログラミングしかしたことないからよくは知らんが、
try {
try {
/*...*/
} catch (std::badalloc()) {
/*...*/
} catch (UserException e) {
/*...*/
}
} catch (...) { // fainally節の代わり
/*...*/
}
じゃあいかんの？実行時コストは知らん
- 191 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 17:00:08.66 ID:NRX1k+Is.net]
- ｽﾏﾝ
誤： } catch (std::badalloc()) {
正： } catch (std::badalloc e) {
- 192 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 17:32:52.06 ID:+HxrBEdK.net]
- 違う。そんぐらいググれ
- 193 名前：デフォルトの名無しさん mailto:sage [2015/12/05(土) 17:37:26.87 ID:KdBqlpoa.net]
- デストラクタの問題点は不可視なところだな
usingやfinallyは目に見えるから安心する
|
 |
