main以外★mallocの後にfree不要と言うバカいるの？

1 ：デフォルトの名無しさん：2012/11/13(火) 22:12:13.29

前提１：一般的なC言語（GC搭載していない）
前提２：main関数は除く
前提３：関数実行後すぐに終了するとは限らない
前提４：関数は何度も使われることがある

これがメモリリークするのは当たり前の話で、
mallocをしたらfreeするのは当たり前。

free不要論とは一体何だったのか。

天邪鬼（バカ）が言葉尻を捉えていただけではないだろうか。
まつもとゆきひろもそのバカの一人だったらしいね。

例外中の例外を除いて、mallocをしたらfreeは必要。
これが真の答えだろう。

2 ：デフォルトの名無しさん：2012/11/13(火) 22:19:16.94

10年前の俺を見ているようだ

3 ：デフォルトの名無しさん：2012/11/13(火) 22:23:33.65

昔のアプリはサーバーなんてものは考えられておらず
アプリ（CUIしかない）は実行したらすぐに終了していたんだよ。

だからfreeしなくてもいいとかいう間違った考え方が生まれた。

4 ：デフォルトの名無しさん：2012/11/14(水) 07:38:29.10

exitで脱出したい時にもいちいち手間掛けてfreeすんのか、って話だとか聞いたけど。それなら
確かにfree要らんわな。
freeしても大抵マークするだけだしプロセス終了時に開放されるからfree不要、って話の方には、
基本的に賛同しないけどな。してもしなくても変わらないケースも多いが、変わるケースも少なく
ないし、freeを省略する利点も無い。実行形式をとことん小さくしたい時くらいかね。

5 ：デフォルトの名無しさん：2012/11/14(水) 10:17:51.41

>>1
つか、その前提条件はmalloc-free論争のときのと違うし。

6 ：デフォルトの名無しさん：2012/11/14(水) 12:14:18.68

>>3
基本的に終了しないアプリなんて、それこそC言語が生まれる前からあるだろ

7 ：デフォルトの名無しさん：2012/11/14(水) 14:35:53.85

free地獄
a = malloc(10);
if (error) {
free(a);
return;
}
b = malloc(10);
if (error) {
free(a);
free(b);
return;
}
c = malloc(10);
if (error) {
free(a);
free(b);
free(c);
return;
}

process();

free(a);
free(b);
free(c);

return;

8 ：片山博文MZボット ◆0lBZNi.Q7evd ：2012/11/14(水) 14:58:41.81

a = malloc(10);
if (!error) {
　b = malloc(10);
　if (!error) {
　　c = malloc(10);
　　if (!error) {
　　　process();
　　}
　　free(c);
　}
　free(b);
}
free(a);
return;

9 ：デフォルトの名無しさん：2012/11/14(水) 15:03:52.19

>>8
真のfree地獄
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.10.1.list

10 ：デフォルトの名無しさん：2012/11/14(水) 15:04:44.67

>>1
> 前提２：main関数は除く
> 前提２'：exit関数を呼び出す場合を除く
これを除外しないのがfree教信者。前提が違う。

11 ：デフォルトの名無しさん：2012/11/14(水) 17:40:49.66

>>7-9
それはfreeの問題じゃなくて書き方がアホなだけだ

12 ：デフォルトの名無しさん：2012/11/14(水) 17:45:31.87

>>7=>>1だったら大爆笑

13 ：デフォルトの名無しさん：2012/11/14(水) 18:08:53.36

少々リークしたってプログラムが終われば無かったことになるから問題ない←free不要派

14 ：デフォルトの名無しさん：2012/11/14(水) 18:17:25.97

ジョブから呼ばれる小さなルーチンを沢山書いてきた
UNIX系の人にメモリーに限らずリソース開放軽視してる人多かったな
PC育ちの自分にとってはそんな書き方したらマトモに
動かなかったから信じられなかったけど。

　プロジェクト全体のリソース管理状況をチェックする担当になった時に
リークチェッカーに引っかかった箇所を、それぞれの担当者に
修正お願いするんだけど、サーバーとの通信部分を担当してた
男版お局さんみたいな人に、DLL解放時にリークしてるところが
あるから修正してくださいって頼んだけど最後まで無視されたな。
実際はプロセス内で何度もロード・アンロードするところだから
問題有ったんだけど、事を荒立てないように見なかったことにした。
立場の弱い人間には強制的に修正させたけどね

韓国の会社が作ったUNIX用の結構大きなソフトのWindowsのポーティングも
やったけど、それもリークが酷かったな。
あの当時、Windowsが糞OSとか叩かれてたけど、ちゃんと書いたプログラムは
ちゃんと動くのを身にしみてたからMSが気の毒だった。

どんな優秀な人でも、一度身についた悪習は中々直せないもんだよ

15 ：デフォルトの名無しさん：2012/11/14(水) 18:20:47.95

>>14
お前、malloc-free論争のこと全然知らないだろ。

知らないなら黙っとけ糞が。

16 ：デフォルトの名無しさん：2012/11/14(水) 18:46:44.69

昔の自称"議論"が永遠に有効だと思ってる人って居るよね。

17 ：デフォルトの名無しさん：2012/11/14(水) 19:13:10.34

> main関数は除く
なぜ？
main関数はfree不要なら、他の関数でも同じじゃないの？

18 ：デフォルトの名無しさん：2012/11/14(水) 19:44:08.68

そりゃmainも除いたらだめよ
mainでmallocして使われなくなってもそのあとまだまだ続かないとも限らないんだから

19 ：デフォルトの名無しさん：2012/11/14(水) 20:04:49.13

「関数終了時」を話題にしているのは明白だろ。バカは死んでくれ。

20 ：デフォルトの名無しさん：2012/11/14(水) 21:22:45.38

mallocしたらfreeする。
そんなのは当然だ。
ただし例外があるというだけの話。

21 ：デフォルトの名無しさん：2012/11/14(水) 22:08:12.11

>>20
その例外がさも一般的なことであるかのように
話をしていたのが、free不要論なんだよなｗ

今の時代、free不要とか言い出したら
キチガイ認定されるだろう。

22 ：デフォルトの名無しさん：2012/11/15(木) 06:13:02.56

「free不要論」とやらの正体が分かんねぇんだよな

A「プロセス終了時に開放してくれるOSでは、exit()を掛ける前にもfree()する必要は無い」
B「free()しなくてもどうせ変わらんから要らない」
どっちの論理なのかのソース出せよ
Aだと思い込んでる奴と、Bだと思い込んでる奴と、言い合っても話が通じるわけねぇだろ

23 ：デフォルトの名無しさん：2012/11/15(木) 07:12:51.68

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

24 ：デフォルトの名無しさん：2012/11/15(木) 07:30:17.50

>>23
ここまで来てからそれか。
敗北宣言と見なされるぞｗ

25 ：デフォルトの名無しさん：2012/11/15(木) 11:11:41.15

>>20
freeするのは当然じゃないよ。
「freeしなければならない場合がある」というだけでそれ以外は不要なんだが、「それ以外」がどういう
ときなのかわからない人が「freeするのは当然」と思考停止してしまうのが論争になった原因。

26 ：デフォルトの名無しさん：2012/11/15(木) 13:15:05.59

思考停止してるのはお前
どうせド素人なんだろうけど

27 ：デフォルトの名無しさん：2012/11/15(木) 13:27:47.33

>>25
思考停止するからダメだって話なのか。マジかよ。激しくダサいなｗ
心理学者かよｗｗｗ

28 ：デフォルトの名無しさん：2012/11/15(木) 15:02:11.07

むしろmallocが不要

29 ：デフォルトの名無しさん：2012/11/15(木) 19:03:09.84

普通は「メモリの解放？何それ、おいしいの？」ってなるようなコードを書くんだがな。

30 ：デフォルトの名無しさん：2012/11/15(木) 19:48:45.89

free()しない奴にライブラリや共有オブジェクト作らせたくないわ

GCが働いてくれる言語でバグ出さないようにしてもらえればそれで十分
こっちくんな

31 ：デフォルトの名無しさん：2012/11/15(木) 22:53:47.27

未だにＣ言語で型保証なしのmallocかよw

32 ：デフォルトの名無しさん：2012/11/16(金) 00:11:11.37

>>25
で、思考停止しないで考えて出した答えは
やっぱりfree必要なんだろ？
そのソースを教えてくれ。

33 ：デフォルトの名無しさん：2012/11/16(金) 04:02:15.37

>>22のAに反対の奴とかBに賛成の奴とかっているの？

34 ：デフォルトの名無しさん：2012/11/16(金) 04:47:17.99

スレッドの走行中に、
たとえば、スレッドがファイルを開いたり閉じたりしている場合、
しかも、スレッドを止めないで親が終了した場合、スレッドのオブジェクトは、解放されますか？

35 ：デフォルトの名無しさん：2012/11/16(金) 06:37:50.74

環境依存

36 ：デフォルトの名無しさん：2012/11/17(土) 00:58:14.40

※この自動車は連続30分走行するとブレーキが利かなくなります。
　定期的にエンジンを再起動してください。

37 ：デフォルトの名無しさん：2012/11/18(日) 07:11:51.32

ニュースグループかよw

38 ：デフォルトの名無しさん：2012/11/18(日) 09:45:30.07

>>36
※この自動車は連続○分エンジンブレーキで走ると
　エンジンがフリーズして二度と動かなくなります。
　定期的にエンジンを空吹かししてください。

混合油2スト時代の常識ｗ

39 ： ◆QZaw55cn4c ：2012/11/19(月) 01:03:17.26

mallc()/free() では信者を巻き込んで熱くなる議論も、これをfopen()/fclose() に置き換えるとまったく結論が異なるようだ。
「fclose() しなくてもOSがディスクリプタを回収してくれるから無問題したがってflocse()不要」という主張はあまり耳にしないのだが？

40 ：デフォルトの名無しさん：2012/11/19(月) 08:56:04.28

>>39
いやその話だって処理系に依存することには変わりはない訳で、本質は同じでしょ

41 ：デフォルトの名無しさん：2012/11/19(月) 10:01:48.18

ここでもバカ晒してるのか。
↓ ここにfcloseしてないチンカスがいますよ。ｗｗｗ

http://codepad.org/mLtuxDOF

42 ：デフォルトの名無しさん：2012/11/19(月) 13:32:23.68

>>39
OSが回収するのは「ディスクリプタ」じゃないけどな

43 ：デフォルトの名無しさん：2012/11/19(月) 18:53:07.46

>>39
そうか？むしろそちらの方を良く聞いたが。
使い捨てのスクリプトなんかは close しないのも結構あるんじゃないか。

44 ：デフォルトの名無しさん：2012/11/19(月) 19:14:21.27

>>42
ふむ。確かに一つのディスクリプタを複数のプロセスで共有しているときに、ひとつのプロセスが終了したからといってディスクリプタ自体を閉じてしまっては一大事ですね。
このあたり疎いのでもしよろしければ参考本を教えてください。

>>40 >>43
んー、最近はclose()/fclose()論争をあまりきかないので‥‥こんど煽ってみよう‥‥

>>41
みつかったか :-)

45 ：デフォルトの名無しさん：2012/11/19(月) 20:13:10.93

Cでgotoを使っていいか悪いか、にも似てるな
使っていいとこはあるけど基本使うなよ、でも無理に使わないことも無いよ、っていうあれ

46 ：デフォルトの名無しさん：2012/11/19(月) 23:08:57.86

今となっては過去の論争だからねぇ。
今だと誰もがfreeすべきだと答えている感じなんだが、
昔はなぜかfreeしなくていいのが多かった感じがする。
しかも詳しい人ほどfreeしなくていいと言ってるみたい。

やっぱ昔はfreeするコストとかまで気にしていて
綺麗なコードよりも、技巧的で速いコードが好まれていたってことかねぇ。

47 ：デフォルトの名無しさん：2012/11/19(月) 23:40:20.28

単にUNIXとかは短いプログラムを
ジョブからプロセスキックする様なシステムが多かったから
いちいち解放しなくてもOSが勝手にやってくれるじゃん
みたいなことじゃね？
そもそも、昔のプロのプログラマーの環境はリソース足りなきゃ
ハードを増強すりゃいいだろみたいな考えだったし。
そして、昔はUNIXプログラム＝プロのプログラム
パソコンプログラム＝アマチュアみたいな感じで下に見る傾向が強かったから
UNIX文化＝常に正しいみたいな根拠のない流の議論になってたんじゃないかな

48 ：デフォルトの名無しさん：2012/11/19(月) 23:46:27.03

そういう人たちってもう死んだの？
当時そう言っていた人が
今は考えを改めたのか知りたいんだけど。
今はfree不要論者全然いないし。

49 ：デフォルトの名無しさん：2012/11/19(月) 23:59:07.36

そういう人たちもfree不要って言ってたのはUNIXコマンドみたいなメモリ常駐期間の短いものを対象に言ってただけで
今みたいな何時間も何日も起動しっぱなしのプロセスについてはfree不要とか言わないよ
それに昔はメモリをそんなに積んでなかったから設計時に全てメモリ使用量を計算済みだったから
プログラムの最初に大方確保してそれを使ってたからね
今みたいに任意のタイミングに動的にメモリ確保とかそんな贅沢できなかった

50 ：デフォルトの名無しさん：2012/11/20(火) 01:48:39.26

>>48
おっかしいなー、
宿題スレではfree()信者はそれこそ｢信者」扱い、free() を省略できなければどんくさい、くらいの価値観が通っているんだけれども。
ダングリングポインタや、手放してしまって金輪際free() できない領域（これなんていうんだろ？）が発生しなければ OK くらいが落としどころになってる。

51 ：デフォルトの名無しさん：2012/11/20(火) 02:14:00.81

>>50
だからそれ、プログラムが完全に終わる直前の話でしょ？

プログラムのすべてをmainでやってるのならともかく、
普通関数の形にするよね。その関数はどういう呼ばれ方をするか
わからないものとして作るから、mallocしたらfreeするよね？

結果的にfreeしないということなんて現実にはまずない話だと思うんだが。
freeを省略できる条件を明確にして欲しいよ。
あ、もちろんエラーで強制終了する場合は除く。

52 ：デフォルトの名無しさん：2012/11/20(火) 07:08:23.35

>（これなんていうんだろ？）

リーク

53 ：デフォルトの名無しさん：2012/11/20(火) 08:16:24.72

>>50
あれはfree教教組が教義を押し付けたけど、その教義がマヌケという事実を
指摘されて火病ってるだけ。

>>51
> プログラムのすべてをmainでやってるのならともかく、
> 普通関数の形にするよね。その関数はどういう呼ばれ方をするか
> わからないものとして作るから、mallocしたらfreeするよね？
関数の形になってても省略可能な例
main()
{
create_object();
print_object();
}

> 結果的にfreeしないということなんて現実にはまずない話だと思うんだが。
* 寿命がmainに等しいシングルトンなオブジェクトは現実的にも普通にあるし
　よく使う。このようなオブジェクトはfreeしなくてもよい。
* BoehmなどのGCは「これまでにアロケートしたものをすべて解放」なんてい
　うインターフェースはもっていない。ルートポインタをNULLにして回収を
　試みてもコンサバティブGCなので回収できることは保証されていない。
　そしてBoehmを利用しているプログラムは現実的にたくさん存在する。

> freeを省略できる条件を明確にして欲しいよ。
自分で考えろ。それを他人に押し付けるな。

54 ：デフォルトの名無しさん：2012/11/20(火) 08:38:58.68

>>53
＞関数の形になってても省略可能な例
ん？簡略化しすぎているんじゃない？
＞シングルトンなオブジェクト
静的にもつほうが多いようなきが
BoehmGC がすべて開放するようなインタフェースを持たない、としてもそれはGCだからでは？
GCにたよらず自力本願なC++において、デストラクタを定義しなくともよい場合がある、という主張はあまりきかない。

＞教義がマヌケ
正常系でもfree()しないのはねえ‥‥

55 ：デフォルトの名無しさん：2012/11/20(火) 08:40:51.06

>>53
お前、create_objectの実装しってんの？
関数使う側は内部の実装のことを気にしないものだよね。

create_objectがもし一時ファイルとか作っていたらどうするの？
delete_objectしないとだめだよね。

56 ：デフォルトの名無しさん：2012/11/20(火) 08:47:34.49

>>54
教組登場。バカは引っ込んでろ。ｗｗｗ

>>55
> お前、create_objectの実装しってんの？
知ってるよ、delete_objectが用意されてない事も。
「mainで全部やらない」という事への反例だから。

57 ：デフォルトの名無しさん：2012/11/20(火) 12:00:15.37

即ち...
テキストファイルを閉じてもメモリを開放しないマルチテキストエディターが作りたいということか...

58 ：デフォルトの名無しさん：2012/11/20(火) 12:04:40.41

今さらCでテキストエディタは作りたくないな

59 ：デフォルトの名無しさん：2012/11/20(火) 13:05:15.85

>>46
単に
「どんな場合でも確実にリソース解放できるわけじゃないから、
　実用上問題になるケースだけリソースを開放すればよい」
というだけ。

60 ：デフォルトの名無しさん：2012/11/20(火) 13:05:43.08

何が「即ち」なんだろう。free教信者の思考停止は救いようがないな。

61 ：デフォルトの名無しさん：2012/11/20(火) 13:17:42.46

> 教組
この手の奴は総じて日本語もダメ

62 ：デフォルトの名無しさん：2012/11/20(火) 13:22:00.29

結局、
・mallocしたものは必ずfreeで開放するべき
・メモリリーク障害を起こさないようにするべき
の違いでしかないんだけどね。

63 ：デフォルトの名無しさん：2012/11/20(火) 13:50:40.25

どうでもいいけどfree不要を唱えるバカとは一切仕事上で関わり合いたくない

64 ：デフォルトの名無しさん：2012/11/20(火) 14:07:59.38

どうでもいいけど、いかなる場合もfreeせよと主張するバカとは一切仕事上で関わり合いたくない

65 ：デフォルトの名無しさん：2012/11/20(火) 14:16:05.37

どうでもいいけどC使いたくない

66 ：デフォルトの名無しさん：2012/11/20(火) 14:36:52.03

>>62-63はもっともな意見だけど、>>64も無視は出来ないよね。
私も>>64のいわんとすることが何となく分かります。

free();しなくて良い時は、
　(1) 書く人が「しなくて良い」ことが分かっている
　(2) 他人にソースを引き継ぐ(または解析されることがある)場合は、
　　　余計な解析をさせないためにコメントに明記する
これが前提にあった上で、free();しなくても良いと思いますよ。

で本題ですが、上記(1)について。
「どういう時にfree()しなくて良いのか」
私が思いつくのは、

　1. malloc()は最初に1度行われ、main()を抜けるとシステムが
　　代わりにfree()してくれる
　2. malloc()は最初に1度行われ、main()は抜けない。
　　無限ループ+電源断か、シャットダウンイベントによって
　　システムが終了する組み込み系など

他に具体例、何かありますか？

67 ：デフォルトの名無しさん：2012/11/20(火) 16:21:58.99

free()のコード読んでからもの言え

68 ：デフォルトの名無しさん：2012/11/20(火) 17:45:54.67

今時freeするなんて
古いよねー

69 ：デフォルトの名無しさん：2012/11/20(火) 18:51:32.55

mainだったら関数が終わるときにfreeをしなくてもいいけど、
将来外部関数としてそのmainが再利用される可能性が
ありうればfreeの処理も書いておく

70 ：デフォルトの名無しさん：2012/11/20(火) 21:39:19.31

まぁ、そゆこっちゃ
喧嘩するほどの話でもない

71 ：デフォルトの名無しさん：2012/11/20(火) 21:51:06.13

mallocでNULLが返って来たとき、ろくに出来る事も無いしexitで即死しようって場合は
すでに確保したメモリをfreeしなくても良いよね？

72 ：デフォルトの名無しさん：2012/11/20(火) 21:58:50.60

環境依存

73 ：デフォルトの名無しさん：2012/11/20(火) 22:09:41.35

余談だけど、malloc()のmanpage によると、malloc()でNULL以外が返ってきて
正常動作するなと思っていても、死ぬことあるんだね。

> バグ
> デフォルトでは、Linuxは楽観的メモリ配置戦略を用いている。
> つまり、malloc()がNULLでない値を返しても、そのメモリが実際に利用可能であることが
> 保証されない。これは本当にまずいバグである。システムがメモリ不足状態になったとき、
> 悪名高いメモリ不足解決器(OOMkiller)によって一つまたは複数のプロセスが削除される。
> 突然あるプロセスが削除されるのが望ましくない状況で使用されていて、しかもカーネルの
> バージョンが十分に最近のものであれば、このメモリを割り当て過ぎる動作(overcommittingbehavior)
> を以下のコマンドで無効にできる。
>　　# echo 2 > /proc/sys/vm/overcommit_memory

74 ：デフォルトの名無しさん：2012/11/20(火) 23:53:44.17

>>56
> 知ってるよ、delete_objectが用意されてない事も。
へんな話だな。

世の中の関数に、リソースはメモリの確保しかしていません。
終了時に解放処理をしなくても大丈夫ですって仕様に書いてるの無いでしょ。

どうせ自分が作った関数だからdelete_object呼ばなくても大丈夫って
知ってるとか言うつもりなんだろうけどさ、そんな話はしてないの。

他人が作った関数を思い浮かべればいいよ。
その関数がmallocをしてメモリを確保するのであれば、
逆にfreeする関数も用意している。

他人が作ったもので、他人がメンテする。だから実装がどうなってるかは考えない。
中の実装を見て、使用者側がコードの使い方変えるとか馬鹿のすること。
そう思うよね？

75 ：デフォルトの名無しさん：2012/11/20(火) 23:56:33.02

処理系依存は気にするのに
OS依存は気にしないんだなｗ

特定の処理系（OS）に依存したコード書くなよ。
OSが必ずメモリ解放してくれるとは限らないだろ。

76 ：デフォルトの名無しさん：2012/11/20(火) 23:58:53.07

>>64
俺は他人の意見を馬鹿にして終わりな奴より、
自分の意見をちゃんと言える人と仕事したいよ。

で、お前の意見は？
どういう場合に限ってfreeしなくていいと言う？

77 ：デフォルトの名無しさん：2012/11/21(水) 00:07:01.66

7.24:
プログラムが終了する前に、確保したメモリを解放しなければならないか。
A:
その必要はない。まともなオペレーティングシステムならきっとプログラムが終了した時点ですべてのメモリを取り返すだろう。
にもかかわらず、個人向けコンピュータ(PC)の中にはメモリを取り戻すことが確実にはできないものもあるようである。
ANSI/ISO C規格から結論つけられることは、解放してくれるかどうかは「実装の品質がどれくらい高いかによる」ということだけである。

References:
ANSI Sec. 4.10.3.2; ISO Sec. 7.10.3.2.

78 ：デフォルトの名無しさん：2012/11/21(水) 00:11:49.69

7.24:
クロスプラットフォームなのでまともじゃないオペレーティングでも動かすことがあるかもしれない。
プログラムが終了する前に、確保したメモリを解放しなければならないか。
A:
とうぜん解放する必要がある。

79 ：デフォルトの名無しさん：2012/11/21(水) 00:15:31.13

>>77
不自然な答えだよな。

OSがまともであるならと
前提をつけて結論を書いてどうするんだろう？
そのあとでまともじゃない場合があると認めてるのにね。
で、最後の行で話をすり替えてる。

80 ：デフォルトの名無しさん：2012/11/21(水) 00:20:22.02

標準ライブラリがまともである保証はあるんですかっ

81 ：デフォルトの名無しさん：2012/11/21(水) 00:26:55.34

俺ならこう答えるかな。

Q. プログラムが終了する前に、確保したメモリを解放しなければならないか。

A. プログラム側でfreeしなくても通常はOSが解放してくれるので直接問題が起きることはありません。
しかしながらそのようなことを気にしなくていけないのであれば設計上の問題がある可能性が高いです。

ライブラリ自体がメモリ解放の責任をもっているのであれば終了時にメモリが確保されたままになることはありません。
ライブラリの使用者側がメモリ解放の責任を持つのであれば、適切な場所でメモリを解放してください。
それなりの規模のソフトであれば、終了間際までメモリを確保したままになることはないはずです。

82 ：デフォルトの名無しさん：2012/11/21(水) 00:33:26.31

一つのファイルに対してある処理をするプログラムを作った。
簡単なツールなのでmain一つで終わっていた。
freeは必要ないということで省略した。

そのうち拡張されコードが増えていった。
さすがに見通しが悪くなったので関数に分けた。
でもfreeは必要ないということで書かなかった。

一つのファイルだけではなく、複数のファイルに対応した
でもfreeは書かなかった。
たくさんのファイルを処理した時、メモリが足りなくなった。

freeを書かないメリットはあったのだろうか？

83 ：デフォルトの名無しさん：2012/11/21(水) 00:59:45.46

教義に従い倍の時間をかけて異常系にもfreeを記述していった。
異常系のテストケースが不十分だったのでフィールドでセグメントフォルトが発生した。

必死になってfreeを書いたメリットはあったのだろうか?

84 ：デフォルトの名無しさん：2012/11/21(水) 01:07:58.93

>>81
＞Q. プログラムが終了する前に、確保したメモリを解放しなければならないか。

俺なら

Ａ．開放しないことでたとえなにが起きても自分で責任とれるならやらなくていい。
わざわざfreeが用意してある意味は自分で考えなさい。

85 ：デフォルトの名無しさん：2012/11/21(水) 01:17:41.31

>>83
じゃあ異常系でのみ省けばいいだろ。

今は正常な終了時の話だ。
いると認めたのなら、そういえ。

86 ：デフォルトの名無しさん：2012/11/21(水) 01:32:28.68

異常系を考えないなんて、学生プログラマかw

87 ：デフォルトの名無しさん：2012/11/21(水) 01:36:50.48

異常系は停止していいと答えがでてるってことだろ。

はい。この話はもう終わり。

88 ：デフォルトの名無しさん：2012/11/21(水) 01:42:39.81

はあ?

お前ら、ライブラリがエラーを返したら即プログラム終了かよ。
素人PGはお気楽でいいな。

89 ：デフォルトの名無しさん：2012/11/21(水) 02:00:23.23

またずれてる奴が来たね
相手にしなくていいぞ。

90 ： ◆QZaw55cn4c ：2012/11/21(水) 03:09:42.60

>>83
信じるものは救われる

91 ：デフォルトの名無しさん：2012/11/21(水) 04:07:47.39

環境依存だろ
これ以上書く奴は馬鹿かチンパンジー↓

92 ：デフォルトの名無しさん：2012/11/21(水) 07:53:04.42

ウキキー（チンパンのおいらでも後片付けくらいするずら）

93 ：デフォルトの名無しさん：2012/11/21(水) 09:06:06.17

newの戻り値はNULLチェックする必要ある？
例外で処理するのが一般的？
deleteするときもNULLチェック必要？

94 ：片山博文MZボット ◆0lBZNi.Q7evd ：2012/11/21(水) 10:16:00.93

>>93
new(std::nothrow)の場合はNULLチェック必要。普通のnewはstd::bad_alloc例外を投げるのでNULLチェック不要。
deleteについてはNULLチェック不要。

95 ：デフォルトの名無しさん：2012/11/21(水) 10:24:10.88

むしろdeleteした後そのポインタにNULLを入れる行為に意味があるのかどうかのが気になるな

96 ：デフォルトの名無しさん：2012/11/21(水) 10:31:26.78

>>76
俺は他人の意見を馬鹿にして終わりな奴より、
自分の意見をちゃんと言える人と仕事したいよ。

で、お前の意見は？
どういう場合にfreeしなきゃいけないという?

97 ：デフォルトの名無しさん：2012/11/21(水) 10:36:38.04

