X
mallocの後にfree不要と言うバカいるの?Part2
■ このスレッドは過去ログ倉庫に格納されています
0466デフォルトの名無しさん
垢版 |
2014/10/13(月) 19:43:33.90ID:7i+sJhXA
>>459
> このようなケースは結構多いと思うんですよ。

自分が作るソフトもそうなの？

まあ、そうだとしても構文木を作成してる所以外でリークしない自信があるとか、リークしても気にしないと言うなら止めないよので、自由にやってくださいな。
0467デフォルトの名無しさん
垢版 |
2014/10/13(月) 19:44:39.36ID:HMQ6z8sD
>本質的に記憶領域の再利用がされないfreeをするために
>循環参照があるリンクトリストを再帰で開放してまわったり
>freeをするための1万回のループをわざわざ書くというのは
>なんというか、知的ではないのではないかと

リスト要素の構築と破棄を一回書けばそれが何万回呼ばれようと
同じだと思うんだが、それを「わざわざ」と言うのはどういうスタイルで
書いてんのか気になるな。
循環参照とか言っているところを見ると、fjのときも出てきたような
「作った本人が正しく破棄することができないデータ構造」とかかねぇ。
0468デフォルトの名無しさん
垢版 |
2014/10/13(月) 19:47:00.34ID:BlK6LuSG
RAIIはおろかな考えというネタでもう一スレ作れそうな気がするな。
0469デフォルトの名無しさん
垢版 |
2014/10/13(月) 20:12:51.45ID:xQhnOcQ3
>>467
> リスト要素の構築と破棄を一回書けばそれが何万回呼ばれようと
> 同じだと思うんだが、

パフォーマンス的には全然同じじゃないよ
コードの字面的に呼び出しが無かったら処理が存在しないとでも思ってるの？馬鹿？
0470デフォルトの名無しさん
垢版 |
2014/10/13(月) 20:25:00.67ID:BlK6LuSG
ちなみに>>469は俺です。

あと500レスみんなで頑張ってください。
0471デフォルトの名無しさん
垢版 |
2014/10/13(月) 20:36:14.64ID:FVrYA5zE
リンクドリストの場合はmallocすら何回もするのがめんどくさいので、
ブロックで確保して破棄はブロックの数分だけでいいのでは？
ゲームでは常識。
0472458
垢版 |
2014/10/13(月) 20:39:23.78ID:XfBY1GST
>>467
わかりにくい書き方ですみません。

前半の部分は
http://www.slideshare.net/iwiwi/ss-11008471
の3ページの交通ネットワークを表すために
31ページみたいなグラフを作って、その解放コードを
ちまちま、解放することを考えています。

後半は、行列なんかを使った後に
for(i = 0; i < ROW_MAX; i++) {
free(row[i]);
}
free(row);
exit(0);
なんてことをやることを想定しています。
0473デフォルトの名無しさん
垢版 |
2014/10/13(月) 20:42:43.81ID:FVrYA5zE
行列は幅が変わらないので、W*Hで確保してW*y+xすれば何度も確保する必要ない。
0474デフォルトの名無しさん
垢版 |
2014/10/13(月) 20:51:37.45ID:XwZMSYHG
>>447
わからないから、教えて下さいだろ。池沼。
0476デフォルトの名無しさん
垢版 |
2014/10/13(月) 21:09:11.84ID:7i+sJhXA
>>469
> パフォーマンス的には全然同じじゃないよ

で、そのパフォーマンスが問題になってるの？
0477デフォルトの名無しさん
垢版 |
2014/10/13(月) 21:09:16.45ID:HMQ6z8sD
>>472
前者は、参照の所有権をちゃんと考えないで複雑なデータ構造を作っちゃうと
いざ壊そうと思ったときに嵌ったりバグったりする典型だね。
後者は、使い捨てのやっつけプログラムとかじゃなければ普通こんなコードが
exit()の直前に置かれることはないと思うし、そうであれば普通に破棄処理として
書くと思うんだけどなぁ。それを「わざわざ」と思うのはまぁ、個人の感覚かも知れんが。
＃あぁ、rowもグローバル変数だったりするのかね？
0478デフォルトの名無しさん
垢版 |
2014/10/13(月) 21:23:47.22ID:QgIQdsn/
>>476
問題になってるかどうかはどうでもよくね？

