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/12(日) 15:30:56.77

mallocの先にfreeしてみてはどうだろうか

**デフォルトの名無しさん** · 2014/10/12(日) 15:35:01.76

>>388
freeは必要だが、場合によってはOSに任せとけって言うやつがいるから
結論として>>370で終了なんだよ
何度言ったらわかるんだ

**デフォルトの名無しさん** · 2014/10/12(日) 15:46:26.73

freeできることの判断を局所化することはできるが、freeしなくても問題ないという
判断は大域的にならざるを得ない。あとはセンスの問題だ。
グローバル変数バンバン使って平気な人もいるしな。

**デフォルトの名無しさん** · 2014/10/12(日) 16:02:22.91

>>390
お前のなかでは終わりなんだろ？
もう、でてくんなよ

**デフォルトの名無しさん** · 2014/10/12(日) 16:04:41.38

>>392
ワロタｗ

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

free必須教の第一信徒はQz

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

>>297はブログに書くことじゃなくてツイッターにでも書けばいい。

「私はRAIDの復旧にcpを使うバカです」

一行で済む。

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

RAID 6 ってつよいの？

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

>>395
RAIDの復旧じゃなくて、復旧不可能なRAIDから生きてるファイルを吸い上げる
だろ、本当にfree必須教信者は頭が悪いな

◆QZaw55cn4c · 2014/10/13(月) 10:04:24.56

>>297 の事情はよくわかる、所詮 free() はプロセスがOSから取得したメモリブロックのなかでのつじつまあわせ

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

>>397
> RAIDの復旧じゃなくて、復旧不可能なRAIDから生きてるファイルを吸い上げる

本質に関係ないところに突っ込むしかないアホが不憫だ w

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

必須派vs不要派　っていう対立が不毛だわな
ワザとやってるのかそれが分からないのか
必須派vs必須じゃあないだろう？派　ってだけだろ

**デフォルトの名無しさん** · 2014/10/13(月) 11:04:25.31

いや逆じゃね。
現実的にはほぼ必須派と、常に要らない派との争いで
何故か常に要らない派が、分かっていて
freeしなくてもいいある意味特殊な例を
持ち出して、だからfreeは必要ないみたいに
無茶な論理を成り立たせようとしているだけ。

**デフォルトの名無しさん** · 2014/10/13(月) 11:08:58.83

不要であるという結論ならば必須派は無駄なことをしていることになる
だが
必要であるという結論ならば不要派がこれまで書いたプログラムがゴミとみなされる

ゆえに必死

**デフォルトの名無しさん** · 2014/10/13(月) 11:28:22.88

>>399
お前>>395だろ
本質じゃない処に突っ込んでるのはお前
バカ過ぎる

>>401
ネタ以外で常に要らないなんて言ってる奴は居ない
本気で、いかなる場合と必要と言ってるバカが居る

**デフォルトの名無しさん** · 2014/10/13(月) 11:30:56.35

そんなことより、小沢GOGO！チャイニーズ for see.の意味が分からん。

**デフォルトの名無しさん** · 2014/10/13(月) 11:58:25.05

>>401みたいな知能だと生きていくのも大変なんだろうな

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

>>403
> 復旧不可能なRAIDから生きてるファイルを吸い上げる

で、なにが違うか書いてみな w

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

>>406
書いてみなじゃなくて、教えて下さいだろ、池沼

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

>>403
「常に」じゃないとすると、どういう基準で要る要らないを判断するのかという話に
なるわけだけど、「exit()の直前は要らない、それ以外は要る」でいいんだっけ？

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

4億3200万ファイル40TBをたかがメモリー10GBのUbuntuで、cp使ってコピー
しようという考えが、頭が悪いという以前に気が狂ってるんだよ。

「UNIXという考え方」などとのたまってそうだよな。

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

ヒープに空きを作りたいときに呼ぶ、たったそれだけのこと。

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

>>407
いつもの書けない言い訳乙 w

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

空きを作りたい時を決定するのに時間がかかるから、こまめに開放する。

こういう事を書くと、「空きを作りたいときに、配列のサイズ調べるだけだろ？」
みたいなことを言い出す奴が必ず出てくる。

もうアホすぎて話にならない。

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

>>410
空きを作りたいときに破棄できるポインタが常に手元にあるわけじゃないだろうし。
まさかそこでまとめてfreeするために、freeせずに取っておいたポインタを渡すというのも
本末転倒だろうし。
それ以前にそもそも、コードのこの部分を実行するときは空きが必要だがこの部分では
必要ないと判断するのも大変そうだなぁ。さらに、必要なときに空きを作れるようにするには
結局freeするコードは記述しておかなくちゃならんわけだよね。

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