釣られないぞ(AAry

98 ：デフォルトの名無しさん：2012/11/21(水) 21:42:04.68

>>96
手術中にメモリ不足で電力供給されなくなって患者を殺したらどう責任取るの？
お前の命じゃ全然足りないよ？

99 ：デフォルトの名無しさん：2012/11/21(水) 22:00:41.60

そういう機器だとfreeしないんでｗｗｗ

100 ：デフォルトの名無しさん：2012/11/21(水) 22:19:33.25

>>99
ついに本性出したか
そういう機器だとメモリ確保しないという発言はメモリリークが危険だということを分かってるからだろ？
GUIアプリでもイベント報告毎にメモリリークしてれば数時間でアプリが落ちる
freeが要らないと言ってるのは職がなく暇だから面白がって煽ってるだけの連中だけ

本気でfree要らないと言ってるやつはメモリの存在を気にかけたことがない
宇宙の素粒子ひとつひとつにデータを書き込めるがごとくメモリ動的確保しまくる
そんな人間

101 ：デフォルトの名無しさん：2012/11/21(水) 22:46:19.36

なんで勝手に条件つけて盛り上がれるんだろう。

102 ：デフォルトの名無しさん：2012/11/21(水) 22:54:28.40

テンプレ

Q. ○○（レアケース）の場合はどうするの？
A. レアケースは例外でいいよｗ

103 ：デフォルトの名無しさん：2012/11/21(水) 22:57:38.25

レアケースは例外というのなら
終了前のfreeそのものがレアケースなんだよな。
アプリの長い生存期間のうち最後の一瞬でしか無い。

104 ：デフォルトの名無しさん：2012/11/21(水) 23:06:29.93

>>95
> むしろdeleteした後そのポインタにNULLを入れる行為に意味があるのかどうかのが気になるな

例外処理の簡略化のためのコードだよ。

deleteしたあとでNULLを入れておくと
例外がどこで起きたとしても
とりえあえずdeleteしておけばよくなる。

オブジェクトが存在している → deleteで消される。
オブジェクトが存在してない(NULLが代入されている) → delete NULL は無害であると保証されている。

105 ：デフォルトの名無しさん：2012/11/21(水) 23:07:58.56

>>93
かなり昔のC++はnewでメモリ不足だったらNULLが帰ってきたんだよね。
一般的にはnewはエラーが起きれば例外を発生させる。NULLは帰ってこない。

106 ：デフォルトの名無しさん：2012/11/22(木) 00:10:18.49

ほー、いまのはnull帰ってこんのか
書くには楽だが、なんつーか、おじさんなんでも例外っていうのはキライだな

107 ：デフォルトの名無しさん：2012/11/22(木) 00:23:45.20

保険のパンフも例外だらけだしな

108 ：デフォルトの名無しさん：2012/11/22(木) 01:29:45.92

>>100
お前バカだな。かわいそうなくらいバカだ。何が論点なのか全然理解していない。

109 ：デフォルトの名無しさん：2012/11/22(木) 02:23:34.87

>105
>一般的にはnewはエラーが起きれば例外を発生させる。NULLは帰ってこない。

値は何が入りますか

110 ：デフォルトの名無しさん：2012/11/22(木) 02:29:53.70

結論は>69で出てると思うんだが。

「mainだから」「exitするから」などと言って書いたコードは、その条件に依存することになり、条件が変わった途端に正常に動作しなくなる。
その際のメンテナンス性を考えて組むなら良いだろうが、freeやdeleteすら面倒臭がる輩がそんな事を気にする訳がない。
(そもそもfree/deleteの徹底自体が、再利用時のメンテを省くための知恵である。)

111 ：デフォルトの名無しさん：2012/11/22(木) 02:50:26.74

コード書くとき面倒でも、あとあとデバッグの段階で効いてくるんだよね。

・モジュールの中でのみ有効なオブジェクトを確保したならモジュールの中で解放する
・引数は出来るだけ(納期やパフォーマンスの兼ね合いもあるが)チェックする

面倒臭がらないよう日頃から徹底していれば、バグの原因の切り分けの手間や、
自分の担当しているモジュールの責任追求も緩和される。

112 ：デフォルトの名無しさん：2012/11/22(木) 02:52:39.68

>>111
追加

・モジュール内で呼ぶ外部モジュールから返ってくるエラーもちゃんとチェックする

113 ：デフォルトの名無しさん：2012/11/22(木) 02:59:50.72

もともとはfreeを書くと思考停止するって話だものｗ太田純ｗｗｗ

114 ：デフォルトの名無しさん：2012/11/22(木) 03:50:13.04

関数内で確保と解放が簡潔するポインタは必ずローカル変数
解放せずに戻り値として返す場合は必ずグローバル変数で保管
atexit()の中でNULLじゃないポインタは全て解放
これでいけるんじゃね？

115 ：デフォルトの名無しさん：2012/11/22(木) 04:09:15.02

atexit()、初めて知った。
すばらしい。ありがとう。

116 ：デフォルトの名無しさん：2012/11/22(木) 06:16:16.84

>>114
グローバル変数使うのもどうかとおもうが、
> atexit()の中でNULLじゃないポインタは全て解放
こんなんだと、どうせすぐバグ埋め込むよ。

117 ：デフォルトの名無しさん：2012/11/22(木) 06:42:38.70

もっと具体的に

118 ：デフォルトの名無しさん：2012/11/22(木) 08:36:37.55

>>109
例外のことを知ったほうがいいよ。

newを行った後に、値を代入するのだから
newが行えなければ、値は代入前の値のままだ。

119 ：デフォルトの名無しさん：2012/11/22(木) 09:07:29.23

ありがとう。
宣言時(newより前)に=0してからnew使うようにします。

120 ：デフォルトの名無しさん：2012/11/22(木) 13:33:53.26

GCもSTLも使えないアプリケーションでも
ローカルヒープつくって適当なところで一括解放ってやるよね。
細かくメモリ確保・解放するなんて頭良くないとやってらんない。

121 ：デフォルトの名無しさん：2012/11/22(木) 13:45:11.81

>>114
どこかでfreeしてて二重にfreeするパターンだな

122 ：デフォルトの名無しさん：2012/11/22(木) 14:02:05.66

>>121

>>114
> atexit()の中でNULLじゃないポインタは全て解放
> これでいけるんじゃね？

とあるから、それは無いでしょう。
↓こんな感じで…

BYTE *g_Data = NULL;

void my_end()
{
if(NULL != g_Data){ free(g_Data); g_Data=NULL; }
}

void aaa()
{
g_Data=(BYTE *) malloc(1234);
//処理…
if(bbb()) exit(1); // error end
//処理…
free(g_Data); g_Data = NULL;
}

int main()
{
atexit(my_end);
//処理…
aaa();
//処理…
}

123 ：デフォルトの名無しさん：2012/11/22(木) 14:16:54.24

あのさぁ、フリーするのは目的じゃなくて手段だろ。
mainの最後にまとめて自分で管理しているメモリー
ポインターを解放するとか本末転倒だろ。

ポインター変数をグローバル変数にして云々とか
それってCのランタイムライブラリぃの再実装に過ぎないだろ。

124 ：デフォルトの名無しさん：2012/11/22(木) 15:50:53.69

>>114
> atexit()の中でNULLじゃないポインタは全て解放
こういうのって、大抵リンクドリストが使われた場合とか、マルチスレッドの場合とか、
シグナル受けた場合の考慮が抜けててgdgdになる。
全部考慮して書けないことはないけど、そこまでやる価値があるようには思えない。

125 ：デフォルトの名無しさん：2012/11/22(木) 18:22:36.64

atexitとfcloseallはヘボプログラマーのために存在する。

126 ：デフォルトの名無しさん：2012/11/22(木) 18:40:55.13

標準に従ってるなら、free(NULL)しても何も起きない事は保証されてる。
つまり解放後のNULL埋めを徹底しとけばfreeやdeleteが多過ぎて無問題。

127 ：デフォルトの名無しさん：2012/11/22(木) 18:47:44.98

あとatexitだのfcloseallだの使えばとか言ってる奴らは、クラスなり関数なりブロックなりで、なるべく「完結」するよう書けと学ばなかったのか。
構造化プログラミング辺りから学び直した方が良いんじゃないか?

128 ： ◆QZaw55cn4c ：2012/11/22(木) 19:34:28.40

盛り上がっていますね信者としてはうれしいですね

129 ：デフォルトの名無しさん：2012/11/22(木) 19:38:10.98

atexit()は、SDLのサンプルにでてくるよ

130 ：デフォルトの名無しさん：2012/11/22(木) 20:06:09.15

複雑な相互再帰が絡まず、オブジェクトの寿命が容易に管理できるケースで
関数/ブロックから抜けるときにfreeしない馬鹿はいないだろ

いないよね？

131 ：デフォルトの名無しさん：2012/11/22(木) 23:36:10.82

>>108
ほらな、そんな負け惜しみしか言えないだろ？
ゴミは黙ってな

132 ：デフォルトの名無しさん：2012/11/23(金) 00:00:10.66

みなさん finally はちゃんと書いていますか？

133 ：デフォルトの名無しさん：2012/11/23(金) 01:25:51.04

unwind-protectなら書くよ

134 ：デフォルトの名無しさん：2012/11/23(金) 10:45:30.95

>>131
お前バカだな。かわいそうなくらいバカだ。

> そういう機器だとメモリ確保しないという発言はメモリリークが危険だということを分かってるからだろ？
そういう機器ではプログラムの起動時にメモリ確保して、プログラムが生き続ける限りはfreeする必要が無いからだ。
そもそもmalloc/freeは無い。

バカは黙ってろ。ｗｗｗ

135 ：デフォルトの名無しさん：2012/11/23(金) 10:50:49.50

確かにｗ

俺が前に使った組み込み機器はmallocとか実装されていなくて
スタックも限界あるからローカル変数は小さいものだけ。
あとはグローバル変数を使っていたな。

136 ：デフォルトの名無しさん：2012/11/23(金) 18:50:43.35

>>134=135
通じないみたいだな日本語
韓国人か猿だろお前

137 ：デフォルトの名無しさん：2012/11/23(金) 19:31:40.45

malloc/newで確保したメモリはいかなる場合もfree/deleteすべきって話が起点なのに、
そもそもmallocが無い環境の話を混ぜ込むとか…
最初から読んでないのか、揚げ足取りたいだけなのか、論点ずらしたいのか知らんがアフォ丸出し。

138 ：デフォルトの名無しさん：2012/11/23(金) 19:39:07.08

そもそもスレタイに「mallocの後に」と書いてあるのが読めんのか。

139 ：デフォルトの名無しさん：2012/11/23(金) 22:16:54.39

どうでもいいが1レスで済む事を2レスに分割してるやつなんなんだ考えまとめてから書けよ

140 ：デフォルトの名無しさん：2012/11/23(金) 22:18:49.73

>>137-138
そのようなmallocの無い環境を持ち出したバカは>>98

141 ：デフォルトの名無しさん：2012/11/23(金) 23:06:21.29

そもそも

>100
>「そういう機器だとメモリ確保しない」という発言はメモリリークが危険だということを分かってるからだろ？

mallocしない環境もあるのがメモリリークの危険性を示してると>100は主張してるのに
ドヤ顔で「mallocの無い環境もある」とか言っちゃう>134,135…

142 ：デフォルトの名無しさん：2012/11/23(金) 23:24:55.29

>>141
> mallocしない環境もあるのがメモリリークの危険性を示してると>100は主張してるのに
これがfree教信者の思考停止というやつだな。

mallocが提供されてない環境はメモリリークの危険性を考えて提供されていないわけじゃない。
かわいそうなくらいのバカ。

143 ：デフォルトの名無しさん：2012/11/24(土) 00:33:50.33

>142
「mallocしない」を「mallocが無い」だと勝手に解釈しちゃう奴。
大前提を勝手に外して話の軸をずらしてんじゃねーよ。

144 ：デフォルトの名無しさん：2012/11/24(土) 01:00:42.81

え？ mallocしない「環境」だろ？

環境の話してるんだが、
mallocしない方針の話じゃないよ。

145 ：デフォルトの名無しさん：2012/11/24(土) 01:06:39.81

>>143
お前壊滅的にバカだな。吐いたつば飲み込むなよ。

> そういう機器だとメモリ確保しないという発言はメモリリークが危険だということを分かってるからだろ？
「(mallocが提供されてないから)freeしないんで」をリスキーだからメモリ確保しないと決めつけたのはお前。

mallocくらいでバグつくるとビビってるヘッポコはブラウザゲームでも作ってろ。ｗｗ

146 ：デフォルトの名無しさん：2012/11/24(土) 01:12:58.67

mallocが提供されているのに、
mallocしない環境って
どういう意味だ？

147 ：デフォルトの名無しさん：2012/11/24(土) 01:13:26.84

Mr. malloc

148 ：デフォルトの名無しさん：2012/11/24(土) 01:47:38.52

mallocs 胃薬

149 ：デフォルトの名無しさん：2012/11/24(土) 01:58:38.98

alloca最強

150 ：デフォルトの名無しさん：2012/11/24(土) 02:14:31.47

c99の可変長配列最強

151 ：デフォルトの名無しさん：2012/11/24(土) 09:15:49.25

お前ら...スレタイを良く見るんだ...mallocの直後にfreeは不要だろ？

152 ：デフォルトの名無しさん：2012/11/24(土) 09:28:22.56

>>151
直後なら流石に「なら確保すんなよカス」だな

153 ：デフォルトの名無しさん：2012/11/24(土) 09:42:18.98

>>153
「mallocしてもfreeは不要」なら議論の余地はあるが...「mallocの後にfree不要」だからな...

154 ：デフォルトの名無しさん：2012/11/24(土) 09:58:58.62

>>153
Cならスタックが壊れる。

155 ：デフォルトの名無しさん：2012/11/24(土) 12:33:37.47

>151
勝手に「直」を付け足すな。

156 ：デフォルトの名無しさん：2012/11/24(土) 12:35:19.97

>151-153
お前らみたいに勝手な解釈する馬鹿が居るからコーディング規約がガチガチになっていくんだぞ。

157 ： ◆QZaw55cn4c ：2012/11/24(土) 12:58:15.43

>>156
malloc()/free() に関するコーディング規則ってよくあるのでしょうか？
win32api は対応する malloc()相当機能と free()相当機能は同じ関数に存在すべし、感に満ちあふれていますけれども

158 ：デフォルトの名無しさん：2012/11/24(土) 17:15:27.19

>>157
どっちかというと、それは「書き忘れないように同じ階層に書いといた方がいいよ」的な
話だね
厳密に守る義務はもちろんないけど、スッキリするんだよね

159 ：デフォルトの名無しさん：2012/11/24(土) 17:16:38.18

>>156
char *po;
po = (char *)malloc(sizeof(char) * 128);
free(po);

これをmallocした後にfreeするって言うんじゃないのか？

160 ：デフォルトの名無しさん：2012/11/24(土) 17:29:11.56

>>159
そのコードになんの意味があるのかね？

161 ：デフォルトの名無しさん：2012/11/24(土) 17:35:49.44

>>159みたいに、
現実にはやらないだろうってコードを
想像していたバカって他にもいるの？ｗ

162 ：デフォルトの名無しさん：2012/11/24(土) 17:40:43.38

>>160-161
君らが言いたいのは

char *po;
free(po);
po = (char *)malloc(sizeof(char) * 128);

って事だなw

163 ：デフォルトの名無しさん：2012/11/24(土) 17:46:05.81

>>162
俺はそんな事言ってないし、
思ってもいない。

アホすぎて考えつかないそのコードを考えたのはお前だろ。
そこにコードを書いてしまったのが仇となってる。
お前が思いついた証拠だ。

164 ：デフォルトの名無しさん：2012/11/24(土) 17:47:28.83

>>160-161
ん?
>>159はおかしいか？
スレタイに沿ったコードじゃん

165 ：デフォルトの名無しさん：2012/11/24(土) 18:05:51.48

>>164
スレタイにそっていても
そのコードに意味は無いよ。

だから誰もそんなコードの話はしていない。

ここまでは理解できる？

166 ：デフォルトの名無しさん：2012/11/24(土) 18:17:13.32

ていうか、>>159はmalloc呼び出し自体が無意味で不要だけど
一旦mallocした後のfreeが不要とは言えない

167 ：デフォルトの名無しさん：2012/11/24(土) 18:32:05.67

free無かったら、GUIのピッカーとか、マウスぐちゃぐちゃ動かしてるだけでメモリリークじゃん。

168 ：デフォルトの名無しさん：2012/11/24(土) 18:41:22.87

sizeof(char)をわざわざ掛けているところがそもそも間違っている

169 ：デフォルトの名無しさん：2012/11/24(土) 20:22:33.56

>>167
不要といってるやつは一瞬で終了するプログラムしか組んだことがない似非プログラマらしい
QZも宿題スレでソート組むとかその程度しかしてないし

170 ：デフォルトの名無しさん：2012/11/24(土) 20:30:51.49

基本free必須でかまわないんだが、何事にも例外というものがあるわけだ。
そして例外の基準はケースバイケースで異なってくるわけだが、バカはそれを
理解せず穴だらけの経典を押し付けてくる。挙句のはてにシグナル禁止する羽目になる。

171 ：デフォルトの名無しさん：2012/11/24(土) 20:42:27.54

128バイトでヒープから取る必要があるかは知らないけど
スタックオーバーフロー避ける為に
意図的にヒープから割り当てることはあるんじゃ無いの？

172 ： ◆QZaw55cn4c ：2012/11/24(土) 21:11:13.78

>>170
完全に禁止するのではない、一時的にマスクするだけだ。
ループ中に、マスクしていたシグナルを有効にする瞬間を作る。
マスク中に到着したシグナルはこの瞬間において必要に応じてシグナルハンドラにジャンプする。
マスク中に到着したシグナルであっても（複数が一つにまとまることはあっても）消えることはない。
旧来のsignal()は扱いにくい、sigaction() が便利である。
つ>>41 http://toro.2ch.net/test/read.cgi/tech/1313183984/592-593

シグナルハンドラの中にまでfree() を記述しておく必要はないと思うが、かりにそうするとしても格別困難ではない。

173 ： ◆QZaw55cn4c ：2012/11/24(土) 21:13:29.34

>>169
おいおい、QZはfree()信者、すなわち malloc()したもの宜しくプロセス終了時にfree()すべき教の（熱心でない）信者だ。

174 ：デフォルトの名無しさん：2012/11/24(土) 21:20:11.52

> シグナルハンドラの中にまでfree() を記述しておく必要はないと思うが、かりにそうするとしても格別困難ではない。
素人発見

175 ： ◆QZaw55cn4c ：2012/11/24(土) 21:23:54.04

もしかしてvolatileのことをいってるの？たしかにあったほうがいいですねえ、これはちょっと失敗か？

176 ：デフォルトの名無しさん：2012/11/24(土) 21:48:31.24

>>162
160だけど、きみはなにいってるの？

177 ：デフォルトの名無しさん：2012/11/24(土) 23:00:26.79

>170
普通シグナルみたいな例外的な(環境によって対応してない)ものは、基本則(この場合mallocしたらfreeする)とは
別に言及するべきだと思う。

178 ：デフォルトの名無しさん：2012/11/24(土) 23:19:53.71

>>177
mallocしたらfreeするを原則とするなら、シグナルくらいは対応しておけよ。
CPU引っこ抜かれた時にまで対応しろとは言わないからさ。

179 ： ◆QZaw55cn4c ：2012/11/24(土) 23:25:31.42

>>177
まああれだ、
QZ が>>170のソースにmalloc() があっても free()がない、とけちをつけたのが発端、
というか QZは恥知らずで糠に釘、
というか >>50=QZ で実は >>170 も QZ も認識は同じだと思う。
というか単なる泥仕合

180 ：デフォルトの名無しさん：2012/11/24(土) 23:33:51.72

>>170 にソースは書いて有りませんよ？ｗ

181 ：デフォルトの名無しさん：2012/11/24(土) 23:41:23.94

お前ら一回寝ろｗｗｗ
スッキリした頭でないといいコードはかけんよ

182 ： ◆QZaw55cn4c ：2012/11/24(土) 23:44:33.13

うふふ、匿名ですものねｗ

183 ：デフォルトの名無しさん：2012/11/25(日) 01:12:38.46

>178
そこまで重要なら、何故malloc/freeみたいにstdlibに入ってないんでしょうねぇ。

184 ：デフォルトの名無しさん：2012/11/25(日) 01:31:53.80

シグナルという機能は
OS依存だからだろ。

C言語はOS依存の機能は搭載しない。

185 ：デフォルトの名無しさん：2012/11/25(日) 02:01:32.16

ANSI Cに入ってますけど。
もちろんstdlibには入ってませんが。

186 ：デフォルトの名無しさん：2012/11/25(日) 02:45:21.50

プログラマがシグナルを処理しなければならないOSは欠陥OS
まともなOSならプログラマの思考を読み取って適切に対処するはず
仕組みはmallocしたアドレスを自動で判断してfreeするのと同じ

187 ：デフォルトの名無しさん：2012/11/25(日) 04:04:56.74

>>176
ちげーよ。教えてやらんけど。お前はシグナル処理をしらない素人。

188 ：デフォルトの名無しさん：2012/11/25(日) 04:30:12.68

UNIX系の開発するときは基礎知識のシグナルの説明をもったいぶる素人が登場したわけだが

189 ：デフォルトの名無しさん：2012/11/25(日) 05:26:54.55

>>188
その素人に見下された気分はどうだ? Qz

190 ：デフォルトの名無しさん：2012/11/25(日) 05:42:01.55

>>185
規格名をくわしく

191 ：デフォルトの名無しさん：2012/11/25(日) 05:43:13.33

>>189
シグナルを誤解しているというかsignal()しかしらないみたいだ

192 ：デフォルトの名無しさん：2012/11/25(日) 05:59:02.77

>>191
基本知識らしいから>>188がもったいぶらずに説明してくれるよ。きっと。
基本知識らしいから誰でも気づくだろうしね。ｗｗ
基本知識を知らないQz ｗｗｗｗ

193 ： ◆QZaw55cn4c ：2012/11/25(日) 06:28:28.77

>>188
>>172 として考えているんだけれども >>189 は何を揚げ足とったつもりでいるのだろう？
volatile を忘れていたのはまずいがそれ以外に何があるのかわからない‥‥‥
まあ所詮泥仕合だからいいけど

194 ：デフォルトの名無しさん：2012/11/25(日) 09:06:47.98

freeしないより致命的な基礎知識なんだけど。>>188はもったいぶらずに教えてやれよ。

195 ：デフォルトの名無しさん：2012/11/25(日) 16:17:07.75

もったいぶってるのは>>187だろ

196 ：デフォルトの名無しさん：2012/11/25(日) 17:30:12.08

シグナル云々の話は、Ctrl-Cとかarrestとかゼロ除算で停止した時にも
ちゃんとfreeするようにしてんの？ってことだろ。

197 ：デフォルトの名無しさん：2012/11/25(日) 20:26:13.81

>>195
いや、オレは最初っからチンカスには教えないと宣言している。
>>188によると基礎知識らしいから>>188が教えてやれ。

198 ：デフォルトの名無しさん：2012/11/25(日) 20:28:53.24

チンカス以外に教えてやれよチンカス

199 ：デフォルトの名無しさん：2012/11/25(日) 21:25:11.76

煽ってもでない、そもそもないから

200 ： ◆USIWdhRmqk ：2012/11/25(日) 21:40:22.69

ttps://www.jpcert.or.jp/sc-rules/c-sig30-c.html

201 ：デフォルトの名無しさん：2012/11/25(日) 21:41:12.94

>>188
もったいぶってないでチンカス以外に教えてやれよ。基礎知識なんだろ。

202 ： ◆QZaw55cn4c ：2012/11/25(日) 22:08:36.15

>>200
signal() だろう？
マスクをあらかじめ設定するとかできないし、はいったらマスクしなおす場合もあるし、ほかいろいろめんどうで、
そもそもSystemV/BSD で挙動がかわったりするし、
こいつを使ってどうこうするのは不便というか不可能。

203 ： ◆USIWdhRmqk ：2012/11/25(日) 22:10:54.47

本題に戻そうか。

MEM00-C. メモリの割り当てと解放は、同じ翻訳単位内の同一抽象レベルで行う
ttps://www.jpcert.or.jp/sc-rules/c-mem00-c.html

204 ：デフォルトの名無しさん：2012/11/25(日) 22:14:40.01

>>203
確保するモジュールと利用するモジュールが異なることなんてざらにあるのに無茶言うな。

205 ：デフォルトの名無しさん：2012/11/25(日) 22:19:11.80

制限としては無駄にきつい気もするが、あれだ、win32api 的には合格だ

206 ：デフォルトの名無しさん：2012/11/25(日) 22:27:17.79

>>204
確保するモジュールと解放するモジュールについて言ってるのにどうして利用するモジュールが出てきた？頭大丈夫か？

207 ：デフォルトの名無しさん：2012/11/25(日) 23:23:22.93

誰が利用してるのか分からないのに勝手に解放できないだろ？

208 ：デフォルトの名無しさん：2012/11/25(日) 23:39:43.61

>>202
往生際がわるい。必死すぎる。素人。

209 ：デフォルトの名無しさん：2012/11/25(日) 23:41:31.09

>>207
モジュールAがあってそこでメモリを確保する。
モジュールAを使うモジュールBがある。

この時モジュールBは、モジュールにAに対して例えば
OpenHandle()を呼び出す。そしてモジュールAはメモリを確保する
モジュールBは不要になったら、モジュールに対して
CloseHandle()を呼び出す。そしてモジュールAはメモリを解放する。

モジュールAで確保したメモリを、モジュールBで解放してはいけない。

同一翻訳単位内の、同一抽象レベルで行うというのはこういうことなんだが
わからなかったのか？

210 ：デフォルトの名無しさん：2012/11/25(日) 23:48:04.05

>>208
え？signal() なんかいまどき使うのですか？普通 sigaction() ではないですか？

211 ：デフォルトの名無しさん：2012/11/26(月) 00:21:48.64

>>210
signal(3)のハンドラでの制限ではないわけだが。

> え？signal() なんかいまどき使うのですか？普通 sigaction() ではないですか？
sigaction(2)を持つOSではsignal(3)はsigaction(2)で実装されてる。

そんな事も知らないで、signalじゃなくてsigaction使ってるオレってプロ。スゲーって自画自賛してるのか。ｗｗｗ
シグナル処理を知らない素人。ｗｗｗ

212 ：デフォルトの名無しさん：2012/11/26(月) 00:25:42.74

わざわざsigactionを実装してくれてるのに低レベルで環境依存のsignalを使えって？
それこそ低脳だ

213 ：デフォルトの名無しさん：2012/11/26(月) 00:29:37.97

救いようのないバカだな。

>>200の制限はsignal(3)のハンドラの制限じゃないから。
signalを使うとか関係無いの。

214 ：デフォルトの名無しさん：2012/11/26(月) 00:45:13.79

>>209
> モジュールAがあってそこでメモリを確保する。
> モジュールAを使うモジュールBがある。
なんでそんな勝手な条件を入れるんだ。

215 ：デフォルトの名無しさん：2012/11/26(月) 00:46:21.05

> わざわざsigactionを実装してくれてるのに低レベルで環境依存のsignalを使えって？
素人丸出し。ｗｗｗ

無い知恵絞ってsigactionで書いた、シグナル喰らってもfreeするお経を否定されたのがそんなに悔しいのか?
あのバカげた方法は処理時間が長い検索処理などでは使えないクソ実装。止めたくなったらどうすんだよ。ｗｗ

216 ：デフォルトの名無しさん：2012/11/26(月) 00:47:01.65

>>209
しかも、問題の解決になってない。。

217 ：デフォルトの名無しさん：2012/11/26(月) 00:49:10.02

ID無いのを良い事に、レスする相手を間違えてるのを黙って見てたらカオスな事になってきたでござるwww

218 ： ◆QZaw55cn4c ：2012/11/26(月) 00:51:07.73

>>212
低レベルというというかなんというか。最近の教科書は signal() の制限とともに sigaction() を紹介することが多い。

>>211
＞signal(3)のハンドラでの制限ではないわけだが。
この文、意味がよくわからないから解説してほしい。なおjmでは signal(2) だった。

＞sigaction(2)を持つOSではsignal(3)はsigaction(2)で実装されてる。
ほう、そりゃ sigaction() の方が細かいところまでこっちで指定できるからね、あと統一されているし。signal() は単なるラッパとするのもうなずける。

＞signalじゃなくてsigaction使ってるオレってプロ。スゲーって自画自賛してるのか。
すごいとは思わない、むしろ当たり前。ちょっと調べればすぐわかること。signal()とsigaction()とどっちを使いたいか検討しなかったの？
こことかで勉強してね。
wikipedia外部リンク: http://www.coins.tsukuba.ac.jp/~syspro/2005/No5.html
jm: http://linuxjm.sourceforge.jp/html/LDP_man-pages/man2/sigaction.2.html
他こことか：http://www.nurs.or.jp/~sug/soft/super/signal.htm#sec6

219 ：デフォルトの名無しさん：2012/11/26(月) 00:57:46.00

>>214
MEM00-C. メモリの割り当てと解放は、同じ翻訳単位内の同一抽象レベルで行う

って書いてあるだろ？

220 ： ◆USIWdhRmqk ：2012/11/26(月) 00:58:04.99

>204,207,214,216
「翻訳単位」の意味をググった方が良いかと。
あと貴方が想定している「問題」はMutexとか参照カウンタとか使うのが一般的な解決策では。

221 ：デフォルトの名無しさん：2012/11/26(月) 01:02:54.43

>>220
知ってるよ。
だから、MEM00-Cじゃ根本的な解決になってないと言ってる。
freeをラッピングしてるだけだ。

222 ： ◆QZaw55cn4c ：2012/11/26(月) 01:03:19.02

>>213
>>200 の制限がめんどくさいと思えばいつでもいかようにこっちで振る舞いを指定できるのが sigaction()。
今回、複数のシグナルに対して一つのシグナルハンドラを共用したが、signal() でそれをやるのは大変だ。

>>215
＞あのバカげた方法は処理時間が長い検索処理などでは使えないクソ実装。止めたくなったらどうすんだよ。ｗｗ
シグナルマスクを解除する瞬間をつくれば、そのときに、保留されていたシグナルにしたがってハンドラに処理が渡るだけでは？
まあ、マスクする時間帯が多少長いけれども
＞シグナル喰らってもfreeする
ことはそんなに難しくないことがわかったわけだ、それで十分。

223 ：デフォルトの名無しさん：2012/11/26(月) 01:03:34.67

もしかして、なにかを改善する目的じゃなかったりする？
> MEM00-C

224 ：デフォルトの名無しさん：2012/11/26(月) 01:15:34.18

>>214は例と条件の違いさえ分からないとんだ池沼だった

225 ：デフォルトの名無しさん：2012/11/26(月) 01:22:03.92

>221
1つのソースから、複数のモジュールを生成することはできるでしょ

226 ：デフォルトの名無しさん：2012/11/26(月) 01:23:26.25

貼り忘れ

翻訳単位 (translation unit)
ひとつのソースファイルと、その中から #includeで取り込んだヘッダおよびソースファイルを合わせたもの。
ttp://takagi.in/modules/bwiki/index.php?%CB%DD%CC%F5%C3%B1%B0%CC

227 ：デフォルトの名無しさん：2012/11/26(月) 01:24:24.45

>>221
問題ってなんの？

全く関係ないはなししてるだろｗ

228 ：デフォルトの名無しさん：2012/11/26(月) 01:32:37.68

>>222
> >>200 の制限がめんどくさいと思えばいつでもいかようにこっちで振る舞いを指定できるのが sigaction()。
バカ。ｗｗｗｗ
せっかく>188がもったいぶらずに教えてくれてる煮に猫に小判、豚に真珠、馬の耳に念仏。ｗｗｗ

229 ：デフォルトの名無しさん：2012/11/26(月) 01:39:31.90

そんなことぐらい自分で判断しやがれ
ここで聞いても答えはでんだろ
他の人の意見を聞くならまだしも
お前が信じるかどうかなんて知ったことじゃねえ

230 ： ◆QZaw55cn4c ：2012/11/26(月) 04:57:48.02

>>228
だ・か・ら、今回は、
> シグナル喰らってもfreeすること

が実際に可能かどうかを検証することにあったわけ、なんか絶対無理みたいな論調でいわれたからね。
シグナルハンドラの書き方の実際は調べればわかるし、非同期に動くからいろいろ気をつけないといけない、特にハンドラを処理したあともとに戻りたければ。
しかし、今回は

> シグナル喰らってもfreeすること
が目的、それさえできれば普通のハンドラの書法に必ずしも沿う必要はない。

>>200 URL・シグナルハンドラ内では非同期安全な関数のみを呼び出すこと。
これはシグナルハンドラを処理中に同じハンドラに再入する可能性があればこその制約、であれば再入させないようにハンドラに入る時点でシグナルをマスクすればいい。

>>200 URL・一般に、標準入出力関数をシグナルハンドラから呼び出すのは安全でない。
ライブラリを使わずに直接ディスクリプタ1, 2 に write() すれば問題ない

>>200 URL・free() 関数もまた非同期安全ではなく、シグナルハンドラから呼び出すことは本ルールに違反するということである。
>>200 URL・free() の呼び出し後に SIGINT が発生した場合、info によって参照されるメモリ領域が2 度解放されてしまうことである。
ハンドラを再入させなければいい。

>>200 URL・volatile として宣言されていない変数をシグナルハンドラが読み取ることである。
メインルーチンでアトミック性を確保するべく適宜シグナルをマスクすればいい。
また、今回はメインからシグナルを受けてシグナルハンドラに移れば、そこにいったっきりでfree()して終わってしまう。
であれば厳密には volatile すら必要ない。

ハンドラの制約には理由がある。それを回避すればいいだけのこと。signal() では困難だが sigaction() ならそれも可能。

231 ：デフォルトの名無しさん：2012/11/26(月) 09:09:49.04

>>230
なんか、そのために生きてるって感じがするな君のいってることを実現したコードって
やりたいことは別にあるのに…って感じがするが（よく考えるのはいいことだけどコード
の本懐ではないと聞こえる）

232 ：デフォルトの名無しさん：2012/11/26(月) 10:10:25.63

> >>200 URL・シグナルハンドラ内では非同期安全な関数のみを呼び出すこと。
> これはシグナルハンドラを処理中に同じハンドラに再入する可能性があればこその制約、であれば再入させないようにハンドラに入る時点でシグナルをマスクすればいい。

バカ。ｗｗｗｗ
非同期安全な関数の意味を全く理解できていない。ｗｗｗｗ

233 ：デフォルトの名無しさん：2012/11/26(月) 10:16:58.96

シグナルハンドラでは非同期安全な関数しか使えないから「困難」と言ったのに、
シグナル処理すればfree教の教義に背くことなく簡単に出来るというので、
それじゃ作ってみろといって出来たのが
http://codepad.org/mLtuxDOF ｗｗｗｗ

処理中のシグナルを禁止するという長い処理の場合に停止不可能な腹絶倒の実装。ｗｗｗ

234 ：デフォルトの名無しさん：2012/11/26(月) 12:17:28.80

　　┏┳━┳━━┳━━┳━━┳━━┳━━┓
　　┃ 　━┫┏┓┃┏┓┃　 ━┫┏┓┃┏┓┃
　　┃┏┓┃┗┛┃┏┓┫　 ━┫┏┓┃┃┃┃
　　┗┛┗┻━━┻┛┗┻━━┻┛┗┻┛┗┛
.　　　　　　　　　　　　　　 _＿__,
　　　　　　　　　　　　／∧＿∧ ＼
　　　　　　　　　　　./ 　<丶｀Д´>､｀、
　　　　　　　　　　/　/＼＼つ　つ、ヽ
　　　　　　　　　　|　|　　,＼＼ﾉ　　|　|
　　　　　　　　　　ヽヽ　し＼＼） /　/
　　　　　　　　　　＼ `＼_____＼' ／／
　　　　　　　　　　　　ヽ､ _＿＿_,, ／

　┏━━┳━━┓┏┓┏┳━━┳━━┳━━┓
　┃┏━┫┏┓┃┃┗┛┃┏┓┃　　　┃　 ━┫
　┃┗┫┃┗┛┃┃┏┓┃┗┛┃┃┃┃　 ━┫
　┗━┻┻━━┛┗┛┗┻━━┻┻┻┻━━┛

235 ： ◆QZaw55cn4c ：2012/11/26(月) 12:34:08.95

>>232,233
ん、メイン側で無理苦理シグナルをマスクして（でもマスクをはずす瞬間も作っているだけれど‥‥）、というのがお気に召さないのね。

>>231-233
要はシグナルハンドラが重すぎる、ということでいいでしょうか？
ではちょっと考え直します。メインに少々手を加えないといけないのが好みではないのですが、まあ仕方がない。

しばしお待ちを。

236 ： ◆QZaw55cn4c ：2012/11/26(月) 12:39:06.25

>>232
え？リエントラントではない関数は使うな、てことじゃないの？割り込みハンドラと同様の意味合いだとばかりおもっていたんですけれどね。
では「非同期安全な関数」とはどういう意味？
そちらこそわかっていないような気がするなあ‥‥‥。

ハンドラがリエントラントでなければ、メイン側で再入しないように捻じ曲げるのもありだと思ったんですけどね。

237 ：デフォルトの名無しさん：2012/11/26(月) 13:49:01.86

>>235
違う。お前はなんというタイトルのスレにレスをしてるんだという話。
シグナルを主題に語るな、malloc, freeを語れ。

238 ：デフォルトの名無しさん：2012/11/26(月) 16:29:28.38

シグナルハンドラでfreeとかwriteとか、恐ろしいな。
まあLinuxとかBSDでなら動きそうな気もするが。

239 ： ◆QZaw55cn4c ：2012/11/26(月) 19:19:16.28

>>238
write() は標準入出力相手なら問題ないのでは？
free() はそのままでは確実にアウト、>>172 は無理苦理に‥‥わかりました、もうやめます。

240 ：デフォルトの名無しさん：2012/11/26(月) 21:59:31.44

>>238
いやいやlinuxというかglibcだけど余裕でデッドロック起こして止まるよ。
フラグだけたててメイン処理で見るなりEINTR拾うなりせんといかん。

241 ：デフォルトの名無しさん：2012/11/26(月) 22:26:14.50

>>239
writeは大丈夫だね。
http://linuxjm.sourceforge.jp/html/LDP_man-pages/man7/signal.7.html

242 ：デフォルトの名無しさん：2012/11/26(月) 22:30:52.18

POSIX完全準拠のシステムならね。
世の中にはPOSIX準拠風のシステムが多い。

243 ： ◆QZaw55cn4c ：2012/11/26(月) 23:08:17.06

シグナルハンドラが重すぎる、という指摘をいただきました。最初にもどって修正しました。
書いてみて、はじめて、>>172 よりもこっちの方がまっとうでわかりやすいと痛感しました。
http://toro.2ch.net/test/read.cgi/tech/1313183984/595

>>231
コメントありがとうございました。

>>232 >>233
最後までお付き合いくださり感謝です。

244 ：デフォルトの名無しさん：2012/11/27(火) 00:58:15.65

こいつ本物のバカだ。0点。ｗｗｗ

245 ： ◆USIWdhRmqk ：2012/11/27(火) 21:23:01.50

ミスを素直に認めてる分だけ、一部の方々よりマシだと思いますが。

246 ：デフォルトの名無しさん：2012/11/27(火) 21:28:53.15

ミスを認めているどころか、全然ダメだって事に気付かずに勝利宣言してるバカじゃん。
修正前よりダメっぷりが倍増してる。

247 ：デフォルトの名無しさん：2012/11/27(火) 22:46:04.66

>>242
そんなに多いかねぇ
writeに関してはLinux Solaris HP-UX AIX OS X(BSD)の
manには記載されているが他にはあるかね？

>>246
どこがどう悪いのか例示出来ないのなら同類。

248 ：デフォルトの名無しさん：2012/11/27(火) 22:57:10.77

クズに教える気はないから。
基本的な事だから、おせっかいな>188みたいのが教えてくれるだろう。

249 ： ◆QZaw55cn4c ：2012/11/27(火) 23:30:33.12

今のいままで具体的な話はなにも。
倍増といわれてもねえ。
fgets() 中の割り込みはキャッチして終わることだけを確認してはいます。

250 ： ◆QZaw55cn4c ：2012/11/28(水) 08:34:27.26

free()か‥‥‥

251 ：デフォルトの名無しさん：2012/11/28(水) 19:44:50.81

All Right Now

252 ： ◆QZaw55cn4c ：2012/11/29(木) 01:23:37.53

もう3年くらい宿題スレで修行することにします....。
http://toro.2ch.net/test/read.cgi/tech/1313183984/596

253 ：デフォルトの名無しさん：2012/11/29(木) 13:49:38.12

スレタイ読んだとき、GCを付けるかどうかの議論スレかと思ったけど、>>1を読んだら違った。

254 ：デフォルトの名無しさん：2012/11/30(金) 00:05:41.66

>>253
GCってタモリが「おにぎり一個でも買えます」とかCMやってるやつか？

255 ：デフォルトの名無しさん：2012/11/30(金) 11:28:31.84

むしろゲームキューブの事

256 ：デフォルトの名無しさん：2012/11/30(金) 22:42:34.87

張本人のカスは逃げ出したか。

257 ：デフォルトの名無しさん：2012/12/01(土) 12:48:59.53

10年以上前のネットニュースのmalloc free論争と
やってる事がほとんど変わらず、おじさんなつかしいよ。

あのころに戻りたい。

結局、freeはいらない派、メモリリークしてもいい派の人なんて議論の中にはいなくて、
オブジェクトの寿命を意識して、それが、プログラムの寿命とほぼ等しかったら、
オブジェクト解体のコストを払うよりも、OSがプロセスの後始末するときに
ついでにやってもらた方がいいだろJKな人がいるだけでしょ。

つまり、freeはオブジェクトの寿命を意識して適切に行え派
（ライブラリ化とか、再利用も考えて総合的なコストが最小になるように
常に考えろ派)

で、それはスレタイの「main以外」という文言から、free必要派の人も
わかってるんでしょ ?

だけど、世の中にはオブジェクトの寿命とか考えずfreeしない
ど低脳も少なからずいるからfreeは絶対必要って言ってかないと
世の中は回らないって思っているんでしょ ?

だったら、freeは必要じゃない場合もあるよ派の人には
愚鈍な人類に今すぐ英知を与えろって言うのがこの議論の
正しい姿なんじゃないかな。

258 ：デフォルトの名無しさん：2012/12/01(土) 12:55:29.39

あと、上のほうのsiganalが絡むときの話は

siganalがからむとfreeするのが難しいって話なのかな ?

でも、siganalが絡もうがfreeしなきゃいけないときは
freeしなきゃいけないんじゃないかな。
(なので、このすれのもともとの議論とはずれているよね。
signalの絡むときの安全なfreeの話題も興味あるので
続けてほしいけど。)

259 ： ◆QZaw55cn4c ：2012/12/01(土) 13:07:39.64

>>257
アマチュアの分際でいうのもなんですが、宿題スレでは xmalloc() とかいうラッパをかませて書くようになりました。
/* xmalloc.h */
#if !defined(XMALLOC_H)
struct supernode {
int id;
unsigned int size;
void *data;
struct supernode *next;
struct supernode *before;
};
void xmallocdump(void);
void *xmalloc(unsigned int, int);
void xfree(void *, int);
void *xrealloc(void *, unsigned int, int);
#define XMALLOC_H
#endif
/* end */
ラッパではわざわざIDをつけて malloc() し、free() のときにIDを確認しています。ロジックがおかしいと自覚できることも時々発生するようになりました。
bcc32 -G -vG の存在を知った今でも、やっぱり使っています。

さぼってラッパを使わないでいると、>>252 のようにすぐにミスります。

260 ：デフォルトの名無しさん：2012/12/01(土) 13:14:49.29

>>258
その通り。いるときはいる。
シグナルで設定ファイルを読み直したりする場合にはよくfreeが絡む。
データベースを壊さないようにしたり、一時ファイルを残さないようにするの
にも必要だけど、古くからあるプログラム(svn gitなど)でも一時ファイルが残っ
てしまったり、データベースが壊れることもあった。そのくらいシグナルを正
しく扱うのは難しい。
だから必要のない場合なら無理して実装することはないと思う。

261 ：デフォルトの名無しさん：2012/12/01(土) 13:24:39.82

>>259
mtraceじゃだめなの？

262 ：デフォルトの名無しさん：2012/12/01(土) 13:30:09.79

>>260
割り込み処理があることを意識したロジックが書けない無能の叫びだな。

263 ： ◆QZaw55cn4c ：2012/12/01(土) 13:32:10.62

>>261
情報ありがとうございます。
#define ばりばり、のときの使い心地はどうでしょうか？
printf() デバッグですませられるのならすましたいです。

264 ：デフォルトの名無しさん：2012/12/01(土) 13:53:25.36

>>256
> siganalがからむとfreeするのが難しいって話なのかな ?
違う。

再利用する可能性がない場合にfreeしなかったら、ド低能がからんできたから、
「そういうお前はどうなんよ。シグナル喰らった時にfreeしてないじゃん」と
からかってやった結末。

265 ：デフォルトの名無しさん：2012/12/01(土) 22:33:53.09

>>46
プロセス終わるときに
解放してから終わるのと
放置してバッサリ終わるのでは
速さが違うとかなんとか

266 ：デフォルトの名無しさん：2012/12/02(日) 00:07:04.75

>>265
スワップアウトされていたメモリをfree()で開放しようとすると、一旦その部分をスワップインすることになる。
バッサリ終わった場合、フツーのOSであればそんなことにはならないんで、素早く終了できる。

大して保存するデータもないはずなのに妙に終了に時間がかかるアプリと、
同じような規模なのにサクッと終了するアプリがあるのはその辺が効いてるんじゃないかな。

free()不要の「不要」を消極的に考えるからいろいろ議論()になるだけで、プロセスの終了をひとつの機能として
真面目に取り組んで、「速度効率のためfree()しないで終了する」という機能を実装する。
というのがここでいうfree()不要論者が言いたいことだと思う。

267 ：デフォルトの名無しさん：2012/12/02(日) 00:29:36.63

>>266
なにいってんの？

少しぐらいはスワップインするかもしれないけど、
どんなに大量のメモリを確保していたとしても、
freeするのに必要なのは、ポインタと管理データ部分だけじゃん。

268 ：デフォルトの名無しさん：2012/12/02(日) 01:04:33.49

HDDだったら1セクタも100セクタもread時間は大して変わらないんだよね。
自前でヒープ確保しmallocもどきを実装して、終了時は一々freeせずヒープごと削除ってのはよくやる。

269 ：デフォルトの名無しさん：2012/12/02(日) 06:53:09.41

>>267
それが時間かかるんだよ

270 ：デフォルトの名無しさん：2012/12/02(日) 08:24:01.08

>>266
素人考えですみませんが、free()での解放もOS(ライブラリ?)によるプロセスリソース解放も、
どちらもスワップアウトされていた一部メモリを一旦スワップインすることになりませんか?

> 大して保存するデータもないはずなのに妙に終了に時間がかかるアプリと、
> 同じような規模なのにサクッと終了するアプリがあるのはその辺が効いてるんじゃないかな。

サクッと終了するのは、ウィンドウが閉じるのが早いだけの体感的なもので、実際はウィンドウが閉じた後は
OS(ライブラリ?)で動く解放処理の分で少しモタつくようになりませんか?

271 ：デフォルトの名無しさん：2012/12/02(日) 09:06:04.06

アプリの終了処理でメモリの解放だけ特別扱いして多少早くなったとしても、
コーディングの手間に対して割が合わんな。

272 ：デフォルトの名無しさん：2012/12/02(日) 09:31:13.84

ジジイ共。いい加減にスワップイン/スワップアウトっていうのやめろ。
ページイン/ページアウトだ。

>>270
ならない。
通常mallocされたブロック(mallocが返してきたポインタ)の前に管理用の情報が置かれている。(たとえば大きさとか)
freeする場合はこの情報にアクセスする必要がある。
OSがバッサリ解放する際にはこれらの情報にはアクセスする必要が無い。

273 ：デフォルトの名無しさん：2012/12/02(日) 10:01:57.06

>>266
しかし、「スワップアウトされた状態での終了の速度」などという恐ろしくどうでもいいことに
こだわってfreeするかしないかコーディングに反映させるプログラマがいたとしたら、
そいつはセンスないだろ。

274 ：デフォルトの名無しさん：2012/12/02(日) 10:06:35.97

>>272
終わるときのことばかり考えて答えを出すのは早計、世の中には原則終わってはならない、終わることなく動き
続けなければならないプログラムというものもある

例えば監視系とかね

275 ：デフォルトの名無しさん：2012/12/02(日) 10:10:24.17

「必ずfreeすべし」への反論なんだから、freeしない方が良い例を
ひとつでも挙げられたら良いんじゃないの？

276 ：デフォルトの名無しさん：2012/12/02(日) 10:19:38.31

>>272
レスありがとうございます。

ということは、malloc()先で呼んでいるメモリアロケータ(?)かどこかにある、
ページイン/ページアウトまでをも司るところが管理しているメモリ情報は、
ページアウトされないところにあるのかな？

277 ：デフォルトの名無しさん：2012/12/02(日) 10:22:27.55

>>274
はあ? 終了するプログラムの話をしてるんだが。文脈読めないバカは絡むな。

>>275
その、必ずfreeしなけりゃならない理由(教義)が薄弱なんだよ。
異常系はどうすんのよとか突っ込むとQzのようなオロカなハメに陥る。
捕捉不可能なシグナルというのが存在するので「必ずfreeする」は不可能でしょ。

278 ： ◆QZaw55cn4c ：2012/12/02(日) 10:29:36.99

>>277
異常系のfree() は QZ もあきらめていたんですけど？
問題は正常系の free() じゃなかった？

279 ：デフォルトの名無しさん：2012/12/02(日) 10:57:40.60

abort()で終われば問題なし? バカげた教義だな。

280 ：デフォルトの名無しさん：2012/12/02(日) 12:07:16.33

「信者」扱いだし

281 ：デフォルトの名無しさん：2012/12/02(日) 12:48:50.74

>>272
じじーだってことがよくわかったな＾＾。ページって言った方が >267 もイメージしやすそうだな。

>>267
ページングの単位って4kbyteとかなんだよ。
ページングの単位より小さい単位でばかりmalloc()していた場合、
ページアウトしていたほとんどすべてがページインされることになるわけだ。

で、これだけじゃなくページアウトされるような状況なわけだから、
free()のためだけにしか意味を持たない領域がページインされることで、
ほかのアプリが使っていたメモリがページアウトされるんだな。
その後、ほかのアプリを使おうとするとそのページアウトされていたメモリが、
ページインしてくる。その間ユーザは重い思いをするんだ。

>>270,276
プロセスのメモリ空間としてのアドレスと、物理アドレスが別物なのは知っていると思うけれど、
それを結び付けているテーブルと、外部記憶ではどこを使っているという情報を破棄するだけで、
実体のメモリや外部記憶の中身を触ることはないんだ。
(セキュリティの観点から外部記憶のデータを塗りつぶすということもあるけれど、それは別の話)
この情報はCPU/MMUが参照するから、アプリが使うメモリとは別管理。
>サクッと…
メモリ少ない環境で Lotus Notes 使ってみると体感できるよ＾＾、きっと。

>>273
うむ。フツーはビジネスロジック上で、malloc()/free()なんて現れないはな。

こういうことを理解したうえでアプリの特性によって malloc()/free() をどう使うかを考えることなく、
必ずfree()っていうのが、思考停止って言われるゆえんじゃないかと思う。

ところで必ず free() っていうのはWin32以前からの古いWindowsプログラマと、
その末裔にその傾向が強いんだよね。GlobalAlloc()で痛い目に合ったのかな?

282 ：デフォルトの名無しさん：2012/12/02(日) 12:57:42.78

>>281
細かなmalloc領域がキューで大量に繋がってたりしたら最悪なんだよね。
一々追いかけながらfreeするの面倒すぎる。

283 ：276：2012/12/02(日) 13:10:30.21

>>281
> この情報はCPU/MMUが参照するから、アプリが使うメモリとは別管理。

なるほど。
その領域はページアウトされないから、パフォーマンスに影響しないということですか。
ありがとうございます。

284 ：デフォルトの名無しさん：2012/12/02(日) 14:11:43.72

>メモリ少ない環境で Lotus Notes 使ってみると体感できるよ＾＾、きっと。
^^;;

285 ：デフォルトの名無しさん：2012/12/02(日) 14:17:51.50

POSIXなmalloc/freeの話なのに、特定のOSの実装を語るキチガイがいる。

286 ：デフォルトの名無しさん：2012/12/02(日) 14:38:24.90

ページテーブルエントリを木構造で管理して例外でTLBに食わせるとか
普通にどのOSでもやってんじゃないの？
MS-DOSとかITRONとかの人？

287 ：デフォルトの名無しさん：2012/12/02(日) 14:46:28.01

もう >>50 でいいんじゃないの？信者も自分で信者といってるくらいだし

288 ：デフォルトの名無しさん：2012/12/02(日) 14:53:10.68

>>283
ページテーブル自身もページングの対象だ。
x64だとページテーブルで0.5%くらいのオーバーヘッドがある。
4Gバイトの空間を管理するために20Mバイト。400Gバイトなら2Gバイト

こんなのに居座られたくない。

289 ：デフォルトの名無しさん：2012/12/02(日) 15:13:16.89

>ページテーブル自身もページングの対象だ。
これ本当？
ページテーブル領域はページアウトされないようロックしておくものだと思ってたのだが。

290 ：デフォルトの名無しさん：2012/12/02(日) 15:43:41.43

METAな議論はfj時代にもう飽きた。現実的な話をしたいんだ。

>>283
単純に言えばそれに近い(>>288 参照)と思うけど、もうちょっと書くと。
その部分の処理はfree()しようがしまいが必須の処理で必ずOSがやることなのさ。
もし、それでパフォーマンスに影響が出るとしても必須のことだから仕方がない。

時間が解決してくれて、それが原因で落ちたりすることはないけど、CPUクロックだってリソース、
最終的に使うユーザの時間は大事なリソースなんだから、いらん処理で時間というリソースを
ダダ漏れさせていいわけない。いらん処理をすると消費電力(モバイル系だと超重要)も増えるしさ。

せっかくアプリが楽できるようにがんばっているのになんで任せてくれないの？
と日頃悲しい思いをしている環境依存部分の下層レイアを書くことが多い、じじいのぐち。

>>289
(表現が不正確かもしれんが)OSのテーブルの話じゃなくて、ユーザレベルのテーブルの話じゃないかな?

>>284
経験者のようだな＾＾

291 ：デフォルトの名無しさん：2012/12/02(日) 16:37:44.61

>>289
本当だよ。ここがわかりやすい。
http://d.hatena.ne.jp/nonakap/20031016

i386ではページは2階層で管理されている。ページアウトされないのはPD。
PDが保持しているPDEを見ればわかるが、2階層目のPTEをページングできるよう、
ページ存在ビットが存在する。

292 ：デフォルトの名無しさん：2012/12/02(日) 16:43:09.97

>>291
それハードウェアの話じゃんｗ
じゃなくてOSが管理してるメモリの話。

メモリ管理領域は、スワップ対象外メモリとして
OSから確保するでしょ。

293 ：289：2012/12/02(日) 17:00:35.04

>>291
なるほど、PDは常に存在するとして、その先のPTはアロケーションしたときだけ生成されるのね。
少し賢くなったｗ
ただそれでも、割り込み禁止状態等でもPTEまではアクセスできるよう、領域ロックはしたほうがよさげ。

294 ：デフォルトの名無しさん：2012/12/02(日) 18:48:58.01

リンクドリスト・ツリー構造のようなものを解放する場合、ヒープにアドレスが
記憶されるわけで、もしそこがページアウトされていた場合には一度ページイン
してアドレス獲得しないといけないかもね。

295 ：デフォルトの名無しさん：2012/12/02(日) 19:14:11.90

処理系に依存

#じじいおおすぎー;-b

296 ：デフォルトの名無しさん：2012/12/02(日) 19:21:24.22

だから今のOSのメモリ管理方式はほとんど同じなんだって。
ページ管理のツリー段数とページサイズが違うくらいで。

297 ：デフォルトの名無しさん：2012/12/02(日) 20:38:27.13

だから、mallocの実装とOSのそれは違うだろって

298 ：デフォルトの名無しさん：2012/12/02(日) 21:20:30.82

mallocの実装ってアンタ・・・
OSから受け取ったメモリブロックを切り分けてるだけだが。

299 ：デフォルトの名無しさん：2012/12/02(日) 21:20:52.90

>>277
いやｗ
動き続ける中で何度も使用される機能なんて当たり前だがあるわけで、その中で
動的にやりくりすることもありますから勝手に終了をプログラム全体が終了する
ケースに限定しないで欲しいのだが

300 ：デフォルトの名無しさん：2012/12/02(日) 21:25:40.33

>>298
20てん

301 ：デフォルトの名無しさん：2012/12/02(日) 23:34:39.56

>>299
うっせ、カス。
プログラムが終わるときの話をしてるのに割り込んできて終わる話に限定するなとか、バカぬかすな。

お前、リアルでも空気読めないとかいわれてハブられてるだろ。

302 ：デフォルトの名無しさん：2012/12/03(月) 00:09:24.26

そんなシビアにメモリ管理しなくちゃいけないハードで組んだことないから、このスレ読むの楽しい。
Free不要なんて考えしたことなかったわ。

303 ：デフォルトの名無しさん：2012/12/03(月) 00:36:53.07

明確な目的や制限を理由にfreeしないのを「free不要」と表現するから軋轢が起こるのだと思う。
原則必要として、但し書きでfree省略が許される/省略すべきと言った方が理解されやすい。

つーわけでfree不要と言い切るような奴とはやはり一緒に仕事したくないな。

304 ：デフォルトの名無しさん：2012/12/03(月) 00:42:33.02

終了時にメモリ解放しないというのならさ、
普通に終了しないで、exitでもすればいいじゃん。
強制終了すればメモリ解放しないで終われるよ。

305 ：デフォルトの名無しさん：2012/12/03(月) 00:43:54.97

えっ

306 ：デフォルトの名無しさん：2012/12/03(月) 01:59:21.16

その「原則」が人によって違うのに、信者が自分の「原則」を布教しようと必死になるからカオスになる。

307 ：デフォルトの名無しさん：2012/12/03(月) 02:03:04.75

>>304
C++が絡むとexitもややこしいんだよね。
staticクラスのデストラクタはatexitに依存している事が多いので

exit(): staticデストラクタ=動くスタック上のデストラクタ=動かない
_exit(): staticデストラクタ=動かないスタック上のデストラクタ=動かない

リモートにセッションを持っていたりすると時々ややこしい事が起こる。

308 ：デフォルトの名無しさん：2012/12/03(月) 02:05:02.19

>>301
スレタイ見てその話をしてるんならばかってだけだなお前が

309 ：デフォルトの名無しさん：2012/12/03(月) 02:14:39.71

>>308
話の流れの読めないバカって本当に存在するんだな。お前退場。

310 ：デフォルトの名無しさん：2012/12/03(月) 07:36:53.89

二時に言い争いｗｗｗ

311 ：デフォルトの名無しさん：2012/12/03(月) 07:44:12.39

>>307
リモート側が糞。

312 ：デフォルトの名無しさん：2012/12/03(月) 12:52:20.41

>>309
ケースを限定してこうだろっての展開しても結論は出ない
これまでもそうだし、これからもそう

313 ：デフォルトの名無しさん：2012/12/03(月) 13:58:17.00

>>312
お前が議論に必要な知能をもっていないバカだという事は良くわかったから、これ以上絡むな。

>>274で見破っておくべきだったと反省。

314 ：デフォルトの名無しさん：2012/12/03(月) 14:56:07.75

>>313
なんで俺が274なわけ？

見境なく噛みつくなよ

315 ：デフォルトの名無しさん：2012/12/03(月) 19:20:40.10

>>314
>>274じゃないと言い逃れするんだな。
>>274は的外れだがテクニカルな議論を吹っかけてのでバカはバカだか救いようがある。

それ以降に参入したというならレスつける価値もない基地外。あ－、損した。

316 ：デフォルトの名無しさん：2012/12/03(月) 21:48:52.30

>>315
一人相撲乙ｗ
気がすんだか？

317 ：デフォルトの名無しさん：2012/12/03(月) 21:56:33.81

あらら…
せっかく気持ちよく帰ってもえらえるところだったのに戻ってきちゃうじゃん

318 ：デフォルトの名無しさん：2012/12/03(月) 22:01:26.04

では、気持ち悪く帰っていただきましょうｗ

319 ：デフォルトの名無しさん：2012/12/04(火) 01:36:08.56

ずいぶん交戦的なタイプだね
まぁいいけど

320 ：デフォルトの名無しさん：2012/12/04(火) 01:48:47.43

>>302
例えば組み込み系だといきなり電源を落とされる運用なんかもあるから、通常は存在する「終了の手続き」そのものが
発生しないなんてなこともあるから、その意味ではfree書かないこともあるよ

321 ：デフォルトの名無しさん：2012/12/04(火) 01:50:54.26

まぁ、この手の話は正確には書かないというか書いても通らないのだけれどね
普通にソフトだけ再起動ってなパターンもあるから、粗油ときは当たり前にここでの議論の対象になっちゃうけど

322 ：デフォルトの名無しさん：2012/12/05(水) 02:14:16.86

>>274みたいな終了しないソフトのほうが
オブジェクトの寿命 = プロセスの寿命
なオブジェクトのfreeが必要ではない
（というか開放できない。プロセスの寿命 = ∞なので)
と思うのだが

323 ：デフォルトの名無しさん：2012/12/05(水) 04:04:39.31

たとえば、ファイルを開いたり閉じたりするだろう。
ファイルを開いたらあたらしいオブジェクトをつくる。
ファイルを閉じたらそのオブジェクトもいらなくなる。

324 ：デフォルトの名無しさん：2012/12/05(水) 08:36:35.78

free教教祖のチンカスの末路。前回よりダメがさらに倍増。
バグもクリスマスセールで増量中。もはや何をやりたいのか意味不明。

http://ideone.com/DKgnoQ

325 ：デフォルトの名無しさん：2012/12/05(水) 19:06:21.56

>>322
323のいうように、動いてる中で動的に取る、解放する、なんてなものがあるね
あなたのいうものは基本は静的に取ってるエリアの話だね

326 ： ◆QZaw55cn4c ：2012/12/05(水) 20:36:52.51

>>324
んー、こんどはどこがバグってますか？やりたいことは、^C, ^Z kill 引数なし、とかを無視することなんですが。
10万モリタポでぜひお願いします。

なお、free()教の教祖ではなくて一信者なんですけど。

327 ：デフォルトの名無しさん：2012/12/05(水) 21:00:43.06

異常系はfreeしなくてOKとか、信者の分際で勝手に教義を変えたらだめだろ。
基地外宗教を他人に押し付けるような基地外信者は信者は盲目的に教義に従ってすべてのメモリをfreeしろよ。

オレならSIGKILLでも捕まえてfree出来るぞ。ｗｗｗ
意味ないからやらないけど。

328 ： ◆QZaw55cn4c ：2012/12/05(水) 21:09:56.50

>>327
おお～、ぜひ教えてください、10万モリタポで
SIGINT, SIGQUIT, SIGTERM, SIGTSTP 対応でお願いいたします、sigkill はどうでもいいから

329 ：デフォルトの名無しさん：2012/12/05(水) 21:19:56.39

バグなら10万モリタポで教えてやるよ。お前が考えたプロトコルで支払え。
ただし、お前が考えたプロトコルなんだから、だまし取られても泣くなよ。ｗｗｗ

330 ：322：2012/12/06(木) 00:17:03.82

>>325
うん、そう。静的な領域。

とりあえず、プロセスがまだまだ生き続けるのに
オブジェクトが解放できる場合は絶対freeしなくては
ならないと思う。

なので、freeが必要か否かは時と場合によると考える。

じぶんの同僚は
「時と場合にとるなんてのはもっとも役に立たない言葉だ !!」
というけれど。

331 ：デフォルトの名無しさん：2012/12/06(木) 02:47:59.71

静的な領域を使って終了するプログラムと

static char buf[1024 * 1024];
int main()
{
　// buf使った処理
　return 0;
}

動的な領域を使って終了するプログラムがあっても

static char *buf;
int main()
{
　buf = malloc(1024 * 1024);
　// buf使った処理
　return 0;
}

プロセスとしては配置されるアドレスが違うだけで意味としては変わらないよね。
前者にはbssの非ページ領域が割り当てられて、
後者はbrkで延長されたプロセスの非ページ領域(libcヒープ内)が割り当てられる。

332 ：デフォルトの名無しさん：2012/12/06(木) 09:12:53.85

>>330
> とりあえず、プロセスがまだまだ生き続けるのに
> オブジェクトが解放できる場合は絶対freeしなくては
> ならないと思う。

> なので、freeが必要か否かは時と場合によると考える。

たった4行なのに矛盾してる。

333 ：デフォルトの名無しさん：2012/12/06(木) 19:02:38.39

全然矛盾していないだろ
上3行が具体的な例で、下1行が一般化したもの
freeしなくても良い場合の具体的な例が示されていないだけ

334 ：デフォルトの名無しさん：2012/12/06(木) 20:35:08.06

絶対って意味知らないの? 例外あったら絶対じゃないの。日本語わかる?

335 ：デフォルトの名無しさん：2012/12/06(木) 21:04:46.13

これがアスペというやつか

336 ：デフォルトの名無しさん：2012/12/06(木) 21:11:41.91

仕様書も行間読んでプログラムつくるのか。ｗ
ダメな奴の典型。

337 ：デフォルトの名無しさん：2012/12/06(木) 21:18:42.58

プロセスが生き続けている間は解放できないオブジェクトについてはfreeしない

>>330と全く矛盾しない

338 ：デフォルトの名無しさん：2012/12/06(木) 21:40:55.79

なんだ、中学数学の論理学も満足に理解できてないバカか。
で、結局キミのいう「絶対」は例外あるのかい? ｗ

339 ：デフォルトの名無しさん：2012/12/06(木) 21:41:48.97

条件付きの命題を理解できない馬鹿か...

340 ：デフォルトの名無しさん：2012/12/06(木) 21:47:28.04

絶対に例外はあるよ。

341 ：デフォルトの名無しさん：2012/12/06(木) 21:52:46.74

例外のある絶対。ｗｗｗｗ
んじゃ、その例外を列挙しろよ。

342 ：デフォルトの名無しさん：2012/12/06(木) 21:53:34.86

絶対に対して存在する例外が絶対の例外です。

343 ：デフォルトの名無しさん：2012/12/06(木) 21:55:00.98

ある条件を満たす場合に絶対成り立つからといって、
その条件の外でまで成り立つわけではない

344 ：デフォルトの名無しさん：2012/12/06(木) 21:55:15.47

>>341
では、まず絶対を提示してください。
さすれば私目が例外をお目にかけましょう。

345 ：デフォルトの名無しさん：2012/12/06(木) 21:58:28.85

>>343
これがアスペというやつか。ｗｗｗ

「プロセスが生き続けている間」という条件下でキミのいう
「絶対」は例外あるのかい?

346 ：デフォルトの名無しさん：2012/12/06(木) 21:59:13.09

とりあえず、>>332みたいな馬鹿と一緒に仕事したら
絶対苦労すると思う。

なので、仕事で苦労するかどうかは時と場合によると考える。

347 ：デフォルトの名無しさん：2012/12/06(木) 22:00:27.36

>>345
条件には「オブジェクトが解放できる場合」までが含まれる

348 ：デフォルトの名無しさん：2012/12/06(木) 22:01:31.46

行間読まないといけない仕様書書くバカとは仕事はしたくないな。
で、キミのいう「絶対」は例外あるのかい? ｗｗ

349 ：デフォルトの名無しさん：2012/12/06(木) 22:08:18.17

>>347
ああ、その条件でいいよ。例外はあるのかい?

350 ：デフォルトの名無しさん：2012/12/06(木) 22:09:24.24

>>349
>>337 >>343

351 ：デフォルトの名無しさん：2012/12/06(木) 22:10:39.64

あるのかないのかはっきりしろよ。自信ないのか? ｗｗｗ

352 ：デフォルトの名無しさん：2012/12/06(木) 22:11:59.43

「例外」という書き方をしてる時点で
全く理解できてないことが分かる

353 ：デフォルトの名無しさん：2012/12/06(木) 22:14:25.22

つまりね、馬鹿にも分かるように書いてあげると、
「ある条件で絶対成り立つ命題があります、でも例外があります」と言ってる訳じゃなくて
「ある条件で絶対成り立つ命題があります、でも条件外では成り立ちません」と言っているわけだが、
あまりに低能すぎて理解できないんだろうなぁ

354 ：デフォルトの名無しさん：2012/12/06(木) 22:19:57.40

条件は「プロセスがまだまだ生き続けるのにオブジェクトが解放できる場合」
で、命題は「絶対freeしなくてはならない」
で良いんだな。最後の訂正チャンスをやるが、訂正するか?

355 ：デフォルトの名無しさん：2012/12/06(木) 22:21:09.19

freeを呼んでstack overflowでもして学校で噂とかされると恥ずかしいし///

356 ：デフォルトの名無しさん：2012/12/06(木) 22:23:27.55

俺は絶対正しい！！！

例外として俺が間違っている場合を除く。

357 ：デフォルトの名無しさん：2012/12/06(木) 22:24:41.56

その命題が正しいかはともかく、それが
「なので、freeが必要か否かは時と場合による」と矛盾しないことについては
全く問題ないよ

だってその命題は「プロセスがまだまだ生き続けるのにオブジェクトが解放できない場合」
についてはfreeが必要とも不要とも言ってないからな

358 ：デフォルトの名無しさん：2012/12/06(木) 22:29:41.44

プロセスの寿命 = オブジェクトの寿命のケースは既出

359 ：デフォルトの名無しさん：2012/12/06(木) 22:34:21.02

プロセスが直ぐに死ぬ場合についても
絶対freeしろとは書いてない>>330 >>354

360 ：デフォルトの名無しさん：2012/12/06(木) 22:54:09.80

>>359
はあ? バカか。
> だってその命題は「プロセスがまだまだ生き続けるのにオブジェクトが解放できない場合」
> についてはfreeが必要とも不要とも言ってないからな
解放できないオブジェクトはfreeしちゃいけないの。あたりまえ。

オブジェクトは解放出来るオブジェクトか解放できないオブジェクトの二種類で、
「解放出来るオブジェクトは絶対にfreeしろ」という命題を真とするならば、

「なので、freeが必要か否かは時と場合による」は矛盾する。

361 ：デフォルトの名無しさん：2012/12/06(木) 23:02:21.68

>>360
その内容を>>359の直後に「矛盾する（キリッ」
って書き込めるのは凄い

362 ：デフォルトの名無しさん：2012/12/06(木) 23:18:58.41

プロセスが終了する場合の話はすでに完了している。
>>274が無理やり割り込んで切り替えた。

363 ：デフォルトの名無しさん：2012/12/06(木) 23:40:36.95

freeをしないのはウンコを流さないのと一緒。

364 ：デフォルトの名無しさん：2012/12/06(木) 23:47:58.72

そもそもmallocしなければfreeなど必要ない
確保できるかどうかすら分からない領域を必要とする時点で設計不良

365 ：デフォルトの名無しさん：2012/12/07(金) 00:33:35.69

もう時代も変わってきたし、この板もID出してもいいのかもな
議論するには不向きだな、やっぱ

366 ：デフォルトの名無しさん：2012/12/07(金) 00:38:34.44

>>364
C++を知らない組み込みプログラマーは死ねばいいと思いませんか？

367 ：デフォルトの名無しさん：2012/12/07(金) 00:40:00.11

議論じゃなく顔真っ赤なお子様同士のつまらない口げんかだろ。
ID出したところで変わらん罠。むしろもっと増える。

368 ：デフォルトの名無しさん：2012/12/07(金) 00:41:30.86

>>366
C++ならインスタンスの動的生成が必須とか信じてるの？ウマシカなの？

369 ：デフォルトの名無しさん：2012/12/07(金) 04:57:40.87

プロセスの寿命が長ければ長いほどfree()しなくて済むように考えるなー。

370 ：デフォルトの名無しさん：2012/12/07(金) 08:51:33.46

全部静的で良いとか、実際にプログラム組んだことの無いやつだけだろ。

371 ：デフォルトの名無しさん：2012/12/07(金) 09:16:45.75

>>370
未だに20年前のCコンパイラしか使ったことのない組み込みプログラマーもな。

372 ：デフォルトの名無しさん：2012/12/07(金) 09:34:35.89

自分の世界の以外の価値を認められない狂信者。
異端は殲滅すべし。

373 ：デフォルトの名無しさん：2012/12/07(金) 09:47:46.45

自分の作業環境が世界の標準と思ってる奴も痛いな

374 ：デフォルトの名無しさん：2012/12/08(土) 02:29:10.25

>>368
標準ライブラリと多態を使わなければ可能だけど現実的じゃないよね。
printfでも内部的にmallocが使われる。

375 ：デフォルトの名無しさん：2012/12/08(土) 18:24:47.61

(*´･∀･)(･∀･｀*)ﾍｰ

376 ：デフォルトの名無しさん：2012/12/08(土) 18:34:55.38

>>374
printfの実装にmallocが必要とは思えないなあ。
キミにもこの言葉を進呈しよう。

>>373
> 自分の作業環境が世界の標準と思ってる奴も痛いな

377 ：デフォルトの名無しさん：2012/12/08(土) 21:16:02.80

>>376
> printfの実装にmallocが必要とは思えないなあ。
printfの仕様もロクに知らないようだな。
そもそも、ちょっとソースコードをググれば分かることだろうが。

378 ：デフォルトの名無しさん：2012/12/08(土) 21:19:50.76

>>376
ソースも見ないで言ってんの？

glibc-2.16.0: vfprintf.cにmalloc
newlib-1.20.0: vfprintf.cに_malloc_r

自分の作業環境で何が起こるくらいは知っておいた方がいいんじゃない？

379 ：デフォルトの名無しさん：2012/12/08(土) 22:21:20.19

ほらよ。無くても出来証拠。
http://svnweb.freebsd.org/base/head/lib/libstand/printf.c?view=co

> printfの仕様もロクに知らないようだな。
printfの仕様のどこからmalloc必要という結論が出てくるんだ?

380 ：デフォルトの名無しさん：2012/12/08(土) 22:40:32.24

実装はまぁいろいろあるわな

可変個引数やら可変長出力なんてなものをスレッドセーフに作るなら
用途にもよるんだろうが当たり前のように使われてると思う
深く考えて実装したくないから

381 ：デフォルトの名無しさん：2012/12/09(日) 06:02:27.54

>>380
> 可変個引数
> 可変長出力
> スレッドセーフ
奴にはそのレベルの話題は無理ｗ

382 ：デフォルトの名無しさん：2012/12/09(日) 08:42:22.41

printf自体に可変個引数の処理があるんじゃなく、
C言語自体の引数の渡し方にフォーマット処理が含まれてるだけにしか思えないのだけど…。
scanfの方だったら、引数の数で本当に挙動が変わってるけど。

383 ：デフォルトの名無しさん：2012/12/09(日) 15:20:02.70

>>379
それスタンドアロン用のサブセットで標準ライブラリじゃないだろ。
libcには入ってるぞ。

http://svnweb.freebsd.org/base/head/lib/libc/stdio/vfprintf.c?view=co

384 ：デフォルトの名無しさん：2012/12/09(日) 16:09:16.94

>>383
libcの実装がそうなってるってだけ。

385 ：デフォルトの名無しさん：2012/12/09(日) 17:19:03.19

malloc使わなくてもprintfは実装できる証拠を出したのに、標準ライブラリは使ってるとか…
限度を超えた頭の悪さだな。

386 ：デフォルトの名無しさん：2012/12/09(日) 17:37:25.25

>>385
そうじゃなくて、大概のライブラリにmallocが入っているのに
どうやって全部静的にプログラミングするのかと。
libstandも他の部分にはmallocは入ってるぞ？

387 ：デフォルトの名無しさん：2012/12/09(日) 18:02:38.50

アセンブラレベルで考えたら、スタック操作とシステムコールだけでコンソール表示はできるけど、
世界標準のC言語の環境がどうかという話だから、mallocが無いという発言はちょっと。

388 ：デフォルトの名無しさん：2012/12/09(日) 20:42:46.06

malloc相当無しでprintfねぇ
出力を複数回に分けてもいいならともかく、一発で送るには必要

389 ：デフォルトの名無しさん：2012/12/09(日) 20:49:46.67

alloca は「malloc相当」ですか?

390 ：デフォルトの名無しさん：2012/12/09(日) 20:58:22.28

>>389
ケチ付ける為の探りっぽいから、無回答

391 ：デフォルトの名無しさん：2012/12/09(日) 22:02:22.08

スタックポインタの巻き戻しもfreeのうちだよね
freeいらない派はそれすらいらないって言ってるんでしょ？
関数callしても元のアドレスに戻れなすぎワロタ

392 ：デフォルトの名無しさん：2012/12/09(日) 22:17:40.40

sbrk戻してOSに返すのもfreeのうちだよね。free教信者は返してるの?

393 ：デフォルトの名無しさん：2012/12/09(日) 22:18:01.69

>>391
せめてアセンブラくらいは読めるようになってから議論に参加しよう。

394 ：デフォルトの名無しさん：2012/12/09(日) 22:50:40.25

>>393の作ったC言語は関数から戻るときにSP足したりするマシン語吐かないんだ？

395 ：デフォルトの名無しさん：2012/12/09(日) 23:31:40.24

おかしな人

396 ：デフォルトの名無しさん：2012/12/09(日) 23:54:08.47

freeのうちとか範囲広げすぎるバカってなんなの

397 ：デフォルトの名無しさん：2012/12/10(月) 00:29:53.36

使ったメモリ返さないとはそういうことだろ
覚悟決めろよ

398 ：デフォルトの名無しさん：2012/12/10(月) 01:25:23.25

スタックはメモリを返すとか返さないとかの問題じゃない。
確保し続けるなら、stack overflow とかおこさないだろ。

399 ：デフォルトの名無しさん：2012/12/10(月) 02:14:22.32

そのうち、プログラムカウンタも更新するなとか言い出しそうだな。

400 ：デフォルトの名無しさん：2012/12/10(月) 02:28:35.88

>>394
SP足したら、free呼ばれるようなアーキテクチャ使ってるの？
もしかして関数呼び出すときには、mallocでスタック確保するわけ？

401 ：デフォルトの名無しさん：2012/12/10(月) 09:04:23.59

このスレって、間違った知識がある奴に限ってやたら自信満々だし、すぐ人を嘲笑するな。

402 ：デフォルトの名無しさん：2012/12/10(月) 10:45:09.13

データスタックとコードスタックを分離して実装すれば、
データスタックを巻き戻さずに関数からの復帰が可能。
スタックを使わずにサブルーチンコールができるCPUなら
スタックを巻き戻さずに関数からの復帰が可能。

403 ：デフォルトの名無しさん：2012/12/10(月) 11:26:38.13

アドレスをデクリメントしてメモリの内容をレジスタに復帰させるだけの処理を省く利点って何？

404 ：デフォルトの名無しさん：2012/12/10(月) 16:51:55.05

メモリアクセスを減らせる。

405 ：デフォルトの名無しさん：2012/12/10(月) 18:43:15.42

セグメントフォルトするからfree使うなというわけの分からない案件ならあった

406 ：デフォルトの名無しさん：2012/12/10(月) 23:26:02.46

おまえら、生きてて楽しい？

407 ：デフォルトの名無しさん：2012/12/11(火) 01:20:37.45

おい>>406を無視すんな！

408 ：デフォルトの名無しさん：2012/12/18(火) 00:55:05.21

コンパイラ次第。
相当軽量な、組み込みとかいう特殊なものでなければメモリリークしない。
それにサブ関数で確保してグローバルでもメモリ使いたい時もある。
free必須ではない。

409 ：デフォルトの名無しさん：2012/12/18(火) 03:04:21.35

コンパイラ依存なのか
知らなかったよ

410 ：デフォルトの名無しさん：2012/12/18(火) 11:21:35.21

違うだろ。

411 ：デフォルトの名無しさん：2012/12/18(火) 12:31:05.27

実行環境依存と言いたいのだろうが、それをコンパイラ依存と言っちゃうところがなんともアレな人だな。

412 ：デフォルトの名無しさん：2012/12/20(木) 23:36:22.97

風邪なおんねぇ・・

413 ：デフォルトの名無しさん：2012/12/29(土) 22:16:41.48

freeいらない派は次の規格でCの標準ライブラリからfree削除頼む

414 ： ◆QZaw55cn4c ：2012/12/29(土) 22:21:23.32

そこでベームGCですよ、と

415 ：デフォルトの名無しさん：2012/12/29(土) 23:28:48.18

>>414
カール・ベーム

416 ：デフォルトの名無しさん：2012/12/30(日) 01:05:39.52

>>413
誰もそんなことは言っていないぞ。バカ。

417 ：デフォルトの名無しさん：2012/12/30(日) 03:34:40.34

>>416お前バカか？
言ってるだろOSが回収するからfreeいらないって
池沼は引きこもってオナニーしてろよ

418 ：デフォルトの名無しさん：2012/12/30(日) 03:48:31.60

てかfreeないC環境既にあるじゃん
その場合mallocもないけど

419 ：デフォルトの名無しさん：2012/12/30(日) 08:12:49.48

>>417
OSが回収するから終了前はfreeが不要と言っている。
全ての場合に不要なんて誰も言っていないぞ。死ねよバカ

420 ：デフォルトの名無しさん：2012/12/30(日) 08:57:26.37

まあそんな移植性も考えていないようなソース、
レビューで全部はじくけどな
おまえ自身がはじかれないように気を付けろよｗ

421 ：デフォルトの名無しさん：2012/12/30(日) 09:26:18.60

いや多分もうはじかれてると思うｗ

422 ：デフォルトの名無しさん：2012/12/30(日) 09:34:19.10

OSが回収とか、BSDとかLinuxくらいしか触ったことないんだろうな。

423 ：デフォルトの名無しさん：2012/12/30(日) 10:03:07.07

>>420
> レビューで全部はじくけどな
絶対はじいてないってw
そもそもレビューできる実力ないだろ。

424 ：デフォルトの名無しさん：2012/12/30(日) 10:18:36.14

ANSI C host environmentで移植性はある。
それ以外のfree standingならば案件毎に異なるから移植性は重要ではない。

こんなことも知らないバカがレビューやってるって、どんなクソ集団だよ。
↓おそらくこういう奴を飼っている集団。ｗｗ

「どんな環境でも動作するように、移植性考慮して、signalくらってもfreeする
ように実装してみました。作業工数10割増しです。そしてバグだらけです。」

425 ：デフォルトの名無しさん：2012/12/30(日) 10:20:20.11

>>424
ずいぶん狭い世界で生きているんだな

426 ：デフォルトの名無しさん：2012/12/30(日) 10:23:14.97

移植性を持ち出されると苦しいらしいｗｗｗ

427 ：デフォルトの名無しさん：2012/12/30(日) 10:41:53.60

レビューなら、

「あれ？こっちの分岐でxxのfree()忘れてない？」
「あぁ、それが成立する条件だと、関数を抜けた後すぐにプログラム終了ですから不要です。」

なんて言っても、問題の有無が判断しにくいという理由でバツだろーな。
実際の動作には問題がなかったとしても。

428 ：デフォルトの名無しさん：2012/12/30(日) 10:47:25.97

>>427
実際にレビューで指摘すると
「うーん、レアケースだからfreeいらないか」
ってなると思う。

429 ：デフォルトの名無しさん：2012/12/30(日) 10:50:56.29

>>427
得意の論点ずらし。
移植性が悪いからレビューではじくという最初の主張はどこに行ったんだよ。
いや、バカだから最初の主張はすでに忘れたのか。ｗ

430 ：デフォルトの名無しさん：2012/12/30(日) 11:27:21.53

>>428
free()追加して済むならそれでおしまいでしょ。無理にわざわざ怪しいコード
残しておく理由もないし。

>>429
どこ行ったもなにも、別人だし。アタマ冷やせよ。

431 ：デフォルトの名無しさん：2012/12/30(日) 11:43:56.76

>>430
> どこ行ったもなにも、別人だし。アタマ冷やせよ。

んじゃ、そういう事にしといてやるよ。ｗ
>>420はレビューアの資格ない素人のタワゴトって事でいいね。

横から論点ずらす突込み入れるときは紛らわしくならないように気を付けろ。

432 ：デフォルトの名無しさん：2012/12/30(日) 12:24:46.18

何一人相撲してるの？ (w

433 ：デフォルトの名無しさん：2012/12/30(日) 13:47:03.93

>>430
レビューできる実力もないのに無理するな。

434 ：デフォルトの名無しさん：2012/12/31(月) 09:46:30.22

お前らほんと屑だなあ

435 ：デフォルトの名無しさん：2013/01/12(土) 18:56:03.72

世に存在するほぼすべてのソフトウェアは残念なことに賞味期限が設定できない

したがって作った人間が半年程度で放棄する想定でも
実際には１０年以上にわたって保守され続けてしまうということが多々ある

ならば
　サイショハ　コウイウ　ツモリ　ダッタンダ
などというつまらない言い訳を吐かなくてもいいように対処しておくのが
人間の知恵というものである

436 ：デフォルトの名無しさん：2013/01/12(土) 19:37:45.44

>>435
>世に存在するほぼすべてのソフトウェアは残念なことに賞味期限が設定できない

試用版とか普通にあるじゃん。

437 ：デフォルトの名無しさん：2013/01/12(土) 23:23:55.53

>>436
お前プログラマじゃないか、ネタでレスつけてるんだろ
お兄さん釣針につられちゃったぞー

438 ：デフォルトの名無しさん：2013/01/13(日) 00:41:08.80

何を言ってるのかさっぱり理解できない。
まあ、理解する必要もなさそうだけど (w

439 ：デフォルトの名無しさん：2013/01/13(日) 01:08:54.52

自分が理解できない事象はすべてカオスということにしておきたいお年頃

440 ：デフォルトの名無しさん：2013/01/13(日) 10:59:45.14

具体的な反論ないところ見ると、本人も理解できてないんだろうな

441 ：デフォルトの名無しさん：2013/01/13(日) 11:13:42.36

って言うかただの煽りだろ

442 ：デフォルトの名無しさん：2013/01/13(日) 13:16:13.05

>>435 に「オーバーエンデュランス」とかもっともらしい名前つけて
不安を煽れば商売になりそう

443 ：デフォルトの名無しさん：2013/01/15(火) 01:08:57.18

ところで、プログラム終了時にmallocがされた領域を
OSに確実に返すのでfreeが必要ないのはFrreBSDやLinuxだからだ、
移植性を考えるなら、プログラム終了時もfree汁!!という人はどういう
環境を想定しているのでしょうか ?

組み込みOSならそもそもプログラムの終了というものがないから
プログラム終了時のfreeの必要性は関係ないよね。

そうでないプロセスの起動と終了の概念のあるOSでプロセス終了時
malllocされた領域を明示的にfreeする必要のある環境なんてあるのだろうか ?

プロセスという概念のある環境でプロセスで確保したリソースを
プロセス終了で返却しないってのはもうほとんどバグに近い振る舞いじゃない ?
(他のプロセスとの共有リソースとかは除く）

444 ：デフォルトの名無しさん：2013/01/15(火) 01:45:07.40

#define free(p)
で解決

445 ：デフォルトの名無しさん：2013/01/15(火) 03:15:49.52

ドライバとかどうなんだろうね

446 ：デフォルトの名無しさん：2013/01/15(火) 14:38:17.12

バグに近いとかじゃなくて、バグ
freeしなくて良いとか言ってる奴って技術以前に精神的に問題ある奴だと思うよ
常に手抜きの言い訳を考えてるような

447 ：デフォルトの名無しさん：2013/01/15(火) 14:42:11.69

>>443
想定するのもいいけど、如何なる環境でも問題ない（減らす）選択という意味で考えても良いと思う
例えば、組み込み系だとすでに入手ができない状態でリプレースとかあったりして

もちろん、開放しても実質してくんないなんて環境なら電源落とせって手順でクリアするしかないわな

448 ：デフォルトの名無しさん：2013/01/15(火) 14:49:18.15

>>446
屁理屈つけてウィンカーを出し渋る馬鹿ドライバーと同じだな。
まともな奴なら、malloc→freeなんざ身体で覚えてるからな。

449 ：デフォルトの名無しさん：2013/01/15(火) 14:59:22.84

どんな原則にも例外は存在するのだが、それを理解できないバカが「いかなる
場合でも必ずfreeしろ」と言い出すから混乱する。

そのバカの典型がQzとかいうクズ。それほどいうなら異常系もfreeしろと
からかってやったら、バグだらけのシグナル処理書いてバカ晒してて笑った。

450 ：デフォルトの名無しさん：2013/01/15(火) 15:47:46.67

allocaの話じゃないのか

451 ：デフォルトの名無しさん：2013/01/15(火) 19:48:39.46

>>449
signal処理程度を例外に該当すると思ってしまうのはよほどのバカだな。
こんなの準正常系だろ。

452 ：デフォルトの名無しさん：2013/01/15(火) 22:44:31.13

signalが正常系じゃないなら組込みは成り立たんわｗ

453 ：デフォルトの名無しさん：2013/01/16(水) 22:09:54.56

アプリケーションレベル(ビジネスロジックとかいうのか)で素のmalloc(), free()なんて
呼んでいる時点で終わっているからどーでもよかろう

454 ：デフォルトの名無しさん：2013/01/16(水) 22:30:05.19

>>445
必要。

455 ：デフォルトの名無しさん：2013/01/16(水) 23:05:25.38

>>454
ドライバは、終了してもOSがfreeしてくれない場合もあるということかな

456 ：443：2013/01/16(水) 23:38:20.37

>>447
自分の読み返してみたら何書いてるかわかんないね。
ひとりよがりですまん。

とりあえず、想定しているのは、例えば数値計算やコンパイラなんかで
プロセススタート時にファイルから読み出されたデータから
連立方程式を作成したり構文木を作成したりで、
それを、プロセス終了時まで使い続け、プロセスの終了とほぼ同時に
開放する（しない）というものを考えています。

自分は数値計算で計算機の物理メモリと同じスケールのメモリを
プロセスの起動時に確保して、終了まで使い続けるというものを書いていました。

こういうのならまだいいんですが、コンパイラなんかだと、
何万もある細かい有向グラフオブジェクト、それが、循環してたりしてってのが
あるらしいですね。それをプロセスの終了時にちまちまfreeしていくのは
どんだけ無駄なんだろうってのが昔のネットニュースで話題になってました。

個人的に、プロセス終了時のfreeはバーベキューなんかで
使い捨ての紙皿を一枚一枚きれいにしてから捨ててるみたいに感じる。

（使い捨ての）テーブルクロスごとゴミ袋に放り込んでしまえと思う。

457 ：443：2013/01/17(木) 00:02:34.94

で、組み込みOSを挙げたのは、
こういう議論をすると、組み込みOSに移植したとき、
組み込みOSだとプロセスの終了時にfreeされていない領域は
OSに返却されないことも考えられるから、移植性を考えると
プロセス終了時にもfree必要という話が出てくるけど、
組み込みLinux(きちんとメモリが回収される）
よりもっと小さなOSが使われる領域だとそもそも、プロセスの
終了ってものをほとんど行わないから、exit前のfreeって議論から
まずはずれるというので話しにあげました。

458 ：デフォルトの名無しさん：2013/01/17(木) 00:08:11.89

>>457
> 組み込みLinux(きちんとメモリが回収される）
> よりもっと小さなOSが使われる領域だとそもそも、プロセスの
> 終了ってものをほとんど行わないから

ワザワザ「無いことの証明」の手間を自分に課している新手のギャグですか？

459 ：デフォルトの名無しさん：2013/01/17(木) 00:14:46.19

プロセスの概念がないOSにプロセスを移植するときに、
プロセスの終了と開始を、動かし続けることで再現することが多いのですが、
プロセス終了するからfreeしなくていいかｗっていう腐った実装をされている場合、
そもそもちょっと手を入れたくらいでは解放できるように作られていなかったり
してとても迷惑なのです。
OSSとかならまあ泣いて作業しますが、自分ところで発注したプログラムだったり
すると、そんな腐った実装をした会社は取引禁止になります。

460 ：デフォルトの名無しさん：2013/01/17(木) 00:33:09.29

>>455
ドライバってそもそもOSの通常の管理から外れたことを特別にやらせるための機構だからなあ、あり得るかも

461 ：デフォルトの名無しさん：2013/01/17(木) 01:06:57.49

性的配列でもつこうてろ

462 ：デフォルトの名無しさん：2013/01/17(木) 01:10:38.20

性的配列いいなーいいな

463 ：デフォルトの名無しさん：2013/01/17(木) 01:13:15.01

性的配列にでもつっこんでろ！

464 ：デフォルトの名無しさん：2013/01/17(木) 01:15:15.79

つっこみすぎたらsegmentation faultしました

465 ：デフォルトの名無しさん：2013/01/17(木) 01:36:09.97

#include <stdlib.h>
extern updown(double erolv);
extern insert(char *yomenonamae);
extern shasei(float angle);

typedef struct {
int (*insert)(char*);
int (*shasei)(int);
int (*onanie)(double);
int (*masturbation)(double);
} __attribute__((packed)) Chinko;

int main(int chinko, char **manko){
Chinko *mypenis;
#define HOKEI NULL
mypenis = malloc(sizeof(Chinko));
if (mypenis == HOKEI) return 0721;
mypenis->masturbation = mypenis->onanie = updown;
while(mypenis->onanie(4.545) > mypenis->insert("まいんちゃん")) {
mypenis->masturbation(0721);
}
return mypenis->shasei(mypenis->masturbation(0721)),free(mypenis),(int)main;
}

466 ：デフォルトの名無しさん：2013/01/17(木) 05:28:49.45

>>465
ウイルス認定されそうなコードだな

467 ：デフォルトの名無しさん：2013/01/17(木) 11:15:20.84

>>459
つまり、発注条件と違う環境に盗用しようとして逆切れしてるわけだね。

468 ：デフォルトの名無しさん：2013/01/17(木) 12:10:57.82

fjで10年以上前に似たような話を延々やっていたなー

前提を勝手に変えておかしな話を展開するあたりも同じだなー

469 ：デフォルトの名無しさん：2013/01/17(木) 12:16:35.56

ここまで俺の自演

470 ：デフォルトの名無しさん：2013/01/17(木) 13:06:39.28

いや俺だ

471 ：デフォルトの名無しさん：2013/01/17(木) 13:37:13.80

おまえか

472 ：デフォルトの名無しさん：2013/01/17(木) 14:40:21.24

static char *p = NULL;
if (NULL != p)
p = (char *)malloc(BUFSIZ);

的な書き方をすれば、malloc, freeを減らせるってヤツ？

473 ：デフォルトの名無しさん：2013/01/17(木) 14:51:58.97

mallocしなけりゃfreeしなくて良いといいたいのか? なら何も書くな。

474 ：デフォルトの名無しさん：2013/01/17(木) 15:32:57.44

if (p != NULL)
じゃなきゃヤダ

475 ：デフォルトの名無しさん：2013/01/17(木) 18:13:36.67

if (!p)じゃなきゃヤダ

476 ：デフォルトの名無しさん：2013/01/17(木) 18:58:02.01

>>475
NULLが非0だとどうすんのそれｗ

477 ：デフォルトの名無しさん：2013/01/17(木) 19:41:35.35

バカが食いついてきた。

478 ：デフォルトの名無しさん：2013/01/17(木) 20:14:18.24

>>477
if (NULL) abort();

479 ：デフォルトの名無しさん：2013/01/17(木) 20:17:54.40

>476
笑ってもいいかな

480 ：デフォルトの名無しさん：2013/01/17(木) 20:31:31.91

　
　　　　　,一-、
　　　　 /￣　l |　　　／￣￣￣￣￣￣￣￣￣￣
　　　　■■-っ　＜　いいとも！
　　　　´∀｀/ 　　　＼＿＿＿＿＿＿＿＿＿＿
　　＿_／|Ｙ/＼.
　Ё|＿_　| /　　|
　　　　| У...　　|

481 ：デフォルトの名無しさん：2013/01/17(木) 20:36:40.12

#define NULL ((void *)0)

482 ：デフォルトの名無しさん：2013/01/17(木) 20:49:06.35

「C言語は、ソースコード上の0が(ポインターを使う場面では)ヌルポインターを作り出す」

C FAQ 5
http://www.kouno.jp/home/c_faq/c5.html

483 ：デフォルトの名無しさん：2013/01/17(木) 20:51:58.95

C FAQ

5.5:
ヌルポインターの内部表現に0でないビットパターンを使っているマシンでは、NULLはどう定義するべきかか。

A: (省略されました)

484 ：457：2013/01/18(金) 01:57:41.80

>>458
適当なことかいてすまん。

>>459
とりあえず、freeというのはある程度時間を消費する処理であることは
よろしいでしょうか ?
特に細かいmallocを繰り返していた場合。
266辺りの議論を参照。

なので、exitの直前にfreeをごりごり繰り返すのはリソースの浪費。

さて、>>459はUNIXやWindows等、プロセスが確保したリソースを
OSがよきに計らってくれる環境で動作することを要求されたプログラムが
プロセスの概念すらないにOS上に移植できないとおっしゃられているのですね。

それは、仕様の不備ではないでしょうか ?
最低でもxxxxというOS上に移植することを考慮すること、と記述すべき
ではないでしょうか ?

485 ：457：2013/01/18(金) 02:50:31.53

>>468
このスレのタイトルに「main以外」と入っているので、
プロセス終了直前のfreeは必ずしも必要ではないというのは
>>1さんも同意していると思う。

これは10年前からの進歩だと思う。

プロセス終了前のfreeは、>>1では「例外中の例外」と
考えられているみたいだけれど、それは、結構多いシチュエーション
だと思う。

自分は、教条主義的にmallocした領域は絶対にfreeしなくてはならないという
固執した考えを治してあげたいと思う。

で、free絶対派の根拠として、組み込みOSなんかはfreeしないとOSがメモリ
回収してくれないものもあるっていうのがあるけど、それが絶対にfreeしなければ
ならないことの根拠にはならないことを示したいと思う。
（もちろん、組み込みOSを考慮した方がいい場合もあると思うけれど、
そうでない場合も多い）

UNIXやWindowsなど、プロセスが終了するとリソースをOSが回収する
OSだとmalloc-freeはsbrkやmmapでOSから取得したメモリを切り分けている
ヒープ管理ライブラリに過ぎないわけで、それが、ある一定の要件を
満たしていることをプログラムの動作用件として要求するのは、妥当だと
思う。
なので、常に組み込みOS等を考慮しなければならないというのは
妥当ではないと思う。

486 ：デフォルトの名無しさん：2013/01/18(金) 11:00:36.23

いいから、mallocって書いたら、すぐに対になるfreeを書け。
屁理屈言ってないで体で覚えろ。
俺はC++でRAIIするけど

487 ：デフォルトの名無しさん：2013/01/18(金) 11:03:30.33

p = malloc(123);
free(p);
strcpy(p, "123");

488 ：デフォルトの名無しさん：2013/01/18(金) 17:16:03.43

>>484
#define quick_free(p)

489 ：デフォルトの名無しさん：2013/01/18(金) 18:41:02.53

>487やると落ちるOSとちゃんと動くOSがあるんだよな。

490 ：デフォルトの名無しさん：2013/01/18(金) 21:31:09.27

昔のreallocはその動作を前提にした仕様なんだっけか？
どっちにしても、strcpyが内部でmalloc使う実装だったり
マルチスレッドだったりしたら「ちゃんと」動くとは限らんな。

491 ：デフォルトの名無しさん：2013/01/19(土) 10:44:53.11

strcpyが内部でmalloc？
ありうるのか？

492 ：デフォルトの名無しさん：2013/01/19(土) 10:48:26.46

>>489
× ちゃんと動くOSがあるんだよな。
○ たまたま動いているように見える環境があるんだよな。

493 ：デフォルトの名無しさん：2013/01/19(土) 10:49:37.56

>>491
おれは見たことない。
>>490 には、どこの実装がそうだったかを示して欲しい。

494 ：デフォルトの名無しさん：2013/01/19(土) 11:01:15.64

ただの仮定の話じゃないの？
ありそうもない仮定だけど

495 ：デフォルトの名無しさん：2013/01/19(土) 11:14:12.50

>>484
終了前のfreeの実行コストなんていう恐ろしくどうでもいいことのために
それを特別扱いするのはプログラミングコストの無駄だと思うがな。
そもそも、実行時のコストを棚に上げて終了時のコストのみ重要視
しなきゃならん例ってのが思いつかん。

496 ：デフォルトの名無しさん：2013/01/19(土) 11:27:40.60

どうでもよくはないよ
大物アプリの終了時に無駄に時間がかかることがしばしばある
後始末、解放処理のためにページインが発生しているんだろうが
もう要らないものを時間かけて読み込んですぐ捨てているわけで、馬鹿馬鹿しい限り

でもC++あたりだと普通RAII + デストラクタなので、「終了時にはfreeしない」戦略が
手抜きにならないどころか、「特別扱い」するほうが面倒な気がする

497 ：デフォルトの名無しさん：2013/01/19(土) 11:49:15.49

それなら（Winの場合なら）ExitProcess呼べば良いだけだから面倒じゃないよ

498 ：デフォルトの名無しさん：2013/01/19(土) 12:20:50.28

>>496
ヒープの大半がページアウトされたプロセスの終了時間だろ？
やっぱりどうでもいいとしか思えん。
仮にもしそれが本当にcriticalな問題になるケースならば、
「もう使わない領域のfreeのためのページインは無駄だが、
実際にアクセスするためのページインは無駄じゃないからOK」
なんて言うわけにもいかんだろうし。

499 ：デフォルトの名無しさん：2013/01/19(土) 18:42:12.88

>>496
criticalな問題ってのがどの程度のものなのかは人それぞれだと思うけど
496にとってアプリケーションを終了させてから、（ここで言うアプリケーションの
終了は、ユーザーが終了の意思を示した、たとえばウィンドウのぺけボタンを
押したり、メニューから終了を選んだりしたときのこと）、
プロセスが終了するまで、じっと数秒待つのはできたら避けたいことじゃぁないの ?

> 「もう使わない領域のfreeのためのページインは無駄だが、
> 実際にアクセスするためのページインは無駄じゃないからOK」
> なんて言うわけにもいかんだろうし。

実際アクセスするためのページインは必要だからやらなきゃいけないんじゃ
ないの ?

500 ：デフォルトの名無しさん：2013/01/19(土) 20:15:58.47

「じっと数秒待つ」のも、必要なことなら許せるというなら気分の問題でしかない。
freeのコストも必要なものだと考えれば気が楽になるぞ。

501 ：デフォルトの名無しさん：2013/01/19(土) 20:40:27.21

ごみプログラマの自己満足以外に何の役にも立ちませんが
ユーザはプロセス終了時に数秒間待つコストを払ってください

502 ：デフォルトの名無しさん：2013/01/19(土) 22:29:33.91

>>499
＞プロセスが終了するまで、じっと数秒待つのはできたら避けたいことじゃぁないの ?

で、ワシらは「じっと待つ」ことの意味がわからんからそこを聞きたいのだが、彼はなんと言ってくるのだろう？
大至急再起動かけんといかんような感じなのかね？

503 ：デフォルトの名無しさん：2013/01/19(土) 23:11:19.07

屁理屈言ってないでfree書けや。
その上で必要なら特殊な終了処理を入れるんだよ。

504 ：デフォルトの名無しさん：2013/01/19(土) 23:18:15.03

お前らをfreeしたいわ

505 ：デフォルトの名無しさん：2013/01/19(土) 23:44:12.32

解放して再利用するなんてありえん。
kill( ) したいわ。

506 ：デフォルトの名無しさん：2013/01/20(日) 00:16:49.66

>>501
終了時にまったくアクセスする必要のないメモリブロックが大量に残って
いるようなプログラムを書いて、それがページアウトされてしまうような
少ないメモリの環境で動かした場合はそりゃ仕方ないわな。

507 ：デフォルトの名無しさん：2013/01/20(日) 00:25:05.01

笑=malloc(バカ)
free(笑)

508 ：デフォルトの名無しさん：2013/01/20(日) 00:53:47.92

馬鹿が書いたプログラムの終了間際の無意味なfreeの所為で
ページアウトさせられてしまう他プロセスは良い迷惑だな。

509 ：デフォルトの名無しさん：2013/01/20(日) 01:10:31.44

fprintf(stderr,
"馬鹿が書いたプログラムの終了間際の無意味なfreeの所為で"
"ページアウトさせられてしまう他プロセスは良い迷惑だな。"
);

510 ：デフォルトの名無しさん：2013/01/20(日) 06:13:42.67

freeをかるくすればいいんじゃね?

511 ：デフォルトの名無しさん：2013/01/20(日) 08:37:13.28

アロケータもいじれない奴はそっとしておいてやりましょう

512 ：デフォルトの名無しさん：2013/01/20(日) 08:57:20.82

この手の人間が「大物アプリ」とやらを作ってると考えるとゾッとするな

513 ：デフォルトの名無しさん：2013/01/20(日) 09:44:06.19

バカが主張しているfreeすべき理由って「再利用する可能性があるから」だけだろ。
お前らバカが書いたソフトが再利用される可能性は皆無だから安心しろ。

514 ：デフォルトの名無しさん：2013/01/20(日) 10:17:58.63

こないだ久々にpure Cのコード書いたが↓みたいなgotoの連打になった
っていうかこう書かないと大量ネスト＋解放箇所分散化で悲惨だと思う
goto使わない教の人ってどう書いてるんだ？

FILE *fp = 0;
char *p = 0;
　　：
if (some_error) goto LABEL;

LABEL:
if (fp) fclose(fp);
if (p) free(p);
　　：

515 ：デフォルトの名無しさん：2013/01/20(日) 10:25:09.98

リークチェックで検出された結果に対していちいち、「これは終了直前まで
実際に必要だったブロックで、終了時のfreeを省略したために出ただけ
なんで無視。」とか確認するだけでも無駄だな。
freeを省略してもいいって人はリークチェッカとか使わないんだろうか。

516 ： ◆QZaw55cn4c ：2013/01/20(日) 10:44:23.09

>>514
free(NULL)は無問題
よってfree()をあえて書く必要はない信者といえどもそれくらいは知っている

517 ： ◆QZaw55cn4c ：2013/01/20(日) 10:46:46.50

>>514
fclose(NULL)はアウトだからラッパをかます

518 ：デフォルトの名無しさん：2013/01/20(日) 10:47:46.82

>>514
do {
　if (some_error) break;
} while(0);

とかじゃね？
俺はそのパターンの時はgoto使う派だけど。

519 ：デフォルトの名無しさん：2013/01/20(日) 11:27:27.79

終了時に全部freeするのは全然構わないけど、
そのために数秒止めるようなコード書く馬鹿はCを使うべきじゃない

520 ：499：2013/01/20(日) 12:12:28.75

>>502
一番思いつくのは、WindowsでGUIのプログラムを使って、
終了を選択したのに、ハードディスクがくるくる回って、
Windowsキーを押してもスタートメニューが開かないような常態。

あと、gccなんかでカーネルとか馬鹿でかいプログラムを
コンパイルするときなんか、全く無駄な処理で時間をつぶしたくは
ないですよね。

521 ：デフォルトの名無しさん：2013/01/20(日) 13:24:54.88

だめだこいつ（笑）

522 ：デフォルトの名無しさん：2013/01/20(日) 13:25:50.08

>>518
該当部分を関数にしてreturnってのもあるけど
それだけの為にってのはなあ

523 ：デフォルトの名無しさん：2013/01/20(日) 13:33:52.36

何GBもメモリ確保して終了まで開放しないようなアプリの話か？
かなり特殊なケースだが、そもそも終了に限らず動作自体遅くて
しょうがないだろう。
本当にそういう条件で動かす必要のあるアプリなら、終了時の
freeどうこう以前にもっと考えなきゃならんことがあるだろ。

524 ：デフォルトの名無しさん：2013/01/20(日) 14:05:00.20

> かなり特殊なケースだが
それはお前の経験値が不足しているだけ。

525 ：デフォルトの名無しさん：2013/01/20(日) 14:21:46.06

経験積んだら>>523みたいなプログラムが一般的になんのかよｗ

526 ：デフォルトの名無しさん：2013/01/20(日) 14:28:50.68

経験値が足りないバカは経験値を積んでもやはりバカ。

527 ：デフォルトの名無しさん：2013/01/20(日) 14:57:11.40

経験値って、昔から使われることばだけど、なんか変だな。単に経験でいい

528 ：デフォルトの名無しさん：2013/01/20(日) 15:02:44.08

経験値って言いたいだけの >>524 とか、スルーで良いと思うんだが…

529 ：デフォルトの名無しさん：2013/01/20(日) 15:10:53.58

んじゃ、経験に基づかずに「かなり特殊なケース」であるというソース示しなよ。
バカには無理だろうけど。

530 ：デフォルトの名無しさん：2013/01/20(日) 15:21:33.75

「ソース出せ」は先に言ったモン勝ちｗ

531 ：デフォルトの名無しさん：2013/01/20(日) 15:36:05.36

>>529
おまえが、「何GBもメモリ確保して終了まで開放しないようなアプリ」の例を挙げれば良いだけの話。
もちろんソースつきでな。

532 ：デフォルトの名無しさん：2013/01/20(日) 15:37:43.68

結論の出なかった論争のリプレイなんだから
結論出るわけがないんだけどね。

533 ：デフォルトの名無しさん：2013/01/20(日) 15:37:55.13

>>523
とりあえず、そういう分野があるということはご理解いただけたみたいですね。

例えば有限体積法なんかでごりごり連立一次方程式を解こうとすると、
最初にがーっとメモリを確保してそれを最後まで使い続けます。

HPCっていうそこそこ大きい市場もあるんだからそれほど特殊とはいえないと
思うんだけど。

連立一次方程式の解放ならそれほど複雑なメモリは取得しないけど、
コンパイラの構文木なんかをプロセス終了時にちまちま解体してたら
あほっぽいよね。

534 ：デフォルトの名無しさん：2013/01/20(日) 15:40:57.65

>>532
リプレイ？
相手の言い分は例外と決めつけるだけの単純な作業じゃん。
劣化コピーにもなっていない。

535 ：デフォルトの名無しさん：2013/01/20(日) 15:43:23.44

メモリプール使えでFA

536 ：デフォルトの名無しさん：2013/01/20(日) 15:48:56.83

>>531
KVストアなんて全部その類。ソースはキーワードさえわかればバカのお前でも検索できるだろ。

537 ：デフォルトの名無しさん：2013/01/20(日) 15:49:04.53

ねぇねぇ、ところで、ここにいるmallocしたぶんは絶対freeしなきゃだめ派の人って
ウィンドウ右上のペケボタンを押したときのexit処理の前にも全てのオブジェクトを
解放して回るの ?

538 ：デフォルトの名無しさん：2013/01/20(日) 15:53:52.15

シグナル喰らって異常終了する時もすべて解放しなきゃいけないらしいですよ。SIGKILLは使用説明書で禁止するのかな。
execveする時の為にスタティックな領域も用意しておいて、そこにコピーするんだって。

539 ：デフォルトの名無しさん：2013/01/20(日) 15:58:35.52

freeしないバカって、mtraceで試験すらしないからそんなこと
言えるんだろうな。品質悪そうだ。

540 ：デフォルトの名無しさん：2013/01/20(日) 16:00:36.46

>>533
それをいちいちページアウトされてしまうような環境で実行して、しかも
終了の時間が重要なんて状況はとても一般的とは言えんだろう。

541 ：デフォルトの名無しさん：2013/01/20(日) 16:06:45.33

>>537
KVM ?
ひょっとして KVS のことか？
KVM でも KVS でも良いんだが、「終了まで解放しない」と言うソースを出してみなよ。
どうせ「ぐぐればわかる」と言って逃げるんだろうけど。

542 ：デフォルトの名無しさん：2013/01/20(日) 16:14:00.79

>>537
そういうのは、ライブラリがやってくれるよ。たぶん。ほとんど待機しないですぐにとじたりする。
自分で用意したボタンをおしたときのほうがおそいことがある

543 ：デフォルトの名無しさん：2013/01/20(日) 16:20:04.81

「変更されています。保存しますか？」

544 ：デフォルトの名無しさん：2013/01/20(日) 16:20:54.74

>>537
今時 GUI アプリで malloc( ) , free( ) 使う方が特殊だと思うのは、俺だけか？

545 ：デフォルトの名無しさん：2013/01/20(日) 16:36:24.31

>>541
やっぱ、お前バカだ。ｗｗｗ
freeしたらどこにデータ持つんだよ。

546 ：デフォルトの名無しさん：2013/01/20(日) 16:42:05.56

>>545
はいはい、ごたくはいいからソース出してみなよ。

547 ：デフォルトの名無しさん：2013/01/20(日) 16:54:29.36

ほらよ
http://www.namazu.org/stable/namazu-2.0.21.tar.gz
http://embedded.eecs.berkeley.edu/pubs/downloads/spice/spice3f5.tar.gz
http://ftp.gnu.org/pub/gnu/emacs/emacs-24.2.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.8-rc4.tar.bz2 こいつは終了しても解放しない。ｗ

548 ：デフォルトの名無しさん：2013/01/20(日) 17:02:55.99

>>533
プロセス空間に散らばったメモリブロックをfreeして回るのに時間がかかると
いうことだったと思ったが？疎行列に特化したアルゴリズムならちまちま
メモリを確保してもおかしくないが、その場合、確保するばかりで増える
一方だとしたらなんか変だな。
コンパイラの構文木の方は、それこそコンパイル中に何度でも作っては
捨てるから廃棄ルーチンは当然書くと思うが？それをわさわさ終了時だけ
呼ばないとか不自然なことするか？

549 ：デフォルトの名無しさん：2013/01/20(日) 17:05:34.98

プロセス空間に散らばったメモリブロックをfreeして回るのに時間がかかることはないでしょう。

なぜなら、時間がかかるのであれば、対策しているはずだから。

freeが必要なのは、プロセス終了時だけではないのですよ？
アプリが起動している時にこそ、たくさんのfreeが行われてるはずです。

550 ：デフォルトの名無しさん：2013/01/20(日) 17:08:48.68

>>547
で、どれが「何GBもメモリ確保して終了まで開放しないようなアプリ」なんだ？
ついでに、どこから「終了」なのかも明示してくれ。

>>548
まあ、コンパイラの作り方にもよるけど、シンボル関係の管理表などは終了まで
追加するのみで廃棄しないこともありえる。

ただ、俺は知らないけど、何ＧＢものメモリを確保するらしいから、それは >>524
とかがソース付きで示してくれるんだろうよ (w

551 ：デフォルトの名無しさん：2013/01/20(日) 17:16:58.41

全部。ソース読めないのはお前の責任。解説してやろうか? 有料で。

552 ：デフォルトの名無しさん：2013/01/20(日) 17:17:49.83

namazは何Gまではいかんか。それは除外してもいいぞ。

553 ：デフォルトの名無しさん：2013/01/20(日) 17:18:45.10

>>551
> 解説してやろうか? 有料で。

解説できない言い訳乙 (w

554 ：デフォルトの名無しさん：2013/01/20(日) 17:20:55.07

free要らない厨があまりに素人丸出しでつまらない

555 ：デフォルトの名無しさん：2013/01/20(日) 17:22:12.41

ソース出せ必死になってて、出されたら読めねーでやんの。ｗｗｗ

556 ：デフォルトの名無しさん：2013/01/20(日) 17:23:06.89

金だしたら教えてやるって言ってるだろうが。

557 ：デフォルトの名無しさん：2013/01/20(日) 17:25:34.88

freeしないバグソースを得意げに出す>>547

558 ：デフォルトの名無しさん：2013/01/20(日) 17:27:06.30

メモリ何ギガなんて使ってなくともページアウトは発生するっしょ
XPまでのWindowsは、ウィンドウ最小化しただけでワーキングセット最小化するし

この辺読んだら
ttp://nyaruru.hatenablog.com/entries/2007/10/10

559 ：デフォルトの名無しさん：2013/01/20(日) 17:28:06.02

誰にでも理解できるように提示できないものはソースとは呼ばない。
さっさと出しなおせ。

560 ：デフォルトの名無しさん：2013/01/20(日) 17:29:51.37

>>550
emacsとspiceはexitが呼ばれるまで。
linuxはreboot()が呼ばれるまで。

561 ：デフォルトの名無しさん：2013/01/20(日) 17:30:35.81

>>559
バカには理解できないからそれは不可能。ｗｗ

562 ：デフォルトの名無しさん：2013/01/20(日) 17:31:22.46

>>561
自分がバカで出せないから不可能？
わかります。

563 ：デフォルトの名無しさん：2013/01/20(日) 17:33:24.62

>>561は適当にでかいファイル貼っただけだからファイル中のどの部分か提示できなくて内心ガクブルｗ

564 ：デフォルトの名無しさん：2013/01/20(日) 17:34:30.48

こういう説明を求められたときに逃げ出す人って
100%まったく理解していないよねｗ

565 ：デフォルトの名無しさん：2013/01/20(日) 17:35:43.89

freeしないとmtraceに怒られる。
だからfreeは必要。
はい論破ｗ

566 ：デフォルトの名無しさん：2013/01/20(日) 17:38:10.04

mtraceに限らずメモリリークチェックツールには怒られる
行儀の悪いプログラム書く奴ってそういうの使ったことないんだろ

567 ：デフォルトの名無しさん：2013/01/20(日) 17:39:56.79

読めもしないのにコード要求するな。バカｗｗｗ

568 ：デフォルトの名無しさん：2013/01/20(日) 17:52:09.18

>>567はどこのスレでも浮いてる人かな
メモリ検査には触れずに都合のいいレスにだけ食いつくような特徴ある行動する人

569 ：デフォルトの名無しさん：2013/01/20(日) 17:53:43.27

>>540
連立一次方程式の解法は最初から最後までメモリを確保したままの例で
ということで出しました。

連立一次方程式の解法はたしかに、物理メモリ上で
すむように計算の大きさを制御するけれど、
問題によっては、仮想記憶を使いたくなるようなシチュエーションも
出るのではないでしょうか ?

レアケースかも知れないけれど、存在するって言うことで、

で、仮想記憶を使わないとしても、俺の実際見ただけでも、数万回のmallocを
やってる例もあって、もっと細かいオブジェクトをたくさん使う分野なら、
何千万のオブジェクトをもっても不思議じゃないでしょ。

それを、exit前にちまちま回収する?（回収してすぐに廃棄）

freeはそんなに簡単な処理じゃなく、結構な時間がかかるんじゃないかな

終了の時間が重要じゃないってのは、そういうのはバッチファイル
でやるから、全体の実行時間が多少伸びても、コーヒーでも飲んどけ
ってこと ?

そうは言っても、無駄なものは無駄だよね。

あと、GUIをかませて、MicrosoftWordを使ってる機械で動くようさせられた
こともあります。
この場合、計算->ワードに書く->ページアウト->シミュレータを終了
するとexit前にfreeした場合、ページインが発生しますね。

570 ：デフォルトの名無しさん：2013/01/20(日) 17:54:36.86

>>566
「俺のコードはそんなツールじゃ判断できないぜ！」
「この糞コーディングルールは××の場合に○○だから完全じゃない。
俺はそんなルールに縛られないぜ！」
と言って、どうでもいいところの改善にこだわったりする。

571 ：デフォルトの名無しさん：2013/01/20(日) 17:54:50.50

そんなもんmtrace黙らせたいだけなら
#ifdef MTRACE
cleanup_things();
#endif
とでもすればいいだけじゃね

572 ：デフォルトの名無しさん：2013/01/20(日) 17:59:24.43

>>568は、>>523の敗北宣言って事でいいね。

573 ：デフォルトの名無しさん：2013/01/20(日) 17:59:31.81

>>571
これはひどい
怒られたとこは全部切っとけばおとなしくなるね
でもお願いだから君はプログラム組まないでね

574 ：デフォルトの名無しさん：2013/01/20(日) 17:59:50.86

ちなみに今は、ページアウトするような狭いメモリの中で
参照していない大きな領域をexit前にfreeするとページインが
発生して数ミリ秒程度処理が遅くなる、という話をしています。

どのみちexit処理でページインしてしまうんですけどね。

575 ：デフォルトの名無しさん：2013/01/20(日) 18:00:53.13

>>571
-Wallでwarningが出ないこと、って条件を付けたら
Makefileから-Wallを消した人に似ている。

576 ：デフォルトの名無しさん：2013/01/20(日) 18:01:19.00

> 参照していない大きな領域をexit前にfreeするとページインが
> 発生して

それが間違い。
その場合にページインは発生しない。

577 ：デフォルトの名無しさん：2013/01/20(日) 18:01:36.32

>>572
こいつ適当に別人のレスをつなぎ合わせて反論に困ったレスをなかったことにし始めたぞ

578 ：デフォルトの名無しさん：2013/01/20(日) 18:01:58.26

>>573
意味わかってる？
「切る」んじゃなくて、解放処理を＊全て＊実装して、cleanup()でそれを呼ぶ
ただしMTRACEが定義されているときだけ
mtraceでチェックしたいときはMTRACEを定義してコンパイルすればいい
MTRACEを未定義にすればそれは含まれないので、不要な解放処理を
リリース版から削除できる

579 ：デフォルトの名無しさん：2013/01/20(日) 18:02:27.11

理屈はファイルを削除するときに
ファイルを読みこまなくてもいいのと同じ。

580 ：デフォルトの名無しさん：2013/01/20(日) 18:03:19.02

>>578
つまり、freeを書く必要はある、ということを認めるわけですね。

581 ：デフォルトの名無しさん：2013/01/20(日) 18:03:28.81

>>578
意味わかってる？
constキャストと同じことだよそれ？

582 ：デフォルトの名無しさん：2013/01/20(日) 18:04:37.58

>>580
俺は別に俺はfree()を書くことに反対してないけど……

583 ：デフォルトの名無しさん：2013/01/20(日) 18:05:31.42

>>581
どこがどう同じなのかもう少し詳しく

584 ：デフォルトの名無しさん：2013/01/20(日) 18:05:42.72

void onDrow()
{
Rect* rc = new Rect(x, y, w, h); // freeしたら負けなので絶対しないこと
}

585 ：デフォルトの名無しさん：2013/01/20(日) 18:11:30.18

ああなんとなくわかった、>>581はただコンパイラ（など）を黙らせるためだけの
コードに嫌悪感を抱いてるのか

cleanup()を有効にした状態でプログラムが正常に動作しリークも検出されないなら
確保したリソースをきちんと追跡できていることは確認できるだろ
というか一定程度以上複雑なプログラムならプールでも使って、最後にプールを
削除するかしないか程度の差でしかない筈だが
(EmacsのようなLisp処理系ならガーベージコレクタを実装するわな）

586 ：デフォルトの名無しさん：2013/01/20(日) 18:27:09.29

うちの方だと物重視でバイナリが変わったらテストやり直しっていう文化がある

587 ：デフォルトの名無しさん：2013/01/20(日) 18:54:04.32

freeする派完全勝利！

588 ：デフォルトの名無しさん：2013/01/20(日) 18:55:57.25

free絶対必要派はmtraceを黙らせるためにexit()前にfreeを並べる
（終了のために解放処理を行う）と。

そういう人ならWindowのペケボタンを押したときのなんかの処理にも
freeが必要って言っても納得できる。

10年前のfjとこのスレの議論でfree絶対派（exit前でも回収する必要ないのに
わざわざfreeする派）の言うことで納得できたのは

1. mallocとfreeは対で使えと言っておかないと、freeが必要な場合でも
. freeしないど低脳が俺の周りにいるんだよ。無い頭使わずfreeしろ !!

2. mtraceを使うから。

なんだけど、あと他にあるかな ?

589 ：デフォルトの名無しさん：2013/01/20(日) 19:01:26.05

そもそも、mallocを持っているすべてのシステムで、
mallocされたメモリがプロセスの終了時に返却される保障はない。

590 ：デフォルトの名無しさん：2013/01/20(日) 19:09:53.41

ANSI Cのホスト環境で保証されている。
「保障」とか使ってるバカは知らなくてもしょうがないけどね。

591 ：デフォルトの名無しさん：2013/01/20(日) 19:12:57.22

>>588
だいたいいいと思うよ、ただ俺の場合、1.は「周りが低脳」というより
自分の頭も楽にするためだな。
どうでもいいことにこだわってわざわざプログラミング難しくして
どうすんの？って感じ。
本当に必要な要件にはそれなりの対応があるわけだし。

592 ：デフォルトの名無しさん：2013/01/20(日) 19:14:39.69

>>590
規格通りの環境しか使ったことない初心者は気楽でいいですね。

593 ：デフォルトの名無しさん：2013/01/20(日) 19:17:41.04

組み込みだと、libcに似た互換ぽい全然別の何か、が標準ライブラリだったりするからね。
わかって解放しない横着者はともかく、「規格です」とかいって解放しないバカが沸くから
必ず解放しなければならない、ということにしておいたほうが都合がいい。

594 ：デフォルトの名無しさん：2013/01/20(日) 19:19:08.24

>>592
規格外の超例外まで持ち出して必死ですねｗ

595 ：デフォルトの名無しさん：2013/01/20(日) 19:21:09.24

保障バカが必死に食いついてくる。ｗｗｗ

596 ：デフォルトの名無しさん：2013/01/20(日) 19:22:28.25

589からここまですべて自演

597 ：デフォルトの名無しさん：2013/01/20(日) 19:55:29.67

メンテ性？移植性？実装がめんどくせーそんなの知ったことじゃねーよ、買うのはエンドユーザでエンドユーザには
そんなことは関係ないんだよ。ユーザーの時間単価をなめるなと。
客先に急ぐときに終了が遅いソフトってスゲーイライラするのも知らないのか？
会社から与えられるPCが十分なスペックだとは限らないこともしらないのか？
「そんな会社に勤めるなよ」なんていう馬鹿がいそうな気がするが、作る側の論理？
自己満足でそんなことを強制されるなんてたまったもんじゃねーよ。

free()命の話を読んでいると、free()だけじゃなくほかにも無駄なことをやりすぎているような気がするんだよな。
fjの頃にもこんなスレッドがあったけれど、これだけPCの性能が上がっているにもかかわらず、しかもソフト自体の
機能はそれほど変わらないのに、なんで未だに速度面で不満があるものがたくさんあるんだ。

っていうのが両方の立場にいる俺の意見だな。

598 ：デフォルトの名無しさん：2013/01/20(日) 20:09:16.51

>>560
> emacsとspiceはexitが呼ばれるまで。

どこの exit( ) ？
まさか、一箇所しかないとか思ってないよね？

> linuxはreboot()が呼ばれるまで。

さすがにバカすぎるから、こっちは見逃してやるよ (w

599 ：デフォルトの名無しさん：2013/01/20(日) 20:56:08.58

>>598
560ではないんだが

> どこの exit( ) ？
> まさか、一箇所しかないとか思ってないよね？

一箇所でもあれば、freeせずにexitする場合も存在するということになるが

free絶対必要でemacs, spiceはその理念に則っているって言うなら
(598がそう言ってるかどうかは別として)全てのexit前にメモリの解放処理
が必要になってくるよ。

ぶっちゃけmtraceを公開しているGNUのプロダクトもexit前のfreeなんて
ほとんどやってないんじゃないの ?
だれか、確かめてよ << 他力本願

>> linuxはreboot()が呼ばれるまで。

> さすがにバカすぎるから、こっちは見逃してやるよ (w

結構、本質的な問題だと思うけど、
プロセスなりカーネルの動作なりが終了して、全てが白紙になる前に、
無駄なfreeをするのは必要かって議論でしょ ?

プロセスの終了とカーネルの終了のこの問題での本質的な違いはあるの ?

600 ：デフォルトの名無しさん：2013/01/20(日) 21:09:21.87

>>599
>>>598
> 一箇所でもあれば、freeせずにexitする場合も存在するということになるが

で、どれが「何GBもメモリ確保して終了まで開放しない」のって聞いてるんだけど、
理解してる？

>プロセスの終了とカーネルの終了のこの問題での本質的な違いはあるの ?

malloc( )/free( ) がどのレイヤーで実装されているか確認しようよ。

601 ：デフォルトの名無しさん：2013/01/20(日) 21:24:41.31

>>598
お前やっぱりバカ。ｗｗｗ
どこから呼ばれようとexit()は一つ

> さすがにバカすぎるから、こっちは見逃してやるよ (w
翻訳すると降参ってことね。

602 ：デフォルトの名無しさん：2013/01/20(日) 21:42:05.50

>>601
>どこから呼ばれようとexit()は一つ

翻訳すると降参ってことね (w

linux の方は、>>600 見てから書いてる？
見てないならまだしも、見てたら単なるアホになってるぞ。

603 ：デフォルトの名無しさん：2013/01/20(日) 21:42:38.27

>>601
バカは話に割り込んでくるな

604 ：デフォルトの名無しさん：2013/01/20(日) 22:06:38.75

>>603
おまえはsignalでも使って割り込んでろ

605 ：デフォルトの名無しさん：2013/01/20(日) 22:34:29.64

>>602
お前本当にバカなんだな。どこから呼ぼうとexitは一つなんだから、
exitを明示的/非明示的を問わず、呼んでるところのすべてって意味に決まってんだろ。
ここまで解説しなきゃわからない。バカには限界値が無いようだ。ｗｗｗ

> linux の方は、>>600 見てから書いてる？
> 見てないならまだしも、見てたら単なるアホになってるぞ。
kmalloc/kfreeはmalloc/freeじゃないってか? ｗｗｗバーカ。バーカ。バーカ。バーカ。

606 ：デフォルトの名無しさん：2013/01/20(日) 22:53:26.69

ついに壊れた (w

具体的に聞くとこういう返ししか出来ないところが、哀れだな。

607 ：デフォルトの名無しさん：2013/01/21(月) 00:24:55.01

幼稚園かここは

608 ：デフォルトの名無しさん：2013/01/21(月) 01:17:35.52

609 ：デフォルトの名無しさん：2013/01/21(月) 01:34:08.16

>>600

> > 一箇所でもあれば、freeせずにexitする場合も存在するということになるが
>
> で、どれが「何GBもメモリ確保して終了まで開放しない」のって聞いてるんだけど、
> 理解してる？

うーーん、それはソースを追ってみないことにはわからないけど、

少なくとも何GByteもメモリを確保したのを解放っていうコストが無い
（数10MByte分のコスト）場合ですら、exit前のreeを行わない、

コストは0ではない以上、全く得るものの無いexit前のfreeなんかを
行うことはただの無駄だという判断なんではないかな。

んで、数GByteという話は、あくまで悪い事例を挙げたもので
そんなコストがなくても無駄なコストを避けるって一例になるんでは
ないだろうか。

っていうか、常識的に、わざわざ時間のかかる数GByteの解放は
しこしこfreeするのに、数MByteの場合はそれを省略するなんて
考えられる ?

GNU Emacsの開発陣がfree絶対派だったら全てのexitの前にfree
してるって

610 ：デフォルトの名無しさん：2013/01/21(月) 01:50:54.48

死体に鞭打ってやるなよw
ここはひとつ線香の一本でも上げがてら名残り惜しんでやれよw

611 ：デフォルトの名無しさん：2013/01/21(月) 02:00:59.79

>>600

> >プロセスの終了とカーネルの終了のこの問題での本質的な違いはあるの ?
>
> malloc( )/free( ) がどのレイヤーで実装されているか確認しようよ。

ここで言ってる本質的って言うのは
再利用されることのないメモリをfreeなどの機構を使って、
再利用するために整理するかどうかっていうこと、

基本的にはfreeはOSから確保したメモリを再度mallocできるように、
整理することが目的で、別にOSにメモリを返すものではない。
（OpenBSDみたいにそういう実装もあるけど、どっちかというと特殊な部類）

malloc()/free()はアプリケーションのライブラリのレイヤーで実装されて
いるんだよね ?
sbrkやmmapでOSから確保したメモリを使いまわすためのライブラリで、
OSからはどんな感じでmalloc/freeを行われたかはわからないよね。

だから、OSから確保したメモリ全てをfreeして、全ての領域を再度malloc
できるようにした状態と、mallocしっぱなしの状態もOSにとっては
全く変わらないっていう認識は共有していると考えてよろしいでしょうか ?

なもんで、exit前のfreeは全くの無駄、どのくらい無駄かというと、
OSが電源切断の前に、RAMの中身を整理するぐらい無駄。

これが、本質的に変わらないでしょって書いた意味です。

612 ： ◆QZaw55cn4c ：2013/01/21(月) 02:29:02.87

そんなことでは、ちゃんとfree()できるけれどもしないのか、できないのかが区別つかないよね。
ダングリングやリークを起こさないという地震があるの？

>>50 でいいんじゃない？

613 ：デフォルトの名無しさん：2013/01/21(月) 12:10:19.27

>>588
たぶんだけど、必要と言ってる人は感覚的にそのように書いちゃうくせがもう出来上がってるから
端的に質問すると（書くもんだって反射的になるから）あんまよくないかもね

614 ：デフォルトの名無しさん：2013/01/21(月) 13:51:39.29

シグナルハンドラさえまともに実装できないウンコは引っ込んでろ。

615 ：デフォルトの名無しさん：2013/01/21(月) 20:13:54.62

atexitの関数内で全部freeしときゃok

616 ：デフォルトの名無しさん：2013/01/21(月) 20:16:13.03

シグナルがある環境、うらやましいです。

617 ：デフォルトの名無しさん：2013/01/21(月) 20:22:16.21

プロセスのある環境、うらやましいです。

618 ：デフォルトの名無しさん：2013/01/21(月) 20:30:45.04

mallocのある環境、うらやましいです。

619 ：デフォルトの名無しさん：2013/01/21(月) 23:54:41.28

freeいらないって言うのは相対性が崩れるのを気持ち悪いと感じる感性がないんだろうなとは思う

620 ：デフォルトの名無しさん：2013/01/22(火) 00:27:03.11

>>609
コスト最重要視するなら、アセンブラでゴリゴリ書けば？

もうそういう時代じゃないんだよ。

621 ：デフォルトの名無しさん：2013/01/22(火) 05:16:23.03

そもそもメモリを解放するコストは限りなく0に近いんだよ。

まずfree()を実行することでスワップインすることはない。

なぜなら、メモリを管理している領域と
メモリの実態は別だから。

メモリを管理している領域は頻繁に参照されるから
常にメモリに乗っている状態。

メモリのスピードは一般的なパソコンで
1GB/s～10GB/sでるんだから
どんなに効率悪いメモリの使い方をしていたとしても
アプリ終了の最後の一回に1秒未満の時間が加わるだけ。

622 ：デフォルトの名無しさん：2013/01/22(火) 08:39:33.94

>>621
それだと終了後に長い間ディスクアクセスがなんたらかんたらと言い出しかねんぞ

623 ：デフォルトの名無しさん：2013/01/22(火) 08:45:08.40

>>622
終了時にデータ保存するアプリかなんかだろ？

freeをやめたら、長いディスクアクセスが
なくなるというコードを持ってきたら
話聞いてやるよｗ

624 ：デフォルトの名無しさん：2013/01/22(火) 11:12:37.51

配列のポインタ配列みたいなデータ構造だと、
配列を解放するためにポインタ配列にアクセスしないといけない。
それがポインタを持ったリスト構造だったりした日には
解放する為にポインタを辿らねばならず、それ自体のコストが馬鹿にならない。
なので、コスト節約のためにfree()省略と言うのも判らんではない。

625 ：デフォルトの名無しさん：2013/01/22(火) 11:46:55.24

>>631
実装によっては、管理データはmallocが返したポインタの前にくっついてるじゃん。素人乙。

626 ：デフォルトの名無しさん：2013/01/22(火) 20:44:46.58

コード読めないバカがまたコード要求してる。ｗｗ

627 ：デフォルトの名無しさん：2013/01/22(火) 21:01:49.99

バカバカ言う奴が一番バカなんだよバカ
あっ

628 ：デフォルトの名無しさん：2013/01/22(火) 21:29:59.97

口だけが口挟んでる

629 ：デフォルトの名無しさん：2013/01/22(火) 21:33:14.56

>>624
ヒープの大半がページアウトした状況も含めて終了に要する時間が重要な
要件だったとしたら、そんな構造のデータを終了直前まで大量に保持してる
コードを書いてる時点でダメだろ。
アホなコードを書いたらアホな対策が有効(ただし効果は限定的)ってだけ。

630 ：デフォルトの名無しさん：2013/01/22(火) 21:58:59.95

なんでこいつら極端な例で遊んでんの？
一般的な例だと議論に持ち込めないから極端な設定でっちあげて優位に立ちたいんかね。

631 ：デフォルトの名無しさん：2013/01/22(火) 22:11:04.04

632 ：デフォルトの名無しさん：2013/01/22(火) 22:14:26.53

この例を最初に持ち出したのは河野真治だっけか？
本人は軽い気持ちで言ったんだろうが、まさか10年後に
まだ真に受けてる奴がいるとは思わなかったろうｗ

633 ：デフォルトの名無しさん：2013/01/22(火) 22:20:07.53

おまえら >>558 読めよ
Windows XPまたはそれ以前という糞OSではそれ全然「極端な例」じゃないから

634 ：デフォルトの名無しさん：2013/01/22(火) 22:26:28.73

fjの論争(10年前まで、fj終了してなかった事に驚き)とやらは知らんけど、
すぐ終了するのに解放処理書くの面倒だから書かねーんだよ。
工数は増える、バグが混入する可能性も増える。良い事はあまりない。

終了時に遅くなるなんてのはどうでもいい。

635 ：デフォルトの名無しさん：2013/01/22(火) 22:38:43.43

>>634
fjは、今でも細々ながら続いてるが？

636 ：デフォルトの名無しさん：2013/01/22(火) 22:54:34.42

>>633
それも長時間アクセスしない場合だろ？つまり、

・大量にメモリを抱えたまま長時間アクセスせず
・終了時にもfree以外にアクセスする必要はなく
・しかし終了に要する時間だけは重要

この3条件が揃って初めて成り立つ議論なわけだ。
そもそもWindowsだと、立ち上げたままのアプリを時間をおいて
操作するだけでディスクアクセスで一呼吸待たされたりするが、
終了時のページインのコストなんかにこだわってる人はそっちは
目をつぶるのかい？

637 ：デフォルトの名無しさん：2013/01/22(火) 23:05:37.88

>>636
>・しかし終了に要する時間だけは重要
誰もそんな話言ってないだろ、なんでそう曲解するんだか
少しでもベターなユーザエクスペリエンスを提供したいと考えるなら、
改善可能なところは改善したいと考えるもんじゃないのか
終了前のfree云々はあくまでその中の一つでしかな

638 ：デフォルトの名無しさん：2013/01/22(火) 23:16:13.28

どこを「ベター」にするのか、それをどのような手段で実現するのか、
そのポイントがずれてるんじゃないか？ってことだ。

639 ：デフォルトの名無しさん：2013/01/22(火) 23:26:16.83

終了時のfreeをなくしても
ユーザーエクスペリエンスの改善にはつながらない。
なぜなら、freeを無くすことで改善されるという
実証コードが存在しないから。

机上の空論、いつまで続けるの？

640 ：デフォルトの名無しさん：2013/01/22(火) 23:52:45.48

コード読めないバカが必死だな。
freeしない方はする方より確実に早い。違うというなら実証コード出してみろ。ｗ

641 ：デフォルトの名無しさん：2013/01/22(火) 23:53:37.50

コード読めないバカが必死だな。
freeしない方はする方より確実に速い。違うというなら実証コード出してみろ。ｗ

642 ：デフォルトの名無しさん：2013/01/22(火) 23:57:31.63

freewを消すことで速くなるという実証コードは
存在しないからだしようがないでしょ？

まあ普通にfree消しても何も変わらなかったとだけは言っておく。
コード欲しい？

int main() {
　void *ptr = malloc(ものすごく大きい値);
　/* free(ptr); */
　return 0
}

これだけだけどね。free入れても入れなくても変わんない。

643 ：デフォルトの名無しさん：2013/01/23(水) 00:11:35.63

>>640
直近20レスくらいプリントアウトしたものを近くの人に見せて、
「この中でバカは誰？」って訊いてみるといいぞ。

644 ：デフォルトの名無しさん：2013/01/23(水) 00:28:17.60

聞いてみたら、「これ見みてどうしろと？」って言われた。
どうすればいい？ >>643

645 ：デフォルトの名無しさん：2013/01/23(水) 00:56:25.98

自分のレスの馬鹿っぽさを客観視してみろという皮肉だったんだが、
本当にやったのか。そりゃ訊かれた人も困ったろう。

646 ：デフォルトの名無しさん：2013/01/23(水) 01:23:42.04

ほらよ、遅くなる「コード」だ。バカには読めないかもな。
$ time ./baka 1
4.43 real 4.02 user 0.40 sys
$ time ./baka
1.71 real 1.57 user 0.13 sys

#include <stdlib.h>
struct l {
struct l *next;
int data;
} *root = NULL;

void free_l(struct l *p)
{
if (p->next)
free_l(p->next);
free(p);
}

int main(int argc, char **argv)
{
unsigned long i;
for (i = 0; i < 10000000; i++) {
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;
}
if (argc > 1)
free_l(root);
return 0;
}

647 ：デフォルトの名無しさん：2013/01/23(水) 01:53:54.10

mallocした領域の生存期間の話じゃないの？
単純実行した速度の話はまた、別の話題のような？

648 ：デフォルトの名無しさん：2013/01/23(水) 03:10:03.72

>>646
ほとんどが再帰呼び出しのコストだな。

10000000段ものコールスタック
いったいスタックどれくらい消費するつもりだよｗ

649 ：デフォルトの名無しさん：2013/01/23(水) 07:38:22.36

>>648
別に再帰をループに書き直しても速度差はあるけど？

650 ：デフォルトの名無しさん：2013/01/23(水) 07:58:16.68

> ほとんどが再帰呼び出しのコストだな。
こんなに簡単に引っかかるとは、清々しいほどのバカだな。ｗ
「再帰呼び出しは遅い」を意味も理解せず信心してるバカ。ｗｗ
正しくは「再帰呼び出しは繰り返しより遅い」だ。憶えとけ。バカ。ｗｗｗ
freeしない
1.70 real 1.57 user 0.12 sys
free再帰
4.39 real 4.00 user 0.39 sys
free繰り返し
3.79 real 3.66 user 0.12 sys
不要なfreeの為に実行速度もバグの入る可能性も高くなる実証コードだけど、バカには読めないかもね。
cb2f247135ebc373f737e1306a05563419cdcdee

651 ：デフォルトの名無しさん：2013/01/23(水) 09:04:21.45

freeの処理でバグの可能性が高くなるってところに決定的な認識の違いが現れてるな。
破棄するときのことを考えずに書いて後でハマるパターンだろ。
オブジェクトの生成破棄なんてどこでも必要になるんだから定形的に書いておけば
いいのに、いちいち「この場合は必要、この場合は不要」なんてやってるから
余計なバグを増やすんだと思うぞ。

652 ：デフォルトの名無しさん：2013/01/23(水) 09:25:12.87

ライブラリ使うだけの簡単なお仕事しかやらないバカにはわからない。

終了直前にfreeするためだけに、不要なデータ構造にして、不要なコード書いて、
バグ作りこむ可能性を高くする。

バカのやる事。

653 ：デフォルトの名無しさん：2013/01/23(水) 09:55:36.71

わけもわからず、楽？しようとするからじゃね
初心者脱出できねえのは

654 ：デフォルトの名無しさん：2013/01/23(水) 12:50:06.99

>>642
> int main() {
> 　void *ptr = malloc(ものすごく大きい値);
> 　/* free(ptr); */
> 　return 0
> }

実際にアクセスしないと何も起きないんじゃないの？

size_t ss = ものすごく大きい値;
unsigned char *ptr = (unsigned char)malloc(ss);
for(int i=0; i<ss; i+=12345) ptr[i] = (unsigned char)(i % 256);
/* free(ptr); */

みたいにしたら?

655 ：デフォルトの名無しさん：2013/01/23(水) 14:38:59.16

>>652
> 終了直前にfreeするためだけに、不要なデータ構造にして、不要なコード書いて
もう何言ってるか、自分でも分かってないだろ？
ただ口答えしたいためだけに、屁理屈つけてゴネてるとしか見えん

656 ：デフォルトの名無しさん：2013/01/23(水) 15:53:40.68

コード読めないだけじゃなく、日本語すら読めない。バカ。ｗｗｗ

657 ：デフォルトの名無しさん：2013/01/23(水) 18:46:12.46

どうでもいいけど
freeしたらバグ増える
なんて言っているバカとは仕事したくないな

658 ：デフォルトの名無しさん：2013/01/23(水) 19:33:33.05

コードを書けば0以上の確率でバグが紛れ込む。
解放処理だけは特別とか考えるバカは死んだ方がいい。

659 ：デフォルトの名無しさん：2013/01/23(水) 19:39:52.47

いや、freeしない設計は認めるけど
freeしたらバグるってのは設計できていない証だから

660 ：デフォルトの名無しさん：2013/01/23(水) 19:42:39.75

>>658
解放処理でバグがでるのは、獲得した領域の扱いそのもののミスなのでかなり致命的。
解放処理でバグが出るやつのソースはすべてにおいて信頼できないクズソースであると認識すべし。

661 ：デフォルトの名無しさん：2013/01/23(水) 20:42:13.06

なるほど、バグが怖いからfreeしないわけか
freeいらない派が低脳な理由がわかったよ

・int dummy[100]; // これがあるとなぜか上手く動く
・//free(p); // これをやると上手く動かないからコメントアウト

662 ：デフォルトの名無しさん：2013/01/23(水) 20:45:08.57

freeしないって人のプログラムは領域破壊なんて当たり前、
くらいに思っていたほうがよさそうだな。
要は動けばＯＫの人たちということが分かった。

663 ：デフォルトの名無しさん：2013/01/23(水) 21:03:54.11

当然SIGKILLも捕まえてfreeしてるんですよね？

664 ：デフォルトの名無しさん：2013/01/23(水) 21:10:24.13

>>659-660
バグを0に出来る設計。ｗｗｗｗ
天才現る。ｗｗｗｗ

665 ：デフォルトの名無しさん：2013/01/23(水) 21:11:13.50

でたよ、free派なら強制終了されてんのにfreeするんだろ？ってやつ。
正常系の終了と異常系の終了の区別も付けられないんだなfreeいらない派

666 ：デフォルトの名無しさん：2013/01/23(水) 21:11:46.66

むしろfreeのバグを0にできない無能はPGやめて農業でもやってるべき。

667 ：デフォルトの名無しさん：2013/01/23(水) 21:13:27.63

>>666
そんな奴が農業やったら作付で領域破壊ｗ

668 ：デフォルトの名無しさん：2013/01/23(水) 21:16:29.09

知能が足りないバカが>>661のような勘違いしてるようだから念のために言っとくけど、
freeしない設計とは>>646でいえばfree_l()が不要になるという事だからな。

669 ：デフォルトの名無しさん：2013/01/23(水) 21:16:56.06

freeでバグる人は、
図書館で本借りても、
返す時に間違えて別の本返しちゃうかもしれないから
返さないで借りパクしちゃうの？

670 ：デフォルトの名無しさん：2013/01/23(水) 21:18:27.88

>>668はsageる知能がないようだが？

671 ：デフォルトの名無しさん：2013/01/23(水) 21:19:33.14

>>669
バカのたとえはたとえになっていない。ｗｗｗ
OSがまとめて回収する機能は図書館で言うとどういう仕組みに該当するんだ? ｗｗｗ

672 ：デフォルトの名無しさん：2013/01/23(水) 21:20:04.18

>>669
どうせ督促状来るからそれまでいいやと開き直るタイプらしい

673 ：デフォルトの名無しさん：2013/01/23(水) 21:20:05.08

>>668
free_lを呼ばないとmtraceが怒るので、検収に通りません。

674 ：デフォルトの名無しさん：2013/01/23(水) 21:20:29.27

>>670
お前らのようなバカは晒しアゲが必定。

675 ：デフォルトの名無しさん：2013/01/23(水) 21:21:09.79

>>671
司書さんが自宅を襲撃します。

676 ：デフォルトの名無しさん：2013/01/23(水) 21:21:31.00

まともなプロジェクトで働いたことないんだと思う。

677 ：デフォルトの名無しさん：2013/01/23(水) 21:21:37.86

>>665
SIGKILLじゃなかったらシグナル捕まえてfreeしてるんですね

678 ：デフォルトの名無しさん：2013/01/23(水) 21:22:25.01

>>674
バカ晒しあげ

679 ：デフォルトの名無しさん：2013/01/23(水) 21:27:00.51

>>671
>OSがまとめて回収する機能は図書館で言うと

行政破たんによる図書館の廃止

680 ：デフォルトの名無しさん：2013/01/23(水) 21:28:53.53

>>673
でた、ツールの奴隷。ｗｗ
本末転倒って言葉を知らないんだろうな。ｗｗ

681 ：デフォルトの名無しさん：2013/01/23(水) 21:30:34.90

>>680
メモリリークや破壊がないことの証明に苦しんだことのない
アマチュアの言い分だな

682 ：デフォルトの名無しさん：2013/01/23(水) 21:31:47.45

GC使えるなら使っときゃいいやん

683 ：デフォルトの名無しさん：2013/01/23(水) 21:31:56.47

>>663
なんでSIGKILLｗ
SIGTERMなら捕まえることはあるよ。サーバーを安全に停止させるためとか。

684 ：デフォルトの名無しさん：2013/01/23(水) 21:32:20.39

>>680
プログラミングごっこではあまり使わないかもねｗ

685 ：デフォルトの名無しさん：2013/01/23(水) 21:35:27.85

mtraceごときでメモリリークや破壊がない証明とかｗ
それこそアマチュアレベルｗｗ

686 ：デフォルトの名無しさん：2013/01/23(水) 21:38:17.83

freeの処理でバグの可能性があるとか言ってたくせに、大きく出たなｗ

687 ：デフォルトの名無しさん：2013/01/23(水) 21:42:09.08

>>682
>>1
>前提１：一般的なC言語（GC搭載していない）

688 ：デフォルトの名無しさん：2013/01/23(水) 21:43:31.63

>>680
バカ晒しあげ

689 ：デフォルトの名無しさん：2013/01/23(水) 21:43:32.86

>>669
本の中身を領域破壊でめちゃくちゃにしてるので
返したくても返せません。

690 ： ◆QZaw55cn4c ：2013/01/23(水) 21:46:47.70

>>666
そうそう自前でラッパを書けばいいこと。バグが怖いからfree()しないって？爆笑

691 ：デフォルトの名無しさん：2013/01/23(水) 21:48:29.60

>>690
ラッパ書いて自分でメモリ管理作っちゃう人ですか？

692 ：デフォルトの名無しさん：2013/01/23(水) 22:01:14.57

シグナル処理も満足に書けないチンカスは引っ込んでいなさい。バグ絶賛放置中だろ。ｗｗｗ

693 ：デフォルトの名無しさん：2013/01/23(水) 22:02:25.86

草生やしの猿一匹が必死だこと

694 ：デフォルトの名無しさん：2013/01/23(水) 22:03:53.16

>>692
freeを満足に書けない人ｗ

695 ：デフォルトの名無しさん：2013/01/23(水) 22:07:53.19

>>692

696 ：デフォルトの名無しさん：2013/01/23(水) 22:09:27.02

経験則だとデータの削除はデータの挿入に比して1.0-1.3倍複雑。
free楽勝とか言ってるバカはおもちゃプログラムしか書いたことないんだろ。ｗｗｗ

697 ：デフォルトの名無しさん：2013/01/23(水) 22:12:56.26

経験則によるとオナリストの作ったデータの削除はデータの挿入に比して1.0-1.3倍複雑
free複雑とか言っているバカは単なるオナニー野郎

698 ：デフォルトの名無しさん：2013/01/23(水) 22:14:49.98

データの挿入が作れるのに削除が複雑とか、脳みそ足りてないんじゃないか？

699 ：デフォルトの名無しさん：2013/01/23(水) 22:16:32.58

芝生やすのに一生懸命になりすぎてデータ構造とアルゴリズムの勉強不足だな

700 ：デフォルトの名無しさん：2013/01/23(水) 22:17:36.29

連結リスト構造の解放処理でダブルポインタが出てきて処理が理解できない人？

701 ：デフォルトの名無しさん：2013/01/23(水) 22:19:01.38

まさかのfreeいらない派ポインタを使いこなせない説ｗｗｗ

702 ：デフォルトの名無しさん：2013/01/23(水) 22:20:35.49

>>700
わかるわ～それ

703 ：デフォルトの名無しさん：2013/01/23(水) 22:20:38.92

>>696

704 ：デフォルトの名無しさん：2013/01/23(水) 22:22:54.90

>>700
連結リストでダブルポインタとか素人かよｗｗｗ

705 ：デフォルトの名無しさん：2013/01/23(水) 22:24:46.41

ポインタの理解が微妙でfreeするとバグるから
freeいらないっていう主張だったとは。

706 ：デフォルトの名無しさん：2013/01/23(水) 22:27:57.47

>>683
> SIGTERMなら捕まえることはあるよ。サーバーを安全に停止させるためとか。

もちろん安全に停止させるためにfreeしたんですよね？

707 ：デフォルトの名無しさん：2013/01/23(水) 22:36:37.47

でた～、言い逃れできなくなると話しそらす奴

708 ：デフォルトの名無しさん：2013/01/23(水) 22:38:11.42

>>706
メインスレッド側でね。ハンドラはフラグ立てるだけ。

709 ：デフォルトの名無しさん：2013/01/23(水) 22:43:24.89

ダブルポインタ? double *の事か? ｗｗｗ
そういえばQzとかいうチンカスがこの意味不明な用語使ってたな。ｗｗｗ

710 ：デフォルトの名無しさん：2013/01/23(水) 22:46:35.40

＞ダブルポインタ? double *の事か? ｗｗｗ
＞ダブルポインタ? double *の事か? ｗｗｗ
＞ダブルポインタ? double *の事か? ｗｗｗ

711 ：デフォルトの名無しさん：2013/01/23(水) 22:46:46.52

さすがにその話のそらし方は苦しすぎるｗ

712 ：デフォルトの名無しさん：2013/01/23(水) 22:48:39.58

double pointersでもpointer to pointerでもいいけど

ポインタの理解が微妙でfreeするとバグるから
freeいらないっていう主張だったとは。

の事実からは逃れられない

713 ：デフォルトの名無しさん：2013/01/23(水) 22:49:26.96

ダブルポインタってこのチンカス以外で使ってるバカにあった事ないけど、
底辺ではふつうに使う用語なのか? ｗｗｗ

714 ：デフォルトの名無しさん：2013/01/23(水) 22:50:36.57

>>712
とびっきりのバカだな。ｗｗｗ

715 ：デフォルトの名無しさん：2013/01/23(水) 22:50:43.02

まさか、「ポインタのポインタ」とか言ってるわけないよね！？

716 ：デフォルトの名無しさん：2013/01/23(水) 22:51:48.35

ｗｗｗの人の残りライフの少なさを感じる。。。

717 ：デフォルトの名無しさん：2013/01/23(水) 22:56:06.79

>>713
お前の俺用語を公開しろよ

718 ：デフォルトの名無しさん：2013/01/23(水) 22:58:59.98

「ポインポイン」に決まってるだろｗｗｗ

719 ：デフォルトの名無しさん：2013/01/23(水) 23:13:16.63

>>715
規格書にもそう書いてあるが、底辺じゃダブルポインタと呼んでるのか。
底辺向けの書籍にでも書いてあるのか? ｗｗｗ
なんて書籍だ?

720 ：デフォルトの名無しさん：2013/01/23(水) 23:16:44.72

話題を逸らすのに必死ですｗ

721 ：デフォルトの名無しさん：2013/01/23(水) 23:18:30.19

解放処理が簡単とか豪語してるバカは>>646の3行より簡単に書いて見せろよ。ｗｗｗ
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;

722 ：デフォルトの名無しさん：2013/01/23(水) 23:19:13.83

>>720
で、どの底辺書籍にそう書いてあるんだ? ｗｗｗ

723 ：デフォルトの名無しさん：2013/01/24(木) 00:01:40.88

＝ただいま草男必死中＝

724 ：デフォルトの名無しさん：2013/01/24(木) 00:47:00.03

そうか、freeのバグ怖いか。
なら確保・解放の個数を減らせばいい。

例えば int型[12][34] 配列を確保・解放する場合…
int i, **d;
だとして、
d = (int **) malloc(sizeof(int *) * 12);
for (i = 0; i < 12; i++) d[i] = (int *) malloc(sizeof(int) * 34);
; // use d[][]; …
for (i = 11; i >= 0; i--) free(d[i]);
free(d);
じゃなくて
d = (int **) malloc(sizeof(int *) * 12);
d[0] = (int *) malloc(sizeof(int) * 12 * 34);
for (i = 1; i < 12; i++) d[i] = &d[0][i * 34];
; // use d[][]; …
free(d[0]);
free(d);
とする。

725 ：デフォルトの名無しさん：2013/01/24(木) 07:40:21.23

>>691
malloc/freeの無い環境ならやるかも

726 ：デフォルトの名無しさん：2013/01/24(木) 08:30:01.55

蜘蛛の子を散らすようにバカどもが逃げ出したな。ｗｗｗｗ

* 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
* 解放処理楽勝と豪語しているバカは下の確保処理より簡単に書け。
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;

バカだから出来るわけないよね。ｗｗｗ

727 ：デフォルトの名無しさん：2013/01/24(木) 08:32:20.36

>>724
バカは問題設定すらまともにできないらしい。ｗｗｗ

> 例えば int型[12][34] 配列を確保・解放する場合…
自分で設定した仕様に対し

> d = (int **) malloc(sizeof(int *) * 12);
> for (i = 0; i < 12; i++) d[i] = (int *) malloc(sizeof(int) * 34);
既に仕様通りに出来ていない。ｗｗｗ
さすが底辺。ｗｗｗｗ

728 ：724：2013/01/24(木) 20:14:58.53

>>727
× int型[12][34] 配列
○ [12][34]でアクセスしたいint型配列

で良いですか？

729 ：デフォルトの名無しさん：2013/01/24(木) 22:42:31.61

解放処理

for (struct l *p = root, *q; p; q = p, p = p->next, free(q));

730 ：デフォルトの名無しさん：2013/01/25(金) 09:01:27.69

>>728
「free楽勝とか言ってるのは、C言語を知らないバカな初心者です」という事を示す自爆レスか。
バカ哀れ。ｗｗｗｗｗｗｗｗｗ

int (*d)[12][34] = malloc(sizeof(*d));
こっちの方が遥かに簡潔だろう。ｗｗｗｗｗｗｗｗｗｗｗｗ

>>729
;で区切らず,で区切れば簡潔。ｗｗｗｗ小学生並みの浅知恵ｗｗｗｗｗｗｗｗｗ

731 ：728：2013/01/25(金) 20:22:06.21

>>730
半信半疑だったけどやってみたら、、、
ttp://ideone.com/VmS6al
久しぶりに勃起した。
mallocの後にfree最高。

732 ：デフォルトの名無しさん：2013/01/25(金) 21:25:02.66

なに的外れな実験してんだよ。バカｗｗｗｗ
文法的に正しい事の検証にしかなってねーだろせめてアドレス出力しなきゃ意味ねーｗｗｗｗ
あっ「free楽勝はバカの寝言」を実証する自爆レスかｗｗｗ

試しに二次元配列 mallocでぐぐったら1ページ目(1-10番)のうち8個アウト。ｗｗｗ
正解は3位のhttp://d.hatena.ne.jp/tondol/20090713/1247426321と
6位のhttp://www.staff.ftokai-u.ac.jp/~miyakawa/lecture/2007/prog3/12/9/ だけｗｗｗｗ

でも6位は「ダブルポインタ」ｗｗｗｗｗ
いくら(ポインタのポインタ)つきでも教員が使うな。ｗｗｗ東海大出だからしょうがないか。ｗｗｗ

しかし、上位10位で
for (i = 1; i < 12; i++) d[i] = &d[0][i * 34];
使ってるのが多い。誰が流行らしたんだ? 最初に使いだしたバカ。死んでしまえ。ｗｗｗ

733 ：デフォルトの名無しさん：2013/01/25(金) 21:49:43.43

>730
配列の要素数があらかじめ分かっていないと使えない方法
さすがに>727はメモリ確保が多すぎてメモリが細切れになりそう(本来なら一度の確保で十分)

>731
式と演算子を理解していれば、あたり前田のクラッカー

734 ：デフォルトの名無しさん：2013/01/25(金) 22:44:11.60

答みてから知ったかするバカが現れた。ｗｗｗ
このスレのバカ召喚性能は異常。ｗｗｗ

> 配列の要素数があらかじめ分かっていないと使えない方法
お題通りに整数で書いたけど、この知ったかバカは可変長配列知らないらしい。ｗｗｗｗ
それともC89を未だに使い続けている原始人ですか? ｗｗｗ

735 ：デフォルトの名無しさん：2013/01/25(金) 23:00:16.03

可変長配列は知っているよ
C99から使えるようになった
一部のコンパイラでは拡張機能として使えたけど

もちろんC89をいまだに使いつづけている原始人ですが何か
gccのフラグは-ansi -std=c89 -pedanticですが何か
-ansiと-pedanticは不要だけどね何か

736 ：デフォルトの名無しさん：2013/01/25(金) 23:08:06.88

>734
前半について、何のことかと思い>732のURLを見たが両方共だめなやり方しか紹介されていない
少なくとも僕が一度の確保で十分と言った方法ではない

いやー、最近はポインタもまともに扱えない人が多いな

737 ：デフォルトの名無しさん：2013/01/25(金) 23:14:08.94

> gccのフラグは-ansi -std=c89 -pedanticですが何か
Linuxや*BSDのカーネルいじれないポンコツｗｗｗ

後付けの言い訳は墓穴掘るだけだぞ。ｗｗｗ

738 ：デフォルトの名無しさん：2013/01/25(金) 23:18:59.80

レスすら追えないバカ。ｗｗｗ
> 少なくとも僕が一度の確保で十分と言った方法ではない

それはひょっとしてバカ(>>724)が「じゃなくて」って言った方か? ｗｗｗ

739 ：デフォルトの名無しさん：2013/01/25(金) 23:22:30.94

心配されなくてもカーネルは専門家に任せて、その上で動くソフトウェアを作るだけだから問題ないんだよ
ひさしぶりに規格ガチ準拠スレの興奮を思い出した

740 ：デフォルトの名無しさん：2013/01/25(金) 23:30:49.30

>738
いや、それは2度確保しているから両方共だめだろ
まぁ、考え方は「じゃなくて」に近いかな

741 ：デフォルトの名無しさん：2013/01/26(土) 00:27:02.84

64 bit Windows の開発ができないポンコツｗｗｗ
32 bitアプリで2Gまでのファイルしか扱えないポンコツｗｗｗ

742 ：デフォルトの名無しさん：2013/01/26(土) 01:35:25.06

#define free(P) malooc(P*0721)

743 ：デフォルトの名無しさん：2013/01/27(日) 01:13:52.26

freeいらない派＝バグが怖くてfreeできない無能の集まり

ということが証明されたのがよほど堪えているようだ。
一人レスを流そうと必死なのが涙を誘うｗ

744 ：デフォルトの名無しさん：2013/01/27(日) 01:43:13.40

証明されちゃったのは
free必須派 == freeなんか楽勝 == 実はバカ素人じゃん。ｗｗｗｗ

バカ必死。ｗｗｗｗ

745 ：デフォルトの名無しさん：2013/01/27(日) 01:46:43.81

free必須バカはまず以下に回答するように。ｗｗｗｗ

* 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
* 解放処理楽勝と豪語しているバカは下の確保処理より簡単に書け。
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;

バカだから出来るわけないよね。ｗｗｗ

746 ：デフォルトの名無しさん：2013/01/27(日) 01:59:06.21

>>744-745
バカ必死晒し

747 ：デフォルトの名無しさん：2013/01/27(日) 02:54:07.43

>>748
ああ、freeバカじゃなくてそれ以下のバカか。ｗｗｗ
別スレでも絡んできたバカだろｗｗｗ

748 ：デフォルトの名無しさん：2013/01/27(日) 04:10:08.88

いちいちfreeする奴は人生の敗北者

749 ：デフォルトの名無しさん：2013/01/27(日) 04:45:06.28

750 ： ◆QZaw55cn4c ：2013/01/27(日) 09:18:44.92

必死だねえ

751 ：デフォルトの名無しさん：2013/01/27(日) 09:33:34.85

教義の矛盾を指摘されても、必死で守ろうとバグ入りシグナル処理書いて満足してるチンカス。ｗｗｗ
素直にexitしとけばバグ作る事もないのに。ｗｗｗ
アマゾンギフト10万円分でバグ教えてあげるよ。ｗｗｗ

752 ： ◆QZaw55cn4c ：2013/01/27(日) 09:45:42.17

必死だねえ

753 ：デフォルトの名無しさん：2013/01/27(日) 10:14:33.96

freeの処理をかけないからfree不要とか小学生かよ。

754 ：デフォルトの名無しさん：2013/01/27(日) 10:24:11.13

>>753
お前もバカだろ。ｗｗｗｗ
(終了直前の)不要なfree処理を書いてバグの可能性を高くするのはバカのやる事といっている。
違いわかるかな? でもバカだからわからないよね。ｗｗｗｗ

うんこQzは目視で楽勝に発見できるバグをなおしてから出直しな。ｗｗｗ

755 ： ◆QZaw55cn4c ：2013/01/27(日) 10:27:07.61

そうそう、malloc()/free() にまつわる手順前後等のミスは自前でラッパを書いて検出につとめればいい。
バグが怖いからfree()しないって？爆笑

756 ：デフォルトの名無しさん：2013/01/27(日) 10:44:17.75

> そうそう、malloc()/free() にまつわる手順前後等のミスは自前でラッパを書いて検出につとめればいい。
あの誰にも相手にされてないうんこラッパの事か? ｗｗｗｗ
あの程度でバグを検出できると思ってるから、お前はダメなんだよ。ｗｗｗ

このレクチャーは無料で良いぞ。ｗｗｗ

757 ：デフォルトの名無しさん：2013/01/27(日) 11:38:05.28

要は「ｗｗｗ」の人は、連結リスト構造の解放処理がわかりません(T_T)
ってことなんだな。こんな単純な処理でバグを入れ込むとかｗｗｗ

まさにクズ人間ｗｗｗ

758 ：デフォルトの名無しさん：2013/01/27(日) 11:45:42.71

>>753
怖いからやらないレベルなので小学生どころか幼稚園児だな

759 ：デフォルトの名無しさん：2013/01/27(日) 12:39:10.10

freeバカがfree楽勝と豪語する根拠はデータ構造は連結リストしか使わないから。ｗｗｗ
それでもバカだからバグ作りこむんだよな。ｗｗｗｗ
freeバカ惨めｗｗｗｗ

760 ：デフォルトの名無しさん：2013/01/27(日) 12:54:39.65

>>759-760
バカとしか言えないバカ惨め (w

761 ：デフォルトの名無しさん：2013/01/27(日) 13:19:44.15

>>760
バカすぎる。ｗｗｗｗｗ

762 ：デフォルトの名無しさん：2013/01/27(日) 13:20:49.37

ここまで俺の自演

763 ：デフォルトの名無しさん：2013/01/27(日) 13:22:29.51

>>584
Drowって何やねん
Drawか

764 ：760：2013/01/27(日) 13:35:42.59

ああ、>>761 「も」追加しとくわ (w

765 ：デフォルトの名無しさん：2013/01/27(日) 13:46:06.87

free不要の人はK社のもしもし向けアプリ作れっていわれたら発狂するんだろうな

766 ：デフォルトの名無しさん：2013/01/27(日) 13:50:19.21

>>648
それを含めて解放のコストですけど。

樹状に作られたリンクが途中でくっついていたり、
ループしてたりすると解放も単純じゃないんだけど

で、それをちまちま解放していくのがめんどいから
mallocでごっそりメモリをとって、プログラムのほうで
メモリ管理をして、解放するときはまとめてfree

って、それってmmapでOSからメモリをとってきて
メモリ管理をしてくれるmalloc/freeとまったく同じことしてるじゃん
屋上屋を重ねるってまさにこのことだね

767 ：デフォルトの名無しさん：2013/01/27(日) 13:51:24.40

>>764
本日一番のバカ。ｗｗｗｗ

768 ：洒落のわからん馬鹿がいるな：2013/01/27(日) 14:03:13.81

>>767
>>767

769 ：デフォルトの名無しさん：2013/01/27(日) 14:07:13.49

>>638
終了時のfreeのみ問題にしているのは、
それ以外のfreeは確保した領域を再利用するための*必要な*freeだから
終了時のfreeはただ単純に無駄だから

まぁ、mtraceを通すためっていうのはわかる。

ただ、mtraceを通すためだけにfreeするのって
コンパイラを通すために○○するっていうのと精神に於いて変わらないような。

mtraceはここのmallocはfreeしなくてもいいですよって指示与える機能はないの ?

指示するよりfree書いちゃったほうが速いと言われるんだろうが

770 ：デフォルトの名無しさん：2013/01/27(日) 14:13:54.25

>766
言いたいことは分かるが
最後の一文は余計だな

同一関数内でmalloc()とfree()を呼ぶことはあまりないと思うんだよなぁ
lintさんはちゃっかり警告してくるけど
malloc()とfree()をラップするような、いわゆるオブジェクト指向をサポートする言語で言うところのコンストラクタとディストラクタを作っておけば開放漏れは防げるでしょ

再三、連結リストが話題に出ているけど、free()不要と言う人は、時間のかかるプロセスが要素を確保して、開放せずにまた別の要素を確保しつづけるの
プロセスがゾンビ化したらfree()とか関係ないけど

771 ：デフォルトの名無しさん：2013/01/27(日) 14:23:15.02

>>769
>ただ、mtraceを通すためだけにfreeするのって
>コンパイラを通すために○○するっていうのと精神に於いて変わらないような。

さすがにその理解力じゃ世の中渡るの辛いだろうな…

772 ：デフォルトの名無しさん：2013/01/27(日) 14:51:33.76

領域を使う処理を作ったら、常識に対になる解放する処理も
作るでしょ。それがデータ構造の設計。
コストの問題でプロセス終了前に解放を省くってのはあり得るけど、
解放処理がバグっているってのはあり得ない。正常系だしね。
それは実力が足りていないかテストが足りていないかの問題で、
プロセス終了前の解放を省くこととはまったくの無関係。

773 ： ◆QZaw55cn4c ：2013/01/27(日) 15:08:41.65

free()不要という人はバグが怖いからfree()しないんだそうですよ。
スレッドタイトルを見る限りは、プログラム終了直前のfree() を省くかどうかを問題にしているわけではないからねえ。

774 ：デフォルトの名無しさん：2013/01/27(日) 15:10:05.20

>>754
＞お前もバカだろ。ｗｗｗｗ

自分がバカという自覚はあるようですね？
早く反論しなくちゃとあせってミスするのが得意なようで。

775 ：デフォルトの名無しさん：2013/01/27(日) 15:41:44.16

>>773
主張を捻じ曲げる事でしか反論できなくなった。バカ。ｗｗｗｗ
目視で簡単に見破られるバグ乱発しなくなってから出直しな。

テメーのうんこプログラムのバグ片手以上は晒しあげた記憶があるぞ。ｗｗｗ
未だにシグナルハンドラバグ入りで絶賛放置中だろ。ｗｗｗ

>>774
お前日本語わからない。バカ。ｗｗｗ
異常なバカ召喚性能を誇るこのスレに召喚されたバカ共の一部という意味。ｗｗｗ
それより、お前「本日一番のバカ」だろ。↓こいつｗｗｗ

From: [760] デフォルトの名無しさん <sage>
Date: 2013/01/27(日) 12:54:39.65

>>759-760
バカとしか言えないバカ惨め (w

776 ：760: >>774 じゃねーし：2013/01/27(日) 15:46:11.96

>>775
> お前「本日一番のバカ」だろ。↓こいつｗｗｗ

ツボ突いたみたいだな (w

777 ：デフォルトの名無しさん：2013/01/27(日) 15:46:44.28

ラッキーセブンゲットだぜage

778 ：デフォルトの名無しさん：2013/01/27(日) 15:52:38.79

本日一番のバカｗｗｗ

From: [760] デフォルトの名無しさん <sage>
Date: 2013/01/27(日) 12:54:39.65

>>759-760
バカとしか言えないバカ惨め (w

779 ：デフォルトの名無しさん：2013/01/27(日) 15:57:35.04

>>778
>>776

780 ：デフォルトの名無しさん：2013/01/27(日) 15:58:54.59

本日一番のバカｗｗｗ

From: [760] デフォルトの名無しさん <sage>
Date: 2013/01/27(日) 12:54:39.65

>>759-760
バカとしか言えないバカ惨め (w

781 ：デフォルトの名無しさん：2013/01/27(日) 15:59:46.89

free不要派の提唱する文脈依存プログラミングとは？

// 起動時に一度しか呼ばれないと思って作った関数
void safe_func(){
　malloc(100000);
}

void onTick(){
　safe_func(); // 安全な関数だから何回呼んでも問題ないよね　まさか中でメモリ確保して放置してるわけがない
}

扱いに細心の注意が必要だった。

782 ：デフォルトの名無しさん：2013/01/27(日) 16:08:27.19

>>781
ああ、Win95か98で、アイコンかなんかの小さいGDIを解放していなくて
空きリソースが微妙に減っていってそのうちシステムが落ちるとかいう
バグを思い出した。

783 ：デフォルトの名無しさん：2013/01/27(日) 16:09:28.01

>>781
そんなことこのスレで言ってるのはバカのお前だけ。ｗｗｗ
またfreeバカの知能の低さが実証されてしまった。ｗｗｗｗ

784 ：デフォルトの名無しさん：2013/01/27(日) 16:10:40.90

>>782
Windows7でもGDIリークは健在で
2週間くらい再起動してないとexplorer.exeが上限の9999になるよ

785 ：デフォルトの名無しさん：2013/01/27(日) 16:11:22.69

>>783
プッ

786 ：デフォルトの名無しさん：2013/01/27(日) 16:12:35.77

草男（くさお）は本当にバカだな

787 ：デフォルトの名無しさん：2013/01/27(日) 16:12:40.69

理論的なこと言い合っていないで手を動かせよ
free()必要・不要とで実際にプログラム書いてみて、出来を判定すればそれで十分だろ
基準は、実効速度・バグの少なさ・保守性(可読性)とかにして

例えば、Linuxに標準で付いている/usr/share/dict/のwordsをケースインセンシティブに始めの一文字がブレークするごとに、単語の文字数が小さくASCII辞書順に別のファイルに出力するプログラムとか

788 ：デフォルトの名無しさん：2013/01/27(日) 16:34:21.76

>>646で既に書いているが。これより簡潔には書けないみたいだよ。ｗｗｗ

int main(int argc, char **argv)
{
unsigned long i;
for (i = 0; i < 10000000; i++) {
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;
}
// 何か処理

return 0;
}

789 ：デフォルトの名無しさん：2013/01/27(日) 16:37:01.42

ところで気になってしょうがないんだが、「ダブルポインタ」って
底辺用語使ってるC言語の解説書籍はあるのかないのかはっきりしろよ。>>700 ｗｗｗ

790 ：デフォルトの名無しさん：2013/01/27(日) 16:45:41.45

草男（くさお）は本当に必死だな

791 ：デフォルトの名無しさん：2013/01/27(日) 16:58:33.48

ダブルポインタｗｗｗｗ
ダブルポインタｗｗｗｗ
ダブルポインタｗｗｗｗ
ダブルポインタｗｗｗｗ
ダブルポインタｗｗｗｗ

792 ：デフォルトの名無しさん：2013/01/27(日) 17:16:32.10

>>790
まあ土日だからしょうがないわな

793 ：デフォルトの名無しさん：2013/01/27(日) 17:24:21.13

ダブルポインタの出典明らかにしろよ。バカ底辺ｗｗｗ

794 ：デフォルトの名無しさん：2013/01/27(日) 18:01:31.95

ぐぐればいくらでもでてくるが？

File I/O With Double Pointer?
http://www.cplusplus.com/forum/general/60351/

795 ： ◆QZaw55cn4c ：2013/01/27(日) 18:28:41.06

>>788
>>646
for (i = 0; i < 10000000; i++) { struct l *p = malloc(sizeof(struct l)); p->next = root; root = p; }

void free_l(struct l *p) {if (p->next) free_l(p->next); free(p); }

確保は線形的、解放は再帰的かいな？
あえて曲げてんのか？解放も普通に書けよ

>>794
いっぱいあるねえ
https://www.google.com/search?q=%22double+pointer%22+linux
約 9,060 件（0.13 秒）

796 ：デフォルトの名無しさん：2013/01/27(日) 18:44:34.55

>>794
困った時のぐぐる頼みｗｗｗ
だからお前は底辺なんだよｗｗｗ

797 ：デフォルトの名無しさん：2013/01/27(日) 18:48:32.59

>>795
ほんとバカだな。ｗｗｗ
実際にはこんなまとめて確保なんかしないだろ。ｗｗｗ
常識的には徐々に増えていくものだ。
簡潔な解放処理を例にあげただけだぞ。ｗｗｗ
そんなことも読み取れない底辺バカ。ｗｗｗ

798 ：デフォルトの名無しさん：2013/01/27(日) 18:49:17.96

>>796
根拠出したら反論できなくなってあせりだしたか
バカは大変だな

799 ：デフォルトの名無しさん：2013/01/27(日) 18:53:05.97

>>797
言いたいことも伝えられない発達障害のその脳ミソじゃ
コミュニケーション取れなくて生きるの辛いだろうな

とりあえず晒しとくか

800 ：デフォルトの名無しさん：2013/01/27(日) 18:54:09.19

ぐぐるが根拠になると思っているバカ底辺。ｗｗｗ
きちんと書籍になっているものを持って来いよ。ｗｗｗ

801 ：デフォルトの名無しさん：2013/01/27(日) 18:55:52.38

書籍になってない用語は認めん。
馬鹿じゃねーのばーか。

802 ：デフォルトの名無しさん：2013/01/27(日) 18:56:31.11

幼稚age

803 ：デフォルトの名無しさん：2013/01/27(日) 18:56:32.75

底辺の論文
参考書籍：ぐぐる検索

ｗｗｗ

804 ：デフォルトの名無しさん：2013/01/27(日) 19:00:20.19

自分で書籍をぐぐれないのか？だからぐぐることを根拠と認めないのか？

https://www.google.co.jp/search?tbm=bks&q="double+pointer"

Object-Oriented Programming With C++ 2ed - 77 ページ
books.google.co.jp/books?isbn=8120336704
Sarang - プレビュー
To access the variable using the double pointer,

Practical .net 2 and C# 2 - 420 ページ
books.google.co.jp/books?isbn=0976613220
Patrick Smacchia - 2006 - プレビュー - 他の版
Here, we talk of a double pointer. For example: long aLong = 98; long * pALong =

もうそろそろ土下座して謝る時が来たようだぜ？

805 ：デフォルトの名無しさん：2013/01/27(日) 19:02:16.40

うわ！

なんと1860件も書籍で使われてる例が見つかる！

これって重複ないのか？
検索結果プレビューを見る限り、
同じ本がリストアップされてないようにみえる。

うわっ！こんなに、書籍で使われてる！

806 ：デフォルトの名無しさん：2013/01/27(日) 19:02:36.94

くさおは根拠のない煽りしかできないからしゃーない

807 ：デフォルトの名無しさん：2013/01/27(日) 19:03:17.94

全部英語じゃんｗ日本語の書籍になってないものは認めん。

808 ：デフォルトの名無しさん：2013/01/27(日) 19:04:07.87

>>807
そこでなんで、"ダブルポインタ"で
日本語の書籍を調べようと思わんの？

809 ：デフォルトの名無しさん：2013/01/27(日) 19:04:21.86

>>801
お前はぐぐって出てさえすればどんな用語でも通用すると思ってんの？ｗｗｗ
底辺が適当に底辺用語を書いたのが拾われているだけかもしれんぞ。ｗｗｗ
まさかぐぐって出てきた用語を日常で使ってないよな。ｗｗｗ
２ちゃんねる語を日常で使うくらい恥ずかしいことだぞ。ｗｗｗ

810 ：デフォルトの名無しさん：2013/01/27(日) 19:05:32.35

>>809
ん？英語の書籍で使われてる用語は
普通に使われていると解釈していいでしょ？

土下座まだ？

811 ：デフォルトの名無しさん：2013/01/27(日) 19:05:40.41

>>804
底辺向けの娯楽書籍が引っかかっただけだぞ。ｗｗｗ
それらの書籍になんの権威があるんだ。ｗｗｗ

812 ：デフォルトの名無しさん：2013/01/27(日) 19:06:46.53

Object-Oriented Programming With C++は底辺向けの娯楽書籍だ！
中身見たから確かなことだよ。

http://www.amazon.co.jp/Object-Oriented-Programming-Kaleidoscope-Robert-Lafore/dp/0672323087

みろ、星すらついていない。

813 ：デフォルトの名無しさん：2013/01/27(日) 19:07:15.50

まさか根拠に自己出版レベルの娯楽書籍を持ち出すとか、
底辺バカはほんとにバカなんだな。ｗｗｗ

814 ：デフォルトの名無しさん：2013/01/27(日) 19:10:13.67

>>812
なんで、日本のamazonで調べるんだよｗ

Double pointerという用語がでてくる
「Object-Oriented Programming in C++ 」が
娯楽書籍かどうか、頭冷やしてよく考えてみろ。

https://www.google.co.jp/search?tbm=bks&q="double+pointer"
> Object-Oriented Programming With C++ 2ed - 77 ページ
> books.google.co.jp/books?isbn=8120336704
> Sarang - プレビュー
> To access the variable using the double pointer,

http://www.amazon.com/Object-Oriented-Programming-C-4th-Edition/dp/0672323087

815 ：デフォルトの名無しさん：2013/01/27(日) 19:12:43.83

底辺向けの書籍に底辺著者が書いていたってことだろ。ｗｗｗ
>>719の通り、規格書レベルではまだ見つけられないようだな。ｗｗｗ

816 ：デフォルトの名無しさん：2013/01/27(日) 19:13:32.29

今の時代はすごいな。
無限といってもいいほどある本の中から
使われてる証拠を簡単に見つけ出すことが出来るんだ。

本当の底辺はてーへんだなｗ

817 ：デフォルトの名無しさん：2013/01/27(日) 19:14:36.48

規格書にない用語を創造して使っている＝底辺バカ
この事実は揺るがない。ｗｗｗ

818 ： ◆QZaw55cn4c ：2013/01/27(日) 19:14:56.51

>>813
お前、amazon.com で買い物したことないのか？
http://www.amazon.com/Object-Oriented-Programming-C-4th-Edition/dp/0672323087/

819 ：デフォルトの名無しさん：2013/01/27(日) 19:22:08.62

作者誰かと思えばRobert Laforeさんじゃないですか。
これで認めないとかちょっと頭おかしいと思う。

それにこの本だけじゃなくて、1840冊も使用例が見つかってるのを
お忘れなく。

https://www.google.co.jp/search?tbm=bks&q="double+pointer"
書籍約 1,890 件（0.13 秒）

820 ： ◆QZaw55cn4c ：2013/01/27(日) 19:23:18.99

まあ「ダブルポインタ」といっても三重、四重なんてざらだしねえ。「トリプルポインタ」とかいわないしねえ。
free() 不要派＝バグが怖くてfree()ができない free() 不能派、であることがばれちゃったので他のそこはかとない根拠を求めて日夜努力しているのですね敬服の限りです

あとスレタイ読んでね。

821 ：デフォルトの名無しさん：2013/01/27(日) 19:25:33.39

洋書知らなくても、「ダブルポインタ」という用語は
オライリーの本でものってるといえば、
もう土下座するしか無いだろうね。

http://books.google.co.jp/books?id=v5OYlkt6uKYC&lpg=PA121&dq=%22double%20pointer%22&hl=ja&pg=PA121#v=onepage&q=%22double%20pointer%22&f=false
http://books.google.co.jp/books?id=HeQoWCQ_S9wC&lpg=PA141&dq=%22double%20pointer%22&hl=ja&pg=PA141#v=onepage&q=%22double%20pointer%22&f=false

822 ：デフォルトの名無しさん：2013/01/27(日) 19:26:35.34

検索することも出来ない、底辺をフルボッコｗｗｗ
楽しすぎｗｗｗ

823 ：デフォルトの名無しさん：2013/01/27(日) 19:29:08.82

>>821
オライリーｗｗｗ
底辺の間で結構人気があるらしいね。ｗｗｗ
でどこの規格書に由来しているの？ｗｗｗ

824 ：デフォルトの名無しさん：2013/01/27(日) 19:31:51.28

>>813
> まさか根拠に自己出版レベルの娯楽書籍を持ち出すとか、

「自己出版」なんて用語は認めんｗｗｗ

>>823
え？オライリー知らないの？そういうレベルの人だね。
「二重のポインタ」という言葉に規格書を要求するって
頭おかしいと思う。

825 ：デフォルトの名無しさん：2013/01/27(日) 19:35:43.42

俺はオライリーよりも頭がいいからな。
オライリーの本を神聖化してるのは底辺ぐらい。

826 ： ◆QZaw55cn4c ：2013/01/27(日) 19:36:06.71

慈悲出版だね、kindle ではお手軽にできるんだとか‥‥「私のデスマ体験」とかだったら売れるかなあ‥‥

827 ：デフォルトの名無しさん：2013/01/27(日) 19:37:59.63

>>825
オライリーよりも・・・頭がいい？
オライリーは人の名前じゃないよ。

828 ：デフォルトの名無しさん：2013/01/27(日) 19:52:58.47

おいおい。ｗｗｗ
両方ともCの専門書じゃないじゃん。ｗｗｗ

http://books.google.co.jp/books?id=v5OYlkt6uKYC&lpg=PA121&dq=%22double%20pointer%22&hl=ja&pg=PA121#v=onepage&q=%22double%20pointer%22&f=false
Using SQLite
http://books.google.co.jp/books?id=HeQoWCQ_S9wC&lpg=PA141&dq=%22double%20pointer%22&hl=ja&pg=PA141#v=onepage&q=%22double%20pointer%22&f=false
COM+ Programming with VisualBasic

まあ、ここら辺でも読むんだな。底辺どもｗｗｗ

http://wiki.answers.com/Q/What_are_double_pointers_in_C
Best Answer
There is no such thing as Double pointers in C, except in case you're referring to the declaration such as:
double *p;

But still, this should better be called as pointer to double.
Some people incorrectly call pointer-to-pointer as double pointer.

829 ：デフォルトの名無しさん：2013/01/27(日) 19:57:26.10

>>828
wiki answersを信用してどうするの？ｗ

830 ：デフォルトの名無しさん：2013/01/27(日) 20:00:44.44

wiki answersにはwiki answersで対抗すればいいのかな？

What is the use of double pointers in C?
http://wiki.answers.com/Q/What_is_the_use_of_double_pointers_in_C

A double pointer in C or C++ ...

int ** ppi;

831 ：828：2013/01/27(日) 20:03:07.86

>>829
wiki.answersしらんの？

wikipedia作った人が、wikipediaと同じ概念で作った
wikiと同じように信頼出来る、
だれでも投稿できるFAQシステムなんだけど？

832 ：デフォルトの名無しさん：2013/01/27(日) 20:13:36.54

>>828
その回答を書いた、 Avsharathってだれなん？
どれくらい権威がある人？

素人にしか見えないんだが、書籍に対抗させようと
してるぐらいだ、書籍以上の何かを
お前は示せるんだろう？

833 ：デフォルトの名無しさん：2013/01/27(日) 20:27:16.68

「ダブルポインタ」という誤用が主に底辺バカの間で使われている事は知っている。だから、
> * 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。

と言ったわけだが、C(C++でもいいけど)言語解説書籍が一つも出てこないな。
検索しか能の無いバカ底辺が必死で探して出てこないって事は、やっぱ無いんじゃないの。ｗｗｗ

834 ：デフォルトの名無しさん：2013/01/27(日) 21:03:08.39

言葉ってのは、誰かが作り出すこともあれば
自然と生まれることもあるんだよ。

間違った使い方（つまり正しい使い方が存在する）ものは誤用でいいが、
新しく生まれた言葉は誤用にはならない。

これだけ多くの本で使われてる言葉だ。
一体お前は何を求めているのだ？

835 ：デフォルトの名無しさん：2013/01/27(日) 21:05:04.08

ダブルポインタとはC言語の用語ではなく
ポインタがある言語共通のプログラミング用語だよ。

836 ：769：2013/01/27(日) 21:09:30.18

>>771
どいういうこと?
理解力のない自分に教えていただきたい。

終了直前のfreeの意義って
mtraceにで警告でないようにする、
社内規定がそうなっている、（上のK社のもしもし向けアプリの話とか)
以外にあるのかな ?

わかってて書くmtraceを通すためのfreeとそうでないコンパイラを通すための
○○ではわかってるかどうかがちがうというなら、書き方が悪かった。

837 ：デフォルトの名無しさん：2013/01/27(日) 21:20:24.08

NI GE TA

838 ：デフォルトの名無しさん：2013/01/27(日) 21:22:35.87

逃げてないしｗ
ダブルポインタって書いてある、底辺向け以外の本はまだ？
評価が高い本でも、底辺向け本はいくら集めても無駄だよ。

839 ：デフォルトの名無しさん：2013/01/27(日) 21:23:04.42

>>834
つまり、必死で探したけどなかったってわけね。ｗｗｗ

>>835
> ポインタがある言語共通のプログラミング用語だよ。
って、Cから派生した以外の言語でポインタのポインタが使えるのってどれだよ。

840 ：デフォルトの名無しさん：2013/01/27(日) 21:24:22.73

書いてある本が沢山見つかる
↓
評価が高い本にも書いてある。
↓
くやしい
↓
そんな本は全部糞だ。底辺向けの本なんだ。
↓
発作おさまる。

841 ：デフォルトの名無しさん：2013/01/27(日) 21:37:46.97

>>795
やっぱりヘボだ。ｗｗｗｗ
> 確保は線形的、解放は再帰的かいな？

確保時のforは列挙だろ。バカヘボ。ｗｗｗ
while (gets(s)) add_str(s, top);
論理的には同じ。これでadd_treeが再帰で書かれていても「確保は線形」とかいうのか? バカすぎるｗｗｗ

842 ：デフォルトの名無しさん：2013/01/27(日) 21:41:19.80

検索しか能がねーんだからとっとと↓これ探せよ。底辺バカ。ｗｗｗ
> * 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。

843 ：デフォルトの名無しさん：2013/01/27(日) 21:41:55.10

>>842

https://www.google.co.jp/search?tbm=bks&q="double+pointer"
> Object-Oriented Programming With C++ 2ed - 77 ページ
> books.google.co.jp/books?isbn=8120336704
> Sarang - プレビュー
> To access the variable using the double pointer,

844 ：デフォルトの名無しさん：2013/01/27(日) 21:50:15.12

>>843
> * 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
それOopの解説書。バカにはわからないらしい。ｗｗｗｗ

845 ：デフォルトの名無しさん：2013/01/27(日) 21:51:21.82

>>844
知ってるよｗわざとだよｗおせよーよw

Magnifying C - 333 ページ
http://books.google.co.jp/books?id=RHqV4aVheMYC&pg=PA333&dq=%22double+pointer%22&hl=ja&sa=X&ei=oCAFUfXBMM79lAXm7IGIAQ&ved=0CGoQ6AEwCg#v=onepage&q=%22double%20pointer%22&f=false

846 ：デフォルトの名無しさん：2013/01/27(日) 21:55:48.52

OOP（C++）の解説書に、ダブルポインタという用語が使われていた
↓
どうしよう！
↓
発作再開

847 ：デフォルトの名無しさん：2013/01/27(日) 21:58:11.33

これがアスペというやつか

848 ：デフォルトの名無しさん：2013/01/27(日) 22:03:46.26

>>845
著者この人? キミたちにぴったりの書籍みたいだね。いや人種差別するわけじゃないけどｗｗｗｗ
http://in.linkedin.com/pub/arpita-gopal/22/247/253

849 ：デフォルトの名無しさん：2013/01/27(日) 22:03:50.83

>>845
おせよーよって何語だよｗｗｗ

850 ：デフォルトの名無しさん：2013/01/27(日) 22:05:07.56

どんなにｗｗｗがスレを流そうとしても、
freeの処理がうまくつくれなくてバグりそうだからfreeいらないと
いっていた事実からは逃れられない！

851 ：デフォルトの名無しさん：2013/01/27(日) 22:08:06.07

>>850
いつそんな事いった? ねつ造すんじゃねーぞ。バカ。ｗｗｗｗ

852 ：デフォルトの名無しさん：2013/01/27(日) 22:11:09.32

「連結リスト構造の解放処理のダブルポインタ」が話題に出てきた瞬間から
顔真っ赤にして発狂してるのはなぜですか？
トラウマだからですか？理解できないからですか？

853 ：デフォルトの名無しさん：2013/01/27(日) 22:14:34.48

宿題ちゃんとやれよ。底辺バカ。ｗｗｗバカはもう忘れてるらしいから再掲してやる。ｗｗｗｗ

free必須バカはまず以下に回答するように。ｗｗｗｗ
* 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
* 解放処理楽勝と豪語しているバカは下の確保処理より簡単に書け。
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;

バカだから出来るわけないよね。ｗｗｗ

854 ：デフォルトの名無しさん：2013/01/27(日) 22:16:37.12

>>852
「ダブルポインタ」って言われて「double *」と勘違いして作って
怒られた経験があるんだよ。その時いくら規格書を持って反論しても
聞いてもらえなくて、俺のほうが全然優秀なのに笑いものにされてしまった
つらい過去があるんだよ。ｗｗｗ

855 ：デフォルトの名無しさん：2013/01/27(日) 22:17:40.67

>>852
「ダブルポインタ」は「ダブルポインタが無い言語は欠陥言語」とか言ってるバカがいて
その言葉を見るだけで腹がよじれるほど笑うので過剰反応になるのはしょうがない。ｗｗｗ

856 ：デフォルトの名無しさん：2013/01/27(日) 23:25:43.36

くさお得意の不利になるとうやむやにする作戦決行中
まあいいけどな

857 ：デフォルトの名無しさん：2013/01/27(日) 23:32:19.80

宿題も満足にできない癖に優位にたってると思ってんの? さすが底辺バカｗｗｗｗ
もう一回貼ってやるよ。宿題ちゃんとやれよ。底辺バカ。ｗｗｗ

free必須バカはまず以下に回答するように。ｗｗｗｗ
* 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
* 解放処理楽勝と豪語しているバカは下の確保処理より簡単に書け。
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;

バカだから出来るわけないよね。ｗｗｗ

858 ：デフォルトの名無しさん：2013/01/27(日) 23:45:37.13

ﾜﾗ

859 ：デフォルトの名無しさん：2013/01/28(月) 00:04:56.97

fjのときよりひどい気がする。
人間の進歩って難しいね。

860 ：デフォルトの名無しさん：2013/01/28(月) 00:29:03.94

可哀想になって>>856が譲歩してまぁいいけどなと言ってるのに
自分で墓穴堀り返すのは趣味なのか

861 ：デフォルトの名無しさん：2013/01/28(月) 00:32:10.36

当然、リスト構造を丸ごと削除する処理は関数にするんだよな？
「短く書け」だから速度も要求してないようだし、2行で書けるんでないか

void free_l(struct l *p) {
if(p && p->next) free_l(p->next);
else free(p);
}

862 ：デフォルトの名無しさん：2013/01/28(月) 00:32:56.53

ごめん間違えたバグってるわwwwww

863 ： ◆QZaw55cn4c ：2013/01/28(月) 00:56:32.29

>>855
まあ、もともとの主張は「java に参照渡しが存在しないのは致命的だ」なんですけれどもねえ。
http://toro.2ch.net/test/read.cgi/tech/1313183984/403

864 ：デフォルトの名無しさん：2013/01/28(月) 00:59:34.31

>>862
elseワロタ

865 ： ◆QZaw55cn4c ：2013/01/28(月) 01:00:10.22

>>841
列挙的だろーが線形的だろーが意味するところはおんなじだろう？
言葉尻を捕らえて差異があるかのように大騒ぎするのはもうやめようね

866 ：デフォルトの名無しさん：2013/01/28(月) 08:10:01.52

>>861
free楽勝とか豪語しているのは底辺バカという事が実証されたようだな。ｗｗｗｗ
お題「簡単に書け」を「短くかけ」とか勝手に変更したうえ、お題には無かった
「判定」操作を加えて複雑にした上に、バグ作りこんでる。ｗｗｗｗｗ
バカの極み。ｗｗｗｗｗ

>>865
やっぱりバカだ。ｗｗｗ
free_lはデータ構造に対する操作。forは入力データに対する操作。
free_lと対比させるなら、データ構造に対する(insert)操作ということになるが、
これは無名のブロック
{ struct l *p = malloc(sizeof(struct l)); p->next = root; root = p; }
が該当する。そしてこれは先頭に追加していくので再帰構造にする必要が無い。

下らねーことに言いがかり付けてんじゃねーよ。チンカス。

867 ：デフォルトの名無しさん：2013/01/28(月) 13:22:40.69

Cにも参照カウントベースのスマートポインタを実装できないものかな。
やっぱテンプレート使えないと面倒かね。

Cのプリプロセスだけ使うオプションみたいに、
C++のテンプレートまで処理を行うオプションないのかな。

868 ：デフォルトの名無しさん：2013/01/28(月) 20:02:41.78

Objective-CのAutoReleasePoolならCでも実装できるんじゃないかな？
C++のスマートポインタはできるのかどうかわからんけど、演算子
オーバーロードがないから似ても似つかないものになりそう。

869 ：デフォルトの名無しさん：2013/01/28(月) 22:07:21.91

????

struct l *p = root;
root = p ? p->next : p;
free(p);

870 ：デフォルトの名無しさん：2013/01/28(月) 22:32:09.44

struct l *p = root;
root = p ? p->next : NUL;
free(p);

871 ： ◆QZaw55cn4c ：2013/01/29(火) 05:08:31.65

>>866
まずスレッドタイトル嫁。プロセス終了直前にfree() が必要かどうかを論じるスレではない。

＞そしてこれは先頭に追加していくので再帰構造にする必要が無い。
解放のときも同じく先頭から解放していけばよく再帰構造にする必要は皆無なのに、どうしてわざわざ再帰にする？ミスリードを狙っているのか？

http://ideone.com/h1Gjuh
$ time ./baka
real 0m0.919s
user 0m0.046s
sys 0m0.015s

$ time ./baka 1
real 0m1.641s
user 0m1.497s
sys 0m0.108s

$ time ./baka 1 2
real 0m0.871s
user 0m0.779s
sys 0m0.062s

再帰のオーバーヘッドは馬鹿にならないね。

872 ：デフォルトの名無しさん：2013/01/29(火) 09:41:31.20

スレタイに逆らって、いかなる場合でもfreeしろって騒いでるバカの筆頭が何ほざいてるんだ。ｗｗｗ

873 ： ◆QZaw55cn4c ：2013/01/29(火) 12:35:53.13

>>872
お前日本語が読めないのか？
信者は >>1 に基本的に賛同する、ただし信者らしく極端なだけ。

874 ：デフォルトの名無しさん：2013/01/29(火) 12:37:44.50

バカがうるさいので書き直してやるよ。ｗｗｗ
void free_l(struct l * restrict p) {
struct l *next = p->next;
free(p);
if (next)
free_l(next);
}

バカのいいがかりなんて所詮この程度の事。バカには意味わからないだろうけどな。ｗｗｗ

875 ：デフォルトの名無しさん：2013/01/29(火) 12:50:52.54

いくつ連結されるかわからないリスト構造を再帰で解放するのは
キチガイのやることです

876 ：デフォルトの名無しさん：2013/01/29(火) 12:58:33.48

ここでｗｗｗさんに問題です
天才には簡単な問題ですので必ず逃げないで答えてください

スタックサイズが8MBのとき、このfree_l関数で解放可能な連結リストは
最大何個連結可能でしょうか？

アーキテクチャは好きに選んでいいですよ

877 ：デフォルトの名無しさん：2013/01/29(火) 13:05:55.37

質問です。再帰を使わない
void free_l(struct l *pp) {
for (struct l *p = pp; p; p = pp) {
pp = p->pNext;
free (p);
}
}
は正しいでしょうか？

878 ：デフォルトの名無しさん：2013/01/29(火) 13:09:29.22

>>877
美しくないです

879 ：デフォルトの名無しさん：2013/01/29(火) 14:21:00.03

>>876
予想通りバカにはわかっていない。ｗｗｗｗ

880 ：デフォルトの名無しさん：2013/01/29(火) 14:31:53.18

予想通りの敗北宣言ありがとうございます

881 ：デフォルトの名無しさん：2013/01/29(火) 14:33:48.54

予想通りのバカ。ｗｗｗｗ

882 ：デフォルトの名無しさん：2013/01/29(火) 14:35:32.20

もういいですよ
顔真っ赤にして罵倒して逃げることしかできない朝鮮人のような
あなたを見ることができて、私は満足しましたから

883 ：デフォルトの名無しさん：2013/01/29(火) 14:38:37.80

「ダブルポインタ」のソースで負けて、
解放処理を簡単に書くコンテストで負けて。しかも参加者はみんなバグってるというおまけつき。ｗｗｗｗ
>>874を理解せずに勝利宣言。ｗｗｗｗｗ

生きてくのつらくないか? 底辺バカｗｗｗｗ

884 ：デフォルトの名無しさん：2013/01/29(火) 14:41:33.76

別にちゃんと>>867を答えてもらってもいいですよ
答えられるならばの話ですけど

885 ：デフォルトの名無しさん：2013/01/29(火) 14:42:41.02

>>884
制限なし。ｗｗｗ
これでいいのか。ｗｗｗ

886 ：デフォルトの名無しさん：2013/01/29(火) 14:47:24.52

>>874
スレ違いで申し訳ない質問です。

> void free_l(struct l * restrict p) {
引数1個で restrict って効果ありますか？

887 ：デフォルトの名無しさん：2013/01/29(火) 14:50:55.82

>>886
ああ、コピペの時の単なるゴミだ。意味ないね。

888 ：デフォルトの名無しさん：2013/01/29(火) 15:11:31.24

>>884
なんだよ。バカに釣られて答えちまったぜ。ｗｗｗｗ
>>867
> Cにも参照カウントベースのスマートポインタを実装できないものかな。
> やっぱテンプレート使えないと面倒かね。
>
> Cのプリプロセスだけ使うオプションみたいに、
> C++のテンプレートまで処理を行うオプションないのかな。
能無しだとは思っていたが、まさかアンカーすらまともにうてないとは予想の斜め上だったぜ。ｗｗｗ

>>885は>>876への回答な。ｗｗｗｗ
息してるか？バカ。ｗｗｗｗ

889 ：デフォルトの名無しさん：2013/01/29(火) 15:16:19.97

すいません、笑いすぎて息でなくて、笑い死にしそうになっていました

890 ：デフォルトの名無しさん：2013/01/29(火) 15:24:04.07

バカには読めないと思うけど、>>874のアセンブリリストね。ｗｗｗｗ
http://pastebin.com/4pBPEWBG

読めなくて良かったな。バカ。ｗｗｗｗｗ
読めてたら憤死するところだぞ。ｗｗｗｗ

891 ：デフォルトの名無しさん：2013/01/29(火) 15:27:35.57

>>887さん、。ｗｗｗｗの人ですか？
回答ありがとう。コピペミス了解。

(出来れば見分けやすいよう、行末に「。ｗｗｗｗ」を付けてくださいｗ)

892 ：デフォルトの名無しさん：2013/01/29(火) 15:30:30.12

>>891
ｗｗｗｗはバカを相手にするとき。

893 ：デフォルトの名無しさん：2013/01/29(火) 15:39:12.99

お、証明までしてもらっちゃってありがとうございます
さすが天才のｗｗｗさんですね

894 ：デフォルトの名無しさん：2013/01/29(火) 15:46:06.58

スレを開いてみたら、予想以上のバカスレだった

895 ：デフォルトの名無しさん：2013/01/29(火) 15:50:18.57

バカが作った危険なソースをコンパイラががんばって最適化してくれただけじゃん。

896 ：デフォルトの名無しさん：2013/01/29(火) 16:02:26.60

ここまで俺の自演

ここから俺の自演

897 ：デフォルトの名無しさん：2013/01/29(火) 16:07:24.29

>>895

>>874で警告しといてあげたのに。ｗｗｗｗｗ
> バカのいいがかりなんて所詮この程度の事。バカには意味わからないだろうけどな。ｗｗｗ

やっぱり、バカにはわからなかったようだね。コンパイラ程度の知能があればよかったのにねｗｗｗｗ
ところで>>876の回答>>885はあってんの? 出題者は採点しろよ。ｗｗｗｗ

898 ：デフォルトの名無しさん：2013/01/29(火) 16:14:23.10

全くの第三者だけど、>>874は再帰でスタックを少しずつ消費するから、無限ってことはないんじゃないの？
それとも、*nextはスタックを消費しないってこと？

899 ：デフォルトの名無しさん：2013/01/29(火) 16:39:16.63

>>874は末尾再帰と呼ばれる形式で、機械的に反復形式に最適化できる。
証拠 → http://pastebin.com/4pBPEWBGの該当部分
.LBB0_1: # %tailrecurse
# =>This Inner Loop Header: Depth=1
movq (%rdi), %rbx
callq free
testq %rbx, %rbx
movq %rbx, %rdi
jne .LBB0_1
全くスタックは消費していない。rdiがfree_lへの引数(p), rbxがnextだな。

せっかく↓警告しといてあげたのにね。
> バカのいいがかりなんて所詮この程度の事。バカには意味わからないだろうけどな。ｗｗｗ

900 ：デフォルトの名無しさん：2013/01/29(火) 16:49:15.78

処理系依存を前提にされても

901 ：デフォルトの名無しさん：2013/01/29(火) 16:59:41.77

>>874は機械的に最適化できる単純な事に必死に絡んでるQzをあざけ笑う事が目的だからな。ｗｗｗ
予定外のバカも釣れたようだが。ｗｗｗ
問題に答えたんだからとっとと採点しろよ。バカ。ｗｗｗｗ

902 ：デフォルトの名無しさん：2013/01/29(火) 17:00:44.99

で末尾再帰が常にループに最適化されるというのは
どの規格書に書いてあるの？

903 ：デフォルトの名無しさん：2013/01/29(火) 17:03:41.08

釣れないから自演を恥めたのか
憐れすぎる

904 ：デフォルトの名無しさん：2013/01/29(火) 17:15:21.16

>>902
Qzやお前らのようなバカより頭のいいコンパイラが存在する事を示せればそれで十分。ｗｗｗｗ
コンパイラより劣る脳しか持ってないバカはコンパイラの奴隷やってろ。ｗｗｗｗ

>>903
おら、とっとと採点しろよ。ｗｗｗｗ

905 ：デフォルトの名無しさん：2013/01/29(火) 17:19:37.24

仕込んだ餌が発動して良かったね(棒)

906 ：デフォルトの名無しさん：2013/01/29(火) 17:20:52.57

バカ入れ食い。ｗｗｗｗｗ
採点まだ～～～～? ｗｗｗ

907 ：デフォルトの名無しさん：2013/01/29(火) 17:44:32.03

じゃあ30点あげましょう

908 ：デフォルトの名無しさん：2013/01/29(火) 18:10:05.87

>>876
気負いこんでかかってきたのに、あっさり撃退されちゃった気分はどう? ｗｗｗｗ
バカみじめすぎる。ｗｗｗｗ

このバカが憤死したら下らねーことに粘着したてめーの責任だ。うんこQz てめーも殉死しろ。

909 ：デフォルトの名無しさん：2013/01/29(火) 18:12:05.83

もちろん実験して答えを確認してからレスしていますので
この展開は予想済みです

910 ：デフォルトの名無しさん：2013/01/29(火) 18:15:39.18

末尾再帰という言葉をちゃんと知っていたのはちょっと予想外でした
意味は完全には理解しきれていないようですけどね
言葉と経験則的に理解しているというところでしょうか

911 ：デフォルトの名無しさん：2013/01/29(火) 18:19:01.22

実験しなきゃ答えがわからなかった時点で底辺バカ確定。ｗｗｗ

912 ：デフォルトの名無しさん：2013/01/29(火) 19:05:58.84

関数コールは少なくとも戻りアドレスのためにスタック食いますよね…

913 ：デフォルトの名無しさん：2013/01/29(火) 19:50:29.00

>>912
いいえ

914 ：デフォルトの名無しさん：2013/01/29(火) 21:13:35.37

root == NULL のときに free_l(root) でクラッシュする
ゴミコードで勝ち誇っている>>874がいるスレはここですか？

>>874みたいなコード書いてりゃ、そりゃfreeすべきでないと言い出すわな
いつクラッシュするか分からんから

915 ：デフォルトの名無しさん：2013/01/29(火) 21:22:00.72

一方向のリストの解放くらいでバグっちゃう怖い怖い言ってるレベルの人ですから。

916 ：デフォルトの名無しさん：2013/01/29(火) 21:27:39.38

とんだバグ野郎でしたね

917 ：デフォルトの名無しさん：2013/01/29(火) 21:30:33.26

俺みたいにこんな幼稚なバグ作っちゃうかもしれないからfreeはしないほうがいい、ってことか。
体を張ってんな。

こんなバグ作るのこいつくらいだけど。

918 ：デフォルトの名無しさん：2013/01/29(火) 21:33:23.31

>>910
末尾再帰もしらないで向かってきた>>876をほめてやれ。ｗｗｗｗ

>>914
free_lの中でいちいち比較するのは無駄なので、普通はfree_lを呼び出すラッパを作って
それで確認する。今回はNULLじゃない事が保証されてるので全部省略。
バカだね。それくらいわかれよ。ｗｗｗｗ

>>915
必死で向かってきたバカのお友達はみんな討死しているぞ。>>861とか。ｗｗｗｗ

本日のバカ一番は>>876。明日は誰だろう。ｗｗｗｗ

919 ：デフォルトの名無しさん：2013/01/29(火) 21:46:57.73

ほめてやれって、それお前の自演だろ。
というか自演下手だな。そんなにスムーズに流れたら誰だってわかるぞ。

920 ：デフォルトの名無しさん：2013/01/29(火) 21:52:20.38

自演かどうかはともかく、この展開は読めていたぞｗ

921 ：デフォルトの名無しさん：2013/01/29(火) 21:54:04.93

おーぃ。>>876
お前がバカ杉で見事に引っかかったから自演だと思われてるぞ。ｗｗｗ
まだ生きてるか? ｗｗｗｗ憤死してもおかしくないよなあ。ｗｗｗｗ

922 ：デフォルトの名無しさん：2013/01/29(火) 21:58:11.43

あんな言いがかりつけるって事はうんこQzも末尾再帰しらないよなあ。ｗｗｗｗ
それとも、>>876を陥れるためにうんこQzが仕組んだ罠だとでも？ｗｗｗｗ

923 ：デフォルトの名無しさん：2013/01/29(火) 21:58:27.03

>今回はNULLじゃない事が保証されてるので

でたよ得意の思い込み

924 ：デフォルトの名無しさん：2013/01/29(火) 22:01:10.09

>>923
突っ込まれたら急きょ前提条件を付け加えて
「そんな前提条件すら気づかないバカ。ｗｗｗ」
とレスするだけの簡単なお仕事です。

925 ：デフォルトの名無しさん：2013/01/29(火) 22:03:35.37

どうせ再帰して解放する際にはroot->next以降はNULLチェックが必要なのに
rootだけNULLチェック飛ばす意味ねーだろ馬鹿か

926 ：デフォルトの名無しさん：2013/01/29(火) 22:03:47.52

まあｗｗｗも勝ってるつもりみたいだし、
Win-Winのいい関係じゃないか。

927 ：デフォルトの名無しさん：2013/01/29(火) 22:03:53.36

そのように作ってあるだろ。ｗｗｗ
NULLになるパスが存在するとでも。ｗｗｗｗ

928 ：デフォルトの名無しさん：2013/01/29(火) 22:05:58.78

#define FREE_L(a) if(a) free_l(a)
というラッパを作るってこと？
確かに期待通りに動くけど、それってfree_lのバグをごまかしてるだけじゃん。

929 ：デフォルトの名無しさん：2013/01/29(火) 22:06:16.19

>>925
エラーチェックのNULL判定とリスト終端NULL判定は意味合いが違わないかな？

930 ：デフォルトの名無しさん：2013/01/29(火) 22:10:12.18

覚えたての末尾再帰を披露したくて大事なとこが抜けたんだろ
lisperから言わせて貰うと　がんばれ

931 ：デフォルトの名無しさん：2013/01/29(火) 22:12:21.95

>>925
rootはNULLじゃない事が確定している。よって省略。わかる? バカにはわかんないかなｗｗｗｗ

932 ：デフォルトの名無しさん：2013/01/29(火) 22:14:40.08

933 ：デフォルトの名無しさん：2013/01/29(火) 22:14:47.91

というか、スタックオーバーフローするかもしれない致命的な実装のミスを
コンパイラの最適化がたまたま勝手に修正してくれただけで、
コンパイラやオプション次第ではスタックオーバーフローする危険なソースで
あることには変わりない。

934 ：デフォルトの名無しさん：2013/01/29(火) 22:16:29.76

for (i = 0; i < n; i++) {
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;
}

こんな感じにループ回数を変数nに一般化したあと、
n < 1 な値が入ってきたときにバグが顕在化するんですね。

935 ：デフォルトの名無しさん：2013/01/29(火) 22:18:57.55

forのループ条件を0との比較になるようにロジックを書けない時点で素人

936 ：デフォルトの名無しさん：2013/01/29(火) 22:20:59.41

sizeof(struct l)
これも素人くさい
プロなら
sizeof(*p)
だな

937 ：デフォルトの名無しさん：2013/01/29(火) 22:25:44.87

>>933
何故わざわざと再帰にしたか考えてみな。ｗｗｗｗ
わからないだろうな。バカにはｗｗｗｗｗ
なんか謎の文字列もついてるし。ｗｗｗｗ

938 ：デフォルトの名無しさん：2013/01/29(火) 22:26:08.19

くさおが追い詰められて「ｗｗｗ」を付けずにレスしてるぞ

939 ：デフォルトの名無しさん：2013/01/29(火) 22:28:06.56

ここまでのまとめ
・freeいる派完全勝利
・freeいらない派のくさおが発狂、レスを流すのに必死

940 ：デフォルトの名無しさん：2013/01/29(火) 22:29:28.16

バカ必死。ｗｗｗｗ
教祖のうんこQzすらfreeしなくていいと日和ってるぞ。ｗｗｗｗ

941 ：デフォルトの名無しさん：2013/01/29(火) 22:32:59.10

んじゃ、このバカの釣堀の次スレ立てといてね。バカの諸君。ｗｗｗｗ

942 ：デフォルトの名無しさん：2013/01/29(火) 22:33:35.33

>>940
-O0 -S

943 ：デフォルトの名無しさん：2013/01/29(火) 22:35:31.49

mtraceが通らないソースは納品できないし、
無駄に再帰しているソースはレビューすら通らない。

これが現実。

944 ：デフォルトの名無しさん：2013/01/29(火) 22:36:02.37

雲行きが怪しくなったのでくさおは逃げましたとさ。
おしまい。

945 ：デフォルトの名無しさん：2013/01/29(火) 22:37:40.99

>>871
> まずスレッドタイトル嫁。プロセス終了直前にfree() が必要かどうかを
> 論じるスレではない。

まぁでも、main以外と書いてあるし、main以外のexit前ならなんとか
スレの範疇かと。
このスレにはプロセス終了直前のfreeは無駄なごみでしかないってことを
理解できない方もいらっしゃるみたいだし。

QZ...ですらプロセス終了直前のfreeは必要ないって思っているってことでいい ?

再帰のオーバーヘッドが大きいって行ってるけど、
それを含めて無駄な解放の、後始末のコストなんじゃない ?
今回の例はあくまで簡潔な例として作られたもので、
例えばn個の枝を持つツリー構造だったら再帰でやっちゃうわけで

再帰で書けば自然なのをわざわざループに書き直すことを考えたら
自明に消せれるfreeは最初っから書かなきゃいいじゃんって思うんだけど。

あと、再帰のオーバーヘッドが消せようがなんだろうが無駄なfreeのコストは
ゼロじゃない。
ただ単に無駄なコストなのに。

946 ：デフォルトの名無しさん：2013/01/29(火) 22:41:57.29

そもそも最後にまとめて解放すればいいという設計がおかしいんだよ。
最後にまとめて解放するくらいならプロセスの終了に任せれば、って
話になるのはそのため。

mtraceの話も出てるけど、リストだろうがツリーだろうが、使っていると
認識している箇所だけを正しく解放していって、最後に何が残るかを
見ないとリークしてるかどうかなんてわからないだろ。

最後にツリーまとめて消してみたら全部消えたのでリークしてません、
なんてことにはならないんだから。
そこに解放したつもりになっているデータが連結されているかどうか
というのが重要なのに。

947 ：デフォルトの名無しさん：2013/01/29(火) 22:45:04.83

こりゃまた大きな釣り針だな。ｗｗｗ

948 ：デフォルトの名無しさん：2013/01/29(火) 22:47:30.66

くさお悔しくて絶好調だな

949 ：デフォルトの名無しさん：2013/01/29(火) 22:47:59.75

>>946
まとめて消して消えるならリークしてないだろ。バカか。

950 ：デフォルトの名無しさん：2013/01/29(火) 23:03:18.74

>>946
> そもそも最後にまとめて解放すればいいという設計がおかしいんだよ。

そうは言っても本質的にプロセスの最後まで持ち続けてるデータだって
あるんだもん。

こういう場合はどうかな ?

画像の色調を変化させたり、輪郭を抽出したり、そういうソフトで
ワーキングエリアにデータを入れてるとして、ユーザが終了を指示したとき
いちいち、mallocした領域をfreeしてから終了する ?

951 ：デフォルトの名無しさん：2013/01/29(火) 23:13:25.53

します。しないと可搬性が低下します。

952 ：デフォルトの名無しさん：2013/01/30(水) 01:05:12.90

>>950
スレ立てな

953 ：デフォルトの名無しさん：2013/01/30(水) 01:22:33.92

>>950
その手のソフトなら、アンドゥ実装したり、起動したまま今のファイルを捨てて、
違うファイルを読み込んだりするだろうから、どうせ領域解放の処理は必要になる。

でかいファイルを読み込んで終了させた時に、解放にとんでもなく時間がかかってる
と言うのがわかればあえて解放しないようにするかもしれないけど、まずは普通に
解放するように作る。

そもそもそういう状況なら、読み込みはもっと時間かかってるはずだし。

954 ：デフォルトの名無しさん：2013/01/30(水) 08:23:22.57

お前らmalloc/free好きだなあ
fj思い出したわｗ

955 ：デフォルトの名無しさん：2013/01/30(水) 11:55:15.87

mallocをやめてrealloc
freeをやめてreallocにすればいんじゃね？

956 ：デフォルトの名無しさん：2013/01/30(水) 14:11:21.93

規模の大きいソフトなら独自で個別のヒープを持つか
ObjectiveCのNSなんとかPoolみたいなので一括解放させる。
そのままlibcのmalloc/freeスタイルでやるとかない。

957 ：デフォルトの名無しさん：2013/01/30(水) 21:39:04.52

ここまでのまとめ
・freeいる派完全勝利
・freeいらない派のくさおが発狂、レスを流すのに必死
・freeいらない派のくさおがバグ付スタックオーバフローソースを作成、
　身をもってfreeは危険だと主張
・freeいらない派のくさおが自演を開始、自画自賛を始める
・freeいらない派のくさおが自演を指摘され遁走　←いまここ

958 ：950：2013/01/30(水) 21:41:16.97

>>952
立てたお

mallocの後にfree不要と言うバカいるの?Part2
http://toro.2ch.net/test/read.cgi/tech/1359549517/

スレ名が長かったのでmain以外って入れれなかったのがすみません。

959 ：950：2013/01/30(水) 21:54:05.58

>>951
>>953

了解した。

>>954
自転車置き場の屋根だったっけ?
そんな感じのもんだいだからじゃない ?

リークさせちゃいけないってのは大前提なはずだし、
exit前のfreeを書くか書かないかなんてスタイルの問題で
どっちでもいいことじゃん

960 ：デフォルトの名無しさん：2013/01/30(水) 23:20:27.27

>>953
ソース出せというので出してやったのに。読めないバカですな。ｗｗｗ
たとえばemacs。解放処理は実装してるけど、終了時の解放なんかしてない。

>>957
かなり悔しかったようだな。>>876 だから忠告してやったのに。ｗｗｗｗ
一日経った今でも爆笑。ｗｗｗｗｗｗ

> From: [876] デフォルトの名無しさん <sage>
> Date: 2013/01/29(火) 12:58:33.48
>
> ここでｗｗｗさんに問題です
> 天才には簡単な問題ですので必ず逃げないで答えてください
>
> スタックサイズが8MBのとき、このfree_l関数で解放可能な連結リストは
> 最大何個連結可能でしょうか？
>
> アーキテクチャは好きに選んでいいですよ

961 ：デフォルトの名無しさん：2013/01/30(水) 23:33:57.26

>>960
953さんは個人の方針を書いただけでしょう。
ソースを出せと言った方とは別の人では?

あまり攻撃的な書き方は感心できませんよ。

962 ：デフォルトの名無しさん：2013/01/30(水) 23:39:56.65

巨大なheapを自前で管理できるなら、終了時の開放時間なんて一瞬のような

963 ：デフォルトの名無しさん：2013/01/31(木) 00:20:03.34

>>958
立て乙
しかしmain以外削除に悪意を感じる

964 ：950：2013/01/31(木) 00:45:05.16

>>963
すまん。
Part2と入れるためにはどこか削除しなくてはならなかったんだ。
「malloc/free問題」とかスレタイを全く変えようかとも思ったんだが
なるべく前スレの雰囲気を残したかったし、刺激的なタイトルの方が
いいかなとも思い「mallocの後にfree不要と言うバカいるの?」というのは
そのまま残しました。

で、元スレの1さんの「main以外」っていう思いは元スレの1を最初のほうに
貼り付ければ、読んでくれるかな。と思いこうしました。
もたもたして2getできなくてすみません。

個人的にはこの「main以外」っていうのは非常に重要な要素で、
元スレの1さんは多分この手の議論はfjなりで経験していて、
exit前のfreeガーってのは既に考慮して、「main以外」なり
「例外中の例外は除く」になったんだと思う。

個人的には、その「例外中の例外」とはなんなのか、
その「例外」とされるものをどういう立場の人がどういう考えで
「例外」として扱うのか、扱わないのかが知りたいと思っている所存です。

でも、そんなスレ立ティストの思いにスレが左右されないように、
できるだけ中立的になるように立てたつもりですが、
お気に召さなかったら申し訳ありません。

965 ：デフォルトの名無しさん：2013/01/31(木) 01:23:29.13

ダメだよ。
削除して立てなおさないと

966 ：デフォルトの名無しさん：2013/01/31(木) 07:51:08.33

立て直した
終了直前以外でfree不要と言うバカいるの？2人目
http://toro.2ch.net/test/read.cgi/tech/1359585842/

967 ：デフォルトの名無しさん：2013/01/31(木) 10:23:57.62

>>966
なんで「main以外」抜くんだ？

968 ：デフォルトの名無しさん：2013/01/31(木) 10:32:57.59

mainを例外扱いするのはmainはexitするからに他ならない。
ところがmain以外でもexitを呼ぶことは可能。
したがって「main以外」とするのは不適切。

mallocを抜いたのは文字数制限

969 ：デフォルトの名無しさん：2013/01/31(木) 10:39:09.71

ご都合主義のおぼっちゃまくんか。
人命に関わるシステムにご都合主義持ち込まれると迷惑だから。。

970 ：デフォルトの名無しさん：2013/01/31(木) 10:47:17.33

人命に関わるシステムだとmain以外ではfreeしなけりゃいけないのか? ｗｗｗｗ
どういう理論だよ。ｗｗｗｗ

971 ：デフォルトの名無しさん：2013/01/31(木) 13:52:10.91

人命云々言い出すとそもそもmallocを使うこと自体が
例えばMISRA-Cに触れるとか

972 ：デフォルトの名無しさん：2013/02/04(月) 15:53:57.74

つうか、mew/deleteじゃない時点で放置

973 ：デフォルトの名無しさん：2013/02/04(月) 16:01:00.75

mew〈猫が〉ニャーと鳴く
久しぶり～ぬこちゃんは強くなったかな？
　　へ-ﾍ
　ﾐ*´ｰ｀ﾐ
～(,_ｕｕﾉ

974 ：デフォルトの名無しさん：2013/02/04(月) 21:03:04.66

http://ideone.com/7tIe2W
mew/deleteのサンプル

975 ：デフォルトの名無しさん：2013/02/05(火) 22:50:05.38

つか、メモリー確保する為に、malloc/newを使う時に、
Linux/Windowsで、同じ動作をするのかね？

仮に、malloc(0)とした場合、動作が異なるしね。

Linuxだと、nullが返るけど、Windowsなら、nullじゃない。

これが、何十万回も呼ばれ、かつ、連続稼働するようなシステムでも
freeが不要なのか？

環境依存、コンパイラの仕様を把握した上での議論なのか？

なんか、スレの流れからすると違和感があるのだけど？
あと、OSが32/64bitなのか明確じゃないし。

プロセスが確保できる上限値に至る可能性がある要求があった場合の
考慮も欠如している。

それでも、free()は、不要なのか？

976 ：デフォルトの名無しさん：2013/02/05(火) 23:22:46.15

他にfreeした領域を指してるポインタがあったらどっかーん

977 ：デフォルトの名無しさん：2013/02/06(水) 02:23:02.90

>>976
それよりは、freeしないでおいて、メモリ不足になった方がマシ。

…ってこと？

978 ：デフォルトの名無しさん：2013/02/06(水) 14:18:41.52

>>977
きみ何言ってんの？ｗ

979 ：デフォルトの名無しさん：2013/02/06(水) 15:35:45.86

>>976 の言うどっかーんはバグだろう。

980 ：デフォルトの名無しさん：2013/02/06(水) 19:10:56.44

参照カウンタ、ですか、めんどくさいなあ

981 ：デフォルトの名無しさん：2013/02/06(水) 21:14:57.74

>>975
> これが、何十万回も呼ばれ、かつ、連続稼働するようなシステムでも
> freeが不要なのか？

freeが全く必要ないって言っている人はほとんどいないと思う。

議論になっているのはexit直前のfreeのように
あっても全く影響のないフリーを書くべきかどうかということ。

> 環境依存、コンパイラの仕様を把握した上での議論なのか？

特に規定はされていない。

なので、Unix or Windows用に書いたプログラムを組み込み用に
移植するから・・・という話も出てくる。

それはそれで実り多い議論だと思う。

> あと、OSが32/64bitなのか明確じゃないし。

それは何か違いが出てくるのだろうか ?
浅学なので教えてほしい。

> プロセスが確保できる上限値に至る可能性がある要求があった場合の
> 考慮も欠如している。

そのことが議論になっていないのは、そうなる前にfreeしろってのが
自明だからだと思う。

> それでも、free()は、不要なのか？

個人的な意見だがfreeは必要でない*場合もある*と思う。