1ナノ秒でも1ミリ秒でも速いほうがいいだろう？
速くなることにメリットはあれどデメリットはない。
0480デフォルトの名無しさん
垢版 |
2014/10/13(月) 21:47:30.33ID:QgIQdsn/
>>479
ちりも積もれば山となるってことわざ知らないの？

1ナノ秒でも積もれば1時間になるんだけど。
0481472
垢版 |
2014/10/13(月) 21:54:16.26ID:XfBY1GST
>>477
> 前者は、参照の所有権をちゃんと考えないで複雑なデータ構造を作っちゃうと
> いざ壊そうと思ったときに嵌ったりバグったりする典型だね。

ですので、freeせずにOSの持つメモリ管理機構を利用して
exitですね。
freeするためにプログラムを作っているのではなく
データを扱うためにプログラムを作っているのですから。

メモリリークチェッカを使わなければならないとかで、絶対freeしろって
言われたらmyMallocとmyFreeを作って、全体をmallocして最後に
一発freeってやりたいです。


> 後者は、使い捨てのやっつけプログラムとかじゃなければ普通こんなコードが
> exit()の直前に置かれることはないと思うし、そうであれば普通に破棄処理として
> 書くと思うんだけどなぁ。それを「わざわざ」と思うのはまぁ、個人の感覚かも知れんが。

なにをもってやっつけのプログラムと言うかはさており、
cpは実際にexitの前にforgetAllって終了処理が

word2vec
http://word2vec.googlecode.com/svn/trunk/word2vec.c
ではvocab, vocab_hash, expTableは解放するならmainからのreturn
直前に記述することになりますね。

> ＃あぁ、rowもグローバル変数だったりするのかね？

あくまで、例のための例ですが、グローバルなときもあります。
# というか、そのほうがすっきりする。
0482デフォルトの名無しさん
垢版 |
2014/10/13(月) 21:57:14.67ID:7i+sJhXA
>>480
> ちりも積もれば山となるってことわざ知らないの？

知ってる。
だから、小手先の最適化なんてしないんだよ。
速さより、重要なことってあるんだよ。
0483デフォルトの名無しさん
垢版 |
2014/10/13(月) 22:05:33.55ID:QgIQdsn/
速さよりも重要な事なんて無いよ。
金さえあればスパコンがほしいぐらい。
0485デフォルトの名無しさん
垢版 |
2014/10/13(月) 22:15:14.16ID:6bh+5rPK
>>483
それは、正確さだなｗ
あと脆弱性への強さ。
コードの見通しのよさ、コードの柔軟さ。

速さがどーしても欲しいってのはリアルタイムOSとかそういう分野なのかなぁ？
0489デフォルトの名無しさん
垢版 |
2014/10/13(月) 23:41:20.11ID:7i+sJhXA
>>485
> 速さがどーしても欲しいってのはリアルタイムOSとかそういう分野なのかなぁ？

そういう分野は、速さと言うよりどんな場合でも決められた時間に間に合うこと（つまり、遅くならないこと）を要求される
ハードリアルアイム でググってみそ
0490デフォルトの名無しさん
垢版 |
2014/10/13(月) 23:42:12.91ID:2IfdctYm
freeが必要だと思う人はしていただき、その必要性はないと思う人はしない
ということで各々ご対応をお願い致します。

それでは、ここらでお開きとさせていただきます。

