mallocの後にfree不要と言うバカいるの?Part2

**デフォルトの名無しさん** · 2013/01/30(水) 21:38:37.44

fjの時代から10年以上に渡るmalloc/free問題について語ってください(^q^)

前スレ
main以外★mallocの後にfree不要と言うバカいるの?
http://toro.2ch.net/test/read.cgi/tech/1352812333/

**デフォルトの名無しさん** · 2014/10/13(月) 18:52:40.24

プログラムの再利用性、安全性を真剣に考えると、RAIIは有効な手法。

これに反対するのは雑魚。

Linuxを使わないことも大事。
Linuxはファイルのコピーすら満足にできないって>>297が述べてる。

**デフォルトの名無しさん** · 2014/10/13(月) 18:59:10.36

>>297のケースで有効な解法はメモリプール
これがわからない奴は雑魚

**デフォルトの名無しさん** · 2014/10/13(月) 19:06:21.99

>>449
cpはハッシュテーブルを最後まで使うから
即座にOSにメモリを返すとか、何にも関係無いんだよなぁ…

**デフォルトの名無しさん** · 2014/10/13(月) 19:15:48.89

>>457
メモリープールが問題になってるのに、メモリープールが解法と言ってるのだから、
わからなくて当然。
もう少し勉強しなさい。

**448** · 2014/10/13(月) 19:19:27.66

>>454
認識が確認できて幸いです。

わざわざそんなケースと言われるけど、
このようなケースは結構多いと思うんですよ。

普段使ってるgccもたぶんそうだし、
cpだってそう。

本質的に記憶領域の再利用がされないfreeをするために
循環参照があるリンクトリストを再帰で開放してまわったり
freeをするための1万回のループをわざわざ書くというのは
なんというか、知的ではないのではないかと

もちろん、ライブラリ化するために、解放処理を記述するのは
必要ですけど、例えばgccの構文木を保持するコードは
gcc以外に使えるとは思えないなぁ。
だから、専用に作ったんでしょ

**デフォルトの名無しさん** · 2014/10/13(月) 19:24:40.28

変な論法だね‥
「free()/delete してもしなくても状況に大きな変化はない。∴free()/delete しなくてよい。」
と理解していいのかな？

**デフォルトの名無しさん** · 2014/10/13(月) 19:27:50.10

>>459
Linux界隈だとそれでいいんですけどね。
ctagsでインテリセンスより強いとか言ってればいい。

でも、いまどきの人は構文上の誤りは即座に指摘してほしいし、書く端から
補完が効いてほしいですよね。
すると、コンパイラの機能だと思われていたものすらエディタに組み込まれたりするわけですよ。

まあ、Linuxなんか使ってると20年前で時が止まっちゃうんですけどね。
世間ではそういうのを雑魚って言うんです。

**デフォルトの名無しさん** · 2014/10/13(月) 19:32:32.92

>>456
その解法がメモリープールというのは、
ハッシュテーブルの領域全体をmallocでとって来て
中身を自前のメモリ管理コードで管理して、
解放するときは全体をfree一発で解放ってことでしょうか ?

malloc-freeはsbrkやmmapで確保した領域を
管理するメモリプールだと考えられます。

ですので、再利用する見込みのない領域をわざわざfreeする必要は
ないんじゃないのって考え方は、
上記の大きな記憶領域を確保して、解放はfree一発というものと
同一になります。

**デフォルトの名無しさん** · 2014/10/13(月) 19:36:18.84

>>461
全然関係ないこと書いてないで、

> 循環参照があるリンクトリストを再帰で開放してまわったり
> freeをするための1万回のループをわざわざ書くというのは

についてコメントしたら？

**デフォルトの名無しさん** · 2014/10/13(月) 19:39:14.34

>>462
それは>>363で指摘したから、そういう話じゃないと思う。

GNUマンセーって話でしょ。

**デフォルトの名無しさん** · 2014/10/13(月) 19:40:18.64

>>463
関係ないと思うなら、もう少し勉強しましょう。

**デフォルトの名無しさん** · 2014/10/13(月) 19:43:33.90