>>413
したいときに、つってるやん。
理由があってfree呼び出し遅延させたいならそうすればいいし、
とっとと片付けておきたいならすぐ呼び出せばいい。
呼びたきゃいつでも呼んでいいんやで？　望みどおりにすればいい。

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

>>414
呼び出したいときを知るのが大変。

いつ呼び出すかについて仕様を述べよ。

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

要は、一貫したルールはないけど好きなようにやらせろと。まぁ、それは自由だな。

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

>>416
一貫したルール云々はよく分からんが、
とにかく自由なんだよ。freeは義務じゃなくて権利な。
空きを作りたいとき呼べば、空きが出来る。それだけ。

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

WindowsのCRTはfreeするとOSがそのメモリを有効に使えるからな。

こういう事書くと、「仮想記憶云々」言い出す奴が必ず出てくる。

もうアホすぎて話にならない。

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

>>417
プログラミングしたことが無いとそう思うんだよ。

「空きを作りたいとき」なんて仕様化できない。

「メモリーの使用量が特定の数値以上になった場合、解放する」
これなら仕様化出来る。

ところが、特定の数値以上になっているかいつ調べるか？ということも
仕様化しないといけなくなる。
これはたいてい、「一定時間経過ごとに」あるいは「メモリー確保の時点で」
となるだろう。
このどちらもいけていない。
オブジェクトの生存期間が過ぎた時点で解放するのが一番いけてるプログラミングマナー。

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

>>417
「若者には間違いを犯す権利がある」
胸熱だな。

**デフォルトの名無しさん** · 2014/10/13(月) 14:02:09.69

したいときにするって、結局、メモリー確保の時点で使用量見て解放することになるんだよ。
なんで、これから計算を始めるときに、わざわざ仕事増やすのさ。

使わなくなった時点で解放するのがあらゆる面で効率良いんだよ。

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

こまめに開放するっていうのも重要だよ。

まとめて一気に解放なんてしたら、ユーザーは処理のもたつきを感じ取るからね。

ホントアホばっかで話にならんわ。

**デフォルトの名無しさん** · 2014/10/13(月) 14:04:57.87

>>421
> 使わなくなった時点で解放するのがあらゆる面で効率良いんだよ。

そうしたいんならそうすりゃいいやん？てだけの話。

**デフォルトの名無しさん** · 2014/10/13(月) 14:08:05.29

>>423
お前、江戸時代だったら切腹申し付けられてるぞ。

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

>>409
プロセス終了時に無駄にfreeする実装では
メモリ10GBじゃ論外に遅いだけで、freeしない効率的な実装なら
普通に終了するよ？
つまりお前のような馬鹿には効率的なコードは書けないって話だね

**デフォルトの名無しさん** · 2014/10/13(月) 14:16:56.04

>>425
ラーメン食うのにスプーン使って、ラーメンはダメだと言ってるようなもの。
箸で食えよ。

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

一つ耳寄りな情報を教えてやろう。

WikipediaのXMLアーカイブ。
Emacsでは開けないだろ？
途中で落ちてしまう。
大きすぎるからな。

ワードなら開けるんだこれが。
目から鱗だろ。

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

>>426は>>297の状況だったら何を使うの？

**デフォルトの名無しさん** · 2014/10/13(月) 14:53:17.45

GC の惨状をみるとね‥世間ではあれをうまくいっている、と評価するようだが

**デフォルトの名無しさん** · 2014/10/13(月) 14:54:54.53

>>422
そうそうマークアンドスウィープなんかの弱点だね

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

|￣|　∧∧
|ニニ( ﾟД∩ｺ
|＿|⊂　　ノ
　　 / ＿０
　　(ノ

　えっ…と、不毛な糞スレ
＼はここかな…、と／
　￣￣￣Ｖ￣￣￣￣
　　∧∧ ∧∧
　∩Дﾟ≡ﾟДﾟ)|￣|
　ヽ　　|)ニニニ|
　　　|　|～　|＿|
　　　∪∪