皆様、活発な意見交換、誠にお疲れ様でございました。
0495デフォルトの名無しさん
垢版 |
2014/10/14(火) 01:48:42.60ID:QI+gLDOE
>>475
わからないから、教えて下さいだろ。池沼。
0498デフォルトの名無しさん
垢版 |
2014/10/14(火) 07:21:14.97ID:VoeXlFKz
この問題の根は、ファイル名に日本語を使うべきでないや、メールタイトルに
日本語を使うべきでない、と同じです。

こういった問題について議論すると、必ず日本語を使うべきでないという結論に落ち着く。
しかし、本当の答えは、日本語が使えるべきです。

RAIIは多くの問題を論理的に解消できるので、常に使えるようにするべきです。

LinuxでRAIIが問題を引き起こすことは良く知られています。
メモリーの開放に時間がかかるので、メモリーの明示的開放を避けるべきという議論も
その一つです。
しかし、本当の答えは、Linuxでもメモリーの開放に時間がかからないようにすることです。
RAIIを避けるべきという議論は、過去に繰り返された日本語を使うべきでないという議論と同じです。
0499デフォルトの名無しさん
垢版 |
2014/10/14(火) 08:43:00.85ID:rLZatyKU
Linux以外なら、細かく何度もmallocして、しかもスワップアウトした領域を
freeして回っても遅く無いってか？馬鹿じゃないの？
0500デフォルトの名無しさん
垢版 |
2014/10/14(火) 08:49:08.26ID:KA+Nt7Wt
先に大きめの領域確保して、開放すれば
細かく領域するときの速度が上げれるかもね
なんででしょうね？
0502デフォルトの名無しさん
垢版 |
2014/10/14(火) 09:05:57.25ID:VoeXlFKz
>>499
その問題の原因は、確保したメモリー領域の先頭に大きさなどの情報を持たせることです。
どれだけの大きさを開放するか調べるために遅い二次記憶から情報を復元します。

ですから、仮想記憶が一般的になると、多くのランタイムライブラリがメモリー管理を
OSに任せるようになりました。
メモリーの開放が直接OSによって処理されることで、OSは二次記憶から情報を取り出さずに
解放するタイミングを得ます。

残念ながらLinuxではそうなっていないため、メモリーを開放すると遅いので
解放するべきではないと主張する人が現れるようになりました。
0503デフォルトの名無しさん
垢版 |
2014/10/14(火) 09:58:22.05ID:9xoyfEkM
exitする直前にfreeしないのは、OSのメモリ管理機能を利用してるってことなんだけど？
0506デフォルトの名無しさん
垢版 |
2014/10/15(水) 20:16:19.78ID:94xVsGz9
>>503
バカ発見。
0508デフォルトの名無しさん
垢版 |
2014/10/16(木) 04:07:06.14ID:7g6vpmsm
>>502
＞ですから、仮想記憶が一般的になると、多くのランタイムライブラリがメモリー管理を
＞OSに任せるようになりました。
＞メモリーの開放が直接OSによって処理されることで、OSは二次記憶から情報を取り出さずに
＞解放するタイミングを得ます。
そんな非効率的なことをやってる環境があるの？
0510デフォルトの名無しさん
垢版 |
2014/10/17(金) 09:39:29.66ID:O3Ha9Xaq
何を非効率と言いたいか知らないが、アプリがfreeしまくればメモリアクセスは当然発生する。

サクッと終了しちゃえば、OSはそのアプリに割り当ててたページをそのまま割り当て解除して
回収するだけ。

この効率の差を理解できないか、OSというものを理解してない発言でしかないわけだがwwwww
0512デフォルトの名無しさん
垢版 |
2014/10/17(金) 16:21:12.12ID:qPP0na7I
アプリ終了以外では
ある程度の大きさ以外は、freeしても割り当て解除はされませんよ
だから、ヘタすると、メモリ分断が怒って....
0513デフォルトの名無しさん
垢版 |
2014/10/17(金) 17:45:37.94ID:O3Ha9Xaq
>>511 メモリを大量に確保するアプリならどれにでもあてはまる、
ということすら理解できないのかw
0514デフォルトの名無しさん
垢版 |
2014/10/17(金) 18:16:31.32ID:P1joaUul
>>513
> >>511 メモリを大量に確保するアプリならどれにでもあてはまる、