>>459
> このようなケースは結構多いと思うんですよ。

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

まあ、そうだとしても構文木を作成してる所以外でリークしない自信があるとか、リークしても気にしないと言うなら止めないよので、自由にやってくださいな。

**デフォルトの名無しさん** · 2014/10/13(月) 19:44:39.36

>本質的に記憶領域の再利用がされないfreeをするために
>循環参照があるリンクトリストを再帰で開放してまわったり
>freeをするための1万回のループをわざわざ書くというのは
>なんというか、知的ではないのではないかと

リスト要素の構築と破棄を一回書けばそれが何万回呼ばれようと
同じだと思うんだが、それを「わざわざ」と言うのはどういうスタイルで
書いてんのか気になるな。
循環参照とか言っているところを見ると、fjのときも出てきたような
「作った本人が正しく破棄することができないデータ構造」とかかねぇ。

**デフォルトの名無しさん** · 2014/10/13(月) 19:47:00.34

RAIIはおろかな考えというネタでもう一スレ作れそうな気がするな。

**デフォルトの名無しさん** · 2014/10/13(月) 20:12:51.45

>>467
> リスト要素の構築と破棄を一回書けばそれが何万回呼ばれようと
> 同じだと思うんだが、

パフォーマンス的には全然同じじゃないよ
コードの字面的に呼び出しが無かったら処理が存在しないとでも思ってるの？馬鹿？

**デフォルトの名無しさん** · 2014/10/13(月) 20:25:00.67

ちなみに>>469は俺です。

あと500レスみんなで頑張ってください。

**デフォルトの名無しさん** · 2014/10/13(月) 20:36:14.64

リンクドリストの場合はmallocすら何回もするのがめんどくさいので、
ブロックで確保して破棄はブロックの数分だけでいいのでは？
ゲームでは常識。

**458** · 2014/10/13(月) 20:39:23.78

>>467
わかりにくい書き方ですみません。

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

後半は、行列なんかを使った後に
for(i = 0; i < ROW_MAX; i++) {
free(row[i]);
}
free(row);
exit(0);
なんてことをやることを想定しています。

**デフォルトの名無しさん** · 2014/10/13(月) 20:42:43.81

行列は幅が変わらないので、W*Hで確保してW*y+xすれば何度も確保する必要ない。

**デフォルトの名無しさん** · 2014/10/13(月) 20:51:37.45

>>447
わからないから、教えて下さいだろ。池沼。

**デフォルトの名無しさん** · 2014/10/13(月) 21:03:25.09

>>474

>>411
>>434
>>435

**デフォルトの名無しさん** · 2014/10/13(月) 21:09:11.84

>>469
> パフォーマンス的には全然同じじゃないよ

で、そのパフォーマンスが問題になってるの？

**デフォルトの名無しさん** · 2014/10/13(月) 21:09:16.45

>>472
前者は、参照の所有権をちゃんと考えないで複雑なデータ構造を作っちゃうと
いざ壊そうと思ったときに嵌ったりバグったりする典型だね。
後者は、使い捨てのやっつけプログラムとかじゃなければ普通こんなコードが
exit()の直前に置かれることはないと思うし、そうであれば普通に破棄処理として
書くと思うんだけどなぁ。それを「わざわざ」と思うのはまぁ、個人の感覚かも知れんが。
＃あぁ、rowもグローバル変数だったりするのかね？

**デフォルトの名無しさん** · 2014/10/13(月) 21:23:47.22

>>476
問題になってるかどうかはどうでもよくね？

1ナノ秒でも1ミリ秒でも速いほうがいいだろう？
速くなることにメリットはあれどデメリットはない。

**デフォルトの名無しさん** · 2014/10/13(月) 21:31:35.61

>>478
小手先の最適化をバンバンやれと言う主張ですね
まあ、頑張ってくださいな w

**デフォルトの名無しさん** · 2014/10/13(月) 21:47:30.33

>>479
ちりも積もれば山となるってことわざ知らないの？

1ナノ秒でも積もれば1時間になるんだけど。

