15/11/30 19:50:22.70 isQX20zS.net
メモリの解放すら管理できない奴が、複雑な仕様を管理できるとは到底思えない・・・。
メモリの解放なんてなんの苦にもならんが・・・。
117:デフォルトの名無しさん
15/11/30 20:14:21.83 Ee9Jt/HC.net
やれやれw
MSやLinuxやFreeBSDまでメモリリークやらかす理由が分らないのか。
118:デフォルトの名無しさん
15/11/30 20:30:16.55 UQyKbzCH.net
>>116
また反論できずに逃走かよw
そもそも欧米は原因分かっててもバグ無視する連中だろうがw
ライセンスで守られてりゃ平気で放置するぞ
119:デフォルトの名無しさん
15/11/30 20:33:04.33 V9s4KAVu.net
人生の管理ができない奴が、メモリを管理できるとは到底思えない
120:デフォルトの名無しさん
15/11/30 20:49:26.08 UQyKbzCH.net
そもそもLinuxカーネルもFreeBSDカーネルもC言語だろ
馬鹿丸出しだなw
121:デフォルトの名無しさん
15/11/30 21:16:22.39 zT+q2mn+.net
>>115
それな
プログラミングにおいてメモリ周囲はまだ初歩だよな
そしてマルチスレッドはそれよりは大変だがこれも慣れると
結局大事なところをガッチリ排他処理するだけのことだしな
プログラミングって最後はインタフェース設計だけだから
使いやすくてコンパクトなインタフェースを求めていくだけ
これがプログラミング道の後半の道のり
122:デフォルトの名無しさん
15/11/30 21:18:50.76 Ee9Jt/HC.net
>>120
で例外系の実装がないから破綻するんだよ。実務経験ないとすぐ短絡的になるのが分る。
123:デフォルトの名無しさん
15/11/30 21:25:49.32 zT+q2mn+.net
意味が不明すぐるｗ
124:デフォルトの名無しさん
15/11/30 21:28:33.92 Ee9Jt/HC.net
うむ。まだおまえには早いかもしれない。
125:デフォルトの名無しさん
15/11/30 21:47:43.54 UQyKbzCH.net
>>122
馬鹿相手にしても時間の無駄だぞ
こいつ具体的なこと何も言わんし
126:デフォルトの名無しさん
15/11/30 22:07:34.86 zT+q2mn+.net
>>124
そやね
一連のレスの意図すらよーわからんわ
127:デフォルトの名無しさん
15/12/01 00:23:09.00 s1rcgCDh.net
Guilty Crown?
たしかに失敗作だったなあ…
128:デフォルトの名無しさん
15/12/01 01:24:29.91 mVPa8mQr.net
GCが云々というより抽象的なプログラミングしたい時は基本的なメモリ管理を言語に任せたいという欲求
129:デフォルトの名無しさん
15/12/01 01:27:09.96 mVPa8mQr.net
>>113
c++素人なんだけどリーク単体はともかくそれにメモリ破壊が合わさると頭がおかしくなって死ぬ
みたいな感じ？
130:デフォルトの名無しさん
15/12/01 01:30:32.01 s1rcgCDh.net
GCは関数型プログラミングでのみ正当化される
命令型プログラミングでは全く正当化されない
命令型プログラミング（＝チューリングマシンに基づく計算モデル）は読み書きの「順序」こそがネ申なので
命令コードの「順序」を横断して存続するブツは善と悪の最終戦争で滅ぼされるであろう
つまり確保し、使ったら後開放する、これを明示的に書き下す姿勢こそが正しい
131:デフォルトの名無しさん
15/12/01 01:31:50.27 s1rcgCDh.net
>GCは関数型プログラミングでのみ正当化される
ちな、これは処理系の裏方としての存在が許される、の意味
132:デフォルトの名無しさん
15/12/01 01:36:31.76 mVPa8mQr.net
関数型プログラミング好きだけど
代数型データ型と型クラスでモナドとかアプリカティブとかtraverse、free monadとかやってる時に
メモリ管理だの言われたら余裕で死ねるな
本物のhaskellプログラマはhaskellで低レイヤを書くらしいけど
133:運用中（トリなしｗ
15/12/01 04:32:07.54 79aHC4wo.net
口 先 人 間 展 覧 会 。（ｱﾊ
134:デフォルトの名無しさん
15/12/01 12:55:11.72 S8usJREu.net
>>128
> メモリ破壊が合わさると
これが合わさるとなんでもありありなので何が起きても不思議はない
なので、ダングリングポインタの管理と配列のレンジチェックはちゃんとやるべし
135:デフォルトの名無しさん
15/12/03 12:20:09.85 AuS7g0FI.net
ここでメモリ確保
ここでメモリ解放
たったこれだけが書けない管理できないとかw
136:デフォルトの名無しさん
15/12/03 12:23:19.04 n26CULk9.net
知らないでやるって幸せなことなんですね
137:デフォルトの名無しさん
15/12/03 13:19:32.39 N5r0JkUz.net
>>134
下には下がいるんだよ
138:デフォルトの名無しさん
15/12/03 13:29:54.15 JbiOZ/E3.net
メモリリークは開放忘れでなると思ってる低レベルがいるのか。
139:デフォルトの名無しさん
15/12/03 14:07:05.91 n26CULk9.net
低レベルなことを舐めるなよ
140:デフォルトの名無しさん
15/12/03 16:32:54.69 JraK7tKY.net
>>134
mallocでOSから確保したメモリはfreeで解放されないんだが、
「ここで解放」はどうやって書くんでしょう?
141:デフォルトの名無しさん
15/12/03 19:43:25.89 R/g8PPkY.net
>>137や>>139みたいのが知識や技術に溺れて本質を見失い、
人と会話ができなくなった人の見本なんだろうか
142:デフォルトの名無しさん
15/12/03 19:47:17.15 JraK7tKY.net
>>140
今まで正しいと信じきってた鰯の頭が迷信だと指摘され発狂中
143:デフォルトの名無しさん
15/12/03 19:53:39.75 R/g8PPkY.net
>>141おｗ おまえ会社で孤立してるだろ派遣ｗ
144:デフォルトの名無しさん
15/12/03 20:32:35.32 R04IP6VM.net
確保したやつが解放するんだぞ。大丈夫か？
145:デフォルトの名無しさん
15/12/03 20:33:46.24 cWTIfUD3.net
想像を絶するアホは居るもんだよ
if (cond) exp; の場合も中カッコを必ず付ける流派ってのがあって
理由を聞くと
if (cond) {exp1; exp2;}とするはずが
if (cond) exp1; exp2;としてしまうのを防ぐための常に中カッコらしい
中カッコを書き忘れるくらいの意識レベルで書かれたコードって
他のとこももう全部ダメだろそれは
146:デフォルトの名無しさん
15/12/03 20:52:03.75 s/TINiTx.net
>>144
お前がアホなｗｗｗ
147:デフォルトの名無しさん
15/12/03 21:25:03.70 n26CULk9.net
カッコ先につけといたほうが 後々、都合がいいことも
148:デフォルトの名無しさん
15/12/03 21:30:08.65 WeEbsZB7.net
アホな書き方といえば
if ( 1 == a ) {
って比較元と先を逆にしてる奴
149:デフォルトの名無しさん
15/12/03 21:41:57.39 4rUKwdGH.net
別におかしくない
基準値が先にあって、それと比べてaがどうなのか、と考えるか
aが先にあって、基準値と比べてどうなのか、と考えるかの違いでしか無いから
どっちでも良い
150:デフォルトの名無しさん
15/12/03 21:59:47.07 /xqyH1ID.net
>>147
知ってて言ってると思うが、定数を==の左辺にするのは
if (a=1) { ...
と書き間違うのを恐れているらしい
>>139
free()から設計し直す、
まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ
>>135
スレッド安全に書かない奴が悪いていうかそれは別の話
シングルスレッド状況（またはそれと等価な状況）では>>134の言っていることは全く正しい
151:デフォルトの名無しさん
15/12/03 22:27:47.14 zepIVOGi.net
ここ数日一気にレベルが下がったなw
ＧＣの話しろよw
152:デフォルトの名無しさん
15/12/03 22:46:13.76 srgQPG9D.net
つーか前スレと同じこと書いてる人多数
頼むから前スレ読んできて
153:デフォルトの名無しさん
15/12/04 04:37:18.54 HtuddwW0.net
【 オンラインTCGエディター 】 >>1
デュエル・マスターズ的な非電源TCGの 《 オンライン化ツクール系ソフト 》 制作の企画。
例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してあるソフト（エディター）。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ライブオン、ディメンション・ゼロ、カードヒーロー、シャーマン・キングなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。
設計思想は 《 RPGツクール 》 が良いかな？ 他に、優れたエディター有ったら挙げてみて。
個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。
↓
エディター群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。
↓
遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述３つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど発売済みゲームソフトが存在してるケースはベンダーに研究させる。
↓
各社TCGを再現するテストプレイ ⇒ 更に改良や修正。
↓
機能制限した下位版を５万円以上で発売 ＋ デュエリ－グ用に改造した上位版でサーバー稼動＝営業開始。
↑
下位版の改造および商用利用には、別途で当社との契約が必要。
さ～て、製作ベンダー見つけよっと！ｗｗ（ｸｽ
ｽﾚﾘﾝｸ(entrance2板:-18番)
154:デフォルトの名無しさん
15/12/04 12:21:13.29 GzeAUkqU.net
>>149
>free()から設計し直す、
>まあfree()の度OSにメモリを律儀に返していたらパフォーマンスが多少落ちるがGCに精神を汚染されるよりはマシ
じゃ>>134は設計し直してから言うんだな。坊や。
って、事でオッケーね。
155:デフォルトの名無しさん
15/12/04 20:05:33.81 SAJ9n/s7.net
>>137これって何が言いたいの？OSやライブラリ自体にミスがあるって言いたいの？
wikiより
>メモリリーク (Memory leak) とは、プログラミングにおけるバグの一種。
>プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。
>プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。
>>137みたいなこと言う奴って、電磁波からデータが盗まれる！対応しないと！とか言い出すタイプ？
156:デフォルトの名無しさん
15/12/04 21:16:45.71 7W1HEY29.net
>>
157:151 そもそも１５年ぐらい前から延々繰り返されてるんだが…
158:デフォルトの名無しさん
15/12/04 23:45:19.53 j6MEWqDN.net
>>154
開放コードを忘れずに書いたのに開放されないという怪奇現象がマルチスレッド状況ではしばしばあるんじゃー！
マルチコア時代になってこれはますます危険になった
見ただけで正しさがわかる系のスレッド安全策はクロックサイクルを糞のごとく消費するし…
こういうのは専門家が徹底的にデバッグしたGCで面倒を見て欲しいと思う反面、
やっぱプロセス全体のごみ処理を選任モジュールにやらせるのはクロックサイクルをドブに捨てるがごとき
センス無い設計なｷﾓｽ、、
159:デフォルトの名無しさん
15/12/05 00:08:28.41 +HxrBEdK.net
それ単にメモリバリアの問題じゃ…
160:デフォルトの名無しさん
15/12/05 04:01:37.91 2vAbbe+i.net
>>154
入門書に書いてるコードしか見たことないんだね。
スレッドプールみたいなテクニックは高速化のためにみな普通に使うんだよ。
OSやライブラリにもメモリリークなんてよくあることだし、それらのバグも開放忘れて起きてるイージーなバグじゃないよ。
他のバグやトラブルがメモリリークという形で表面化してるにすぎない。
161:デフォルトの名無しさん
15/12/05 08:28:25.61 Pfi54LUx.net
>>158
具体的にいつのどのバージョンのライブラリで起きてるの？
使い終わったらメモリを開放しろ。使い終わってないなら開放する必要はない。これとスレッドプールとどこに関連性があるの？
162:デフォルトの名無しさん
15/12/05 09:45:44.55 P9ivIQ+p.net
>>159詰めても無意味。
こういう連中は、まず自分の考えややり方が絶対正しく絶対に曲げない。曲げないために無理やり理由を当てはめようとしている。
で、さもそれを自分はやってるように言っているが、実際は単に本に載ってることを言ってるだけ。
実装もできない。面前で詰めてやれば発狂して勝敗がハッキリつくけどネット上では無理だね。
163:デフォルトの名無しさん
15/12/05 09:48:00.71 BOwcKS4A.net
メモリの話とスレッドの話を混ぜ込んでしまうタイプは
問題の切り分けがそもそも出来ないタイプ
だからメモリリーク（）に悩まされる
スレッド間の協調と、メモリのケアは直交する別の話題
164:デフォルトの名無しさん
15/12/05 10:18:00.14 NRX1k+Is.net
>>158
ちょっ漏れが作ったわけでも漏れの使い方に問題があるわけでもない階層で起きるメモリリークの責任を漏れに負わされても困る…
それに他人が作ったモジュール内でのメモリリークも結局は開放が書かれていなかったか、書かれていても正しくなかったからリークしているはず…
>>161
全面同意だが同意したからと言ってメモリリークがゼロになるかっていうと以下略
単純にクリティカルセクションとかキューによるシリアライズ（Active Objectパターン）で排他して
マルチコアを活かさずパフォーマンスをドブに捨てて良ければ平和なんだが…
165:デフォルトの名無しさん
15/12/05 12:34:30.29 eGerJrSR.net
だからメモリを自動開放してほしいときはスマートポインタを使えばよいだろ
循環参照が無い限りshared_ptrで問題ないだろ
循環参照がある場合はどちらかをweak_ptrにすれば済む話だろ
現実にshared_ptrの様な物が存在して無いなら、そういう議論も意味があるが
実際にはshared_ptrは現実に有るのだから、自動管理したい場合は使えばよいだけの話でしかない
166:デフォルトの名無しさん
15/12/05 12:38:09.16 eGerJrSR.net
むしろ議論すべきはshared_ptrのような参照カウンタ方式のスマポと
言語ビルドインのマークスイープ系のGCとで
どちらが良いか、だろう
参照カウンタ方式は循環参照で問題を起こすし
マークスイープ系のGCはいつ実行されるか分からない
167:デフォルトの名無しさん
15/12/05 13:11:12.91 eGerJrSR.net
つまり、完璧なGCは無いということだ
完璧なGCが無い以上、使う側が状況に合わせて選べた方が良いわけだが
そうなるとC++/CLIのような変体言語しかないのが残念だ
168:デフォルトの名無しさん
15/12/05 13:42:35.29 FurPG6R/.net
普通に言語を選べば良いだけの話では
169:デフォルトの名無しさん
15/12/05 13:49:45.99 Pfi54LUx.net
このスレ論点が一致してないよね。
freeやdeleteを記述すべきという論点で話をしている人
freeやdeleteしたところでメモリが解放されてるわけではないですがという論点の人
freeやdeleteは当然、さらにnull等を記述すべきという論点で話をしている人
GCの実装そのものを論点にしている人
論点がばらっばらだから咬み合わない
170:デフォルトの名無しさん
15/12/05 13:58:32.14 wharPYQR.net
>>158
> OSやライブラリにもメモリリークなんてよくあることだし
よくあると言うなら１０個ぐらいすぐにあげられるよな
もちろん最新版でリークする奴ね
171:デフォルトの名無しさん
15/12/05 14:16:25.84 2vAbbe+i.net
MSのサイトにfix分と調査中のものが全部公開されてる。他のOSもlog、mlみれば腐るほど出てくる。
10個上げろとか、ほんと幼稚園児かよ、おまえらは。頭悪すぎw
172:デフォルトの名無しさん
15/12/05 14:33:31.47 9PUwCRa0.net
C++でRAIIを徹底しておくのが一番いいよ
解放タイミングのコントロールが必要になったら後からでも柔軟に対応できるし
GCは解放に係る少し変わった条件が発生した時に滅茶汚いことをしなきゃならなくなる
173:デフォルトの名無しさん
15/12/05 14:36:53.80 NRX1k+Is.net
shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって
どんなシチュでもベストにフィットするような一押しの決定版ってほどでも無い…
参照カウンタの排他が不要で循環参照が無いことも保証できるまで設計が詰められているなら
スレッドごとに、メモリを確保して使って返す処理を直に書くのが一番良い
174:デフォルトの名無しさん
15/12/05 14:43:55.34 9PUwCRa0.net
確保／解放を直に書くのはスピード的には一番速いだろうけど解放漏れバグの温床過ぎてネ
特に例外が絡むとやってられない状況になる
175:デフォルトの名無しさん
15/12/05 14:45:23.69 +HxrBEdK.net
>>167
null云々は別言語だ馬鹿
176:デフォルトの名無しさん
15/12/05 14:47:17.08 wharPYQR.net
>>169
> もちろん最新版でリークする奴ね
早くあげてよね w
177:デフォルトの名無しさん
15/12/05 14:52:20.59 NRX1k+Is.net
>>172
>特に例外が絡むとやってられない状況になる
そこだけはstd::unique_ptr<T>の一押し
これで例外状況でのRAIIが完成するので真にGCが要らんところまで逝く
ていうか大概のアプリなら、例外を生じたらFatal errorなことをユーザーに知らせて終了、でいいんじゃ…
178:デフォルトの名無しさん
15/12/05 14:59:01.89 9PUwCRa0.net
>>175
いやーリソース獲得した状態でファイルI/Oとかネットワークとかが絡む場合は終了じゃすまん場合が多いでしょ
179:デフォルトの名無しさん
15/12/05 15:06:58.28 MOG2PmhH.net
昔C言語で数珠繋ぎの独自スコープとしてblock_enter/block_leaveというのを作って
{
block_handle h = block_enter(b)
object = block_create_object(h)
block_leave(h)
}
180:デフォルトの名無しさん
15/12/05 15:10:52.59 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:デフォルトの名無しさん
15/12/05 15:15:45.24 MOG2PmhH.net
デメリットはblock_create～で作成するものは全部ヒープに確保されること
結局C言語でここまで必要な案件てのが回ってこなくてあんま使ってないけどリーク予防法の参考程度に
182:デフォルトの名無しさん
15/12/05 15:24:40.86 4CEShJeO.net
例外にも対応って？
183:デフォルトの名無しさん
15/12/05 15:29:31.41 K
184:dBqlpoa.net
185:デフォルトの名無しさん
15/12/05 15:30:53.84 MOG2PmhH.net
>>180
例外つってるのは具体的にはSEHの話
どっかで止めた時点のblock_leave(b, h)でそれまでの開放が保証されるってこと
186:デフォルトの名無しさん
15/12/05 15:39:23.63 eGerJrSR.net
C++にfinallyが無いのが気に食わない
今はラムダが有るのでマクロでそれっぽいものを自作したが
標準で用意しておいてほしい
C++はリソースを自分で管理する傾向のある言語なのに
finallyが無いのは本来おかしいよな
ラッパー作ってRAIIを徹底しろってことなんだろうけど
すべてのリソースに対してラッパーを用意するのは面倒だよ
fainallyが有ったって邪魔になるわけでもないのに
最終的に使うかどうかは利用者が選べばよいことだし
C++ってそういう言語だろ
187:デフォルトの名無しさん
15/12/05 15:50:01.56 9PUwCRa0.net
>>183
C++にはテンプレートがあるからリソースの型をテンプレート引数とするラッパーを作るのは
そんなに面倒なことじゃないと思う
あとC++でRAIIを徹底してればfainallyの必要性を感じたことはない
fainallyを書かなければいけない時点で危なっかしいコードだと思う
188:デフォルトの名無しさん
15/12/05 16:34:34.82 +HxrBEdK.net
むしろfinallyってデストラクタがない言語だから
必要なものなんじゃ…
どうしても必要ならデストラクタで任意のラムダ呼ぶ
ユーティリティクラス作れば同じこと出来るし
189:デフォルトの名無しさん
15/12/05 16:50:13.74 +HxrBEdK.net
98以前でもローカルクラス定義できるんだからすこし冗長なだけで同じだし
190:デフォルトの名無しさん
15/12/05 16:59:06.52 NRX1k+Is.net
例外発生はバグ、というプログラミングしかしたことないからよくは知らんが、
try {
try {
/*...*/
} catch (std::badalloc()) {
/*...*/
} catch (UserException e) {
/*...*/
}
} catch (...) { // fainally節の代わり
/*...*/
}
じゃあいかんの？実行時コストは知らん
191:デフォルトの名無しさん
15/12/05 17:00:08.66 NRX1k+Is.net
ｽﾏﾝ
誤： } catch (std::badalloc()) {
正： } catch (std::badalloc e) {
192:デフォルトの名無しさん
15/12/05 17:32:52.06 +HxrBEdK.net
違う。そんぐらいググれ
193:デフォルトの名無しさん
15/12/05 17:37:26.87 KdBqlpoa.net
デストラクタの問題点は不可視なところだな
usingやfinallyは目に見えるから安心する
194:デフォルトの名無しさん
15/12/05 18:00:14.20 NRX1k+Is.net
>>189
内側のtry～catchから再throwするのを忘れたorz
内側のtry～catchから再throwして外側ので再捕捉したらいいんじゃ…
195:デフォルトの名無しさん
15/12/05 18:22:16.37 0v99S3Ys.net
例外をロジックとして使うなってばっちゃんが言ってた
196:デフォルトの名無しさん
15/12/05 19:38:41.80 eGerJrSR.net
>>191
throwせずにreturnするパスが有ったらどうするんだよ
そういうのを防ぐためのfinallyやRAIIなのに
まったくちんぷんかんぷん
結局returnする前に手動で忘れないようにthrowすることを強制するんなら
goto文とか開放用ラムダ呼び出すのとかと替わらないだろ
197:デフォルトの名無しさん
15/12/05 20:44:27.97 ZNw2R9x1.net
だから忘れる忘れないレベルをぶち込んでくるのは止めようやｗ
これをぶち込むから全ての議論が池沼レベルになってる
198:デフォルトの名無しさん
15/12/06 06:02:02.37 JYyEEHci.net
異常系で例外返す仕様のライブラリが失敗。
199:デフォルトの名無しさん
15/12/06 08:06:42.75 XhferEg+.net
>>194
GCなんて池沼のために生まれたようなものだし・・・
NULLったりfreeったりすることすらまともに把握、指示しきれない
200:デフォルトの名無しさん
15/12/06 11:36:02.06 G3VNQyn5.net
c++のデストラクタって後処理に失敗しても
例外投げられないからウンコ
結果的にエラーを握り潰すゴミコードを量産する原因になってる
201:デフォルトの名無しさん
15/12/06 11:40:47.08 zGnP2wpv.net
そのクラスが管理してる範囲で後処理の失敗って何が起こるの？
202:デフォルトの名無しさん
15/12/06 12:05:41.69 kVHO13oj.net
どうしてもやりたいなら対処法はあるしなぁ。
203:デフォルトの名無しさん
15/12/06 12:23:19.67 MkaxAbH2.net
現実的な確率で発生して無視出来ないリスクが有る解放処理はデストラクタでやるべきじゃない
そういうリソースに対してデストラクタがやる事はプログラマに対しいて未解放のリソースを通知する事だけでよい
204:デフォルトの名無しさん
15/12/06 12:30:12.96 XhferEg+.net
具体的に何があるん？？？
クラス内で使っているリソースで解放に失敗（失敗し続ける）するって。
205:デフォルトの名無しさん
15/12/06 13:14:17.95 lk97yytv.net
どっか他のオブジェクトと共有してるものを解放しようとして失敗するとか？
それはそもそもの設計に問題ありすぎだが。。
206:デフォルトの名無しさん
15/12/06 15:01:28.77 XhferEg+.net
>>202
だよね。
否定しようとして無理やり現象を創りだそうとしているとしか・・・。
でもその無理やりつくった現象は、そもそも論理設計のミスが大前提だったりする。
論理設計のミスまで言われたらなんにも組めないわ。
207:デフォルトの名無しさん
15/12/06 15:42:32.97 wxELMJDc.net
>>200
デストラクタの中で起きた例外については
try { } catch (...) { }で囲った上で、リカバリ処理（何とかしてリソース解法漏れをなくす）を行えばいいじゃない？
もし例外発生後に行うべき適切なリカバリ処理が書けない（存在しない）んだとすると、
もはやデストラクタ内に限った話ではなくなって、例外を発生させた時点で設計か実装にバグが居たとしか…
208:デフォルトの名無しさん
15/12/06 16:03:58.23 5cQQ9Lrm.net
バグ（リソースへのポインタやハンドルを壊しちゃったとか）以外で
リソース解放に失敗するケースなんて１つも思いつかない
209: ◆QZaw55cn4c
15/12/06 16:19:39.63 4bjdt2kC.net
fclose() にも失敗があるじゃないか？
210:デフォルトの名無しさん
15/12/06 16:54:30.29 djRjUyAt.net
fflush() しとけばＯＫ
211:デフォルトの名無しさん
15/12/06 16:59:21.77 5cQQ9Lrm.net
>>206
fcloseの失敗はハンドルが正しい限りflush時のI/Oエラーの通知であって、その場合でもリソースは解放されるよ
212:デフォルトの名無しさん
15/12/06 17:35:51.31 G3VNQyn5.net
c++信者ってアホだなー
みんなこんなんなの？
URLﾘﾝｸ(cpplover.blogspot.jp)
213:デフォルトの名無しさん
15/12/06 17:44:16.50 G3VNQyn5.net
fcloseに失敗してファイルに正常に書き込みされなくてもシカトしてるんだよね？
それともerrnoとかチェックしちゃってるの？
214:デフォルトの名無しさん
15/12/06 19:05:12.47 RyqEmv/A.net
まあC++の例外を援護するつもりはないがそういう場合は
普通にフラッシュしろよ
そもそもC++が二重例外時にstd::terminate呼ぶのはGCのあるなしに
関係ないからスレ違いだお前ら。よそでやれ
215:デフォルトの名無しさん
15/12/06 19:24:21.60 XJADMoL5.net
GCというよりライブラリとの関係だな
.net framework libraryのいくつかのクラスは中で自分自身をロックするから
プログラマ側で参照が切れてもGCされない
216:デフォルトの名無しさん
15/12/06 19:25:02.74 XJADMoL5.net
今日一日なんでFormがGCされないのか調べてて大変な思いしたわ
217:デフォルトの名無しさん
15/12/06 19:31:56.53 bkfT5adp.net
>>213
よくそこまで調べたな。( ・∀・)つ旦 お茶ﾄﾞｿﾞｰ
218:デフォルトの名無しさん
15/12/06 19:37:02.30 Gxx7TgqC.net
いまだにプログラマはアセンブリ言語を使えるべきだ派？
219:デフォルトの名無しさん
15/12/06 19:40:49.58 JYyEEHci.net
アセンブラ知ってると知らないとじゃスキルレベル全然違うからな。話にならないぐらいのレベル差
220:。
221:デフォルトの名無しさん
15/12/06 20:22:00.43 RyqEmv/A.net
まあ実際Java屋とかってコンパイラやメモリ意識できない奴多いよね
以前2chで↓みたいなコードが勝手に最適化されると思って
StringBuilder使う奴は馬鹿！とか言い出す奴いて目眩したわ
String s;
for(int i = 0; i < strarray.length; ++i){ s += strarray[i]; }
222:デフォルトの名無しさん
15/12/06 20:58:14.61 wxELMJDc.net
>>217
それはStringの+=の実装次第ではあんまり差が付かないケースなんじゃ…
（左辺と右辺が別の実体である（アドレスが違う）ケースでは多分右辺を左辺の末尾に1回コピーするだけという実装が有り得る
真に糞なのは
StringBuilder sb;
String s = "Hello";
sb.Append("[" + s + "]");
が遅いからStringBuilderは糞、と結論付けるニンゲンであってコードではない、
みたいな？
223:デフォルトの名無しさん
15/12/06 21:26:17.35 IAFYzi6n.net
>>217みたいにループ中で一個づつくっつける場合は別にして
s = a + b + c + d; // このように、高々数個をくっつけてる場合は
Javaだと無駄にStringBufferが作られてダメと言うのが定説だったが
C#の場合は内部的にString#Concatに置き換えられて
それによって
StringBuilder b = 略
s = a.Append(b)中略.Append(d).ToString()
するより早い、という話題があってそれと勘違いしたのかもね
224:デフォルトの名無しさん
15/12/06 21:28:20.04 IAFYzi6n.net
いちおう訂正しとこｗ
StringBuilder sb = 略
s = sb.Append(a)中略.Append(d).ToString()
225:デフォルトの名無しさん
15/12/06 21:50:20.98 MkaxAbH2.net
そもそもその最適化は仕様なのか
226:デフォルトの名無しさん
15/12/06 22:27:08.91 RyqEmv/A.net
>>218
？？、これJavaだぞ。演算子オーバーロードなんて出来ないから
>>219
違う違う。+の連結がStringじゃなくてStringBufferに
最適化されるらしいって話だけで、StringBulderって
必要ないでしょ？レガプロ？(笑)、って認識レベル
しかもそいつ一人ならまだしもスレに同じレベルの
認識の奴結構多かったよ。レベルの低さ舐めたらあかんで
227:デフォルトの名無しさん
15/12/07 01:50:02.58 3Z+aJEnB.net
>>222
実装云々でなんで演算子オーバーロードがでてくるんだ？
228:デフォルトの名無しさん
15/12/07 05:22:13.32 QznWTKRS.net
逆だろ？
C#との勘違いでないなら、その最適化されるJVM実装とやらを示さないと
229:デフォルトの名無しさん
15/12/07 07:11:57.22 X5Y+ON7N.net
>>219
全く逆の認識してないか？
classファイル解析したら分かるけど、ループ中の+=の方が問題で毎回newされるから遅い
s = a + b + c + d の方は一つしかStringBuilderのインスタンスは作られない
230:デフォルトの名無しさん
15/12/07 08:02:18.14 nEG5/lEo.net
こうやって、比較的プログラミングという行為を好きでいる・好きでやっている・興味を持っているという人ですらまともに言語仕様を理解出来ていない。
malloc、freeで管理、GCで管理だと、機構の複雑さは後者。
結局GCもその機構を正しく理解しないと参照が切れてない、参照が切れていても別のリソースが・・・と。
機構を正しく理解していることが前提なら、機構はシンプルなほうがいい。
その点を誤ったから
>プログラマをメモリ管理から開放する！
>といいつつ、メモリリーク問題の文献が大量にある。
>これすなわち、メモリリーク問題が全然解決していないということ。
>さらに、メモリ解放のタイミングの文献まで大量に生み出した。
>これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
なんてことになったんだろうね
231:デフォルトの名無しさん
15/12/07 08:12:44.70 EA
232:/TwAsy.net
233:デフォルトの名無しさん
15/12/07 09:22:45.43 q5G1dKJA.net
やっぱりARC最強だな
234:デフォルトの名無しさん
15/12/07 15:38:30.00 6rSJBSiX.net
結局いつ開放されるか分からないってのが曲者で
使い終わったら確実にリソースを開放してほしいときは
別の仕組みが必要になってしまったってのが問題だろう
その別の仕組も、C++のデストラクタのようにクラスのメンバに関して
芋づる式に呼び出す仕組みがないから
C++のデストラクタがやっていることを手動で再現しなければならない始末
一方でC++のスマポなどの参照カウンタ方式は循環参照だけが問題だが
それ以外の問題が一切発生しない、デメリットは循環参照だけ
しかも循環参照が発生する場合は片方をweak_ptrにすれば良い
ということが分かりきっているし、循環参照が発生する箇所も
設計段階でわかる
循環参照に気を配れる知能が有るのであれば、参照カウンタ方式のほうがスマート
235:デフォルトの名無しさん
15/12/07 17:29:26.60 nEG5/lEo.net
>>229
処理速度やタイミングがシビアな組み込みや科学技術計算系とかならいざしらず、
ソレ以外は、実際の解放のタイミング自体は問題にならんでしょ。(膨大なメモリの使用も別だけど)
問題は、使い終わったよーって明示しないで良い。という運用が結局、悪い結果をもたらしているという点。
メモリの管理をしっかり最後までやるクセのないプログラマは、
平然と参照が途切れている可能性のあるポイントで参照しに行こうとする。
結局は、そいつがバカだからに集約されてしまうんだけど、使い終わりの明示をしない文化がバカを生む土壌となっている
236:デフォルトの名無しさん
15/12/07 18:21:02.44 q5G1dKJA.net
そういう事になる原因ってさ、構造がぐちゃぐちゃでオブジェクト間も依存しまくって、
いつ解放していいのかわかんねえーというヘボいプログラミングなんだろうなと思う。
237:デフォルトの名無しさん
15/12/07 18:23:12.12 tBfENkIS.net
と馬鹿なSEやPGはそう思うだろうなとも思う。
238:デフォルトの名無しさん
15/12/07 19:54:31.23 GogXEvJk.net
ある意味メモリなんて一番扱いやすいリソースだからな。
メモリの管理すら適当なプログラマが、他のリソースを適切に扱える訳がないのに、GC前提の言語ではそちらのケアが言語側でやりづらくなってしまっている。
239:デフォルトの名無しさん
15/12/07 20:05:22.53 W4QZalq7.net
メモリ意識した時点で雑魚プログラマ決定だろ。
JavaScriptもPascalも使えないんじゃ話にならないよ。
おちんぽ見られることを意識しすぎて温泉に入れないようなもの。
癒やしのない人生に刺激なんてない。←これ名言
240:デフォルトの名無しさん
15/12/07 20:07:43.02 nEG5/lEo.net
>>231
そう。そういう状態にしちゃう原因が、いい加減なメモリの管理で教育された結果にあるのではないか？ということで。
241:デフォルトの名無しさん
15/12/07 20:09:47.14 nEG5/lEo.net
>>234
だれの名言かしらんが、
刺激のない人生に癒やしはない。
ならなんかしっくりくる。まぁ逆とっても同じ意味だからいいんだけど・・・。
242:デフォルトの名無しさん
15/12/07 20:16:31.05 ZNsl6+sP.net
メモリ意識しないプログラマとかカスだろ。
243:デフォルトの名無しさん
15/12/07 20:42:25.43 wP/KA6jo.net
JavaやC#ではリソースをプログラマが管理してはいけない
せっかくメモリ管理を透過的にしたのにリソース管理でコードをより複雑化させては意味がない
真っ当な教育を受けた少数のプログラマがSafeHandleを作成する
末端のプログラマはSafeHandleのファイナライザに全てを任せてメモリと同様にリソースを完全に透過的に扱うべきだ
244:デフォルトの名無しさん
15/12/07 23:25:36.31 QznWTKRS.net
>>230
JavaのGCでサーバー応答が止まるなんてザラにある話だよ
それを聞いたことがないなら文系SEと同レベルだね
>>238
管理放棄して開くだけ開いて計算資源を食い潰す玄人気取りプログラマ
245:デフォルトの名無しさん
15/12/08 00:48:22.00 pyjW8EMu.net
full GCが頻繁に生じちゃうのは明らかに設計ミスやな
immutableな短命objectを使いまくるのだ。。
つかimmutableなオブジェクト使いまくるとGCないときつくね？
246:デフォルトの名無しさん
15/12/08 02:05:45.39 H3TgUaFB.net
RAIIで事足りる
immutableかどうかとＧＣは無関係
247:デフォルトの名無しさん
15/12/08 02:21:53.95 RVFMry3L.net
むしろ短命なオブジェクトなんてスタックで十分だし
管理するならshared_ptrのが優れてる
248:デフォルトの名無しさん
15/12/08 03:41:28.67 pU1qoPPC.net
ライブラリ、アプリ、ユーザの三者で考えないと
一部リソースはユーザがを閉じることができる。
そのときアプリの参照を消す仕組みがどのライブラリにもない
249:デフォルトの名無しさん
15/12/08 08:07:46.77 rWJ9nJMw.net
>>243
よくわからんが、それは階層的におかしいのでは？
ユーザーがアプリを通さずにリソースを閉じる事ができるって事？
250:デフォルトの名無しさん
15/12/08 12:16:07.11 VV6tYNBF.net
Manager.Execute((res) => ...);
これが終着点
短命なリソースは全てこの形式で事足りし長命なリソースはファイナライザにでも任せればよい
ユーザーが管理しちゃ絶対にダメ
251:デフォルトの名無しさん
15/12/08 15:11:36.25 DYNM3xm/.net
このスレでGCいらんて言ってる人たちは環境に恵まれてるんだなぁって思う
252:デフォルトの名無しさん
15/12/08 15:20:06.88 Bkt0caBE.net
GC
タモリが昔宣伝してやつ？
253:デフォルトの名無しさん
15/12/08 15:28:54.90 NMHe7TFl.net
むしろGCなんて環境良くないと使えないだろ
254:デフォルトの名無しさん
15/12/08 16:16:30.38 zjJIjn6V.net
参照がなくなったタイミングで必ず開放してくれて
かつ
循環参照でも問題ない
パーフェクトなGCが有れば最高なわけだが
実際にはそんなGCは無い
となれば、通常であれば言語側は性質の異なる複数のGCを用意しておいて
使う側はシチュエーションに合わせて選べるようにしておくのが自然な発想
しかしそういう言語は殆ど無い、これが問題
といってもマークスイープ系GCが前提のC#やJavaのような言語に
RAIIの発想を持ち込もうとしても
C++のデストラクタのように自身のメンバのデストラクタを自動で芋づる式に呼び出す仕組みが
元々無いので、手動で芋づる式に解放関数を呼び出すコードを書かなければならなく
うまく行っていない
255:デフォルトの名無しさん
15/12/08 16:25:08.60 RVFMry3L.net
>>246
JavaでPhantomReferenceも使ったこと無い人って恵まれてるんだなあって思う
>>249
無いのでってもろにAutoCloseableとかあるやん
256:デフォルトの名無しさん
15/12/08 16:37:24.80 zjJIjn6V.net
>>250
自分のクラスがファイルなんかのcloseを持つリソースをメンバに持っていたとする
そうすると、それらのメンバのリソースを明示的にcloseできるようにするために
自身もcloseを実装することになるだろう
それで、自身のcloseが呼ばれた時、勝手にメンバのcloseが呼ばれるか？
結局手動でメンバのcloseを呼び出しまわるコードを書かなければならない
C++のデストラクタならメンバのデストラクタが芋づる式に勝手に呼び出されるから
気にしなくて良い
257:デフォルトの名無しさん
15/12/08 17:08:50.17 NMHe7TFl.net
強参照、ソフト参照、弱参照、ファントム参照
この字面だけで糞言語って察せられるから凄い
258:デフォルトの名無しさん
15/12/08 19:22:21.31 RKxPG6yJ.net
Rustはどう？
明文化されたmoveセマンティクスと、オブジェクトの寿命と参照のチェッカを型システムに組み込んでるおかげで、
リソース管理の実行時コストをゼロにしつつ、メモリリークが発生しないプログラムが書ける。
shared_ptrに相当するRcもあるから、所有者を複数にしたい場合のコストもそれなりに抑えられる。
259:デフォルトの名無しさん
15/12/08 19:35:14.32 Hrv9Cion.net
>>253
すげえ難しいらしいじゃん
260:デフォルトの名無しさん
15/12/08 19:52:40.51 NMHe7TFl.net
rustの清貧さは好みだけどまだ触った事ないな
同期処理を省略するためかshared_ptr相当がタスク間跨げないらしいけど
そこら辺の使い勝手ってどうなんだろう
261:デフォルトの名無しさん
15/12/08 21:00:06.21 RKxPG6yJ.net
>>254 難しいのは難しいが、低レベルの世界に相応な難易度であって、理不尽さはあまり無いと思う。
自分が遭遇した理不尽というか不便は、トレイト(型クラスみたいなの)を戻り値にした、ジェネリックな関数の型注釈の煩雑さで、
そのworkaroundが、その関数の返り値専用の型を定義する、ってのがカルチャーショックだった。
URLﾘﾝｸ(doc.rust-lang.org)
↑はIteratorトレイト(Listインターフェイスみたいなもの)のドキュメントだけど、mapとかfoldとかよくある高階関数の戻り値が、それ専用の型(MapとかFold)になってる。
だから、よくある関数型言語のイメージで、何か高階関数を利用したアダプタ関数を試しに定義してみよう！ってやると、
型注釈のエラー、ライフタイムのエラー等が一辺に出てきてわけが分からなくなる。
その関数の戻り値専用の型、なんて贅沢に見えるけど、返り値のサイズを見る限り、余計なデータで膨れているわけでもなかった。
Cでstruct wrap_int { int c; };とやったときにsizeof(wrap_int)がsizeof(int)と等しいけど、それと同じことをやっていた。
型情報なんてコンパイル時に全部消えちゃうから、実行コストも無いんじゃないかと今では思う。
メモリ/リソースの所有権を意識してコードを書くこと、が身について面白いよ。
ヒープを贅沢に使ってコピーしまくりなコードを書くと汚いし遅いしなんで、ちょっとダイエットする気分も出てくる。
262:デフォルトの名無しさん
15/12/08 22:39:35.60 RVFMry3L.net
>>251
C++もヒープ相手は自分で呼ぶので、実装は必要だよ
Javaでもメンバの特定メソッド呼び出しはやろうと思えばできる
現実に横断的な呼び出しをやる場合はある
結局要求される物と実装の問題
263:デフォルトの名無しさん
15/12/08 22:59:22.32 RKxPG6yJ.net
>>255 shared_ptrと恒等なものは無いけど、ポインタ的に使える型がBox, Rc, Cell(あるいはRefCell)とあって、
Boxはヒープ領域であること、Rcは複数の所有者がいる(つまり所有者全員が死ぬまでは生きている)こと、Cellは複数の書き込みが作れること、
とか機能とコストが別れているから、これらを組み合わせて使う。
で、Thread Safetyを実現させる機構は上記には無いので、Atomicityを導入させるRcの類似形であるArcと、
書き込みもしたいならMutexっていう型も合わせて使う。
すると、例えば整数のベクトルをスレッド間で共有したい、とかになるとArc<Mutex<Vec<i32>>>という目が滑るような型表記をすることになる。
あんま詳しくないので、ケース毎にもっと簡単なやり方があるとは思うんだけどね。
264:デフォルトの名無しさん
15/12/08 23:55:28.64 NMHe7TFl.net
>>258
ああ、Arcってのが別にいるのね。納得
個人的にもう一点気になる所があるから聞いてしまう
BoxやDropを使ってるとコピー禁止になるらしいけど
これ面倒な場合ない？
最初はコピー可能な型としてガンガンコピーしてたけど
途中から終了処理を書きたくなったらコピーしてる箇所
全部直すって事？
ちなみにググってたらRWArcっての見つけたんだけど
これ読み書き可能なArcなんじゃね
265:デフォルトの名無しさん
15/12/09 00:46:02.26 WVnNYSfg.net
>>249
javaは世代別管理でGCの種類は色々選べるはずでは
266:デフォルトの名無しさん
15/12/09 01:14:15.85 wAGGTtTq.net
>>260
起動時に切り替えられるだけであって
オブジェクトごとには切り替えられないのでは
267:デフォルトの名無しさん
15/12/09 01:50:08.36 x/ryIvcR.net
>>259 コピーしまくっているような変数の型をTからBox<T>に変えた場合、確かに面倒なことになる。
けど、基本的に単純な代入(let x = y)はコピーじゃなくてmoveになるし、
Box<T>の値をコピーしてBox<T>の値を生成するっていうのは、同じヒープ領域を指すポインタを作るんじゃなく、
新しいヒープ領域を確保して中身をコピーし、そのポインタを返すという意味なんで、
変数の型を後でTをBox<T>に変える、という場面はあまり無い(少なくとも自分は学んでいる最中にそういうことをしたくなったことがない)
値をコピーする場面では、元の変数の型がBox<T>であってもTであっても、参照型&Tを受け取ってTを生成、ということをするのが定石。
&Tはほぼ無制限に安全に作ることができるし、安全じゃない可能性があったらコンパイルが通らない。
で、コピーした型Tの値は呼び出し元がBoxに包んでヒープ領域に置いたりするのが定石
Dropも別にコピーを禁止することは無いよ。後からつけたらエラーまみれ、ということにはならない。
あと、自作じゃない型に自作じゃないトレイト(インターフェイスみたいなもの)をつけることができないので、
例えば標準ライブラリのFileやTcpStreamはCopyできるようには決してできない。メモリ以外の資源管理も安全だよ。
268:デフォルトの名無しさん
15/12/12 10:36:13.53 mXWFWn5f.net
freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなｗ
freeしきれないとかｗｗｗｗ
269:デフォルトの名無しさん
15/12/12 11:52:29.69 v/VbuB+R.net
>>263
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。
270:デフォルトの名無しさん
15/12/12 12:05:07.06 yfUf7LLZ.net
shared_ptrって参照カウント式のGCじゃないの？
271:デフォルトの名無しさん
15/12/12 12:44:09.71 7G0ybzbE.net
循環を綺麗に扱えるなら参照カウントの方が良いと思うけど
VB6は循環参照の扱いどうやってるんだろう
272:デフォルトの名無しさん
15/12/12 14:25:51.97 npRd3MLZ.net
>>265
RAIIじゃろ
273:デフォルトの名無しさん
15/12/12 15:20:38.55 tVgJgcBS.net
>>265
GCの一種だけど、文脈的にはプログラマが
管理が非局所的で明確な型宣言もなしに使えるのをGCと言ってるわけで
議論で揚げ足にしかならない野暮な突っ込みはやめようぜ
274:名無しさん＠そうだ選挙に行こう
15/12/14 08:16:09.53 hn3965Zz.net
>>264
いや、下手って一言で片付けられるよ。
よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り
275:名無しさん＠そうだ選挙に行こう
15/12/14 08:38:44.84 sXTPVO5Q.net
片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。
どの分野でもな。
276:名無しさん＠そうだ選挙に行こう
15/12/14 09:09:02.89 lNUL9lX8.net
freeとか言ってる奴はC++使えよ。いつまでＣ使ってんだ。
277:名無しさん＠そうだ選挙に行こう
15/12/14 09:20:53.11 MauTQhQ/.net
>>270
東大生が人に教えるとき、何がわからないのかわからないというのがわからない。
上級者になればなるほど自分がやってることなんて簡単に見えてくる
278:名無しさん＠そうだ選挙に行こう
15/12/14 09:35:23.70 sXTPVO5Q.net
>>272
何が分らないか分らない、つまり東大生も生徒がどういう思考をしてるか分析できず分らないと言ってるのだ。
低学歴ほど、分らないのはおまえが馬鹿だからと簡単に片付けるものだ。
279:名無しさん＠そうだ選挙に行こう
15/12/14 09:37:05.77 eBJzgHzn.net
それ中級者
あと、東大生は教えるの上手いのもいるから想像で話すな馬鹿
280:名無しさん＠そうだ選挙に行こう
15/12/14 09:41:37.74 sXTPVO5Q.net
このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。
スレッドがデッドロックしてメモリを開放できないなんてよくあることだ。
281:名無しさん＠そうだ選挙に行こう
15/12/14 10:59:16.82 hn3965Zz.net
>>275
。。。。。完全な設計ミスじゃん
282:名無しさん＠そうだ選挙に行こう
15/12/14 11:15:19.23 eBJzgHzn.net
>>275
俺は272に向けてたんだが
そりゃコンテキスト読めてないように見えるよなw
283:名無しさん＠そうだ選挙に行こう
15/12/14 11:40:27.14 ETDpPCfc.net
スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww
284:名無しさん＠そうだ選挙に行こう
15/12/14 14:48:51.74 MOnxQz3f.net
スレッドがデッドロックしちゃってメモリ解放できない（泣）
っていうPGが五万といるのかよｗ
285:名無しさん＠そうだ選挙に行こう
15/12/14 15:51:19.55 hn3965Zz.net
まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない！」って言われたらソレは真実なんだろうけど・・・。
そんな脳みそPGに「もっと複雑な業務使用」を理解できるとは思えないんだ。
そんなPGにプログラミングの場を与えるのが間違い。
286:名無しさん＠そうだ選挙に行こう
15/12/14 15:58:21.86 2JSVZtRY.net
そもそも実務でスレッド使うＰＧなんてゴマンもいない
287:名無しさん＠そうだ選挙に行こう
15/12/14 17:06:58.52 eBJzgHzn.net
Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する
そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから
更に隠蔽したフレームワークもどきが出来上がる
288:名無しさん＠そうだ選挙に行こう
15/12/14 17:59:33.07 hn3965Zz.net
>>282
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。
289:名無しさん＠そうだ選挙に行こう
15/12/14 18:15:27.90 Z4FycFda.net
javaってc++のconst参照に対応するものが無いのに、素人みたいなプログラマを大量にかき集めているのが怖すぎる。
290:名無しさん＠そうだ選挙に行こう
15/12/14 18:28:13.63 eBJzgHzn.net
>>283
理解してないのに無理してレスしなくていいから
291:名無しさん＠そうだ選挙に行こう
15/12/14 18:42:08.38 CJqGCki1.net
C#はマルチスレッド使いまくりだけど事故の話はあまり聞かないな
マイクロソフトが優秀なのか低品質プログラマがいないのか
292:名無しさん＠そうだ選挙に行こう
15/12/14 19:01:59.11 2+GDL4RD.net
JAVA自体がDQN
293:uy ◆Qawu9.2l1E
15/12/14 20:57:26.55 J5PYIleC.net
Freeし忘れ
↑これ。
ソースコード書いてる人間の注意力次第でバグが入るなら
言語も設計も間違ってるよ
294:デフォルトの名無しさん
15/12/14 21:54:10.80 ETDpPCfc.net
動的型言語
↑
これ
コード書いている人間の注意力次第でtypoするだけで
実行するまでわからないバグが入るなら
言語も設計も間違ってるよ
295:デフォルトの名無しさん
15/12/14 22:23:00.81 lNUL9lX8.net
C#でcatchやfinally書くの嫌すぎる
C++に戻りたい
296:デフォルトの名無しさん
15/12/14 22:43:08.79 bhzmg0NL.net
>>290
おかえり
297:デフォルトの名無しさん
15/12/15 06:39:51.52 gQhFMQgY.net
(ヽ´ω`)眠い
298:デフォルトの名無しさん
15/12/16 08:46:15.45 fgV80IeN.net
>>290
C++/CLR「こっちこいよ」
299:デフォルトの名無しさん
15/12/17 17:18:40.36 Szn4FINI.net
COMのVariantとかJSとかリークしまくりだし
300:デフォルトの名無しさん
15/12/17 23:16:36.40 kltDf5Nv.net
そういやVBScriptって参照カウンタ以外のGC積んでんのあれ
必要には見えないんだけど
301:デフォルトの名無しさん
15/12/18 23:17:49.50 b1Otx84Y.net
プログラマはMacを使ってるってマジ？
ｽﾚﾘﾝｸ(news板)
302:デフォルトの名無しさん
15/12/19 07:07:37.11 qL4RiVer.net
マカーってどんだけアホなの？
303:デフォルトの名無しさん
15/12/19 12:49:09.79 EW8XrhCB.net
解放処理
すら、まともにお前ら管理できねーのかよ・・・・・・・・・・・・・・・・。そらオレが完璧な仕様書渡してもバグってるわけだ
304:デフォルトの名無しさん
15/12/19 13:38:07.82 i3zp3GbO.net
開放処理を手動でやれって書いてある仕様書かw
御免こうむるwwwww
305:デフォルトの名無しさん
15/12/19 14:42:49.35 iG82T79N.net
ガベコレのあるPyObjectをラップするクラスをガベコレのあるDで書いたら
wxPythonで書いたクラスをDから使ったとき意味不明なタイミングで落ちるようになった
二重に管理するとだめなんかな
306:デフォルトの名無しさん
15/12/19 15:57:38.71 qL4RiVer.net
>>298
ﾌﾟﾌﾟﾌﾟ 馬鹿だこいつw
307:デフォルトの名無しさん
15/12/20 08:46:23.14 gr0U1KS4.net
ガベージコレクションはたしかに便利だ
だからといって「本来はてめぇのケツはてめぇで拭け＝自分で解放すること」を忘れてはならない
そんだけ
308:デフォルトの名無しさん
15/12/20 11:55:11.08 HXRBhwTH.net
C#ではSafeHandleだけ作って後は放置
usingも使わないってのがトレンドだけどね
自分で解放とかバカバカしい
面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな
309:デフォルトの名無しさん
15/12/20 12:13:23.36 ofrSOHxv.net
>>303
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
Cオープン
A生成
B生成
A, B使用
B開放
A開放
Cクローズ
でええやん？
さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄
310:デフォルトの名無しさん
15/12/20 12:21:54.48 ofrSOHxv.net
つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、
計算モデルは明らかに状態遷移ベース（チューリングマシン）の方に分がある
GCとかチューリングマシンで無理矢理関数型プログラミングを行うためのつなぎの技術、
いわば邪道
どんだけ蛇が出てくるか、GCの方がかえってわからん
311:デフォルトの名無しさん
15/12/20 13:48:14.94 HXRBhwTH.net
>>304
設計が悪い
使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
知らなきゃ困るような設計にしたのが間違いだね
312:デフォルトの名無しさん
15/12/20 13:52:55.68 8RLYRFXT.net
メモリ空間は無限であるべき
使い終わったメモリの断片化なにそれ？
仮想メモリを管理するのはCPUの責任だろ
313:デフォルトの名無しさん
15/12/20 14:03:49.29 ofrSOHxv.net
>>306
>>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの？
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの？
つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話
314:デフォルトの名無しさん
15/12/20 14:28:20.48 i39XsMQ2.net
>>308
そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
意見を否定するためだけの極端な反例(この場合は例にすらなっていないが)を引き合いに出すのは不毛だよ
315:デフォルトの名無しさん
15/12/20 14:35:53.96 xl2QwS3M.net
>>303
いい加減だなぁw
316:デフォルトの名無しさん
15/12/20 14:36:58.02 ofrSOHxv.net
>>309
>そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
極論なもんｶﾖ；
例： 表示デバイスの数＞表示したいスレッドの数
というのはざらにある
で、>>308のオブジェクトDのケースはどう解決すんのさ…
GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど
（A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ；
317:デフォルトの名無しさん
15/12/20 14:42:20.07 ofrSOHxv.net
解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで
リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない
かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう
GCに合わせて生きることは、神仙にでもならねば到底かなわぬ…
318:デフォルトの名無しさん
15/12/20 14:44:35.05 ZDEpjFBd.net
つくづく、ARC最強だな。
319:デフォルトの名無しさん
15/12/20 14:46:27.58 i39XsMQ2.net
>>311
その例じゃ308の状況にならないよ
どんなコード書いてんだよw
320:デフォルトの名無しさん
15/12/20 14:48:11.36 ofrSOHxv.net
>>314
>その例じゃ308の状況にならないよ
なんで？ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…；
321:デフォルトの名無しさん
15/12/20 14:51:52.93 i39XsMQ2.net
だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから
322:デフォルトの名無しさん
15/12/20 14:55:30.48 ofrSOHxv.net
ていうか>>316の言っていることはますます矛盾で、
>同時に書く設計が悪い
>そんな必要はないってわかる
というのは明白に「書き込みの順序を設計できる」ということを言っていて、
それはその通り（チューリングマシンの計算モデルに合致する）ので別段漏れの立場と対立するものではなく、
かつ気合を入れて設計すれば順序で全て解決する（GCは不要である）という言明でもある
323:デフォルトの名無しさん
15/12/20 15:17:45.93 14eB8c4R.net
>>315
もはやGCがどう関係するのかわからない
324:デフォルトの名無しさん
15/12/20 15:20:28.11 i39XsMQ2.net
>>318
彼は敵対意見に反論する材料が欲しいというだけで変な例をでっち上げて出してしまったんだ
本人も今頃困ってるんじゃないかな
325:デフォルトの名無しさん
15/12/20 17:05:42.48 6vo8OCaj.net
>>319
>>308を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について：
繰り返しになるが、>>308のオブジェクトDのケースはどう解決すんのさ…
たとえ変でも反例は反例だし
>>308のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない
読み書き順序の設計の必要性（破壊的代入前提のプログラミング）を口にしつつ
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない （>306）
と言い切ることはできないとかそういう話
で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
>>318
ウィンドウシステムでの描画は一般に裏VRAMに描いてハードウェアでBitBlt転送するが
裏VRAMに書く際のデバイスコンテキストが複数使えるが数に限りがある場合…
とか細かい話をしても通じないようならリソースCをファイルと考えてくんな
326:デフォルトの名無しさん
15/12/20 17:12:24.84 6vo8OCaj.net
ﾌﾟﾁ訂正
誤: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
正: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>308)
327:デフォルトの名無しさん
15/12/20 17:19:25.13 HXRBhwTH.net
読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
書き込みたいから読み込み終わるの待ってますってリソースの無駄だろ
328:デフォルトの名無しさん
15/12/20 17:21:31.86 ZDEpjFBd.net
なんか参照カウントの話とマルチスレッドの話がごっちゃになってね？
329:デフォルトの名無しさん
15/12/20 17:33:49.10 6vo8OCaj.net
>>322
>読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
破壊的代入の世界ではそいつは常に可能とは限らない
>308の例で、リソースCがファイルXなのだとしたら、オブジェクトDが上書きすべきもあくまでファイルXでないといけない。
つまりリソース分離の余地など無い
（正確には、無理矢理ファイルA、BはファイルX、DはファイルYに分ける設計もありえるが、XとYに対する変更をいつどのように統合するかという超難題が生じる
この手の混乱は、A、BがアクセスするリソースCの開放タイミングの決定をGCに任せてサボったがために生じるのである
330:デフォルトの名無しさん
15/12/20 18:10:09.92 ZDEpjFBd.net
おいおい、バージョン管理のマージの話にまで拡張したら収集つかなくなるぞw
331:デフォルトの名無しさん
15/12/20 19:32:49.85 i39XsMQ2.net
>>324
ファイルの分割は必ずしも必要ではないし更新モデルから読み取りモデルへの同期も必要ないよ
332:デフォルトの名無しさん
15/12/20 19:44:06.53 9YX+2XWA.net
>>323 (Rust信者で)すまんな。
URLﾘﾝｸ(smallcultfollowing.com)
マルチスレッドで起きるデータ競合といった問題も、シングルスレッドで起きうるdangling pointerなどの問題も、
どっちも所有権を持つオブジェクトが無闇にいたり、変な参照関係があるから起きるんじゃないか？って言う人がおる。
根っこが同じ、あるいは近しい問題なんで、横滑りに見えても堪忍な。
333:デフォルトの名無しさん
15/12/20 19:49:46.85 kaqci566.net
メモリ管理もできないんだから
データの依存関係とか関係ねえ～～～～～～～～～～～～
でおわりでは
334:デフォルトの名無しさん
15/12/21 05:26:25.94 ejqZ3DMD.net
GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない
GoogleChromeでは、svchost.exeを使用せずに、chrome.exe自身で制御しているらしい
Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Width/1360px/1920px
335:デフォルトの名無しさん
15/12/21 05:32:28.99 ejqZ3DMD.net
その理由・・・GCは失敗。メモリは自分で管理せよ！
ｽﾚﾘﾝｸ(tech板)l50
336:デフォルトの名無しさん
15/12/21 05:35:31.18 ejqZ3DMD.net
メインメモリに対するGC・・・MGC
HDDならストレージGC・・・SGC
337:デフォルトの名無しさん
15/12/21 05:38:11.78 ejqZ3DMD.net
GoogleChromeかsvchost.exeを使わなくなった理由・・・ページメモリGC制御が遅過ぎでお粗末だからか？
338:デフォルトの名無しさん
2
339:015/12/21(月) 05:42:27.02 ID:ejqZ3DMD.net
340:デフォルトの名無しさん
15/12/21 05:45:15.43 ejqZ3DMD.net
「Svchost Process Analyzer」
svchost.exeのプロセスの中身が何かを調べて表示するフリーソフト
URLﾘﾝｸ(gigazine.net)
341:デフォルトの名無しさん
15/12/21 05:51:39.30 ejqZ3DMD.net
そろそろsvchost.exeを使うソフトは使用禁止なのかも？
342:デフォルトの名無しさん
15/12/21 06:11:17.64 ejqZ3DMD.net
svchost.exeを使わないことでGoogleChromeは確実に応答性能が速くなって�
343:｢る ・・・動画マルチ再生でクラッシュしたFirefoxは見習うべき
344:デフォルトの名無しさん
15/12/21 06:17:26.48 ejqZ3DMD.net
残念だがスリープだ！
URLﾘﾝｸ(pds.exblog.jp) URLﾘﾝｸ(i.imgur.com)
345:デフォルトの名無しさん
15/12/21 06:40:32.08 ejqZ3DMD.net
Wave
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
346:デフォルトの名無しさん
15/12/21 06:42:41.39 ejqZ3DMD.net
LG OLED TV : You Dream We Display
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
347:デフォルトの名無しさん
15/12/21 06:43:24.61 ejqZ3DMD.net
LG OLED TV - The Ultimate Display
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
348:デフォルトの名無しさん
15/12/21 07:08:24.86 ejqZ3DMD.net
LG 4K OLED: Paris and Chicago
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
349:デフォルトの名無しさん
15/12/21 09:26:05.64 ejqZ3DMD.net
国別ISO登録件数 ⇒ 技術マフィア ⇒ 技術流出状況
URLﾘﾝｸ(www.jicqa.co.jp)
URLﾘﾝｸ(www.jicqa.co.jp)
URLﾘﾝｸ(www.jicqa.co.jp)
URLﾘﾝｸ(www.jicqa.co.jp)
URLﾘﾝｸ(www.google.co.jp)
URLﾘﾝｸ(pds.exblog.jp)
350:デフォルトの名無しさん
15/12/21 09:41:02.29 ejqZ3DMD.net
中国、ダークマターの検出に挑む探査衛星「悟空」を打ち上げ
URLﾘﾝｸ(news.mynavi.jp)
URLﾘﾝｸ(n.mynv.jp)
URLﾘﾝｸ(n.mynv.jp)
URLﾘﾝｸ(n.mynv.jp)
351:デフォルトの名無しさん
15/12/21 09:44:40.17 ejqZ3DMD.net
京がお仕置き候補に???
URLﾘﾝｸ(gigazine.net)
◆1位：Tianhe-2(天河二号)、中国人民解放軍国防科学技術大学
URLﾘﾝｸ(i.gzn.jp)
IntelのIvy Bridge(12コア・2.2GHz)とXeon Phi(57コア・1.1GHz)を採用し、
コア数は312万、計算速度は33.9ペタフロップス、消費電力は17.8MW
◆2位：Titan、アメリカのオークリッジ国立研究所
URLﾘﾝｸ(i.gzn.jp)
AMD Opteron 6274(16コア・2.2GHz)とNvidia Kepler(14コア・0.732GHz)を採用し、
コア数は56万640、計算速度は17.6ペタフロップス、消費電力は8.3MW
◆3位：Sequoia、アメリカのローレンス・リバモア国立研究所
URLﾘﾝｸ(i.gzn.jp)
IBM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は157万2864、計算速度は17.2ペタフロップス、消費電力は7.9MW
◆4位：スーパーコンピュータ京、独立行政法人理化学研究所 計算科学研究機構(AICS)
URLﾘﾝｸ(i.gzn.jp)
富士通 SPARC64 VIIIfx(8コア・2.0GHz)を採用し、コア数は70万5204、
計算速度は10.5ペタフロップス、消費電力は12.7MW
◆5位：Mira、アメリカのアルゴンヌ国立研究所のエネルギー部門
URLﾘﾝｸ(i.gzn.jp)
BM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は78万6432、計算速度は8.6ペタフロップス、消費電力は3.95MW
352:デフォルトの名無しさん
15/12/21 09:50:17.19 ejqZ3DMD.net
気づかないかISOは中国のためにある
URLﾘﾝｸ(www.jicqa.co.jp)
353:デフォルトの名無しさん
15/12/21 10:45:57.17 1HvlxK+M.net
>>344
蓮舫さんに次の選挙は次点で良いですよねって言ってきて
354:デフォルトの名無しさん
15/12/21 11:12:03.51 1HvlxK+M.net
>>336
ほんそれ
355:デフォルトの名無しさん
15/12/21 12:31:40.33 ejqZ3DMD.net
URLﾘﾝｸ(ja.wikipedia.org)
356:デフォルトの名無しさん
15/12/21 12:34:04.50 ejqZ3DMD.net
URLﾘﾝｸ(www.google.co.jp)
357:デフォルトの名無しさん
15/12/21 12:36:38.19 x6st9rMu.net
ただしChromeはプロセスが一杯できるから
タスクマネージャ覗いた時に気持ち悪い
358:デフォルトの名無しさん
15/12/21 16:06:45.56 ejqZ3DMD.net
64の時代だから、そろそろCore64ぐらいでイイのでは？
URLﾘﾝｸ(blogs.msdn.com)
URLﾘﾝｸ(download.intel.com)
359:デフォルトの名無しさん
15/12/21 16:21:26.45 ejqZ3DMD.net
ラーメン
URLﾘﾝｸ(www.chikuwachan.com)
URLﾘﾝｸ(www.chikuwachan.com)
360:デフォルトの名無しさん
15/12/21 16:33:49.61 ejqZ3DMD.net
URLﾘﾝｸ(www.dospara.co.jp)
URLﾘﾝｸ(www.dospara.co.jp)
361:デフォルトの名無しさん
15/12/21 16:35:11.77 ejqZ3DMD.net
diginnos stickpc_02
URLﾘﾝｸ(www.youtube.com)
362:デフォルトの名無しさん
15/12/21 18:37:51.00 ejqZ3DMD.net
Holiday Glam
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
363:デフォルトの名無しさん
15/12/21 18:38:29.84 ejqZ3DMD.net
Midnight Luster
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
364:デフォルトの名無しさん
15/12/21 18:43:07.58 ejqZ3DMD.net
Chromeの調子が良い件について・・・TCL 4K Demo: Ultra-Running Beauty
URLﾘﾝｸ(aurorawave.atspace.tv) URLﾘﾝｸ(i1.ytimg.com) #AuroraWaveTV
365:デフォルトの名無しさん
16/01/10 12:45:59.41 LOFSek54.net
723 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:24:00.06 ID:rlcuxF0A0
Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため？かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
724 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:31:29.50 ID:rlcuxF0A0
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい
タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
725 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:33:41.35 ID:rlcuxF0A0
命題・・・Vivaldiは遅い起動を早期解消せよ！
726 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:37:50.17 ID:rlcuxF0A0
ランダム書込用HDDスペースを作る 個数*固定サイズ
１トランザクション 個数1024個、固定サイズ256kバイト
727 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:40:34.65 ID:rlcuxF0A0
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
728 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:44:26.42 ID:rlcuxF0A0
オーバーヘッドはドコにあるのか？
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ
366:デフォルトの名無しさん
16/01/10 12:47:28.36 LOFSek54.net
Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため？かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい
タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
命題・・・Vivaldiは遅い起動を早期解消せよ！
ランダム書込用HDDスペースを作る 個数*固定サイズ
１トランザクション 個数1024個、固定サイズ256kバイト
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
オーバーヘッドはドコにあるのか？
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ
367:デフォルトの名無しさん
16/01/10 12:52:32.51 LOFSek54.net
fopen();のときフォルダ構造検索するようだ
368:デフォルトの名無しさん
16/01/26 06:48:44.23 v48l+1vS.net
やっとこの気色の悪い仕組みにトドメが刺されたか
javaとかGCが基本だけどflash();とかできるの？
369:デフォルトの名無しさん
16/01/26 07:35:03.77 RBo8KHcc.net
ゴミ言語は所詮ゴミ
370:デフォルトの名無しさん
16/01/27 17:10:09.80 eULyfEEH.net
GCのすべてを否定するつもりはないけど・・・
GCはメモリ管理を自動化する技術だけど、今のコンピュータはメインメモリを何十ギガ積んでたりするのも普通で
メインメモリが足りなくなることはほぼ無くて、しかも仮想メモリもあるから、なおさらメモリは潤沢で・・・
むしろメインメモリ以外のリソースの方が余程貴重で、もし仮にメインメモリが足りなくなるまで
GCを発動しないアホなGCが有ったとしたらメインメモリより先に他のリソースが枯渇する状況
だからメインメモリは無駄遣いしてもよいけど、他のリソースは使い終わったら
こまめに開放しないとダメだから、いつ実行されるか分からないマークスイープ系GCの余計にRAIIな仕組みも必要なわけ
しかしこのRAIIが付け焼刃でなまっちょろい出来だったりする
C#で言えばDisposeが有るけど、C++のデストラクタのように特別扱いされておらず
ただの普通の関数でしかないので、C++のデストラクタみたいに自身のメンバ変数について
自動で芋づる式に呼び出してくれない
だから手動でメンバのDisposeを芋づる式に呼び出すコードを記述しなければならない
いちいち自身のメンバ変数にIDisposableなものが有るか無いか調べるのもひと手間かかるし
もしそうだったら自身もIDisposableにする必要があり、例の一連のイディオムを書かなければならない
当たり前にDisposeの呼び出し忘れが有ってもいけない
まるで、mallocしたらfreeするのと似ている
しかもIDisposableはコンポジションで増殖する
IDisposableなオブジェクトをコンポジションしたら、自身もIDisposableといった具合
C#のようにコンパイラマジックでなんでも実現する言語で
どうしてDisposeをC++のデストラクタみたいに特別扱いしなかったのか謎だ
371:デフォルトの名無しさん
16/01/27 17:24:38.54 eULyfEEH.net
謎だといったが、理由ははっきりしていて
メンバのDisposableを自動で呼び出す為には
他で使われてないことを保証する必要があって
参照カウンタ方式のようにローコストなものなら簡単に分かるが
これでは循環参照の問題が出る
プログラマが循環参照を気にしなくてもよいことが前提の
マークスイープ系のGCを搭載した言語では設計思想が破たんするので
参照カウンタ方式は採用できないし
マークスイープ系GCでは何処からも参照されていないことがローコストに分からないので
自動でDisposeを呼び出す仕組みを用意できない
どうにもならない
結局C++の方式が一番優れている
循環参照が発生する場合はweak_ptrを使う事だけ注意を払えば
GCにまつわる他の問題が一切発生しない
372:デフォルトの名無しさん
16/01/27 17:46:52.79 eULyfEEH.net
もっと言えばC#でDisposeを実装する場合でも↑は問題になる
自身のメンバのDisposeを呼んでよいのかどうなのか
完全に自分しか使ってないことが分かっているのであればDisposeを呼び出して問題ないが
あちこちから参照されている可能性があるメンバなら勝手にDisposeを呼び出してはいけない
GC任せにするか、自分で参照カウンタを実装するか
どちらにせよ、RAIIと相性が悪い
373:デフォルトの名無しさん
16/01/27 17:58:09.12 aloDWtjb.net
前から何度も言ってるがDisposeの実装はしていいが呼び出しは禁止
これがC#では基本だからね
リソースの使用効率が悪いとか軟弱な反論をするバカがたまにいるが
実行効率気にするならそもそも別の言語使えって話になるからな
C++CLIを使えってこった
本質を見誤るなよ
374:デフォルトの名無しさん
16/01/27 18:38:52.76 XmqLFQFE.net
c#の欠点はデストラクタが呼び出されるタイミングが分からないこと。
不便で仕方ないや。
375:デフォルトの名無しさん
16/01/27 18:56:08.53 VDkVQpP+.net
最近VB.NETを使い始めたんだけど
new したオブジェクトが不要�
376:ﾉなった時にDispose()よんだり参照にNothing代入する必要ってない（やってもいいが無意味・無駄）なのかな？
377:デフォルトの名無しさん
16/01/28 08:05:17.75 oip5UtLa.net
c++のデストラクタは例外投げられないウンコ仕様
だから皆デストラクタ内で発生したエラーは握り潰してる
他の言語はあんなバカなの真似する必要ない
378:デフォルトの名無しさん
16/01/28 17:53:06.50 M0BYpVOa.net
デストラクタで投げるなよ。迷惑な奴だな。
379:デフォルトの名無しさん
16/01/28 18:02:00.92 xwQj4KRs.net
javaはファイナライザで発生した例外は握りつぶすことが仕様で決まっているな。
c++の場合は、デストラクタでどうしても例外を外に伝えたかったらやりようはある。
380:デフォルトの名無しさん
16/01/30 01:11:50.31 QZN0GaAw.net
そら伝えたかったらやりようはいくらでもあるでしょう？C++に限らず
381:デフォルトの名無しさん
16/02/10 11:29:59.19 lL2Wg2mH.net
Javaは強制的に解放させることもできるようにすべきだったな。
382:デフォルトの名無しさん
16/02/10 11:41:46.63 83b7Yxnh.net
Java(VM)は(すべてのプラットフォームで)強制的に解放させることもできるようにすべきだったな。
383:デフォルトの名無しさん
16/02/10 12:19:44.29 k9iR7lzz.net
都度メモリ管理するよか、GCに任せた方がスループット的に有利な場合も多いでしょ。
384:デフォルトの名無しさん
16/02/10 14:29:59.29 CcpqYYAq.net
GCはメモリ管理に関しては成功してる、
でも、メモリブロックをオブジェクトに昇格させたにも関わらず、相変わらず「メモリ管理」だから失敗。
385:デフォルトの名無しさん
16/02/10 17:29:46.71 +sMp0qjD.net
そうそう、メインメモリの管理に関しては100%成功している
しかし、今やメインメモリはそれほど貴重なものではないわけだがな
コンシューマでも数十GB積んでたりは珍しくない
メインメモリがなくなるより他のリソースが枯渇する方が現実的
だからメインメモリ以外のリソースに関しては使い終わったら即座に開放してほしいから
GCとは別にRAIIを行う仕組みを導入するわけだが
真剣に考えていくと、RAIIはGCと相性が悪い
そもそも使い終わったら自動で即座に開放(RAII)できるなら全てのGCはそう実装すべきで
それが出来ないからわざわざコストのかかるマークスイープを遅延して実行しているわけだからな
C++みたいにGCを参照カウンタ方式にして、プログラマが人力で循環参照が無いことを保証する以外に
あちこちから参照されるオブジェクトのRAIIを自動化する方法は無い
386:デフォルトの名無しさん
16/02/10 20:59:51.38 rEABlirv.net
JAVAはクソ
387:デフォルトの名無しさん
16/02/10 21:00:45.91 ZQ/yQmxu.net
簡単だよ
スレッド立ててGCをフルサイクル実行し続けるだけ
388:デフォルトの名無しさん
16/02/11 16:22:39.56 vxbPXQEr.net
javaもsandy-bridge以降でSSDとかならそれほど重いってわけじゃないけど
相変わらずatomでeMMCだったりする環境も並行して存在してて
そこで動かすと改めて糞だと思うわけよ
GCが悪いんじゃなくてjavaランタイムが悪いんだろうけどね
389:デフォルトの名無しさん
16/02/11 19:04:56.18 EuRhj+pR.net
フラッシュとJAVAは、システムに見つかり次第、速攻アンインストールしている
390:デフォルトの名無しさん
16/02/12 08:32:20.35 Uwfak+5B.net
>>377
Pythonみたいに参照カウント+GC（循環参照を解放するため）が最強ってこと？
391:デフォルトの名無しさん
16/02/13 15:34:22.04 OKKAbu21.net
最近のPC環境でも贅沢が過ぎるプログラムは動かん。
最近の奴だと、Node.jsのパッケージマネージャnpmが`npm search`と初回に打つとパッケージ検索用のインデックスを作ろうとするんだけど、
1つのjsonオブジェクトにまとめようとするからかOOMエラーを吐いて失敗するっていう不具合。
npmに登録されてるパッケージ数が膨大になったせいもあるが、設計を間違えると遅いどころか動かなくなる。
392:デフォルトの名無しさん
16/02/13 22:32:48.48 6Xm9VASh.net
GCがある言語でRAIIみたいな事したいのなら
loan patten使えばいいだけでは
393:デフォルトの名無しさん
16/02/13 23:42:47.95 VLo29AwR.net
リソースを共有した上で最後の参照が切れた時点で回収してほしい
しかし誰が共有するかもその寿命も実行時までわからない
そういう前時代的なダサい設計をした時の話しなんだろ
Loan Patternはこの状況では役に立たない
394:デフォルトの名無しさん
16/02/14 00:56:38.97 mwiD0ozs.net
しかし、言語側は、そういうダサい設計も許さないといけないので
マークスイープ系GC搭載で、循環参照が有っても良いことが前提になっている言語で
「使い終わったら自動で即座に開放」を実現するのは困難
そんなことが可能なら、マークスイープは要らないからな
395:デフォルトの名無しさん
16/02/14 19:42:04.72 I7Qc+kxz.net
循環参照なんて放置すればいいの
どうせプロセスが終了すればOSが開放してくれるの
396:デフォルトの名無しさん
16/02/14 20:10:25.23 EqhxGdNa.net
>>387
Windowsのように定期的に再起動しなければいけないソフトウェアができあがっちゃいそう
397:デフォルトの名無しさん
16/02/15 18:16:17.47 TvNTryet.net
ErlangでOS作るか
398:デフォルトの名無しさん
16/02/15 19:50:44.55 L+A+Kd2h.net
そこはRustで
399:デフォルトの名無しさん
16/03/01 15:00:17.89 QERDe7Jh.net
5分でわかるガベージコレクションの仕組み
URLﾘﾝｸ(geechs-magazine.com)
400:デフォルトの名無しさん
16/03/23 02:31:06.32 MFzvJNSi.net
常識的に考えてカーネルの実装にはGCなんて使えないし
業務アプリケーションではパフォーマンスより開発速度がはるかに重要になる
結局適材適所だ
GCを強制されるのは苦痛だが使えないのも苦痛だ
好きな時に使える言語がいいよね！
401:デフォルトの名無しさん
16/03/23 03:41:39.64 SoMbpeP6.net
パフォーマンスが問題にならないGCが一つだけあって、それが参照カウンタ方式のGC
パフォーマンスが問題にならない→即座に逐一削除できる→RAIIが出来る
非常に強力だがプログラマが循環参照が無いことを保証しなければならない
しかし、循環参照が発生する場合は設計段階で分かるのでそれほど深刻では無いのだ！
402:デフォルトの名無しさん
16/03/23 03:47:03.14 VzK80P8k.net
androidでもう何も判らん状態でプログラミングして
それなりに動くのができたからおれは許したよ
でもサービスまで勝手に回収されちゃうとは思わなかったわ
アホだろグーグル
403:デフォルトの名無しさん
16/03/23 07:53:14.58 JT2FURwc.net
RAIIに必要なのはデストラクタが呼ばれることであって実際にメモリが解放されることじゃないから
GC言語でもRAIIができないわけじゃない。
404:デフォルトの名無しさん
16/03/23 10:07:19.06 SB04Y3rp.net
RAIIに必要なのは適切なタイミングで確実に解放処理が呼ばれることであって
いつ呼ばれるかわからないデストラクタではだめ
405:デフォルトの名無しさん
16/03/23 18:24:05.29 jWiL+V+6.net
かつてStandard MLの実装で、GCじゃないメモリ管理方法をやってみたのがあったな。
コンパイラが全部自動でやるからコードの見た目はSMLなんだけど、いざ動かすとGCより遅かった。
ある程度プログラマがリソース管理のためのヒントを与えないと、GCを捨てられない。
406:デフォルトの名無しさん
16/03/23 20:05:29.02 JT2FURwc.net
>>396
おまえが言っているのはファイナライザ。
それと、デストラクタはメモリの解放なんかしないよ。デストラクトするだけ。
407:デフォルトの名無しさん
16/03/23 21:43:30.89 SoMbpeP6.net
この際、呼び名はどうでも良い
参照カウンタ方式以外のGCでは、どこからも参照されなくなったことが、即座にはわからない
だから、自動で即座に開放関数を呼び出すことが出来ない→RAIIが出来ない
C#で言うところのusingみたいに、プログラマが手動で情報を与えるなら出来る
だが、usingはGCでは無い
408:デフォルトの名無しさん
16/03/24 00:53:54.57 smGLwjga.net
いまさら、ゲームキューブ叩いてどうするんだ？
409:デフォルトの名無しさん
16/03/26 05:40:22.28 vD3g1idC.net
>>393
間違い
マークスイープのように負荷が集中しないだけでありパフォーマンスへの影響はある
特にツリー状のデータついてルートが削除された時子要素もデクリメントする必要があるため負荷が大きい
カウンタはオブジェクト毎に持つためコピーオンライトとの相性が悪い
また言語の機能として実装されなければ明示的に行う必要がある（例えばCとか）
そのためgcない言語ではマークスイープと比べ非常に面倒なことになる
410:デフォルトの名無しさん
16/03/26 10:35:48.15 GKwGPSgf.net
androidで原因不明のフリーズが発生、プロジェクトはデスマーチに突入した
これだからGCは
411:デフォルトの名無しさん
16/03/26 11:39:27.66 drxQ1xsy.net
これだからGCに頼りきった未熟者は
412:デフォルトの名無しさん
16/03/26 11:39:40.83 MgEq8J/o.net
>>401
そりゃどんなものだって多少の負荷は有るよ
しかし参照カウンタの上げ下げの負荷なんか
マークスイープに比べれば無いも同然
413:デフォルトの名無しさん
16/03/26 18:02:09.56 2IjmMYr5.net
マルチスレッド環境だと参照カウンタとかいうクソアルゴリズムは使い物にならない
414:デフォルトの名無しさん
16/03/26 18:52:26.07 QL60ocAy.net
参照カウンタがオーバーフローしたらどうなんの？
415:デフォルトの名無しさん
16/03/26 19:10:36.57 nXtJgRqN.net
>>405
SSOのが遅いだろ
>>406
size_t にしとけばオーバーフローしない
416:デフォルトの名無しさん
16/03/26 19:44:45.11 R9brpoqy.net
>>406
殿堂入りさせて、回収しない
417:デフォルトの名無しさん
16/03/26 20:22:44.37 QL60ocAy.net
>>407
確かに現実的にオーバーフローしないと言えると思うけど
STLとかもそういう実装になってる？
418:デフォルトの名無しさん
16/03/26 20:52:01.21 rTAUpSul.net
使う側は少なくとも１つのポインタを持たなくちゃいけないんだからオーバーフローし得ないだろ
419:デフォルトの名無しさん
16/03/26 22:10:23.58 6zuFQelp.net
マルチスレッドでGCスレッド立ち上げて、再配置起こる可能性のある普通のGCだと、オブジェクト毎にLock,Unlockできる何らかの機構が必要だし、参照カウンタ増減するより高頻度でその機構使うよね。
420:デフォルトの名無しさん
16/03/26 22:34:25.82 2IjmMYr5.net
そうでもない
421:デフォルトの名無しさん
16/03/26 23:56:59.65 MgEq8J/o.net
例えばWindowsだとInterlocked系のAPIを使えば
マルチスレッドでも安全に参照カウンタを増減できるから
パフォーマンスは何の問題もない
422:デフォルトの名無しさん
16/03/27 00:13:33.76 MdJCnp0Y.net
C#なら参照のコピーはただのワード代入で済む
メモリ確保もポインタへの加算だけで済むから圧倒的に速い
回収もマルチスレッドで処理されるから圧縮フェーズ以外はUIへの影響もなくユーザ目線では実質コストゼロ
良いコードを書いてるなら圧縮もたまにしか起こらないし起こっても大した事ない
423:デフォルトの名無しさん
16/03/27 00:26:17.07 vj+h39OC.net
>>399からの流れを見ればわかるがそういう話ではない
参照カウンタ方式以外のGCは、オブジェクトがどこからも参照されなくなったことが「即座」にわからない
だからRAIIが出来ない、そういう話
もちろん、参照の値が書き換わるたびに毎回マークスイープを実行すれば
即座にゴミが分かるがのでRAII出来るが、マークスイープは重いので参照が書き換わるたびに毎回実行できない
その意味で、循環参照以外のGCは重いと言っている
参照カウンタ方式は軽いので毎回実行できる
即座にゴミが分かるからRAIIが出来る
参照カウンタ方式で問題になるのは循環参照が起こった場合だが
循環参照が発生する箇所は設計段階で分かるので、実際には大した問題ではない
C++であれば、片方をweak_ptrにすればよいというだけの話
そこさえ気を付ければ、参照カウンタ方式とデストラクタの組み合わせは非常にうまく機能する
IDisposableのようなものも要らない
424:デフォルトの名無しさん
16/03/27 00:27:10.73 vj+h39OC.net
>循環参照以外のGCは重いと言っている
↑間違えた
参照カウンタ方式以外のGCは重いと言っている
425:デフォルトの名無しさん
16/03/27 00:41:23.52 15KjVKPo.net
>>413
安全が何で保証されてるのかを知るためにアセンブラを勉強しなさい。
その上で「パフォーマンスは何の問題もない」かどうかを語りなさい。
426:デフォルトの名無しさん
16/03/27 00:59:17.81 kBj57j3O.net
前にも書いたが、RAIIとGCは直接の関係はないよ。
現にC++/CLIでは、ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
メモリの回収自体はGCで行われる。
427:デフォルトの名無しさん
16/03/27 01:02:24.98 MdJCnp0Y.net
>>415
そもそも不可視のコードでリソースを解放するのが愚行そのもの
プログラマとしての良識があるならusingを使いなさい
RAIIなどというくだらないバッドノウハウはC#では必要ない
428:デフォルトの名無しさん
16/03/27 01:31:49.74 vj+h39OC.net
>ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
>gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
>メモリの回収自体はGCで行われる。
それはGC関係ないRAIIの話だろ
C#でもusing使えばRAII出来るが
usingも、ローカル変数も、deleteも、何れもGCじゃない
手動で寿命管理しているに過ぎない
寿命管理を自動化(GC)しつつ、RAIIを実現する話をしているわけだが
どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
RAII出来るに決まっているだろ、それに何の意味が有るんだよ
自動化の話だよ
429:デフォルトの名無しさん
16/03/27 01:33:16.88 vj+h39OC.net
>そもそも不可視のコードでリソースを解放するのが愚行そのもの
その最たるものが、マークスイープ系GCなわけですが
いつ実行されるかすら分からない
まさに不可視
430:デフォルトの名無しさん
16/03/27 01:51:43.15 vj+h39OC.net
極端な話
mallocして使い終わったらfreeして
はい、手動でRAII出来ました！って主張
それ何の意味が有る話なの？ってね
431:デフォルトの名無しさん
16/03/27 07:41:27.84 kBj57j3O.net
>>420
>それはGC関係ないRAIIの話だろ
メモリはGCで回収されると書いたが？あと、そもそもRAII自体がGCと直接関係ないとも書いた。
>usingも、ローカル変数も、deleteも、何れもGCじゃない
いずれもメモリ領域はGCで回収される。
>どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
>RAII出来るに決まっているだろ、それに何の意味が有るんだよ
ローカルスコープに置いたオブジェクトは手動で呼ぶ必要はない。
gcnewで作成したものにはdeleteを使うってのは普通のC++と同じだ。
ローカルスコープの変数を基点に、スコープを抜けたときに連鎖的にデストラクタが呼ばれて
delete等の後始末がされるってのがRAIIだからな。
普通のC++ではそのdeleteのときにoperator deleteでメモリ領域が解放されるが、C++/CLIでは
GCで回収されるというだけ。
「GCで有ろうが無かろうが」「RAII出来るに決まっている」ということを理解したならまぁそれでいい。
できないってのを否定しただけで、別に意味があるかないかを話していたわけじゃないからな。
要は、GCを使う多くの言語でRAIIができないのはデストラクタの仕組みを持っていないからであって、
それがあるC++/CLIならRAIIも可能ということ。逆にGCを使わない言語でも、デストラクタがなければ
RAIIは不可能。
つまり最初の結論、RAIIとGCの有無に直接の関係はない。
432:デフォルトの名無しさん
16/03/27 10:01:03.80 MdJCnp0Y.net
メモリとその他のリソースを混同して考えるからダメ
まずその他のリソースは不可視のコードで解放しちゃダメ
リソースのスコープは明示的でなければならない
これはデストラクタにもGCにも任せられない
逆にメモリは不可視のコードで解放してもよい
まずこの基本原則から話を進めよう
433:デフォルトの名無しさん
16/03/27 10:12:42.93 Ap0rkncx.net
schemeにはdynamic-windみたいな他所に継続が飛んでも後処理が保証される仕掛けがあるし
デストラクタがない==RAIIできないにはならないと思うの・・・
434:デフォルトの名無しさん
16/03/27 11:03:59.82 +zMq83Ww.net
>>424
んな事はない。
あらゆるリソースの寿命はライブラリでデフォルトの管理がされるべきであり、使用者の完全性を前提にすべきではない。
435:デフォルトの名無しさん
16/03/27 11:16:32.31 MdJCnp0Y.net
>>426
銀の弾丸は無い
あらゆるリソースのあらゆる利用形態に対してデフォルトの動作を定義できるなら話は別だが無理だよね
結局は人が方針を決めて書くしか無い
幸いにしてメインメモリにはRAIIやマークスイープという正解が見つかっているのでそれを使えばいい
だが他のリソースはダメだ
436:デフォルトの名無しさん
16/03/27 16:21:42.54 vj+h39OC.net
>>423
そんな基本的なことを言って何がしたいの？
RAIIとGCは密接な関係が有るんだよ
君はローカル変数が好きみたいだから、ローカル変数の事例で説明するとする
(嫌ならC#のusingと読み替えてもらっても構わない)
ローカルに確保したオブジェクトが、メンバ変数に他のオブジェクトを持っていたとする
いわゆるコンポジションの状態、よくある話
C++で言えば、class my_class{ object *obj; }; といった感じのクラスになる、分かるよね？
で、ローカル変数はスコープを抜けたら解放される、usingも似たようなもの、これはRAIIの基本、良いね？
このとき、マークスイープ系GCだと、my_classのobｊに他からの参照が有るかどうか、即座にわからないので
objを開放してよいのか判断が付かない→my_classは破棄されてもobjはGC発動まで保留される→objは残るのでRAIIの意味がない
もしくは、my_classのobjに他からの参照が全く無いことをプログラマが保証して
my_classの開放部にobjをdeleteなりdisposeなりするコードを記入する
しかしこれは、objの所有権がはっきりしていないことには使えない上に、「手動」である
C++の場合はスマポが有るのでまだましだが、C#のDisposeは完全に手動で呼ばなければならない
自身のメンバにIDisposableなメンバいたら、自身もIDisposableにしなければならず、Disposeメソッドを実装して
自身のメンバのDisposeを芋づる式に呼び出すコードを手動で書かなければならない
mallocしたらfreeしましょうと一緒で、C言語レベルの全くの手動になってしまう
参照カウンタ方式のGCではこれらの問題は発生しない
他からの参照が有るか無いかは即座にわかるし、参照カウンタが0になれば、その場で即座に破棄される
自身のメンバに対して、デストラクタは芋づる式に呼び出されるので、C#のDispose実装のような面倒さは無い
>>424
お前言ってること無茶苦茶すぎるだろ
>リソースのスコープは明示的でなければならない、デストラクタにもGCにも任せられない
GCはともかく、デストラクタでもダメって意味不明すぎるんだが
考えの根本がおかしい
437:デフォルトの名無しさん
16/03/27 16:43:31.54 vj+h39OC.net
C++で書けば
struct A{ *obj };
void func()
{
A a;
}
こういったRAIIの場合のobjの開放はどういう扱いにするんだって話
aが完全にobjを所有しているケースなら、Aのデストラクタにdelete obj;とでも書くかscoped_ptrでも使えばよい
しかし、objが彼方此方から参照されている可能性もあるので
そこんとこコンパイラは判断が付かないので、自動化はきない
あくまで、プログラマが保証する形になる
C#のDisposeのような仕組みを言語側で用意したところで、自身のメンバにIDisposableなメンバが有るかどうか
いちいち調べなきゃならなないし、調べ忘れや呼び出し忘れをするという問題が出てくる
しかも、所有権が単一である場合にしか成り立たない
一方でマークスイープ系GCに任せっぱなしにすると、objの開放はGC発動まで遅延してしまうだろう
参照カウンタはこれらの問題をすべて解決する
参照数はどのタイミングでも直ぐに分かるし、0になれば遅延なしで即座に削除される
デストラクタは自身のメンバに対して芋づる式に自動で呼び出されるので
スマポを使っておけば呼び出し忘れるということもないし
Disposeのような冗長なコードを書く必要もない
438:デフォルトの名無しさん
16/03/27 16:44:43.86 vj+h39OC.net
訂正
struct A{ *obj };
void func()
{
A a;
}
↓
struct A{ object *obj };
void func()
{
A a;
}
439:デフォルトの名無しさん
16/03/27 17:07:08.54 vj+h39OC.net
結局、C#のDisposeはどこまで行ってもどんなに進化しても手動で書かなければならない
自身のDisposeが呼ばれたからと言って、自身のメンバ変数のDisposeを芋づる式に勝手に呼び出して良いかは
コンパイラにはまったく判断が付かない
他からも参照されていて今まさに使われている可能性がある以上
コンパイラが勝手に自動でDisposeを呼び出すコードを生成することはできない
GCを発動してみるまでは、どこからも参照されなくなったことが保証できない
しかし、GCの発動まで開放が遅延しても良いのであれば、そもそもDisposeは要らないわけで
Disposeの実行はGC発動より先行していなければならず、GCに頼れないということになる
なので、自身のDisposeが呼ばれたときに、自身のメンバのDisposeをしてよいかは
プログラマが考え、手動で呼び出す必要が有る
所有権が単一であれば、手動でメンバのDisposeを呼び出せばよい
手動で記述しなければならないので面倒くさいし、ミスの元ではあるが、一応できる
所有権が複数であれば参照カウンタを使うしか現実的な方法は無いだろう
マークスイープ系GCなのに参照カウンタで独自に管理するのは馬鹿げているがな
参照カウンタ方式＋デストラクタ
であればこれらの問題は一切発生しない
参照カウンタが0になったことは即座にわかるし、デストラクタはメンバ変数に対して芋づる式に呼び出されるので
開放に関しての特別なコードを手動で書く必要は無い
開放処理も一本化される
440:デフォルトの名無しさん
16/03/27 17:16:20.56 UGnRhUEw.net
長文は漏れなく基地外
441:デフォルトの名無しさん
16/03/27 17:17:01.33 MdJCnp0Y.net
>>428
バカすぎる
細かい事気にせずデストラクタで解放すりゃそれでおkって感じの適当な現場でしか働いた事無いんだろうな
442:デフォルトの名無しさん
16/03/27 17:22:53.59 /D0vdPDd.net
ポインタがメンバ変数になってたら公開しちゃいかんでしょ
443:デフォルトの名無しさん
16/03/27 17:24:21.54 MdJCnp0Y.net
まずDisposeは生成できる
めんどくさいという奴は知識が無いだけ
リソースを共有する事は少ない
というか設計段階で可能な限り少なくする
そして共有するならするでしっかり管理して自動解放などという手抜きはしない
基本中の基本だ
444:デフォルトの名無しさん
16/03/27 17:32:09.52 +zMq83Ww.net
デストラクタで解放してはいけないリソースをデストラクタで解放しなければいいだけで、デストラクタで解放すればいいリソースはデストラクタで自動的に解放すべき。
445:デフォルトの名無しさん
16/03/27 20:12:26.78 kBj57j3O.net
>参照カウンタ方式＋デストラクタ
>であればこれらの問題は一切発生しない
.NETのマーク&スイープGCの上でRAIIを実現している実例としてC++/CLIを説明したんだが、
「基本的なこと」とか言いながら結局何も理解してないんだな。
そもそもRAIIの話で所有権が共有されたオブジェクトを持ち出すのが意味不明すぎる。
>参照カウンタが0になったことは即座にわかるし、
「いつか」全員が所有権を手放したら「即座に」破棄される
「いつか」全員が所有権を手放したら「いつか」GCで破棄される
どう違うというのか。
446:デフォルトの名無しさん
16/03/27 20:35:08.73 Ng/EIIMI.net
RAII信者の痛さは異常
オブジェクトをコピーされたら破綻するのに
447:デフォルトの名無しさん
16/03/27 21:10:56.38 N7IGtcj3.net
グローバルインスタンスホルダーは明確にインスタンスの状態を把握したいときに積極的に使うべき