メモリの確保の仕方によって全然違うことも理解できないアホ乙
0515デフォルトの名無しさん
垢版 |
2014/10/17(金) 18:16:40.65ID:xzFrNjz5
>>510
>>502の言うようにOSにメモリ確保を丸投げしてる場合、APIによってはOSも参照カウントの操作・確認も行うかもしれんぞ？
(例えば、WinのCreateFileMappingで確保したページファイル領域は生きたハンドル(を持つプロセス)があれば残る)
解放をOSに任せることで確実に軽減できるのは、アプリ側が解放すべきハンドルやポインタを走査するコストだけ。
その他のコストは実装依存でどのくらい軽減できるかが異なる。
…けど、これが問題になるケースも実装もそう多くないだろうからなぁ…

>>513
メモリ管理情報の操作に時間がかかってるんだから、小さい領域を山のように確保してるアプリじゃないか？
ポインタの走査にも時間がかかりやすい構造(馬鹿正直なリンクリストなど)だとよりコストが増える。
0516デフォルトの名無しさん
垢版 |
2014/10/17(金) 19:39:54.06ID:lxCKNdJC
HeapAllocはプロセス内で確保したメモリを小分けして管理してるだけで、
それをOSの機能の一部みたいに扱うのはなんかモニョるな。
0518デフォルトの名無しさん
垢版 |
2014/10/17(金) 21:53:10.77ID:xzFrNjz5
>>516
言いたいことは分かるがWin32APIって案外そういうの多いからなぁ…
user32とかkernel32にも標準CライブラリみたいなAPI(sprintfモドキも居るしｗ)が結構一杯ある。
MulDivやCopyMemoryみたいなのも居るし、CopyRectに至ってはただの32バイトコピー。
HeapAlloc程度でモニョってたらこいつらはモニョるなんてレベルじゃすまんぞｗ
MulDiv(32ビット値3つから中間値64ビットの掛け算と割り算)が何故カーネル扱いなのかと。
0520デフォルトの名無しさん
垢版 |
2014/10/18(土) 13:08:53.33ID:36yYJ0yX
>>510
昔はそんなにメモリが潤沢になかったから、アプリが終了する前でも
不要になったら開放する方が、いろいろとよかった時代もあったんだよ

>>all
もうお前ら不毛だからこの辺にしとけ
0521デフォルトの名無しさん
垢版 |
2014/10/18(土) 13:50:57.61ID:/oNwCDSd
>>520
そうもいかない、そんな結論では C++ がいまだに営々と複雑化にこだわっている立つ瀬がない‥
0522デフォルトの名無しさん
垢版 |
2014/10/18(土) 16:59:54.98ID:36yYJ0yX
メモリは動的に確保するくせに開放は静的にOSに任せたい
だったら、必要になるであろうメモリも配列で静的に確保しとけばいいんじゃね？
とか思うんだが…