**472** · 2014/10/13(月) 21:54:16.26

>>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もグローバル変数だったりするのかね？

あくまで、例のための例ですが、グローバルなときもあります。
# というか、そのほうがすっきりする。

**デフォルトの名無しさん** · 2014/10/13(月) 21:57:14.67

>>480
> ちりも積もれば山となるってことわざ知らないの？

知ってる。
だから、小手先の最適化なんてしないんだよ。
速さより、重要なことってあるんだよ。

**デフォルトの名無しさん** · 2014/10/13(月) 22:05:33.55

速さよりも重要な事なんて無いよ。
金さえあればスパコンがほしいぐらい。

**デフォルトの名無しさん** · 2014/10/13(月) 22:09:28.23

そーゆーレベルだとアルゴリズム工夫した方が早くならね？

**デフォルトの名無しさん** · 2014/10/13(月) 22:15:14.16

>>483
それは、正確さだなｗ
あと脆弱性への強さ。
コードの見通しのよさ、コードの柔軟さ。

速さがどーしても欲しいってのはリアルタイムOSとかそういう分野なのかなぁ？

**デフォルトの名無しさん** · 2014/10/13(月) 22:17:23.60

>>483
マルチスレッド使っての高速化とかは無理？

**デフォルトの名無しさん** · 2014/10/13(月) 23:38:21.18

>>483 は素早く間違った結果が欲しいんだろう w

**デフォルトの名無しさん** · 2014/10/13(月) 23:41:05.25

>>470
いや、俺はお前みたいな馬鹿じゃないぞ

**デフォルトの名無しさん** · 2014/10/13(月) 23:41:20.11

>>485
> 速さがどーしても欲しいってのはリアルタイムOSとかそういう分野なのかなぁ？

そういう分野は、速さと言うよりどんな場合でも決められた時間に間に合うこと（つまり、遅くならないこと）を要求される
ハードリアルアイムでググってみそ

**デフォルトの名無しさん** · 2014/10/13(月) 23:42:12.91

freeが必要だと思う人はしていただき、その必要性はないと思う人はしない
ということで各々ご対応をお願い致します。

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

皆様、活発な意見交換、誠にお疲れ様でございました。

**デフォルトの名無しさん** · 2014/10/13(月) 23:50:17.84

>>490
>>379

**デフォルトの名無しさん** · 2014/10/14(火) 00:04:57.97

>>491
おまえ、まだいたのかｗｗｗｗ

**デフォルトの名無しさん** · 2014/10/14(火) 00:16:00.24

>>492
チキン君乙

**デフォルトの名無しさん** · 2014/10/14(火) 00:17:04.09

よく吠えるやつほど弱いのはどこでも同じだな

**デフォルトの名無しさん** · 2014/10/14(火) 01:48:42.60

>>475
わからないから、教えて下さいだろ。池沼。

**デフォルトの名無しさん** · 2014/10/14(火) 06:32:50.32

>>403
ネタ主張を1400レスも続けるとかヒッデェなぁ…

**デフォルトの名無しさん** · 2014/10/14(火) 06:34:31.53

>>494
うんうん、そうだねー
で、説明は？ w

**デフォルトの名無しさん** · 2014/10/14(火) 07:21:14.97

この問題の根は、ファイル名に日本語を使うべきでないや、メールタイトルに
日本語を使うべきでない、と同じです。

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

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

LinuxでRAIIが問題を引き起こすことは良く知られています。
メモリーの開放に時間がかかるので、メモリーの明示的開放を避けるべきという議論も
その一つです。
しかし、本当の答えは、Linuxでもメモリーの開放に時間がかからないようにすることです。
RAIIを避けるべきという議論は、過去に繰り返された日本語を使うべきでないという議論と同じです。

**デフォルトの名無しさん** · 2014/10/14(火) 08:43:00.85

Linux以外なら、細かく何度もmallocして、しかもスワップアウトした領域を
freeして回っても遅く無いってか？馬鹿じゃないの？

**デフォルトの名無しさん** · 2014/10/14(火) 08:49:08.26