　　∧∧ ミ　ドスッおつおつ
　 (　　) ＿＿＿
　 /　　つ終了｜
～(　 /　￣||￣
　∪∪　　　|| ε3
　　　　　ﾞﾞ~ﾞ~

**デフォルトの名無しさん** · 2014/10/13(月) 16:11:24.20

>>408
ダメ。その領域を再利用する必要/可能性がない場合。
exitの直前はその典型例だがそれだけではない。

>>411
バカなので分かりません。教えてくださいって言えよ。ｗ ID:7i+sJhXA

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

GNU製品はホント糞だな。

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

>>432
大丈夫、ちゃんとわかってるから

どうせ ID:XwZMSYHG は、逃げ回って答えられないことをね w

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

>>432
答えられないのか。
情けねーな。

**デフォルトの名無しさん** · 2014/10/13(月) 16:29:31.58

他人に答えを強制するくせに>>428には答えずに逃げる、と

**デフォルトの名無しさん** · 2014/10/13(月) 16:33:17.28

>>436
雑用は雑魚にやらせてるから。
システム導入時にユーティリティーが一式ついてきたみたいだよ。

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

>>432
その判断は大域的にならざるを得ないわけだよな。
個々の処理がいつどのように呼ばれるか、さらにはそれより後で実行される処理で
新たなヒープメモリの確保がされるのか、等々、気にしないとならないわけだ。
なんとも前近代的な印象を受けるが。

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

>>418
で、32bitのコンパイラで断片化させて2Gの壁に突き当たると
64bitの場合の限界は環境依存なんだっけ？

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

>>437
まさかの雑魚以下!?

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

このスレまだあったんだ。

おっさん感激 !!

ところで、Free必須論者は
本質的に寿命がプログラムの寿命と同じオブジェクトが
あるということは認識してくれているのかな。

例えばさっきのcpのハッシュテーブルだったり、
コンパイラの構文木だったり

これらのオブジェクトが必要なくなるとき=プログラムが終了するとき
なんだけど、こんなかんじでfreeして開放された領域が2度と使われないことが
保障されているオブジェクトが存在するということは認識してくれている ?

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

>>441
> コンパイラの構文木だったり

もうその話耳タコで飽きたわ

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

>>441
OSと協調できないのはglibcの欠陥だから、主にLinuxでのみ問題になるんだよね。
Linuxなんか使うからそういう事になるんだよ。

まともなランタイム使ってれば解放して大丈夫だよ。
ホントGNU製品って糞だよな。
糞を一般化して語るなって話。

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

>>297
「私はRAIDの復旧にcpを使うバカです」

ということだろ？

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

>>434
> 大丈夫、ちゃんとわかってるから
わかってるなら、↓こういう間抜けな発言はしない。ｗｗｗ

> From: [395] デフォルトの名無しさん <>
> Date: 2014/10/13(月) 08:15:56.25 ID:BlK6LuSG
>
> >>297はブログに書くことじゃなくてツイッターにでも書けばいい。
>
> 「私はRAIDの復旧にcpを使うバカです」
>
> 一行で済む。

**441** · 2014/10/13(月) 18:24:11.09

>>442
それなんで、cpのハッシュテーブルっていう実例が出てうれしいです^ ~

自分の経験で出せる例だと、
連立一次方程式を解くときの疎行列なんかぐらいになっちゃいます。

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

>>445
>>406 の答え書けないなら、でてくんなよ w

**441** · 2014/10/13(月) 18:32:16.15

>>443
オブジェクトの寿命 = プログラム(プロセス)の寿命
なオブジェクトが存在し、それはfreeをしても確保したメモリ領域が
再利用されることはない。
というのはご理解いただいているのですね。

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

>>446
Linux特有の問題。
いまどきのランタイムはメモリを開放すると即座にOSに返す。
OSは適切に取り扱う。

ところがglibcはOSの機能を使えない。
ディスクに退避されたデータによってスラッシングが引き起こされる。

「だからfreeするべきではない」
↑これ間違い。

欠陥ランタイムを使うべきでないというのが正しい。

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

>>441
＞ところで、Free必須論者は
＞本質的に寿命がプログラムの寿命と同じオブジェクトが
＞あるということは認識してくれているのかな。

認識してます。
結局のところ C/C++ にしか関係ない些細なことなんです。他の言語はすでにこの手の話は自動化されていますし、うまくいっているとはいいませんが。

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

>>448
俺は、きちんとモジュール化するべきだと思うよ。
ハッシュテーブルを実装するなら、テーブルを削除する時点でメモリーも
解放する。
そして、他のプログラムでもそのハッシュテーブル実装を使えるようにする。

メモリーの開放が遅いのはglibcの欠陥。
欠陥品に合わせてすべてを台無しにする必要はない。
欠陥品を使わないことが大切。

まあ、こんな当たり前のことがわからないから雑魚なんですわ。

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

>>449
＞いまどきのランタイムはメモリを開放すると即座にOSに返す。
ほう、それは初耳、いったん握ったメモリは返さないものとおもっていた‥

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

>>452

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

>>448
そういうケースが存在することはわかってるが、わざわざそんなケースだけを特別扱いすべきとは思わない
測定してみて、本当に解放が問題になる場合に free をやめると言うならわかる
つまり、小手先の最適化と同じレベルの話

**デフォルトの名無しさん** · 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
いや、俺はお前みたいな馬鹿じゃないぞ