でこういうこと言うと荒れるから、結論は
freeしたい人はして、したくない人はしない
で終了でいいんじゃね？っていう
0523デフォルトの名無しさん
垢版 |
2014/10/18(土) 17:06:19.18ID:/oNwCDSd
>>522
それは古来lispでもよくみられたプール式、cons セルという定サイズ領域を多量に使う用途で採用されているのをみたことがある
0524デフォルトの名無しさん
垢版 |
2014/10/19(日) 18:09:53.15ID:9/KRJRbT
解放しないプロセスってデバッガで実行すると終了時に大量のleak検出を吐き出したりしないのか？
0526デフォルトの名無しさん
垢版 |
2014/10/20(月) 12:45:42.29ID:4QGk34Ml
たぶんメモリリークしてもプロセス終了時に
全部解放されるんだから大丈夫だと思ってるんじゃない？
0529デフォルトの名無しさん
垢版 |
2014/10/20(月) 19:48:59.73ID:+DF5oC/s
メモリリーク検出ツールでリークと解放の
区別がつかなくなるから解放しとけって話でしょｗ
0530デフォルトの名無しさん
垢版 |
2014/10/20(月) 23:06:26.87ID:exxFMbgq
プログラム中で確保したメモリの各々がfreeする必要あるかないか、間違えずに
判断できる達人ならリークチェッカ使う必要ないな。
0534デフォルトの名無しさん
垢版 |
2014/10/21(火) 13:25:02.74ID:LAOYaiit
リークチェッカなんて必要ない。
作った奴は馬鹿だ。
ミスをしなければいいだけの話。
0536デフォルトの名無しさん
垢版 |
2014/10/21(火) 17:55:34.62ID:RumsGmel
デバッグモードでコンパイルしたときだけ解放したら
良いだけじゃん馬鹿すぎ
0537デフォルトの名無しさん
垢版 |
2014/10/21(火) 18:51:18.50ID:LAOYaiit
>>535
その修正をサポートするルールがリークチェッカでしょ？

で、free不要なんていって、free書いてないから
たくさん出るエラーの中から本当にリークしているものを
探して出すというマヌケな作業を行うｗｗｗ

結論出たじゃん？ freeは必要。
0539デフォルトの名無しさん
垢版 |
2014/10/21(火) 20:16:00.88ID:7WAeJlTS
なんでfree関数というものがあるのかを考えればわかるよな
もう終わりだろ…
0540デフォルトの名無しさん
垢版 |
2014/10/21(火) 21:03:35.69ID:c8NUu7RB
意図的にfree省略してる場合は>>536で済むってのは置いといても、
>>534ではリークチェッカ自体が不要と言っているのに、
>>537ではリークチェッカの為にfreeが必要って変な結論だなぁ…
0541デフォルトの名無しさん
垢版 |
2014/10/21(火) 21:34:25.75ID:FB8PDZ29
リークチェッカのエラーをなくすことが答えだと思ってる人もいますね
微妙な...
0542デフォルトの名無しさん
垢版 |
2014/10/21(火) 22:04:40.05ID:RG7X7O+y
リークチェッカーでリークを葬ったら、おもむろに選別していけば言いだけの話
というか、リソースリークの方が深刻でちょっと困っている
0543デフォルトの名無しさん
垢版 |
2014/10/22(水) 21:25:19.20ID:9Jwqj8Ni
おもむろに選別する効果・・・0.001秒速くなる。
デメリット、選別作業に数時間。
ドラブルあって、戻すのに数時間
0546デフォルトの名無しさん
垢版 |
2014/12/03(水) 21:28:00.02ID:j0dAKNGZ
C++だと、動的確保って

int *a = new int;

/*
aを使った処理
*/

delete a;

みたく書くと思うけど、deleteしないとアプリケーションを終了させても
確保されっぱなしだよね？
free()不要とか言ってるやつは、上記でいうdelete不要って言ってるのと
同じだよね？
0547デフォルトの名無しさん
垢版 |
2014/12/03(水) 21:41:48.53ID:JFY2u8h+
newは互換性のためにmallocで実装されてると聞いたことがある。ほんとか知らんけど。
0548デフォルトの名無しさん
垢版 |
2014/12/03(水) 22:01:51.69ID:U2a4HdIu
>>546
＞deleteしないとアプリケーションを終了させても確保されっぱなしだよね？
いや、それはない。アプリ終了時にアプリの使用していたメモリは OS が解放する。これは基本的な共通認識。
それをみこして free()/delete を①まったくしないでもいい、②選別して使用しないのもありだ、③信者ならどんな new/malloc() も必ず delete/free() すべきだ、真っ向に対立している。
0550デフォルトの名無しさん
垢版 |
2014/12/04(木) 02:18:35.19ID:wOy+480c
C++なら、メモリマネージメントクラス書くでしょ。その前にstd::vectorあるけど。
0551デフォルトの名無しさん
垢版 |
2014/12/04(木) 04:20:29.25ID:ViSTblTx
Jane使ってる人は分かると思うけど、一度に多量の画像を保存する機会が多いと思う
そしてJaneは一度立ち上げたらOS再起動するまで大抵立ち上げっぱなし