先に大きめの領域確保して、開放すれば
細かく領域するときの速度が上げれるかもね
なんででしょうね？

**デフォルトの名無しさん** · 2014/10/14(火) 08:50:02.00

☓細かく領域するとき
○細かく領域確保するとき

**デフォルトの名無しさん** · 2014/10/14(火) 09:05:57.25

>>499
その問題の原因は、確保したメモリー領域の先頭に大きさなどの情報を持たせることです。
どれだけの大きさを開放するか調べるために遅い二次記憶から情報を復元します。

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

残念ながらLinuxではそうなっていないため、メモリーを開放すると遅いので
解放するべきではないと主張する人が現れるようになりました。

**デフォルトの名無しさん** · 2014/10/14(火) 09:58:22.05

exitする直前にfreeしないのは、OSのメモリ管理機能を利用してるってことなんだけど？

**デフォルトの名無しさん** · 2014/10/14(火) 10:05:00.55

てなしたやはたてやな

**デフォルトの名無しさん** · 2014/10/14(火) 10:21:21.80

長文の割にワケワカなこと書いて漫画な

**デフォルトの名無しさん** · 2014/10/15(水) 20:16:19.78

>>503
バカ発見。

**デフォルトの名無しさん** · 2014/10/15(水) 20:25:23.13

自己紹介乙

**デフォルトの名無しさん** · 2014/10/16(木) 04:07:06.14

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

**デフォルトの名無しさん** · 2014/10/16(木) 06:57:35.08

VCのmallocはHeapAllocに丸投げする場合があるようだが、一般的かっていうと…

**デフォルトの名無しさん** · 2014/10/17(金) 09:39:29.66

何を非効率と言いたいか知らないが、アプリがfreeしまくればメモリアクセスは当然発生する。

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

この効率の差を理解できないか、OSというものを理解してない発言でしかないわけだがwwwww

**デフォルトの名無しさん** · 2014/10/17(金) 16:14:49.18

>>510
で、その効率の差が実感できるアプリケーションってなに？
心のよりどころの cp だけ？ w

**デフォルトの名無しさん** · 2014/10/17(金) 16:21:12.12

アプリ終了以外では
ある程度の大きさ以外は、freeしても割り当て解除はされませんよ
だから、ヘタすると、メモリ分断が怒って....

**デフォルトの名無しさん** · 2014/10/17(金) 17:45:37.94

>>511 メモリを大量に確保するアプリならどれにでもあてはまる、
ということすら理解できないのかw

**デフォルトの名無しさん** · 2014/10/17(金) 18:16:31.32

>>513
> >>511 メモリを大量に確保するアプリならどれにでもあてはまる、

メモリの確保の仕方によって全然違うことも理解できないアホ乙

**デフォルトの名無しさん** · 2014/10/17(金) 18:16:40.65

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

>>513
メモリ管理情報の操作に時間がかかってるんだから、小さい領域を山のように確保してるアプリじゃないか？
ポインタの走査にも時間がかかりやすい構造(馬鹿正直なリンクリストなど)だとよりコストが増える。

**デフォルトの名無しさん** · 2014/10/17(金) 19:39:54.06

HeapAllocはプロセス内で確保したメモリを小分けして管理してるだけで、
それをOSの機能の一部みたいに扱うのはなんかモニョるな。

**デフォルトの名無しさん** · 2014/10/17(金) 20:22:20.74

>>511
お前がひねり出したうんこプログラム全部

**デフォルトの名無しさん** · 2014/10/17(金) 21:53:10.77

>>516
言いたいことは分かるがWin32APIって案外そういうの多いからなぁ…
user32とかkernel32にも標準CライブラリみたいなAPI(sprintfモドキも居るしｗ)が結構一杯ある。
MulDivやCopyMemoryみたいなのも居るし、CopyRectに至ってはただの32バイトコピー。
HeapAlloc程度でモニョってたらこいつらはモニョるなんてレベルじゃすまんぞｗ
MulDiv(32ビット値3つから中間値64ビットの掛け算と割り算)が何故カーネル扱いなのかと。