そんな状態で画像の展開領域のためにmalloc()もしくはnewしたメモリをfree()やdelete
しなかったらどうなる？これ32bitアプリでしょ？120～150枚ほど画像を開くと、例えば俺の
環境の場合Windows8.1だからJaneには2GB割り当あられるけど、free()しないとすぐに
メモリがなくなっちゃうね
0552デフォルトの名無しさん
垢版 |
2014/12/04(木) 07:46:58.88ID:44/e6+B9
delete/free()不要って言ってる人って、もはやなぜメモリを動的に確保するのか？
の意味を見失ってる人ですよね？
可哀想です
0553デフォルトの名無しさん
垢版 |
2014/12/04(木) 08:53:33.85ID:i8WWsgkD
>>548
最初は1を主張する馬鹿を論破するだけで、2と3の区別なんて無かったんだけどなぁ…
2に対する3を定義しなおして信者信者言うのは論破された1が苦し紛れに言い出したかのような話題でなんていうかアレ。

そもそも2は全てdelete/freeも出来ない奴のスキルでは不可能だし、
メンテナンス性などの面から見ても必要があれば全て開放できる設計でないとダメ。
そもそも選択して開放しない方が良いなんて言うケースの方が例外的なのに、そんなの持ちだしてまで騒ぐなよ、と。

>>552
だよね。本来はその一言で終わる話題なのに・・・
0554デフォルトの名無しさん
垢版 |
2014/12/04(木) 09:15:31.23ID:otxDKoZc
ガベージコレクションはいらない、と必死でやせ我慢してC++を使う俺カッコイイ、というわけですねわかります
本来はこの一言で終わる話なのに、可哀想です
0557デフォルトの名無しさん
垢版 |
2014/12/04(木) 20:36:19.32ID:e632zg1P
>>554
GC はまだ「完成された」というほどの領域に至っていない、Mark&Sweep とか　CopyGC, 世代別GC、incrementalGCなど、いろんな手法を駆使してだましだまし実装しているレベル
うそだと思うのなら、スマフォアプリを見ればよい、スマフォは定期的に再起動しないといけないレベル、iphone は定期的にiOSアップデートの方が先にやってくるようだが
0559デフォルトの名無しさん
垢版 |
2014/12/04(木) 20:50:13.03ID:otxDKoZc
研究が盛んなあらゆる分野に「まだ「完成された」というほどの領域に至っていない」って
喧嘩売ってみろよw
0561デフォルトの名無しさん
垢版 |
2014/12/04(木) 21:25:34.66ID:otxDKoZc
いろんな手法を駆使してだましだまし漏れがないようにしているレベル、って言うんじゃないのか、それw
0563デフォルトの名無しさん
垢版 |
2014/12/04(木) 23:15:24.98ID:Q4EOsLJ8
malloc/freeでバグばっかり出してる奴が「freeしない」という解決策を正当化しようとしているだけの話。
0564デフォルトの名無しさん
垢版 |
2014/12/05(金) 00:48:52.11ID:3wjXi0Au
この感じだとバグ出す以前の問題で、deleteの使い方知らずに恥かいたJava厨なんじゃね？
0565デフォルトの名無しさん
垢版 |
2014/12/05(金) 01:39:25.94ID:eQEw8fvn
なぜメモリを動的に確保する必要があるのか？という基本に立ち返って考えれば
不要論は論外であることに気づくだろう
注：このスレタイからわかるように近年のGCは範疇に入っていない
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況