**デフォルトの名無しさん** · 2014/10/18(土) 01:39:31.35

>>510
つスレッドタイトル

**デフォルトの名無しさん** · 2014/10/18(土) 13:08:53.33

>>510
昔はそんなにメモリが潤沢になかったから、アプリが終了する前でも
不要になったら開放する方が、いろいろとよかった時代もあったんだよ

>>all
もうお前ら不毛だからこの辺にしとけ

**デフォルトの名無しさん** · 2014/10/18(土) 13:50:57.61

>>520
そうもいかない、そんな結論では C++ がいまだに営々と複雑化にこだわっている立つ瀬がない‥

**デフォルトの名無しさん** · 2014/10/18(土) 16:59:54.98

メモリは動的に確保するくせに開放は静的にOSに任せたい
だったら、必要になるであろうメモリも配列で静的に確保しとけばいいんじゃね？
とか思うんだが…

でこういうこと言うと荒れるから、結論は
freeしたい人はして、したくない人はしない
で終了でいいんじゃね？っていう

**デフォルトの名無しさん** · 2014/10/18(土) 17:06:19.18

>>522
それは古来lispでもよくみられたプール式、cons セルという定サイズ領域を多量に使う用途で採用されているのをみたことがある

**デフォルトの名無しさん** · 2014/10/19(日) 18:09:53.15

解放しないプロセスってデバッガで実行すると終了時に大量のleak検出を吐き出したりしないのか？

**デフォルトの名無しさん** · 2014/10/20(月) 02:00:02.18

吐いたとしても意図的に吐かせてるつもりだろうから問題ないんだろ

**デフォルトの名無しさん** · 2014/10/20(月) 12:45:42.29

たぶんメモリリークしてもプロセス終了時に
全部解放されるんだから大丈夫だと思ってるんじゃない？

**デフォルトの名無しさん** · 2014/10/20(月) 12:49:49.79

リソースリークとメモリリークの区別もできないとかが典型例だな

**デフォルトの名無しさん** · 2014/10/20(月) 19:41:25.28

リークと解放の区別が付かないバカは死ねば良いと思う。

**デフォルトの名無しさん** · 2014/10/20(月) 19:48:59.73

メモリリーク検出ツールでリークと解放の
区別がつかなくなるから解放しとけって話でしょｗ

**デフォルトの名無しさん** · 2014/10/20(月) 23:06:26.87

プログラム中で確保したメモリの各々がfreeする必要あるかないか、間違えずに
判断できる達人ならリークチェッカ使う必要ないな。

**デフォルトの名無しさん** · 2014/10/21(火) 12:31:58.89

>>530を省略すると、

ミスをしない人はリークチェッカはいらない。

ということ。

**デフォルトの名無しさん** · 2014/10/21(火) 12:58:58.48

要約？

**デフォルトの名無しさん** · 2014/10/21(火) 13:01:27.03

普通にできないといけないことではないかと

**デフォルトの名無しさん** · 2014/10/21(火) 13:25:02.74

リークチェッカなんて必要ない。
作った奴は馬鹿だ。
ミスをしなければいいだけの話。

**デフォルトの名無しさん** · 2014/10/21(火) 13:49:27.95

ミスしてもいいのでは、修正できれば
いきなり完成品？作れる人いるのけ

**デフォルトの名無しさん** · 2014/10/21(火) 17:55:34.62

デバッグモードでコンパイルしたときだけ解放したら
良いだけじゃん馬鹿すぎ

**デフォルトの名無しさん** · 2014/10/21(火) 18:51:18.50

>>535
その修正をサポートするルールがリークチェッカでしょ？

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

結論出たじゃん？ freeは必要。

**デフォルトの名無しさん** · 2014/10/21(火) 19:58:14.89

便利な道具がある。
とかいうとわからないでも出来ると勘違い...

**デフォルトの名無しさん** · 2014/10/21(火) 20:16:00.88

なんでfree関数というものがあるのかを考えればわかるよな
もう終わりだろ…

**デフォルトの名無しさん** · 2014/10/21(火) 21:03:35.69

意図的にfree省略してる場合は>>536で済むってのは置いといても、
>>534ではリークチェッカ自体が不要と言っているのに、
>>537ではリークチェッカの為にfreeが必要って変な結論だなぁ…

**デフォルトの名無しさん** · 2014/10/21(火) 21:34:25.75

リークチェッカのエラーをなくすことが答えだと思ってる人もいますね
微妙な...

**デフォルトの名無しさん** · 2014/10/21(火) 22:04:40.05

リークチェッカーでリークを葬ったら、おもむろに選別していけば言いだけの話
というか、リソースリークの方が深刻でちょっと困っている

**デフォルトの名無しさん** · 2014/10/22(水) 21:25:19.20

おもむろに選別する効果・・・0.001秒速くなる。
デメリット、選別作業に数時間。
ドラブルあって、戻すのに数時間

**デフォルトの名無しさん** · 2014/10/23(木) 01:07:59.70

>>542
リソースの確保・開放処理をリークチェッカと同じ仕組でラップしよう。

**デフォルトの名無しさん** · 2014/10/23(木) 08:36:30.18

>>544
api の数だけラップを用意するのもなんだかね‥

**デフォルトの名無しさん** · 2014/12/03(水) 21:28:00.02

C++だと、動的確保って

int *a = new int;

/*
aを使った処理
*/

delete a;

みたく書くと思うけど、deleteしないとアプリケーションを終了させても
確保されっぱなしだよね？
free()不要とか言ってるやつは、上記でいうdelete不要って言ってるのと
同じだよね？

**デフォルトの名無しさん** · 2014/12/03(水) 21:41:48.53

newは互換性のためにmallocで実装されてると聞いたことがある。ほんとか知らんけど。

**デフォルトの名無しさん** · 2014/12/03(水) 22:01:51.69

>>546
＞deleteしないとアプリケーションを終了させても確保されっぱなしだよね？
いや、それはない。アプリ終了時にアプリの使用していたメモリは OS が解放する。これは基本的な共通認識。
それをみこして free()/delete を①まったくしないでもいい、②選別して使用しないのもありだ、③信者ならどんな new/malloc() も必ず delete/free() すべきだ、真っ向に対立している。

**デフォルトの名無しさん** · 2014/12/03(水) 22:25:43.16

③選別するほうが面倒くさいだろう

**デフォルトの名無しさん** · 2014/12/04(木) 02:18:35.19

C++なら、メモリマネージメントクラス書くでしょ。その前にstd::vectorあるけど。

**デフォルトの名無しさん** · 2014/12/04(木) 04:20:29.25

Jane使ってる人は分かると思うけど、一度に多量の画像を保存する機会が多いと思う
そしてJaneは一度立ち上げたらOS再起動するまで大抵立ち上げっぱなし

そんな状態で画像の展開領域のためにmalloc()もしくはnewしたメモリをfree()やdelete
しなかったらどうなる？これ32bitアプリでしょ？120～150枚ほど画像を開くと、例えば俺の
環境の場合Windows8.1だからJaneには2GB割り当あられるけど、free()しないとすぐに
メモリがなくなっちゃうね

**デフォルトの名無しさん** · 2014/12/04(木) 07:46:58.88

delete/free()不要って言ってる人って、もはやなぜメモリを動的に確保するのか？
の意味を見失ってる人ですよね？
可哀想です

**デフォルトの名無しさん** · 2014/12/04(木) 08:53:33.85

>>548
最初は1を主張する馬鹿を論破するだけで、2と3の区別なんて無かったんだけどなぁ…
2に対する3を定義しなおして信者信者言うのは論破された1が苦し紛れに言い出したかのような話題でなんていうかアレ。

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

>>552
だよね。本来はその一言で終わる話題なのに・・・

**デフォルトの名無しさん** · 2014/12/04(木) 09:15:31.23

ガベージコレクションはいらない、と必死でやせ我慢してC++を使う俺カッコイイ、というわけですねわかります
本来はこの一言で終わる話なのに、可哀想です