main以外★mallocの後にfree不要と言うバカいるの？
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん
2012/11/13(火) 22:12:13.29前提２：main関数は除く
前提３：関数実行後すぐに終了するとは限らない
前提４：関数は何度も使われることがある
これがメモリリークするのは当たり前の話で、
mallocをしたらfreeするのは当たり前。
free不要論とは一体何だったのか。
天邪鬼（バカ）が言葉尻を捉えていただけではないだろうか。
まつもと ゆきひろもそのバカの一人だったらしいね。
例外中の例外を除いて、mallocをしたらfreeは必要。
これが真の答えだろう。
0002デフォルトの名無しさん
2012/11/13(火) 22:19:16.940003デフォルトの名無しさん
2012/11/13(火) 22:23:33.65アプリ（CUIしかない）は実行したらすぐに終了していたんだよ。
だからfreeしなくてもいいとかいう間違った考え方が生まれた。
0004デフォルトの名無しさん
2012/11/14(水) 07:38:29.10確かにfree要らんわな。
freeしても大抵マークするだけだしプロセス終了時に開放されるからfree不要、って話の方には、
基本的に賛同しないけどな。してもしなくても変わらないケースも多いが、変わるケースも少なく
ないし、freeを省略する利点も無い。実行形式をとことん小さくしたい時くらいかね。
0005デフォルトの名無しさん
2012/11/14(水) 10:17:51.41つか、その前提条件はmalloc-free論争のときのと違うし。
0006デフォルトの名無しさん
2012/11/14(水) 12:14:18.68基本的に終了しないアプリなんて、それこそC言語が生まれる前からあるだろ
0007デフォルトの名無しさん
2012/11/14(水) 14:35:53.85a = 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;
0008片山博文MZボット ◆0lBZNi.Q7evd
2012/11/14(水) 14:58:41.81if (!error) {
b = malloc(10);
if (!error) {
c = malloc(10);
if (!error) {
process();
}
free(c);
}
free(b);
}
free(a);
return;
0009デフォルトの名無しさん
2012/11/14(水) 15:03:52.19真のfree地獄
http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.10.1.list
0010デフォルトの名無しさん
2012/11/14(水) 15:04:44.67> 前提２：main関数は除く
> 前提２'：exit関数を呼び出す場合を除く
これを除外しないのがfree教信者。前提が違う。
0011デフォルトの名無しさん
2012/11/14(水) 17:40:49.66それはfreeの問題じゃなくて書き方がアホなだけだ
0012デフォルトの名無しさん
2012/11/14(水) 17:45:31.870013デフォルトの名無しさん
2012/11/14(水) 18:08:53.360014デフォルトの名無しさん
2012/11/14(水) 18:17:25.97UNIX系の人にメモリーに限らずリソース開放軽視してる人多かったな
PC育ちの自分にとってはそんな書き方したらマトモに
動かなかったから信じられなかったけど。
プロジェクト全体のリソース管理状況をチェックする担当になった時に
リークチェッカーに引っかかった箇所を、それぞれの担当者に
修正お願いするんだけど、サーバーとの通信部分を担当してた
男版お局さんみたいな人に、DLL解放時にリークしてるところが
あるから修正してくださいって頼んだけど最後まで無視されたな。
実際はプロセス内で何度もロード・アンロードするところだから
問題有ったんだけど、事を荒立てないように見なかったことにした。
立場の弱い人間には強制的に修正させたけどね
韓国の会社が作ったUNIX用の結構大きなソフトのWindowsのポーティングも
やったけど、それもリークが酷かったな。
あの当時、Windowsが糞OSとか叩かれてたけど、ちゃんと書いたプログラムは
ちゃんと動くのを身にしみてたからMSが気の毒だった。
どんな優秀な人でも、一度身についた悪習は中々直せないもんだよ
0015デフォルトの名無しさん
2012/11/14(水) 18:20:47.95お前、malloc-free論争のこと全然知らないだろ。
知らないなら黙っとけ糞が。
0016デフォルトの名無しさん
2012/11/14(水) 18:46:44.690017デフォルトの名無しさん
2012/11/14(水) 19:13:10.34なぜ？
main関数はfree不要なら、他の関数でも同じじゃないの？
0018デフォルトの名無しさん
2012/11/14(水) 19:44:08.68mainでmallocして使われなくなってもそのあとまだまだ続かないとも限らないんだから
0019デフォルトの名無しさん
2012/11/14(水) 20:04:49.130020デフォルトの名無しさん
2012/11/14(水) 21:22:45.38そんなのは当然だ。
ただし例外があるというだけの話。
0021デフォルトの名無しさん
2012/11/14(水) 22:08:12.11その例外がさも一般的なことであるかのように
話をしていたのが、free不要論なんだよなｗ
今の時代、free不要とか言い出したら
キチガイ認定されるだろう。
0022デフォルトの名無しさん
2012/11/15(木) 06:13:02.56A「プロセス終了時に開放してくれるOSでは、exit()を掛ける前にもfree()する必要は無い」
B「free()しなくてもどうせ変わらんから要らない」
どっちの論理なのかのソース出せよ
Aだと思い込んでる奴と、Bだと思い込んでる奴と、言い合っても話が通じるわけねぇだろ
0023デフォルトの名無しさん
2012/11/15(木) 07:12:51.68言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
0024デフォルトの名無しさん
2012/11/15(木) 07:30:17.50ここまで来てからそれか。
敗北宣言と見なされるぞｗ
0025デフォルトの名無しさん
2012/11/15(木) 11:11:41.15freeするのは当然じゃないよ。
「freeしなければならない場合がある」というだけでそれ以外は不要なんだが、「それ以外」がどういう
ときなのかわからない人が「freeするのは当然」と思考停止してしまうのが論争になった原因。
0026デフォルトの名無しさん
2012/11/15(木) 13:15:05.59どうせド素人なんだろうけど
0027デフォルトの名無しさん
2012/11/15(木) 13:27:47.33思考停止するからダメだって話なのか。マジかよ。激しくダサいなｗ
心理学者かよｗｗｗ
0028デフォルトの名無しさん
2012/11/15(木) 15:02:11.070029デフォルトの名無しさん
2012/11/15(木) 19:03:09.840030デフォルトの名無しさん
2012/11/15(木) 19:48:45.89GCが働いてくれる言語でバグ出さないようにしてもらえればそれで十分
こっちくんな
0031デフォルトの名無しさん
2012/11/15(木) 22:53:47.270032デフォルトの名無しさん
2012/11/16(金) 00:11:11.37で、思考停止しないで考えて出した答えは
やっぱりfree必要なんだろ？
そのソースを教えてくれ。
0033デフォルトの名無しさん
2012/11/16(金) 04:02:15.370034デフォルトの名無しさん
2012/11/16(金) 04:47:17.99たとえば、スレッドがファイルを開いたり閉じたりしている場合、
しかも、スレッドを止めないで親が終了した場合、スレッドのオブジェクトは、解放されますか？
0035デフォルトの名無しさん
2012/11/16(金) 06:37:50.740036デフォルトの名無しさん
2012/11/17(土) 00:58:14.40定期的にエンジンを再起動してください。
0037デフォルトの名無しさん
2012/11/18(日) 07:11:51.320038デフォルトの名無しさん
2012/11/18(日) 09:45:30.07※この自動車は連続○分エンジンブレーキで走ると
エンジンがフリーズして二度と動かなくなります。
定期的にエンジンを空吹かししてください。
混合油2スト時代の常識ｗ
「fclose() しなくてもOSがディスクリプタを回収してくれるから無問題したがってflocse()不要」という主張はあまり耳にしないのだが？
0040デフォルトの名無しさん
2012/11/19(月) 08:56:04.28いやその話だって処理系に依存することには変わりはない訳で、本質は同じでしょ
0041デフォルトの名無しさん
2012/11/19(月) 10:01:48.18↓ ここにfcloseしてないチンカスがいますよ。 ｗｗｗ
http://codepad.org/mLtuxDOF
0042デフォルトの名無しさん
2012/11/19(月) 13:32:23.68OSが回収するのは「ディスクリプタ」じゃないけどな
0043デフォルトの名無しさん
2012/11/19(月) 18:53:07.46そうか？ むしろそちらの方を良く聞いたが。
使い捨てのスクリプトなんかは close しないのも結構あるんじゃないか。
0044デフォルトの名無しさん
2012/11/19(月) 19:14:21.27ふむ。確かに一つのディスクリプタを複数のプロセスで共有しているときに、ひとつのプロセスが終了したからといってディスクリプタ自体を閉じてしまっては一大事ですね。
このあたり疎いのでもしよろしければ参考本を教えてください。
>>40 >>43
んー、最近はclose()/fclose()論争をあまりきかないので‥‥こんど煽ってみよう‥‥
>>41
みつかったか :-)
0045デフォルトの名無しさん
2012/11/19(月) 20:13:10.93使っていいとこはあるけど基本使うなよ、でも無理に使わないことも無いよ、っていうあれ
0046デフォルトの名無しさん
2012/11/19(月) 23:08:57.86今だと誰もがfreeすべきだと答えている感じなんだが、
昔はなぜかfreeしなくていいのが多かった感じがする。
しかも詳しい人ほどfreeしなくていいと言ってるみたい。
やっぱ昔はfreeするコストとかまで気にしていて
綺麗なコードよりも、技巧的で速いコードが好まれていたってことかねぇ。
0047デフォルトの名無しさん
2012/11/19(月) 23:40:20.28ジョブからプロセスキックする様なシステムが多かったから
いちいち解放しなくてもOSが勝手にやってくれるじゃん
みたいなことじゃね？
そもそも、昔のプロのプログラマーの環境はリソース足りなきゃ
ハードを増強すりゃいいだろみたいな考えだったし。
そして、昔はUNIXプログラム＝プロのプログラム
パソコンプログラム＝アマチュアみたいな感じで下に見る傾向が強かったから
UNIX文化＝常に正しいみたいな根拠のない流の議論になってたんじゃないかな
0048デフォルトの名無しさん
2012/11/19(月) 23:46:27.03当時そう言っていた人が
今は考えを改めたのか知りたいんだけど。
今はfree不要論者全然いないし。
0049デフォルトの名無しさん
2012/11/19(月) 23:59:07.36今みたいな何時間も何日も起動しっぱなしのプロセスについてはfree不要とか言わないよ
それに昔はメモリをそんなに積んでなかったから設計時に全てメモリ使用量を計算済みだったから
プログラムの最初に大方確保してそれを使ってたからね
今みたいに任意のタイミングに動的にメモリ確保とかそんな贅沢できなかった
0050デフォルトの名無しさん
2012/11/20(火) 01:48:39.26おっかしいなー、
宿題スレではfree()信者はそれこそ｢信者」扱い、free() を省略できなければどんくさい、くらいの価値観が通っているんだけれども。
ダングリングポインタや、手放してしまって金輪際free() できない領域（これなんていうんだろ？）が発生しなければ OK くらいが落としどころになってる。
0051デフォルトの名無しさん
2012/11/20(火) 02:14:00.81だからそれ、プログラムが完全に終わる直前の話でしょ？
プログラムのすべてをmainでやってるのならともかく、
普通関数の形にするよね。その関数はどういう呼ばれ方をするか
わからないものとして作るから、mallocしたらfreeするよね？
結果的にfreeしないということなんて現実にはまずない話だと思うんだが。
freeを省略できる条件を明確にして欲しいよ。
あ、もちろんエラーで強制終了する場合は除く。
0052デフォルトの名無しさん
2012/11/20(火) 07:08:23.35リーク
0053デフォルトの名無しさん
2012/11/20(火) 08:16:24.72あれはfree教教組が教義を押し付けたけど、その教義がマヌケという事実を
指摘されて火病ってるだけ。
>>51
> プログラムのすべてをmainでやってるのならともかく、
> 普通関数の形にするよね。その関数はどういう呼ばれ方をするか
> わからないものとして作るから、mallocしたらfreeするよね？
関数の形になってても省略可能な例
main()
{
create_object();
print_object();
}
> 結果的にfreeしないということなんて現実にはまずない話だと思うんだが。
* 寿命がmainに等しいシングルトンなオブジェクトは現実的にも普通にあるし
よく使う。このようなオブジェクトはfreeしなくてもよい。
* BoehmなどのGCは「これまでにアロケートしたものをすべて解放」なんてい
うインターフェースはもっていない。ルートポインタをNULLにして回収を
試みてもコンサバティブGCなので回収できることは保証されていない。
そしてBoehmを利用しているプログラムは現実的にたくさん存在する。
> freeを省略できる条件を明確にして欲しいよ。
自分で考えろ。それを他人に押し付けるな。
0054デフォルトの名無しさん
2012/11/20(火) 08:38:58.68＞関数の形になってても省略可能な例
ん？簡略化しすぎているんじゃない？
＞シングルトンなオブジェクト
静的にもつほうが多いようなきが
BoehmGC がすべて開放するようなインタフェースを持たない、としてもそれはGCだからでは？
GCにたよらず自力本願なC++において、デストラクタを定義しなくともよい場合がある、という主張はあまりきかない。
＞教義がマヌケ
正常系でもfree()しないのはねえ‥‥
0055デフォルトの名無しさん
2012/11/20(火) 08:40:51.06お前、create_objectの実装しってんの？
関数使う側は内部の実装のことを気にしないものだよね。
create_objectがもし一時ファイルとか作っていたらどうするの？
delete_objectしないとだめだよね。
0056デフォルトの名無しさん
2012/11/20(火) 08:47:34.49教組登場。バカは引っ込んでろ。ｗｗｗ
>>55
> お前、create_objectの実装しってんの？
知ってるよ、delete_objectが用意されてない事も。
「mainで全部やらない」という事への反例だから。
0057デフォルトの名無しさん
2012/11/20(火) 12:00:15.37テキストファイルを閉じてもメモリを開放しないマルチテキストエディターが作りたいということか...
0058デフォルトの名無しさん
2012/11/20(火) 12:04:40.410059デフォルトの名無しさん
2012/11/20(火) 13:05:15.85単に
「どんな場合でも確実にリソース解放できるわけじゃないから、
実用上問題になるケースだけリソースを開放すればよい」
というだけ。
0060デフォルトの名無しさん
2012/11/20(火) 13:05:43.080061デフォルトの名無しさん
2012/11/20(火) 13:17:42.46この手の奴は総じて日本語もダメ
0062デフォルトの名無しさん
2012/11/20(火) 13:22:00.29・mallocしたものは必ずfreeで開放するべき
・メモリリーク障害を起こさないようにするべき
の違いでしかないんだけどね。
0063デフォルトの名無しさん
2012/11/20(火) 13:50:40.250064デフォルトの名無しさん
2012/11/20(火) 14:07:59.380065デフォルトの名無しさん
2012/11/20(火) 14:16:05.370066デフォルトの名無しさん
2012/11/20(火) 14:36:52.03私も>>64のいわんとすることが何となく分かります。
free();しなくて良い時は、
(1) 書く人が「しなくて良い」ことが分かっている
(2) 他人にソースを引き継ぐ(または解析されることがある)場合は、
余計な解析をさせないためにコメントに明記する
これが前提にあった上で、free();しなくても良いと思いますよ。
で本題ですが、上記(1)について。
「どういう時にfree()しなくて良いのか」
私が思いつくのは、
1. malloc()は最初に1度行われ、main()を抜けるとシステムが
代わりにfree()してくれる
2. malloc()は最初に1度行われ、main()は抜けない。
無限ループ+電源断か、シャットダウンイベントによって
システムが終了する組み込み系など
他に具体例、何かありますか？
0067デフォルトの名無しさん
2012/11/20(火) 16:21:58.990068デフォルトの名無しさん
2012/11/20(火) 17:45:54.67古いよねー
0069デフォルトの名無しさん
2012/11/20(火) 18:51:32.55将来外部関数としてそのmainが再利用される可能性が
ありうればfreeの処理も書いておく
0070デフォルトの名無しさん
2012/11/20(火) 21:39:19.31喧嘩するほどの話でもない
0071デフォルトの名無しさん
2012/11/20(火) 21:51:06.13すでに確保したメモリをfreeしなくても良いよね？
0072デフォルトの名無しさん
2012/11/20(火) 21:58:50.600073デフォルトの名無しさん
2012/11/20(火) 22:09:41.35正常動作するなと思っていても、死ぬことあるんだね。
> バグ
> デフォルトでは、Linuxは楽観的メモリ配置戦略を用いている。
> つまり、malloc()がNULLでない値を返しても、そのメモリが実際に利用可能であることが
> 保証されない。これは本当にまずいバグである。システムがメモリ不足状態になったとき、
> 悪名高いメモリ不足解決器(OOMkiller)によって一つまたは複数のプロセスが削除される。
> 突然あるプロセスが削除されるのが望ましくない状況で使用されていて、しかもカーネルの
> バージョンが十分に最近のものであれば、このメモリを割り当て過ぎる動作(overcommittingbehavior)
> を以下のコマンドで無効にできる。
> # echo 2 > /proc/sys/vm/overcommit_memory
0074デフォルトの名無しさん
2012/11/20(火) 23:53:44.17> 知ってるよ、delete_objectが用意されてない事も。
へんな話だな。
世の中の関数に、リソースはメモリの確保しかしていません。
終了時に解放処理をしなくても大丈夫ですって仕様に書いてるの無いでしょ。
どうせ自分が作った関数だからdelete_object呼ばなくても大丈夫って
知ってるとか言うつもりなんだろうけどさ、そんな話はしてないの。
他人が作った関数を思い浮かべればいいよ。
その関数がmallocをしてメモリを確保するのであれば、
逆にfreeする関数も用意している。
他人が作ったもので、他人がメンテする。だから実装がどうなってるかは考えない。
中の実装を見て、使用者側がコードの使い方変えるとか馬鹿のすること。
そう思うよね？
0075デフォルトの名無しさん
2012/11/20(火) 23:56:33.02OS依存は気にしないんだなｗ
特定の処理系（OS）に依存したコード書くなよ。
OSが必ずメモリ解放してくれるとは限らないだろ。
0076デフォルトの名無しさん
2012/11/20(火) 23:58:53.07俺は他人の意見を馬鹿にして終わりな奴より、
自分の意見をちゃんと言える人と仕事したいよ。
で、お前の意見は？
どういう場合に限ってfreeしなくていいと言う？
0077デフォルトの名無しさん
2012/11/21(水) 00:07:01.66プログラムが終了する前に、確保したメモリを解放しなければならな いか。
A:
その必要はない。まともなオペレーティングシステムならきっとプロ グラムが終了した時点ですべてのメモリを取り返すだろう。
にもかか わらず、個人向けコンピュータ(PC)の中にはメモリを取り戻すことが 確実にはできないものもあるようである。
ANSI/ISO C規格から結論つ けられることは、解放してくれるかどうかは「実装の品質がどれくら い高いかによる」ということだけである。
References:
ANSI Sec. 4.10.3.2; ISO Sec. 7.10.3.2.
0078デフォルトの名無しさん
2012/11/21(水) 00:11:49.69クロスプラットフォームなのでまともじゃないオペレーティングでも動かすことがあるかもしれない。
プログラムが終了する前に、確保したメモリを解放しなければならな いか。
A:
とうぜん解放する必要がある。
0079デフォルトの名無しさん
2012/11/21(水) 00:15:31.13不自然な答えだよな。
OSがまともであるならと
前提をつけて結論を書いてどうするんだろう？
そのあとでまともじゃない場合があると認めてるのにね。
で、最後の行で話をすり替えてる。
0080デフォルトの名無しさん
2012/11/21(水) 00:20:22.020081デフォルトの名無しさん
2012/11/21(水) 00:26:55.34Q. プログラムが終了する前に、確保したメモリを解放しなければならな いか。
A. プログラム側でfreeしなくても通常はOSが解放してくれるので直接問題が起きることはありません。
しかしながらそのようなことを気にしなくていけないのであれば設計上の問題がある可能性が高いです。
ライブラリ自体がメモリ解放の責任をもっているのであれば終了時にメモリが確保されたままになることはありません。
ライブラリの使用者側がメモリ解放の責任を持つのであれば、適切な場所でメモリを解放してください。
それなりの規模のソフトであれば、終了間際までメモリを確保したままになることはないはずです。
0082デフォルトの名無しさん
2012/11/21(水) 00:33:26.31簡単なツールなのでmain一つで終わっていた。
freeは必要ないということで省略した。
そのうち拡張されコードが増えていった。
さすがに見通しが悪くなったので関数に分けた。
でもfreeは必要ないということで書かなかった。
一つのファイルだけではなく、複数のファイルに対応した
でもfreeは書かなかった。
たくさんのファイルを処理した時、メモリが足りなくなった。
freeを書かないメリットはあったのだろうか？
0083デフォルトの名無しさん
2012/11/21(水) 00:59:45.46異常系のテストケースが不十分だったのでフィールドでセグメントフォルトが発生した。
必死になってfreeを書いたメリットはあったのだろうか?
0084デフォルトの名無しさん
2012/11/21(水) 01:07:58.93＞Q. プログラムが終了する前に、確保したメモリを解放しなければならな いか。
俺なら
Ａ．開放しないことでたとえなにが起きても自分で責任とれるならやらなくていい。
わざわざfreeが用意してある意味は自分で考えなさい。
0085デフォルトの名無しさん
2012/11/21(水) 01:17:41.31じゃあ異常系でのみ省けばいいだろ。
今は正常な終了時の話だ。
いると認めたのなら、そういえ。
0086デフォルトの名無しさん
2012/11/21(水) 01:32:28.680087デフォルトの名無しさん
2012/11/21(水) 01:36:50.48はい。この話はもう終わり。
0088デフォルトの名無しさん
2012/11/21(水) 01:42:39.81お前ら、ライブラリがエラーを返したら即プログラム終了かよ。
素人PGはお気楽でいいな。
0089デフォルトの名無しさん
2012/11/21(水) 02:00:23.23相手にしなくていいぞ。
信じるものは救われる
0091デフォルトの名無しさん
2012/11/21(水) 04:07:47.39これ以上書く奴は馬鹿かチンパンジー↓
0092デフォルトの名無しさん
2012/11/21(水) 07:53:04.420093デフォルトの名無しさん
2012/11/21(水) 09:06:06.17例外で処理するのが一般的？
deleteするときもNULLチェック必要？
0094片山博文MZボット ◆0lBZNi.Q7evd
2012/11/21(水) 10:16:00.93new(std::nothrow)の場合はNULLチェック必要。普通のnewはstd::bad_alloc例外を投げるのでNULLチェック不要。
deleteについてはNULLチェック不要。
0095デフォルトの名無しさん
2012/11/21(水) 10:24:10.880096デフォルトの名無しさん
2012/11/21(水) 10:31:26.78俺は他人の意見を馬鹿にして終わりな奴より、
自分の意見をちゃんと言える人と仕事したいよ。
で、お前の意見は？
どういう場合にfreeしなきゃいけないという?
0097デフォルトの名無しさん
2012/11/21(水) 10:36:38.040098デフォルトの名無しさん
2012/11/21(水) 21:42:04.68手術中にメモリ不足で電力供給されなくなって患者を殺したらどう責任取るの？
お前の命じゃ全然足りないよ？
0099デフォルトの名無しさん
2012/11/21(水) 22:00:41.600100デフォルトの名無しさん
2012/11/21(水) 22:19:33.25ついに本性出したか
そういう機器だとメモリ確保しないという発言はメモリリークが危険だということを分かってるからだろ？
GUIアプリでもイベント報告毎にメモリリークしてれば数時間でアプリが落ちる
freeが要らないと言ってるのは職がなく暇だから面白がって煽ってるだけの連中だけ
本気でfree要らないと言ってるやつはメモリの存在を気にかけたことがない
宇宙の素粒子ひとつひとつにデータを書き込めるがごとくメモリ動的確保しまくる
そんな人間
0101デフォルトの名無しさん
2012/11/21(水) 22:46:19.360102デフォルトの名無しさん
2012/11/21(水) 22:54:28.40Q. ○○（レアケース）の場合はどうするの？
A. レアケースは例外でいいよｗ
0103デフォルトの名無しさん
2012/11/21(水) 22:57:38.25終了前のfreeそのものがレアケースなんだよな。
アプリの長い生存期間のうち最後の一瞬でしか無い。
0104デフォルトの名無しさん
2012/11/21(水) 23:06:29.93> むしろdeleteした後そのポインタにNULLを入れる行為に意味があるのかどうかのが気になるな
例外処理の簡略化のためのコードだよ。
deleteしたあとでNULLを入れておくと
例外がどこで起きたとしても
とりえあえずdeleteしておけばよくなる。
オブジェクトが存在している → deleteで消される。
オブジェクトが存在してない(NULLが代入されている) → delete NULL は無害であると保証されている。
0105デフォルトの名無しさん
2012/11/21(水) 23:07:58.56かなり昔のC++はnewでメモリ不足だったらNULLが帰ってきたんだよね。
一般的にはnewはエラーが起きれば例外を発生させる。NULLは帰ってこない。
0106デフォルトの名無しさん
2012/11/22(木) 00:10:18.49書くには楽だが、なんつーか、おじさんなんでも例外っていうのはキライだな
0107デフォルトの名無しさん
2012/11/22(木) 00:23:45.200108デフォルトの名無しさん
2012/11/22(木) 01:29:45.92お前バカだな。かわいそうなくらいバカだ。何が論点なのか全然理解していない。
0109デフォルトの名無しさん
2012/11/22(木) 02:23:34.87>一般的にはnewはエラーが起きれば例外を発生させる。NULLは帰ってこない。
値は何が入りますか
0110デフォルトの名無しさん
2012/11/22(木) 02:29:53.70「mainだから」「exitするから」などと言って書いたコードは、その条件に依存することになり、条件が変わった途端に正常に動作しなくなる。
その際のメンテナンス性を考えて組むなら良いだろうが、freeやdeleteすら面倒臭がる輩がそんな事を気にする訳がない。
(そもそもfree/deleteの徹底自体が、再利用時のメンテを省くための知恵である。)
0111デフォルトの名無しさん
2012/11/22(木) 02:50:26.74・モジュールの中でのみ有効なオブジェクトを確保したならモジュールの中で解放する
・引数は出来るだけ(納期やパフォーマンスの兼ね合いもあるが)チェックする
面倒臭がらないよう日頃から徹底していれば、バグの原因の切り分けの手間や、
自分の担当しているモジュールの責任追求も緩和される。
0112デフォルトの名無しさん
2012/11/22(木) 02:52:39.68追加
・モジュール内で呼ぶ外部モジュールから返ってくるエラーもちゃんとチェックする
0113デフォルトの名無しさん
2012/11/22(木) 02:59:50.720114デフォルトの名無しさん
2012/11/22(木) 03:50:13.04解放せずに戻り値として返す場合は必ずグローバル変数で保管
atexit()の中でNULLじゃないポインタは全て解放
これでいけるんじゃね？
0115デフォルトの名無しさん
2012/11/22(木) 04:09:15.02すばらしい。ありがとう。
0116デフォルトの名無しさん
2012/11/22(木) 06:16:16.84グローバル変数使うのもどうかとおもうが、
> atexit()の中でNULLじゃないポインタは全て解放
こんなんだと、どうせすぐバグ埋め込むよ。
0117デフォルトの名無しさん
2012/11/22(木) 06:42:38.700118デフォルトの名無しさん
2012/11/22(木) 08:36:37.55例外のことを知ったほうがいいよ。
newを行った後に、値を代入するのだから
newが行えなければ、値は代入前の値のままだ。
0119デフォルトの名無しさん
2012/11/22(木) 09:07:29.23宣言時(newより前)に=0してからnew使うようにします。
0120デフォルトの名無しさん
2012/11/22(木) 13:33:53.26ローカルヒープつくって適当なところで一括解放ってやるよね。
細かくメモリ確保・解放するなんて頭良くないとやってらんない。
0121デフォルトの名無しさん
2012/11/22(木) 13:45:11.81どこかでfreeしてて二重にfreeするパターンだな
0122デフォルトの名無しさん
2012/11/22(木) 14:02:05.66>>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();
//処理…
}
0123デフォルトの名無しさん
2012/11/22(木) 14:16:54.24mainの最後にまとめて自分で管理しているメモリー
ポインターを解放するとか本末転倒だろ。
ポインター変数をグローバル変数にして云々とか
それってCのランタイムライブラリぃの再実装に過ぎないだろ。
0124デフォルトの名無しさん
2012/11/22(木) 15:50:53.69> atexit()の中でNULLじゃないポインタは全て解放
こういうのって、大抵リンクドリストが使われた場合とか、マルチスレッドの場合とか、
シグナル受けた場合の考慮が抜けててgdgdになる。
全部考慮して書けないことはないけど、そこまでやる価値があるようには思えない。
0125デフォルトの名無しさん
2012/11/22(木) 18:22:36.640126デフォルトの名無しさん
2012/11/22(木) 18:40:55.13つまり解放後のNULL埋めを徹底しとけばfreeやdeleteが多過ぎて無問題。
0127デフォルトの名無しさん
2012/11/22(木) 18:47:44.98構造化プログラミング辺りから学び直した方が良いんじゃないか?
0129デフォルトの名無しさん
2012/11/22(木) 19:38:10.980130デフォルトの名無しさん
2012/11/22(木) 20:06:09.15関数/ブロックから抜けるときにfreeしない馬鹿はいないだろ
いないよね？
0131デフォルトの名無しさん
2012/11/22(木) 23:36:10.82ほらな、そんな負け惜しみしか言えないだろ？
ゴミは黙ってな
0132デフォルトの名無しさん
2012/11/23(金) 00:00:10.660133デフォルトの名無しさん
2012/11/23(金) 01:25:51.040134デフォルトの名無しさん
2012/11/23(金) 10:45:30.95お前バカだな。かわいそうなくらいバカだ。
> そういう機器だとメモリ確保しないという発言はメモリリークが危険だということを分かってるからだろ？
そういう機器ではプログラムの起動時にメモリ確保して、プログラムが生き続ける限りはfreeする必要が無いからだ。
そもそもmalloc/freeは無い。
バカは黙ってろ。ｗｗｗ
0135デフォルトの名無しさん
2012/11/23(金) 10:50:49.50俺が前に使った組み込み機器はmallocとか実装されていなくて
スタックも限界あるからローカル変数は小さいものだけ。
あとはグローバル変数を使っていたな。
0136デフォルトの名無しさん
2012/11/23(金) 18:50:43.35通じないみたいだな日本語
韓国人か猿だろお前
0137デフォルトの名無しさん
2012/11/23(金) 19:31:40.45そもそもmallocが無い環境の話を混ぜ込むとか…
最初から読んでないのか、揚げ足取りたいだけなのか、論点ずらしたいのか知らんがアフォ丸出し。
0138デフォルトの名無しさん
2012/11/23(金) 19:39:07.080139デフォルトの名無しさん
2012/11/23(金) 22:16:54.390140デフォルトの名無しさん
2012/11/23(金) 22:18:49.73そのようなmallocの無い環境を持ち出したバカは>>98
0141デフォルトの名無しさん
2012/11/23(金) 23:06:21.29>100
>「そういう機器だとメモリ確保しない」という発言はメモリリークが危険だということを分かってるからだろ？
mallocしない環境もあるのがメモリリークの危険性を示してると>100は主張してるのに
ドヤ顔で「mallocの無い環境もある」とか言っちゃう>134,135…
0142デフォルトの名無しさん
2012/11/23(金) 23:24:55.29> mallocしない環境もあるのがメモリリークの危険性を示してると>100は主張してるのに
これがfree教信者の思考停止というやつだな。
mallocが提供されてない環境はメモリリークの危険性を考えて提供されていないわけじゃない。
かわいそうなくらいのバカ。
0143デフォルトの名無しさん
2012/11/24(土) 00:33:50.33「mallocしない」を「mallocが無い」だと勝手に解釈しちゃう奴。
大前提を勝手に外して話の軸をずらしてんじゃねーよ。
0144デフォルトの名無しさん
2012/11/24(土) 01:00:42.81環境の話してるんだが、
mallocしない方針の話じゃないよ。
0145デフォルトの名無しさん
2012/11/24(土) 01:06:39.81お前壊滅的にバカだな。吐いたつば飲み込むなよ。
> そういう機器だとメモリ確保しないという発言はメモリリークが危険だということを分かってるからだろ？
「(mallocが提供されてないから)freeしないんで」をリスキーだからメモリ確保しないと決めつけたのはお前。
mallocくらいでバグつくるとビビってるヘッポコはブラウザゲームでも作ってろ。ｗｗ
0146デフォルトの名無しさん
2012/11/24(土) 01:12:58.67mallocしない環境って
どういう意味だ？
0147デフォルトの名無しさん
2012/11/24(土) 01:13:26.840148デフォルトの名無しさん
2012/11/24(土) 01:47:38.520149デフォルトの名無しさん
2012/11/24(土) 01:58:38.980150デフォルトの名無しさん
2012/11/24(土) 02:14:31.470151デフォルトの名無しさん
2012/11/24(土) 09:15:49.250152デフォルトの名無しさん
2012/11/24(土) 09:28:22.56直後なら流石に「なら確保すんなよカス」だな
0153デフォルトの名無しさん
2012/11/24(土) 09:42:18.98「mallocしてもfreeは不要」なら議論の余地はあるが...「mallocの後にfree不要」だからな...
0154デフォルトの名無しさん
2012/11/24(土) 09:58:58.62Cならスタックが壊れる。
0155デフォルトの名無しさん
2012/11/24(土) 12:33:37.47勝手に「直」を付け足すな。
0156デフォルトの名無しさん
2012/11/24(土) 12:35:19.97お前らみたいに勝手な解釈する馬鹿が居るからコーディング規約がガチガチになっていくんだぞ。
malloc()/free() に関するコーディング規則ってよくあるのでしょうか？
win32api は対応する malloc()相当機能 と free()相当機能は同じ関数に存在すべし、感に満ちあふれていますけれども
0158デフォルトの名無しさん
2012/11/24(土) 17:15:27.19どっちかというと、それは「書き忘れないように同じ階層に書いといた方がいいよ」的な
話だね
厳密に守る義務はもちろんないけど、スッキリするんだよね
0159デフォルトの名無しさん
2012/11/24(土) 17:16:38.18char *po;
po = (char *)malloc(sizeof(char) * 128);
free(po);
これをmallocした後にfreeするって言うんじゃないのか？
0160デフォルトの名無しさん
2012/11/24(土) 17:29:11.56そのコードになんの意味があるのかね？
0161デフォルトの名無しさん
2012/11/24(土) 17:35:49.44現実にはやらないだろうってコードを
想像していたバカって他にもいるの？ｗ
0162デフォルトの名無しさん
2012/11/24(土) 17:40:43.38君らが言いたいのは
char *po;
free(po);
po = (char *)malloc(sizeof(char) * 128);
って事だなw
0163デフォルトの名無しさん
2012/11/24(土) 17:46:05.81俺はそんな事言ってないし、
思ってもいない。
アホすぎて考えつかないそのコードを考えたのはお前だろ。
そこにコードを書いてしまったのが仇となってる。
お前が思いついた証拠だ。
0164デフォルトの名無しさん
2012/11/24(土) 17:47:28.83ん?
>>159はおかしいか？
スレタイに沿ったコードじゃん
0165デフォルトの名無しさん
2012/11/24(土) 18:05:51.48スレタイにそっていても
そのコードに意味は無いよ。
だから誰もそんなコードの話はしていない。
ここまでは理解できる？
0166デフォルトの名無しさん
2012/11/24(土) 18:17:13.32一旦mallocした後のfreeが不要とは言えない
0167デフォルトの名無しさん
2012/11/24(土) 18:32:05.670168デフォルトの名無しさん
2012/11/24(土) 18:41:22.870169デフォルトの名無しさん
2012/11/24(土) 20:22:33.56不要といってるやつは一瞬で終了するプログラムしか組んだことがない似非プログラマらしい
QZも宿題スレでソート組むとかその程度しかしてないし
0170デフォルトの名無しさん
2012/11/24(土) 20:30:51.49そして例外の基準はケースバイケースで異なってくるわけだが、バカはそれを
理解せず穴だらけの経典を押し付けてくる。挙句のはてにシグナル禁止する羽目になる。
0171デフォルトの名無しさん
2012/11/24(土) 20:42:27.54スタックオーバーフロー避ける為に
意図的にヒープから割り当てることはあるんじゃ無いの？
完全に禁止するのではない、一時的にマスクするだけだ。
ループ中に、マスクしていたシグナルを有効にする瞬間を作る。
マスク中に到着したシグナルはこの瞬間において必要に応じてシグナルハンドラにジャンプする。
マスク中に到着したシグナルであっても（複数が一つにまとまることはあっても）消えることはない。
旧来のsignal()は扱いにくい、sigaction() が便利である。
つ>>41 http://toro.2ch.net/test/read.cgi/tech/1313183984/592-593
シグナルハンドラの中にまでfree() を記述しておく必要はないと思うが、かりにそうするとしても格別困難ではない。
おいおい、QZはfree()信者、すなわち malloc()したもの宜しくプロセス終了時にfree()すべき教の（熱心でない）信者だ。
0174デフォルトの名無しさん
2012/11/24(土) 21:20:11.52素人発見
0176デフォルトの名無しさん
2012/11/24(土) 21:48:31.24160だけど、きみはなにいってるの？
0177デフォルトの名無しさん
2012/11/24(土) 23:00:26.79普通シグナルみたいな例外的な(環境によって対応してない)ものは、基本則(この場合mallocしたらfreeする)とは
別に言及するべきだと思う。
0178デフォルトの名無しさん
2012/11/24(土) 23:19:53.71mallocしたらfreeするを原則とするなら、シグナルくらいは対応しておけよ。
CPU引っこ抜かれた時にまで対応しろとは言わないからさ。
まああれだ、
QZ が>>170のソースにmalloc() があっても free()がない、とけちをつけたのが発端、
というか QZは恥知らずで糠に釘、
というか >>50=QZ で実は >>170 も QZ も認識は同じだと思う。
というか 単なる泥仕合
0180デフォルトの名無しさん
2012/11/24(土) 23:33:51.720181デフォルトの名無しさん
2012/11/24(土) 23:41:23.94スッキリした頭でないといいコードはかけんよ
0183デフォルトの名無しさん
2012/11/25(日) 01:12:38.46そこまで重要なら、何故malloc/freeみたいにstdlibに入ってないんでしょうねぇ。
0184デフォルトの名無しさん
2012/11/25(日) 01:31:53.80OS依存だからだろ。
C言語はOS依存の機能は搭載しない。
0185デフォルトの名無しさん
2012/11/25(日) 02:01:32.16もちろんstdlibには入ってませんが。
0186デフォルトの名無しさん
2012/11/25(日) 02:45:21.50まともなOSならプログラマの思考を読み取って適切に対処するはず
仕組みはmallocしたアドレスを自動で判断してfreeするのと同じ
0187デフォルトの名無しさん
2012/11/25(日) 04:04:56.74ちげーよ。教えてやらんけど。お前はシグナル処理をしらない素人。
0188デフォルトの名無しさん
2012/11/25(日) 04:30:12.680189デフォルトの名無しさん
2012/11/25(日) 05:26:54.55その素人に見下された気分はどうだ? Qz
0190デフォルトの名無しさん
2012/11/25(日) 05:42:01.55規格名をくわしく
0191デフォルトの名無しさん
2012/11/25(日) 05:43:13.33シグナルを誤解しているというかsignal()しかしらないみたいだ
0192デフォルトの名無しさん
2012/11/25(日) 05:59:02.77基本知識らしいから>>188がもったいぶらずに説明してくれるよ。きっと。
基本知識らしいから誰でも気づくだろうしね。ｗｗ
基本知識を知らないQz ｗｗｗｗ
>>172 として考えているんだけれども >>189 は何を揚げ足とったつもりでいるのだろう？
volatile を忘れていたのはまずいがそれ以外に何があるのかわからない‥‥‥
まあ所詮泥仕合だからいいけど
0194デフォルトの名無しさん
2012/11/25(日) 09:06:47.980195デフォルトの名無しさん
2012/11/25(日) 16:17:07.750196デフォルトの名無しさん
2012/11/25(日) 17:30:12.08ちゃんとfreeするようにしてんの？ってことだろ。
0197デフォルトの名無しさん
2012/11/25(日) 20:26:13.81いや、オレは最初っからチンカスには教えないと宣言している。
>>188によると基礎知識らしいから>>188が教えてやれ。
0198デフォルトの名無しさん
2012/11/25(日) 20:28:53.240199デフォルトの名無しさん
2012/11/25(日) 21:25:11.760201デフォルトの名無しさん
2012/11/25(日) 21:41:12.94もったいぶってないでチンカス以外に教えてやれよ。基礎知識なんだろ。
signal() だろう？
マスクをあらかじめ設定するとかできないし、はいったらマスクしなおす場合もあるし、ほかいろいろめんどうで、
そもそもSystemV/BSD で挙動がかわったりするし、
こいつを使ってどうこうするのは不便というか不可能。
MEM00-C. メモリの割り当てと解放は、同じ翻訳単位内の同一抽象レベルで行う
ttps://www.jpcert.or.jp/sc-rules/c-mem00-c.html
0204デフォルトの名無しさん
2012/11/25(日) 22:14:40.01確保するモジュールと利用するモジュールが異なることなんてざらにあるのに無茶言うな。
0205デフォルトの名無しさん
2012/11/25(日) 22:19:11.800206デフォルトの名無しさん
2012/11/25(日) 22:27:17.79確保するモジュールと解放するモジュールについて言ってるのにどうして利用するモジュールが出てきた？頭大丈夫か？
0207デフォルトの名無しさん
2012/11/25(日) 23:23:22.930208デフォルトの名無しさん
2012/11/25(日) 23:39:43.61往生際がわるい。必死すぎる。素人。
0209デフォルトの名無しさん
2012/11/25(日) 23:41:31.09モジュールAがあってそこでメモリを確保する。
モジュールAを使うモジュールBがある。
この時モジュールBは、モジュールにAに対して例えば
OpenHandle()を呼び出す。そしてモジュールAはメモリを確保する
モジュールBは不要になったら、モジュールに対して
CloseHandle()を呼び出す。そしてモジュールAはメモリを解放する。
モジュールAで確保したメモリを、モジュールBで解放してはいけない。
同一翻訳単位内の、同一抽象レベルで行うというのはこういうことなんだが
わからなかったのか？
0210デフォルトの名無しさん
2012/11/25(日) 23:48:04.05え？signal() なんかいまどき使うのですか？普通 sigaction() ではないですか？
0211デフォルトの名無しさん
2012/11/26(月) 00:21:48.64signal(3)のハンドラでの制限ではないわけだが。
> え？signal() なんかいまどき使うのですか？普通 sigaction() ではないですか？
sigaction(2)を持つOSではsignal(3)はsigaction(2)で実装されてる。
そんな事も知らないで、signalじゃなくてsigaction使ってるオレってプロ。スゲーって自画自賛してるのか。ｗｗｗ
シグナル処理を知らない素人。ｗｗｗ
0212デフォルトの名無しさん
2012/11/26(月) 00:25:42.74それこそ低脳だ
0213デフォルトの名無しさん
2012/11/26(月) 00:29:37.97>>200の制限はsignal(3)のハンドラの制限じゃないから。
signalを使うとか関係無いの。
0214デフォルトの名無しさん
2012/11/26(月) 00:45:13.79> モジュールAがあってそこでメモリを確保する。
> モジュールAを使うモジュールBがある。
なんでそんな勝手な条件を入れるんだ。
0215デフォルトの名無しさん
2012/11/26(月) 00:46:21.05素人丸出し。ｗｗｗ
無い知恵絞ってsigactionで書いた、シグナル喰らってもfreeするお経を否定されたのがそんなに悔しいのか?
あのバカげた方法は処理時間が長い検索処理などでは使えないクソ実装。止めたくなったらどうすんだよ。ｗｗ
0216デフォルトの名無しさん
2012/11/26(月) 00:47:01.65しかも、問題の解決になってない。。
0217デフォルトの名無しさん
2012/11/26(月) 00:49:10.02低レベルというというかなんというか。最近の教科書は 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
0219デフォルトの名無しさん
2012/11/26(月) 00:57:46.00MEM00-C. メモリの割り当てと解放は、同じ翻訳単位内の同一抽象レベルで行う
って書いてあるだろ？
「翻訳単位」の意味をググった方が良いかと。
あと貴方が想定している「問題」はMutexとか参照カウンタとか使うのが一般的な解決策では。
0221デフォルトの名無しさん
2012/11/26(月) 01:02:54.43知ってるよ。
だから、MEM00-Cじゃ根本的な解決になってないと言ってる。
freeをラッピングしてるだけだ。
>>200 の制限がめんどくさいと思えばいつでもいかようにこっちで振る舞いを指定できるのが sigaction()。
今回、複数のシグナルに対して一つのシグナルハンドラを共用したが、signal() でそれをやるのは大変だ。
>>215
＞あのバカげた方法は処理時間が長い検索処理などでは使えないクソ実装。止めたくなったらどうすんだよ。ｗｗ
シグナルマスクを解除する瞬間をつくれば、そのときに、保留されていたシグナルにしたがってハンドラに処理が渡るだけでは？
まあ、マスクする時間帯が多少長いけれども
＞シグナル喰らってもfreeする
ことはそんなに難しくないことがわかったわけだ、それで十分。
0223デフォルトの名無しさん
2012/11/26(月) 01:03:34.67> MEM00-C
0224デフォルトの名無しさん
2012/11/26(月) 01:15:34.180225デフォルトの名無しさん
2012/11/26(月) 01:22:03.921つのソースから、複数のモジュールを生成することはできるでしょ
0226デフォルトの名無しさん
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
0227デフォルトの名無しさん
2012/11/26(月) 01:24:24.45問題ってなんの？
全く関係ないはなししてるだろｗ
0228デフォルトの名無しさん
2012/11/26(月) 01:32:37.68> >>200 の制限がめんどくさいと思えばいつでもいかようにこっちで振る舞いを指定できるのが sigaction()。
バカ。ｗｗｗｗ
せっかく>188がもったいぶらずに教えてくれてる煮に猫に小判、豚に真珠、馬の耳に念仏。ｗｗｗ
0229デフォルトの名無しさん
2012/11/26(月) 01:39:31.90ここで聞いても答えはでんだろ
他の人の意見を聞くならまだしも
お前が信じるかどうかなんて知ったことじゃねえ
だ・か・ら、今回は、
> シグナル喰らっても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() ならそれも可能。
0231デフォルトの名無しさん
2012/11/26(月) 09:09:49.04なんか、そのために生きてるって感じがするな君のいってることを実現したコードって
やりたいことは別にあるのに…って感じがするが（よく考えるのはいいことだけどコード
の本懐ではないと聞こえる）
0232デフォルトの名無しさん
2012/11/26(月) 10:10:25.63> これはシグナルハンドラを処理中に同じハンドラに再入する可能性があればこその制約、であれば再入させないようにハンドラに入る時点でシグナルをマスクすればいい。
バカ。ｗｗｗｗ
非同期安全な関数の意味を全く理解できていない。ｗｗｗｗ
0233デフォルトの名無しさん
2012/11/26(月) 10:16:58.96シグナル処理すればfree教の教義に背くことなく簡単に出来るというので、
それじゃ作ってみろといって出来たのが
http://codepad.org/mLtuxDOF ｗｗｗｗ
処理中のシグナルを禁止するという長い処理の場合に停止不可能な腹絶倒の実装。 ｗｗｗ
0234デフォルトの名無しさん
2012/11/26(月) 12:17:28.80┃ ━┫┏┓┃┏┓┃ ━┫┏┓┃┏┓┃
┃┏┓┃┗┛┃┏┓┫ ━┫┏┓┃┃┃┃
┗┛┗┻━━┻┛┗┻━━┻┛┗┻┛┗┛
. _＿__,
／∧＿∧ ＼
./ <丶｀Д´>､｀、
/ /＼ ＼つ つ、ヽ
| | ,＼ ＼ ﾉ | |
ヽヽ し ＼ ＼） / /
＼ `＼_____＼' ／／
ヽ､ _＿＿_,, ／
┏━━┳━━┓┏┓┏┳━━┳━━┳━━┓
┃┏━┫┏┓┃┃┗┛┃┏┓┃ ┃ ━┫
┃┗┫┃┗┛┃┃┏┓┃┗┛┃┃┃┃ ━┫
┗━┻┻━━┛┗┛┗┻━━┻┻┻┻━━┛
ん、メイン側で無理苦理シグナルをマスクして（でもマスクをはずす瞬間も作っているだけれど‥‥）、というのがお気に召さないのね。
>>231-233
要はシグナルハンドラが重すぎる、ということでいいでしょうか？
ではちょっと考え直します。メインに少々手を加えないといけないのが好みではないのですが、まあ仕方がない。
しばしお待ちを。
え？リエントラントではない関数は使うな、てことじゃないの？割り込みハンドラと同様の意味合いだとばかりおもっていたんですけれどね。
では「非同期安全な関数」とはどういう意味？
そちらこそわかっていないような気がするなあ‥‥‥。
ハンドラがリエントラントでなければ、メイン側で再入しないように捻じ曲げるのもありだと思ったんですけどね。
0237デフォルトの名無しさん
2012/11/26(月) 13:49:01.86違う。お前はなんというタイトルのスレにレスをしてるんだという話。
シグナルを主題に語るな、malloc, freeを語れ。
0238デフォルトの名無しさん
2012/11/26(月) 16:29:28.38まあLinuxとかBSDでなら動きそうな気もするが。
0240デフォルトの名無しさん
2012/11/26(月) 21:59:31.44いやいやlinuxというかglibcだけど余裕でデッドロック起こして止まるよ。
フラグだけたててメイン処理で見るなりEINTR拾うなりせんといかん。
0241デフォルトの名無しさん
2012/11/26(月) 22:26:14.50writeは大丈夫だね。
http://linuxjm.sourceforge.jp/html/LDP_man-pages/man7/signal.7.html
0242デフォルトの名無しさん
2012/11/26(月) 22:30:52.18世の中にはPOSIX準拠風のシステムが多い。
書いてみて、はじめて、>>172 よりもこっちの方がまっとうでわかりやすいと痛感しました。
http://toro.2ch.net/test/read.cgi/tech/1313183984/595
>>231
コメントありがとうございました。
>>232 >>233
最後までお付き合いくださり感謝です。
0244デフォルトの名無しさん
2012/11/27(火) 00:58:15.650246デフォルトの名無しさん
2012/11/27(火) 21:28:53.15修正前よりダメっぷりが倍増してる。
0247デフォルトの名無しさん
2012/11/27(火) 22:46:04.66そんなに多いかねぇ
writeに関してはLinux Solaris HP-UX AIX OS X(BSD)の
manには記載されているが他にはあるかね？
>>246
どこがどう悪いのか例示出来ないのなら同類。
0248デフォルトの名無しさん
2012/11/27(火) 22:57:10.77基本的な事だから、おせっかいな>188みたいのが教えてくれるだろう。
倍増といわれてもねえ。
fgets() 中の割り込みはキャッチして終わることだけを確認してはいます。
0251デフォルトの名無しさん
2012/11/28(水) 19:44:50.81http://toro.2ch.net/test/read.cgi/tech/1313183984/596
0253デフォルトの名無しさん
2012/11/29(木) 13:49:38.120254デフォルトの名無しさん
2012/11/30(金) 00:05:41.66GCってタモリが「おにぎり一個でも買えます」とかCMやってるやつか？
0255デフォルトの名無しさん
2012/11/30(金) 11:28:31.840256デフォルトの名無しさん
2012/11/30(金) 22:42:34.870257デフォルトの名無しさん
2012/12/01(土) 12:48:59.53やってる事がほとんど変わらず、おじさんなつかしいよ。
あのころに戻りたい。
結局、freeはいらない派、メモリリークしてもいい派の人なんて議論の中にはいなくて、
オブジェクトの寿命を意識して、それが、プログラムの寿命とほぼ等しかったら、
オブジェクト解体のコストを払うよりも、OSがプロセスの後始末するときに
ついでにやってもらた方がいいだろJKな人がいるだけでしょ。
つまり、freeはオブジェクトの寿命を意識して適切に行え派
（ライブラリ化とか、再利用も考えて総合的なコストが最小になるように
常に考えろ派)
で、それはスレタイの「main以外」という文言から、free必要派の人も
わかってるんでしょ ?
だけど、世の中にはオブジェクトの寿命とか考えずfreeしない
ど低脳も少なからずいるからfreeは絶対必要って言ってかないと
世の中は回らないって思っているんでしょ ?
だったら、freeは必要じゃない場合もあるよ派の人には
愚鈍な人類に今すぐ英知を与えろって言うのがこの議論の
正しい姿なんじゃないかな。
0258デフォルトの名無しさん
2012/12/01(土) 12:55:29.39siganalがからむとfreeするのが難しいって話なのかな ?
でも、siganalが絡もうがfreeしなきゃいけないときは
freeしなきゃいけないんじゃないかな。
(なので、このすれのもともとの議論とはずれているよね。
signalの絡むときの安全なfreeの話題も興味あるので
続けてほしいけど。)
アマチュアの分際でいうのもなんですが、宿題スレでは 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 のようにすぐにミスります。
0260デフォルトの名無しさん
2012/12/01(土) 13:14:49.29その通り。いるときはいる。
シグナルで設定ファイルを読み直したりする場合にはよくfreeが絡む。
データベースを壊さないようにしたり、一時ファイルを残さないようにするの
にも必要だけど、古くからあるプログラム(svn gitなど)でも一時ファイルが残っ
てしまったり、データベースが壊れることもあった。そのくらいシグナルを正
しく扱うのは難しい。
だから必要のない場合なら無理して実装することはないと思う。
0261デフォルトの名無しさん
2012/12/01(土) 13:24:39.82mtraceじゃだめなの？
0262デフォルトの名無しさん
2012/12/01(土) 13:30:09.79割り込み処理があることを意識したロジックが書けない無能の叫びだな。
情報ありがとうございます。
#define ばりばり、のときの使い心地はどうでしょうか？
printf() デバッグですませられるのならすましたいです。
0264デフォルトの名無しさん
2012/12/01(土) 13:53:25.36> siganalがからむとfreeするのが難しいって話なのかな ?
違う。
再利用する可能性がない場合にfreeしなかったら、ド低能がからんできたから、
「そういうお前はどうなんよ。シグナル喰らった時にfreeしてないじゃん」と
からかってやった結末。
0265デフォルトの名無しさん
2012/12/01(土) 22:33:53.09プロセス終わるときに
解放してから終わるのと
放置してバッサリ終わるのでは
速さが違うとかなんとか
0266デフォルトの名無しさん
2012/12/02(日) 00:07:04.75スワップアウトされていたメモリをfree()で開放しようとすると、一旦その部分をスワップインすることになる。
バッサリ終わった場合、フツーのOSであればそんなことにはならないんで、素早く終了できる。
大して保存するデータもないはずなのに妙に終了に時間がかかるアプリと、
同じような規模なのにサクッと終了するアプリがあるのはその辺が効いてるんじゃないかな。
free()不要の「不要」を消極的に考えるからいろいろ議論()になるだけで、プロセスの終了をひとつの機能として
真面目に取り組んで、「速度効率のためfree()しないで終了する」という機能を実装する。
というのがここでいうfree()不要論者が言いたいことだと思う。
0267デフォルトの名無しさん
2012/12/02(日) 00:29:36.63なにいってんの？
少しぐらいはスワップインするかもしれないけど、
どんなに大量のメモリを確保していたとしても、
freeするのに必要なのは、ポインタと管理データ部分だけじゃん。
0268デフォルトの名無しさん
2012/12/02(日) 01:04:33.49自前でヒープ確保しmallocもどきを実装して、終了時は一々freeせずヒープごと削除ってのはよくやる。
0269デフォルトの名無しさん
2012/12/02(日) 06:53:09.41それが時間かかるんだよ
0270デフォルトの名無しさん
2012/12/02(日) 08:24:01.08素人考えですみませんが、free()での解放もOS(ライブラリ?)によるプロセスリソース解放も、
どちらもスワップアウトされていた一部メモリを一旦スワップインすることになりませんか?
> 大して保存するデータもないはずなのに妙に終了に時間がかかるアプリと、
> 同じような規模なのにサクッと終了するアプリがあるのはその辺が効いてるんじゃないかな。
サクッと終了するのは、ウィンドウが閉じるのが早いだけの体感的なもので、実際はウィンドウが閉じた後は
OS(ライブラリ?)で動く解放処理の分で少しモタつくようになりませんか?
0271デフォルトの名無しさん
2012/12/02(日) 09:06:04.06コーディングの手間に対して割が合わんな。
0272デフォルトの名無しさん
2012/12/02(日) 09:31:13.84ページイン/ページアウトだ。
>>270
ならない。
通常mallocされたブロック(mallocが返してきたポインタ)の前に管理用の情報が置かれている。(たとえば大きさとか)
freeする場合はこの情報にアクセスする必要がある。
OSがバッサリ解放する際にはこれらの情報にはアクセスする必要が無い。
0273デフォルトの名無しさん
2012/12/02(日) 10:01:57.06しかし、「スワップアウトされた状態での終了の速度」などという恐ろしくどうでもいいことに
こだわってfreeするかしないかコーディングに反映させるプログラマがいたとしたら、
そいつはセンスないだろ。
0274デフォルトの名無しさん
2012/12/02(日) 10:06:35.97終わるときのことばかり考えて答えを出すのは早計、世の中には原則終わってはならない、終わることなく動き
続けなければならないプログラムというものもある
例えば監視系とかね
0275デフォルトの名無しさん
2012/12/02(日) 10:10:24.17ひとつでも挙げられたら良いんじゃないの？
0276デフォルトの名無しさん
2012/12/02(日) 10:19:38.31レスありがとうございます。
ということは、malloc()先で呼んでいるメモリアロケータ(?)かどこかにある、
ページイン/ページアウトまでをも司るところが管理しているメモリ情報は、
ページアウトされないところにあるのかな？
0277デフォルトの名無しさん
2012/12/02(日) 10:22:27.55はあ? 終了するプログラムの話をしてるんだが。文脈読めないバカは絡むな。
>>275
その、必ずfreeしなけりゃならない理由(教義)が薄弱なんだよ。
異常系はどうすんのよとか突っ込むとQzのようなオロカなハメに陥る。
捕捉不可能なシグナルというのが存在するので「必ずfreeする」は不可能でしょ。
異常系のfree() は QZ もあきらめていたんですけど？
問題は正常系の free() じゃなかった？
0279デフォルトの名無しさん
2012/12/02(日) 10:57:40.600280デフォルトの名無しさん
2012/12/02(日) 12:07:16.330281デフォルトの名無しさん
2012/12/02(日) 12:48:50.74じじーだってことがよくわかったな＾＾。ページって言った方が >267 もイメージしやすそうだな。
>>267
ページングの単位って4kbyteとかなんだよ。
ページングの単位より小さい単位でばかりmalloc()していた場合、
ページアウトしていたほとんどすべてがページインされることになるわけだ。
で、これだけじゃなくページアウトされるような状況なわけだから、
free()のためだけにしか意味を持たない領域がページインされることで、
ほかのアプリが使っていたメモリがページアウトされるんだな。
その後、ほかのアプリを使おうとするとそのページアウトされていたメモリが、
ページインしてくる。その間ユーザは重い思いをするんだ。
>>270,276
プロセスのメモリ空間としてのアドレスと、物理アドレスが別物なのは知っていると思うけれど、
それを結び付けているテーブルと、外部記憶ではどこを使っているという情報を破棄するだけで、
実体のメモリや外部記憶の中身を触ることはないんだ。
(セキュリティの観点から外部記憶のデータを塗りつぶすということもあるけれど、それは別の話)
この情報はCPU/MMUが参照するから、アプリが使うメモリとは別管理。
>サクッと…
メモリ少ない環境で Lotus Notes 使ってみると体感できるよ＾＾、きっと。
>>273
うむ。フツーはビジネスロジック上で、malloc()/free()なんて現れないはな。
こういうことを理解したうえでアプリの特性によって malloc()/free() をどう使うかを考えることなく、
必ずfree()っていうのが、思考停止って言われるゆえんじゃないかと思う。
ところで必ず free() っていうのはWin32以前からの古いWindowsプログラマと、
その末裔にその傾向が強いんだよね。GlobalAlloc()で痛い目に合ったのかな?
0282デフォルトの名無しさん
2012/12/02(日) 12:57:42.78細かなmalloc領域がキューで大量に繋がってたりしたら最悪なんだよね。
一々追いかけながらfreeするの面倒すぎる。
0283276
2012/12/02(日) 13:10:30.21> この情報はCPU/MMUが参照するから、アプリが使うメモリとは別管理。
なるほど。
その領域はページアウトされないから、パフォーマンスに影響しないということですか。
ありがとうございます。
0284デフォルトの名無しさん
2012/12/02(日) 14:11:43.72^^;;
0285デフォルトの名無しさん
2012/12/02(日) 14:17:51.500286デフォルトの名無しさん
2012/12/02(日) 14:38:24.90普通にどのOSでもやってんじゃないの？
MS-DOSとかITRONとかの人？
0287デフォルトの名無しさん
2012/12/02(日) 14:46:28.010288デフォルトの名無しさん
2012/12/02(日) 14:53:10.68ページテーブル自身もページングの対象だ。
x64だとページテーブルで0.5%くらいのオーバーヘッドがある。
4Gバイトの空間を管理するために20Mバイト。400Gバイトなら2Gバイト
こんなのに居座られたくない。
0289デフォルトの名無しさん
2012/12/02(日) 15:13:16.89これ本当？
ページテーブル領域はページアウトされないようロックしておくものだと思ってたのだが。
0290デフォルトの名無しさん
2012/12/02(日) 15:43:41.43>>283
単純に言えばそれに近い(>>288 参照)と思うけど、もうちょっと書くと。
その部分の処理はfree()しようがしまいが必須の処理で必ずOSがやることなのさ。
もし、それでパフォーマンスに影響が出るとしても必須のことだから仕方がない。
時間が解決してくれて、それが原因で落ちたりすることはないけど、CPUクロックだってリソース、
最終的に使うユーザの時間は大事なリソースなんだから、いらん処理で時間というリソースを
ダダ漏れさせていいわけない。いらん処理をすると消費電力(モバイル系だと超重要)も増えるしさ。
せっかくアプリが楽できるようにがんばっているのになんで任せてくれないの？
と日頃悲しい思いをしている環境依存部分の下層レイアを書くことが多い、じじいのぐち。
>>289
(表現が不正確かもしれんが)OSのテーブルの話じゃなくて、ユーザレベルのテーブルの話じゃないかな?
>>284
経験者のようだな＾＾
0291デフォルトの名無しさん
2012/12/02(日) 16:37:44.61本当だよ。ここがわかりやすい。
http://d.hatena.ne.jp/nonakap/20031016
i386ではページは2階層で管理されている。ページアウトされないのはPD。
PDが保持しているPDEを見ればわかるが、2階層目のPTEをページングできるよう、
ページ存在ビットが存在する。
0292デフォルトの名無しさん
2012/12/02(日) 16:43:09.97それハードウェアの話じゃんｗ
じゃなくてOSが管理してるメモリの話。
メモリ管理領域は、スワップ対象外メモリとして
OSから確保するでしょ。
0293289
2012/12/02(日) 17:00:35.04なるほど、PDは常に存在するとして、その先のPTはアロケーションしたときだけ生成されるのね。
少し賢くなったｗ
ただそれでも、割り込み禁止状態等でもPTEまではアクセスできるよう、領域ロックはしたほうがよさげ。
0294デフォルトの名無しさん
2012/12/02(日) 18:48:58.01記憶されるわけで、もしそこがページアウトされていた場合には一度ページイン
してアドレス獲得しないといけないかもね。
0295デフォルトの名無しさん
2012/12/02(日) 19:14:11.90#じじいおおすぎー;-b
0296デフォルトの名無しさん
2012/12/02(日) 19:21:24.22ページ管理のツリー段数とページサイズが違うくらいで。
0297デフォルトの名無しさん
2012/12/02(日) 20:38:27.130298デフォルトの名無しさん
2012/12/02(日) 21:20:30.82OSから受け取ったメモリブロックを切り分けてるだけだが。
0299デフォルトの名無しさん
2012/12/02(日) 21:20:52.90いやｗ
動き続ける中で何度も使用される機能なんて当たり前だがあるわけで、その中で
動的にやりくりすることもありますから勝手に終了をプログラム全体が終了する
ケースに限定しないで欲しいのだが
0300デフォルトの名無しさん
2012/12/02(日) 21:25:40.3320てん
0301デフォルトの名無しさん
2012/12/02(日) 23:34:39.56うっせ、カス。
プログラムが終わるときの話をしてるのに割り込んできて終わる話に限定するなとか、バカぬかすな。
お前、リアルでも空気読めないとかいわれてハブられてるだろ。
0302デフォルトの名無しさん
2012/12/03(月) 00:09:24.26Free不要なんて考えしたことなかったわ。
0303デフォルトの名無しさん
2012/12/03(月) 00:36:53.07原則必要として、但し書きでfree省略が許される/省略すべきと言った方が理解されやすい。
つーわけでfree不要と言い切るような奴とはやはり一緒に仕事したくないな。
0304デフォルトの名無しさん
2012/12/03(月) 00:42:33.02普通に終了しないで、exitでもすればいいじゃん。
強制終了すればメモリ解放しないで終われるよ。
0305デフォルトの名無しさん
2012/12/03(月) 00:43:54.970306デフォルトの名無しさん
2012/12/03(月) 01:59:21.160307デフォルトの名無しさん
2012/12/03(月) 02:03:04.75C++が絡むとexitもややこしいんだよね。
staticクラスのデストラクタはatexitに依存している事が多いので
exit(): staticデストラクタ=動く スタック上のデストラクタ=動かない
_exit(): staticデストラクタ=動かない スタック上のデストラクタ=動かない
リモートにセッションを持っていたりすると時々ややこしい事が起こる。
0308デフォルトの名無しさん
2012/12/03(月) 02:05:02.19スレタイ見てその話をしてるんならばかってだけだなお前が
0309デフォルトの名無しさん
2012/12/03(月) 02:14:39.71話の流れの読めないバカって本当に存在するんだな。お前退場。
0310デフォルトの名無しさん
2012/12/03(月) 07:36:53.890311デフォルトの名無しさん
2012/12/03(月) 07:44:12.39リモート側が糞。
0312デフォルトの名無しさん
2012/12/03(月) 12:52:20.41ケースを限定してこうだろっての展開しても結論は出ない
これまでもそうだし、これからもそう
0313デフォルトの名無しさん
2012/12/03(月) 13:58:17.00お前が議論に必要な知能をもっていないバカだという事は良くわかったから、これ以上絡むな。
>>274で見破っておくべきだったと反省。
0314デフォルトの名無しさん
2012/12/03(月) 14:56:07.75なんで俺が274なわけ？
見境なく噛みつくなよ
0315デフォルトの名無しさん
2012/12/03(月) 19:20:40.10>>274じゃないと言い逃れするんだな。
>>274は的外れだがテクニカルな議論を吹っかけてのでバカはバカだか救いようがある。
それ以降に参入したというならレスつける価値もない基地外。あ−、損した。
0316デフォルトの名無しさん
2012/12/03(月) 21:48:52.30一人相撲乙ｗ
気がすんだか？
0317デフォルトの名無しさん
2012/12/03(月) 21:56:33.81せっかく気持ちよく帰ってもえらえるところだったのに戻ってきちゃうじゃん
0318デフォルトの名無しさん
2012/12/03(月) 22:01:26.040319デフォルトの名無しさん
2012/12/04(火) 01:36:08.56まぁいいけど
0320デフォルトの名無しさん
2012/12/04(火) 01:48:47.43例えば組み込み系だといきなり電源を落とされる運用なんかもあるから、通常は存在する「終了の手続き」そのものが
発生しないなんてなこともあるから、その意味ではfree書かないこともあるよ
0321デフォルトの名無しさん
2012/12/04(火) 01:50:54.26普通にソフトだけ再起動ってなパターンもあるから、粗油ときは当たり前にここでの議論の対象になっちゃうけど
0322デフォルトの名無しさん
2012/12/05(水) 02:14:16.86オブジェクトの寿命 = プロセスの寿命
なオブジェクトのfreeが必要ではない
（というか開放できない。プロセスの寿命 = ∞なので)
と思うのだが
0323デフォルトの名無しさん
2012/12/05(水) 04:04:39.31ファイルを開いたらあたらしいオブジェクトをつくる。
ファイルを閉じたらそのオブジェクトもいらなくなる。
0324デフォルトの名無しさん
2012/12/05(水) 08:36:35.78バグもクリスマスセールで増量中。もはや何をやりたいのか意味不明。
http://ideone.com/DKgnoQ
0325デフォルトの名無しさん
2012/12/05(水) 19:06:21.56323のいうように、動いてる中で動的に取る、解放する、なんてなものがあるね
あなたのいうものは基本は静的に取ってるエリアの話だね
んー、こんどはどこがバグってますか？やりたいことは、^C, ^Z kill 引数なし、とかを無視することなんですが。
10万モリタポでぜひお願いします。
なお、free()教の教祖ではなくて一信者なんですけど。
0327デフォルトの名無しさん
2012/12/05(水) 21:00:43.06基地外宗教を他人に押し付けるような基地外信者は信者は盲目的に教義に従ってすべてのメモリをfreeしろよ。
オレならSIGKILLでも捕まえてfree出来るぞ。ｗｗｗ
意味ないからやらないけど。
おお〜、ぜひ教えてください、10万モリタポで
SIGINT, SIGQUIT, SIGTERM, SIGTSTP 対応でお願いいたします、sigkill はどうでもいいから
0329デフォルトの名無しさん
2012/12/05(水) 21:19:56.39ただし、お前が考えたプロトコルなんだから、だまし取られても泣くなよ。ｗｗｗ
0330322
2012/12/06(木) 00:17:03.82うん、そう。静的な領域。
とりあえず、プロセスがまだまだ生き続けるのに
オブジェクトが解放できる場合は絶対freeしなくては
ならないと思う。
なので、freeが必要か否かは時と場合によると考える。
じぶんの同僚は
「時と場合にとるなんてのはもっとも役に立たない言葉だ !!」
というけれど。
0331デフォルトの名無しさん
2012/12/06(木) 02:47:59.71static char buf[1024 * 1024];
int main()
{
// buf使った処理
return 0;
}
動的な領域を使って終了するプログラムがあっても
static char *buf;
int main()
{
buf = malloc(1024 * 1024);
// buf使った処理
return 0;
}
プロセスとしては配置されるアドレスが違うだけで意味としては変わらないよね。
前者にはbssの非ページ領域が割り当てられて、
後者はbrkで延長されたプロセスの非ページ領域(libcヒープ内)が割り当てられる。
0332デフォルトの名無しさん
2012/12/06(木) 09:12:53.85> とりあえず、プロセスがまだまだ生き続けるのに
> オブジェクトが解放できる場合は絶対freeしなくては
> ならないと思う。
> なので、freeが必要か否かは時と場合によると考える。
たった4行なのに矛盾してる。
0333デフォルトの名無しさん
2012/12/06(木) 19:02:38.39上3行が具体的な例で、下1行が一般化したもの
freeしなくても良い場合の具体的な例が示されていないだけ
0334デフォルトの名無しさん
2012/12/06(木) 20:35:08.060335デフォルトの名無しさん
2012/12/06(木) 21:04:46.130336デフォルトの名無しさん
2012/12/06(木) 21:11:41.91ダメな奴の典型。
0337デフォルトの名無しさん
2012/12/06(木) 21:18:42.58>>330と全く矛盾しない
0338デフォルトの名無しさん
2012/12/06(木) 21:40:55.79で、結局キミのいう「絶対」は例外あるのかい? ｗ
0339デフォルトの名無しさん
2012/12/06(木) 21:41:48.970340デフォルトの名無しさん
2012/12/06(木) 21:47:28.040341デフォルトの名無しさん
2012/12/06(木) 21:52:46.74んじゃ、その例外を列挙しろよ。
0342デフォルトの名無しさん
2012/12/06(木) 21:53:34.860343デフォルトの名無しさん
2012/12/06(木) 21:55:00.98その条件の外でまで成り立つわけではない
0344デフォルトの名無しさん
2012/12/06(木) 21:55:15.47では、まず絶対を提示してください。
さすれば私目が例外をお目にかけましょう。
0345デフォルトの名無しさん
2012/12/06(木) 21:58:28.85これがアスペというやつか。ｗｗｗ
「プロセスが生き続けている間」という条件下でキミのいう
「絶対」は例外あるのかい?
0346デフォルトの名無しさん
2012/12/06(木) 21:59:13.09絶対苦労すると思う。
なので、仕事で苦労するかどうかは時と場合によると考える。
0347デフォルトの名無しさん
2012/12/06(木) 22:00:27.36条件には「オブジェクトが解放できる場合」までが含まれる
0348デフォルトの名無しさん
2012/12/06(木) 22:01:31.46で、キミのいう「絶対」は例外あるのかい? ｗｗ
0349デフォルトの名無しさん
2012/12/06(木) 22:08:18.17ああ、その条件でいいよ。例外はあるのかい?
0350デフォルトの名無しさん
2012/12/06(木) 22:09:24.24>>337>>343
0351デフォルトの名無しさん
2012/12/06(木) 22:10:39.640352デフォルトの名無しさん
2012/12/06(木) 22:11:59.43全く理解できてないことが分かる
0353デフォルトの名無しさん
2012/12/06(木) 22:14:25.22「ある条件で絶対成り立つ命題があります、でも例外があります」と言ってる訳じゃなくて
「ある条件で絶対成り立つ命題があります、でも条件外では成り立ちません」と言っているわけだが、
あまりに低能すぎて理解できないんだろうなぁ
0354デフォルトの名無しさん
2012/12/06(木) 22:19:57.40で、命題は「絶対freeしなくてはならない」
で良いんだな。最後の訂正チャンスをやるが、訂正するか?
0355デフォルトの名無しさん
2012/12/06(木) 22:21:09.190356デフォルトの名無しさん
2012/12/06(木) 22:23:27.55例外として俺が間違っている場合を除く。
0357デフォルトの名無しさん
2012/12/06(木) 22:24:41.56「なので、freeが必要か否かは時と場合による」と矛盾しないことについては
全く問題ないよ
だってその命題は「プロセスがまだまだ生き続けるのにオブジェクトが解放できない場合」
についてはfreeが必要とも不要とも言ってないからな
0358デフォルトの名無しさん
2012/12/06(木) 22:29:41.440359デフォルトの名無しさん
2012/12/06(木) 22:34:21.02絶対freeしろとは書いてない>>330>>354
0360デフォルトの名無しさん
2012/12/06(木) 22:54:09.80はあ? バカか。
> だってその命題は「プロセスがまだまだ生き続けるのにオブジェクトが解放できない場合」
> についてはfreeが必要とも不要とも言ってないからな
解放できないオブジェクトはfreeしちゃいけないの。あたりまえ。
オブジェクトは解放出来るオブジェクトか解放できないオブジェクトの二種類で、
「解放出来るオブジェクトは絶対にfreeしろ」という命題を真とするならば、
「なので、freeが必要か否かは時と場合による」は矛盾する。
0361デフォルトの名無しさん
2012/12/06(木) 23:02:21.68その内容を>>359の直後に「矛盾する（キリッ」
って書き込めるのは凄い
0362デフォルトの名無しさん
2012/12/06(木) 23:18:58.41>>274が無理やり割り込んで切り替えた。
0363デフォルトの名無しさん
2012/12/06(木) 23:40:36.950364デフォルトの名無しさん
2012/12/06(木) 23:47:58.72確保できるかどうかすら分からない領域を必要とする時点で設計不良
0365デフォルトの名無しさん
2012/12/07(金) 00:33:35.69議論するには不向きだな、やっぱ
0366デフォルトの名無しさん
2012/12/07(金) 00:38:34.44C++を知らない組み込みプログラマーは死ねばいいと思いませんか？
0367デフォルトの名無しさん
2012/12/07(金) 00:40:00.11ID出したところで変わらん罠。むしろもっと増える。
0368デフォルトの名無しさん
2012/12/07(金) 00:41:30.86C++ならインスタンスの動的生成が必須とか信じてるの？ウマシカなの？
0369デフォルトの名無しさん
2012/12/07(金) 04:57:40.870370デフォルトの名無しさん
2012/12/07(金) 08:51:33.460371デフォルトの名無しさん
2012/12/07(金) 09:16:45.75未だに20年前のCコンパイラしか使ったことのない組み込みプログラマーもな。
0372デフォルトの名無しさん
2012/12/07(金) 09:34:35.89異端は殲滅すべし。
0373デフォルトの名無しさん
2012/12/07(金) 09:47:46.450374デフォルトの名無しさん
2012/12/08(土) 02:29:10.25標準ライブラリと多態を使わなければ可能だけど現実的じゃないよね。
printfでも内部的にmallocが使われる。
0375デフォルトの名無しさん
2012/12/08(土) 18:24:47.610376デフォルトの名無しさん
2012/12/08(土) 18:34:55.38printfの実装にmallocが必要とは思えないなあ。
キミにもこの言葉を進呈しよう。
>>373
> 自分の作業環境が世界の標準と思ってる奴も痛いな
0377デフォルトの名無しさん
2012/12/08(土) 21:16:02.80> printfの実装にmallocが必要とは思えないなあ。
printfの仕様もロクに知らないようだな。
そもそも、ちょっとソースコードをググれば分かることだろうが。
0378デフォルトの名無しさん
2012/12/08(土) 21:19:50.76ソースも見ないで言ってんの？
glibc-2.16.0: vfprintf.cにmalloc
newlib-1.20.0: vfprintf.cに_malloc_r
自分の作業環境で何が起こるくらいは知っておいた方がいいんじゃない？
0379デフォルトの名無しさん
2012/12/08(土) 22:21:20.19http://svnweb.freebsd.org/base/head/lib/libstand/printf.c?view=co
> printfの仕様もロクに知らないようだな。
printfの仕様のどこからmalloc必要という結論が出てくるんだ?
0380デフォルトの名無しさん
2012/12/08(土) 22:40:32.24可変個引数やら可変長出力なんてなものをスレッドセーフに作るなら
用途にもよるんだろうが当たり前のように使われてると思う
深く考えて実装したくないから
0381デフォルトの名無しさん
2012/12/09(日) 06:02:27.54> 可変個引数
> 可変長出力
> スレッドセーフ
奴にはそのレベルの話題は無理ｗ
0382デフォルトの名無しさん
2012/12/09(日) 08:42:22.41C言語自体の引数の渡し方にフォーマット処理が含まれてるだけにしか思えないのだけど…。
scanfの方だったら、引数の数で本当に挙動が変わってるけど。
0383デフォルトの名無しさん
2012/12/09(日) 15:20:02.70それスタンドアロン用のサブセットで標準ライブラリじゃないだろ。
libcには入ってるぞ。
http://svnweb.freebsd.org/base/head/lib/libc/stdio/vfprintf.c?view=co
0384デフォルトの名無しさん
2012/12/09(日) 16:09:16.94libcの実装がそうなってるってだけ。
0385デフォルトの名無しさん
2012/12/09(日) 17:19:03.19限度を超えた頭の悪さだな。
0386デフォルトの名無しさん
2012/12/09(日) 17:37:25.25そうじゃなくて、大概のライブラリにmallocが入っているのに
どうやって全部静的にプログラミングするのかと。
libstandも他の部分にはmallocは入ってるぞ？
0387デフォルトの名無しさん
2012/12/09(日) 18:02:38.50世界標準のC言語の環境がどうかという話だから、mallocが無いという発言はちょっと。
0388デフォルトの名無しさん
2012/12/09(日) 20:42:46.06出力を複数回に分けてもいいならともかく、一発で送るには必要
0389デフォルトの名無しさん
2012/12/09(日) 20:49:46.670390デフォルトの名無しさん
2012/12/09(日) 20:58:22.28ケチ付ける為の探りっぽいから、無回答
0391デフォルトの名無しさん
2012/12/09(日) 22:02:22.08freeいらない派はそれすらいらないって言ってるんでしょ？
関数callしても元のアドレスに戻れなすぎワロタ
0392デフォルトの名無しさん
2012/12/09(日) 22:17:40.400393デフォルトの名無しさん
2012/12/09(日) 22:18:01.69せめてアセンブラくらいは読めるようになってから議論に参加しよう。
0394デフォルトの名無しさん
2012/12/09(日) 22:50:40.250395デフォルトの名無しさん
2012/12/09(日) 23:31:40.240396デフォルトの名無しさん
2012/12/09(日) 23:54:08.470397デフォルトの名無しさん
2012/12/10(月) 00:29:53.36覚悟決めろよ
0398デフォルトの名無しさん
2012/12/10(月) 01:25:23.25確保し続けるなら、stack overflow とかおこさないだろ。
0399デフォルトの名無しさん
2012/12/10(月) 02:14:22.320400デフォルトの名無しさん
2012/12/10(月) 02:28:35.88SP足したら、free呼ばれるようなアーキテクチャ使ってるの？
もしかして関数呼び出すときには、mallocでスタック確保するわけ？
0401デフォルトの名無しさん
2012/12/10(月) 09:04:23.590402デフォルトの名無しさん
2012/12/10(月) 10:45:09.13データスタックを巻き戻さずに関数からの復帰が可能。
スタックを使わずにサブルーチンコールができるCPUなら
スタックを巻き戻さずに関数からの復帰が可能。
0403デフォルトの名無しさん
2012/12/10(月) 11:26:38.130404デフォルトの名無しさん
2012/12/10(月) 16:51:55.050405デフォルトの名無しさん
2012/12/10(月) 18:43:15.420406デフォルトの名無しさん
2012/12/10(月) 23:26:02.460407デフォルトの名無しさん
2012/12/11(火) 01:20:37.450408デフォルトの名無しさん
2012/12/18(火) 00:55:05.21相当軽量な、組み込みとかいう特殊なものでなければメモリリークしない。
それにサブ関数で確保してグローバルでもメモリ使いたい時もある。
free必須ではない。
0409デフォルトの名無しさん
2012/12/18(火) 03:04:21.35知らなかったよ
0410デフォルトの名無しさん
2012/12/18(火) 11:21:35.210411デフォルトの名無しさん
2012/12/18(火) 12:31:05.270412デフォルトの名無しさん
2012/12/20(木) 23:36:22.970413デフォルトの名無しさん
2012/12/29(土) 22:16:41.480415デフォルトの名無しさん
2012/12/29(土) 23:28:48.18カール・ベーム
0416デフォルトの名無しさん
2012/12/30(日) 01:05:39.52誰もそんなことは言っていないぞ。バカ。
0417デフォルトの名無しさん
2012/12/30(日) 03:34:40.34言ってるだろOSが回収するからfreeいらないって
池沼は引きこもってオナニーしてろよ
0418デフォルトの名無しさん
2012/12/30(日) 03:48:31.60その場合mallocもないけど
0419デフォルトの名無しさん
2012/12/30(日) 08:12:49.48OSが回収するから終了前はfreeが不要と言っている。
全ての場合に不要なんて誰も言っていないぞ。死ねよバカ
0420デフォルトの名無しさん
2012/12/30(日) 08:57:26.37レビューで全部はじくけどな
おまえ自身がはじかれないように気を付けろよｗ
0421デフォルトの名無しさん
2012/12/30(日) 09:26:18.600422デフォルトの名無しさん
2012/12/30(日) 09:34:19.100423デフォルトの名無しさん
2012/12/30(日) 10:03:07.07> レビューで全部はじくけどな
絶対はじいてないってw
そもそもレビューできる実力ないだろ。
0424デフォルトの名無しさん
2012/12/30(日) 10:18:36.14それ以外のfree standingならば案件毎に異なるから移植性は重要ではない。
こんなことも知らないバカがレビューやってるって、どんなクソ集団だよ。
↓おそらくこういう奴を飼っている集団。 ｗｗ
「どんな環境でも動作するように、移植性考慮して、signalくらってもfreeする
ように実装してみました。作業工数10割増しです。そしてバグだらけです。」
0425デフォルトの名無しさん
2012/12/30(日) 10:20:20.11ずいぶん狭い世界で生きているんだな
0426デフォルトの名無しさん
2012/12/30(日) 10:23:14.970427デフォルトの名無しさん
2012/12/30(日) 10:41:53.60「あれ？こっちの分岐でxxのfree()忘れてない？」
「あぁ、それが成立する条件だと、関数を抜けた後すぐにプログラム終了ですから不要です。」
なんて言っても、問題の有無が判断しにくいという理由でバツだろーな。
実際の動作には問題がなかったとしても。
0428デフォルトの名無しさん
2012/12/30(日) 10:47:25.97実際にレビューで指摘すると
「うーん、レアケースだからfreeいらないか」
ってなると思う。
0429デフォルトの名無しさん
2012/12/30(日) 10:50:56.29得意の論点ずらし。
移植性が悪いからレビューではじくという最初の主張はどこに行ったんだよ。
いや、バカだから最初の主張はすでに忘れたのか。ｗ
0430デフォルトの名無しさん
2012/12/30(日) 11:27:21.53free()追加して済むならそれでおしまいでしょ。無理にわざわざ怪しいコード
残しておく理由もないし。
>>429
どこ行ったもなにも、別人だし。アタマ冷やせよ。
0431デフォルトの名無しさん
2012/12/30(日) 11:43:56.76> どこ行ったもなにも、別人だし。アタマ冷やせよ。
んじゃ、そういう事にしといてやるよ。ｗ
>>420はレビューアの資格ない素人のタワゴトって事でいいね。
横から論点ずらす突込み入れるときは紛らわしくならないように気を付けろ。
0432デフォルトの名無しさん
2012/12/30(日) 12:24:46.180433デフォルトの名無しさん
2012/12/30(日) 13:47:03.93レビューできる実力もないのに無理するな。
0434デフォルトの名無しさん
2012/12/31(月) 09:46:30.220435デフォルトの名無しさん
2013/01/12(土) 18:56:03.72したがって作った人間が半年程度で放棄する想定でも
実際には１０年以上にわたって保守され続けてしまうということが多々ある
ならば
サイショハ コウイウ ツモリ ダッタンダ
などというつまらない言い訳を吐かなくてもいいように対処しておくのが
人間の知恵というものである
0436デフォルトの名無しさん
2013/01/12(土) 19:37:45.44>世に存在するほぼすべてのソフトウェアは残念なことに賞味期限が設定できない
試用版とか普通にあるじゃん。
0437デフォルトの名無しさん
2013/01/12(土) 23:23:55.53お前プログラマじゃないか、ネタでレスつけてるんだろ
お兄さん釣針につられちゃったぞー
0438デフォルトの名無しさん
2013/01/13(日) 00:41:08.80まあ、理解する必要もなさそうだけど (w
0439デフォルトの名無しさん
2013/01/13(日) 01:08:54.520440デフォルトの名無しさん
2013/01/13(日) 10:59:45.140441デフォルトの名無しさん
2013/01/13(日) 11:13:42.360442デフォルトの名無しさん
2013/01/13(日) 13:16:13.05不安を煽れば商売になりそう
0443デフォルトの名無しさん
2013/01/15(火) 01:08:57.18OSに確実に返すのでfreeが必要ないのはFrreBSDやLinuxだからだ、
移植性を考えるなら、プログラム終了時もfree汁!!という人はどういう
環境を想定しているのでしょうか ?
組み込みOSならそもそもプログラムの終了というものがないから
プログラム終了時のfreeの必要性は関係ないよね。
そうでないプロセスの起動と終了の概念のあるOSでプロセス終了時
malllocされた領域を明示的にfreeする必要のある環境なんてあるのだろうか ?
プロセスという概念のある環境でプロセスで確保したリソースを
プロセス終了で返却しないってのはもうほとんどバグに近い振る舞いじゃない ?
(他のプロセスとの共有リソースとかは除く）
0444デフォルトの名無しさん
2013/01/15(火) 01:45:07.40で解決
0445デフォルトの名無しさん
2013/01/15(火) 03:15:49.520446デフォルトの名無しさん
2013/01/15(火) 14:38:17.12freeしなくて良いとか言ってる奴って技術以前に精神的に問題ある奴だと思うよ
常に手抜きの言い訳を考えてるような
0447デフォルトの名無しさん
2013/01/15(火) 14:42:11.69想定するのもいいけど、如何なる環境でも問題ない（減らす）選択という意味で考えても良いと思う
例えば、組み込み系だとすでに入手ができない状態でリプレースとかあったりして
もちろん、開放しても実質してくんないなんて環境なら電源落とせって手順でクリアするしかないわな
0448デフォルトの名無しさん
2013/01/15(火) 14:49:18.15屁理屈つけてウィンカーを出し渋る馬鹿ドライバーと同じだな。
まともな奴なら、malloc→freeなんざ身体で覚えてるからな。
0449デフォルトの名無しさん
2013/01/15(火) 14:59:22.84場合でも必ずfreeしろ」と言い出すから混乱する。
そのバカの典型がQzとかいうクズ。それほどいうなら異常系もfreeしろと
からかってやったら、バグだらけのシグナル処理書いてバカ晒してて笑った。
0450デフォルトの名無しさん
2013/01/15(火) 15:47:46.670451デフォルトの名無しさん
2013/01/15(火) 19:48:39.46signal処理程度を例外に該当すると思ってしまうのはよほどのバカだな。
こんなの準正常系だろ。
0452デフォルトの名無しさん
2013/01/15(火) 22:44:31.130453デフォルトの名無しさん
2013/01/16(水) 22:09:54.56呼んでいる時点で終わっているからどーでもよかろう
0454デフォルトの名無しさん
2013/01/16(水) 22:30:05.19必要。
0455デフォルトの名無しさん
2013/01/16(水) 23:05:25.38ドライバは、終了してもOSがfreeしてくれない場合もあるということかな
0456443
2013/01/16(水) 23:38:20.37自分の読み返してみたら何書いてるかわかんないね。
ひとりよがりですまん。
とりあえず、想定しているのは、例えば数値計算やコンパイラなんかで
プロセススタート時にファイルから読み出されたデータから
連立方程式を作成したり構文木を作成したりで、
それを、プロセス終了時まで使い続け、プロセスの終了とほぼ同時に
開放する（しない）というものを考えています。
自分は数値計算で計算機の物理メモリと同じスケールのメモリを
プロセスの起動時に確保して、終了まで使い続けるというものを書いていました。
こういうのならまだいいんですが、コンパイラなんかだと、
何万もある細かい有向グラフオブジェクト、それが、循環してたりしてってのが
あるらしいですね。それをプロセスの終了時にちまちまfreeしていくのは
どんだけ無駄なんだろうってのが昔のネットニュースで話題になってました。
個人的に、プロセス終了時のfreeはバーベキューなんかで
使い捨ての紙皿を一枚一枚きれいにしてから捨ててるみたいに感じる。
（使い捨ての）テーブルクロスごとゴミ袋に放り込んでしまえと思う。
0457443
2013/01/17(木) 00:02:34.94こういう議論をすると、組み込みOSに移植したとき、
組み込みOSだとプロセスの終了時にfreeされていない領域は
OSに返却されないことも考えられるから、移植性を考えると
プロセス終了時にもfree必要という話が出てくるけど、
組み込みLinux(きちんとメモリが回収される）
よりもっと小さなOSが使われる領域だとそもそも、プロセスの
終了ってものをほとんど行わないから、exit前のfreeって議論から
まずはずれるというので話しにあげました。
0458デフォルトの名無しさん
2013/01/17(木) 00:08:11.89> 組み込みLinux(きちんとメモリが回収される）
> よりもっと小さなOSが使われる領域だとそもそも、プロセスの
> 終了ってものをほとんど行わないから
ワザワザ「無いことの証明」の手間を自分に課している新手のギャグですか？
0459デフォルトの名無しさん
2013/01/17(木) 00:14:46.19プロセスの終了と開始を、動かし続けることで再現することが多いのですが、
プロセス終了するからfreeしなくていいかｗっていう腐った実装をされている場合、
そもそもちょっと手を入れたくらいでは解放できるように作られていなかったり
してとても迷惑なのです。
OSSとかならまあ泣いて作業しますが、自分ところで発注したプログラムだったり
すると、そんな腐った実装をした会社は取引禁止になります。
0460デフォルトの名無しさん
2013/01/17(木) 00:33:09.29ドライバってそもそもOSの通常の管理から外れたことを特別にやらせるための機構だからなあ、あり得るかも
0461デフォルトの名無しさん
2013/01/17(木) 01:06:57.490462デフォルトの名無しさん
2013/01/17(木) 01:10:38.200463デフォルトの名無しさん
2013/01/17(木) 01:13:15.010464デフォルトの名無しさん
2013/01/17(木) 01:15:15.790465デフォルトの名無しさん
2013/01/17(木) 01:36:09.97extern 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;
}
0466デフォルトの名無しさん
2013/01/17(木) 05:28:49.45ウイルス認定されそうなコードだな
0467デフォルトの名無しさん
2013/01/17(木) 11:15:20.84つまり、発注条件と違う環境に盗用しようとして逆切れしてるわけだね。
0468デフォルトの名無しさん
2013/01/17(木) 12:10:57.82前提を勝手に変えておかしな話を展開するあたりも同じだなー
0469デフォルトの名無しさん
2013/01/17(木) 12:16:35.560470デフォルトの名無しさん
2013/01/17(木) 13:06:39.280471デフォルトの名無しさん
2013/01/17(木) 13:37:13.800472デフォルトの名無しさん
2013/01/17(木) 14:40:21.24if (NULL != p)
p = (char *)malloc(BUFSIZ);
的な書き方をすれば、malloc, freeを減らせるってヤツ？
0473デフォルトの名無しさん
2013/01/17(木) 14:51:58.970474デフォルトの名無しさん
2013/01/17(木) 15:32:57.44じゃなきゃヤダ
0475デフォルトの名無しさん
2013/01/17(木) 18:13:36.670476デフォルトの名無しさん
2013/01/17(木) 18:58:02.01NULLが非0だとどうすんのそれｗ
0477デフォルトの名無しさん
2013/01/17(木) 19:41:35.350478デフォルトの名無しさん
2013/01/17(木) 20:14:18.24if (NULL) abort();
0479デフォルトの名無しさん
2013/01/17(木) 20:17:54.40笑ってもいいかな
0480デフォルトの名無しさん
2013/01/17(木) 20:31:31.91,一-、
/￣ l | ／￣￣￣￣￣￣￣￣￣￣
■■-っ ＜ いいとも！
´∀｀/ ＼＿＿＿＿＿＿＿＿＿＿
＿_／|Ｙ/＼.
Ё|＿_ | / |
| У... |
0481デフォルトの名無しさん
2013/01/17(木) 20:36:40.120482デフォルトの名無しさん
2013/01/17(木) 20:49:06.35C FAQ 5
http://www.kouno.jp/home/c_faq/c5.html
0483デフォルトの名無しさん
2013/01/17(木) 20:51:58.955.5:
ヌルポインターの内部表現に0でないビットパターンを使っているマシンでは、NULLはどう定義するべきかか。
A: (省略されました)
0484457
2013/01/18(金) 01:57:41.80適当なことかいてすまん。
>>459
とりあえず、freeというのはある程度時間を消費する処理であることは
よろしいでしょうか ?
特に細かいmallocを繰り返していた場合。
266辺りの議論を参照。
なので、exitの直前にfreeをごりごり繰り返すのはリソースの浪費。
さて、>>459はUNIXやWindows等、プロセスが確保したリソースを
OSがよきに計らってくれる環境で動作することを要求されたプログラムが
プロセスの概念すらないにOS上に移植できないとおっしゃられているのですね。
それは、仕様の不備ではないでしょうか ?
最低でもxxxxというOS上に移植することを考慮すること、と記述すべき
ではないでしょうか ?
0485457
2013/01/18(金) 02:50:31.53このスレのタイトルに「main以外」と入っているので、
プロセス終了直前のfreeは必ずしも必要ではないというのは
>>1さんも同意していると思う。
これは10年前からの進歩だと思う。
プロセス終了前のfreeは、>>1では「例外中の例外」と
考えられているみたいだけれど、それは、結構多いシチュエーション
だと思う。
自分は、教条主義的にmallocした領域は絶対にfreeしなくてはならないという
固執した考えを治してあげたいと思う。
で、free絶対派の根拠として、組み込みOSなんかはfreeしないとOSがメモリ
回収してくれないものもあるっていうのがあるけど、それが絶対にfreeしなければ
ならないことの根拠にはならないことを示したいと思う。
（もちろん、組み込みOSを考慮した方がいい場合もあると思うけれど、
そうでない場合も多い）
UNIXやWindowsなど、プロセスが終了するとリソースをOSが回収する
OSだとmalloc-freeはsbrkやmmapでOSから取得したメモリを切り分けている
ヒープ管理ライブラリに過ぎないわけで、それが、ある一定の要件を
満たしていることをプログラムの動作用件として要求するのは、妥当だと
思う。
なので、常に組み込みOS等を考慮しなければならないというのは
妥当ではないと思う。
0486デフォルトの名無しさん
2013/01/18(金) 11:00:36.23屁理屈言ってないで体で覚えろ。
俺はC++でRAIIするけど
0487デフォルトの名無しさん
2013/01/18(金) 11:03:30.33free(p);
strcpy(p, "123");
0488デフォルトの名無しさん
2013/01/18(金) 17:16:03.43#define quick_free(p)
0489デフォルトの名無しさん
2013/01/18(金) 18:41:02.530490デフォルトの名無しさん
2013/01/18(金) 21:31:09.27どっちにしても、strcpyが内部でmalloc使う実装だったり
マルチスレッドだったりしたら「ちゃんと」動くとは限らんな。
0491デフォルトの名無しさん
2013/01/19(土) 10:44:53.11ありうるのか？
0492デフォルトの名無しさん
2013/01/19(土) 10:48:26.46× ちゃんと動くOSがあるんだよな。
○ たまたま動いているように見える環境があるんだよな。
0493デフォルトの名無しさん
2013/01/19(土) 10:49:37.56おれは見たことない。
>>490 には、どこの実装がそうだったかを示して欲しい。
0494デフォルトの名無しさん
2013/01/19(土) 11:01:15.64ありそうもない仮定だけど
0495デフォルトの名無しさん
2013/01/19(土) 11:14:12.50終了前のfreeの実行コストなんていう恐ろしくどうでもいいことのために
それを特別扱いするのはプログラミングコストの無駄だと思うがな。
そもそも、実行時のコストを棚に上げて終了時のコストのみ重要視
しなきゃならん例ってのが思いつかん。
0496デフォルトの名無しさん
2013/01/19(土) 11:27:40.60大物アプリの終了時に無駄に時間がかかることがしばしばある
後始末、解放処理のためにページインが発生しているんだろうが
もう要らないものを時間かけて読み込んですぐ捨てているわけで、馬鹿馬鹿しい限り
でもC++あたりだと普通RAII + デストラクタなので、「終了時にはfreeしない」戦略が
手抜きにならないどころか、「特別扱い」するほうが面倒な気がする
0497デフォルトの名無しさん
2013/01/19(土) 11:49:15.490498デフォルトの名無しさん
2013/01/19(土) 12:20:50.28ヒープの大半がページアウトされたプロセスの終了時間だろ？
やっぱりどうでもいいとしか思えん。
仮にもしそれが本当にcriticalな問題になるケースならば、
「もう使わない領域のfreeのためのページインは無駄だが、
実際にアクセスするためのページインは無駄じゃないからOK」
なんて言うわけにもいかんだろうし。
0499デフォルトの名無しさん
2013/01/19(土) 18:42:12.88criticalな問題ってのがどの程度のものなのかは人それぞれだと思うけど
496にとってアプリケーションを終了させてから、（ここで言うアプリケーションの
終了は、ユーザーが終了の意思を示した、たとえばウィンドウのぺけボタンを
押したり、メニューから終了を選んだりしたときのこと）、
プロセスが終了するまで、じっと数秒待つのはできたら避けたいことじゃぁないの ?
> 「もう使わない領域のfreeのためのページインは無駄だが、
> 実際にアクセスするためのページインは無駄じゃないからOK」
> なんて言うわけにもいかんだろうし。
実際アクセスするためのページインは必要だからやらなきゃいけないんじゃ
ないの ?
0500デフォルトの名無しさん
2013/01/19(土) 20:15:58.47freeのコストも必要なものだと考えれば気が楽になるぞ。
0501デフォルトの名無しさん
2013/01/19(土) 20:40:27.21ユーザはプロセス終了時に数秒間待つコストを払ってください
0502デフォルトの名無しさん
2013/01/19(土) 22:29:33.91＞プロセスが終了するまで、じっと数秒待つのはできたら避けたいことじゃぁないの ?
で、ワシらは「じっと待つ」ことの意味がわからんからそこを聞きたいのだが、彼はなんと言ってくるのだろう？
大至急再起動かけんといかんような感じなのかね？
0503デフォルトの名無しさん
2013/01/19(土) 23:11:19.07その上で必要なら特殊な終了処理を入れるんだよ。
0504デフォルトの名無しさん
2013/01/19(土) 23:18:15.030505デフォルトの名無しさん
2013/01/19(土) 23:44:12.32kill( ) したいわ。
0506デフォルトの名無しさん
2013/01/20(日) 00:16:49.66終了時にまったくアクセスする必要のないメモリブロックが大量に残って
いるようなプログラムを書いて、それがページアウトされてしまうような
少ないメモリの環境で動かした場合はそりゃ仕方ないわな。
0507デフォルトの名無しさん
2013/01/20(日) 00:25:05.01free(笑)
0508デフォルトの名無しさん
2013/01/20(日) 00:53:47.92ページアウトさせられてしまう他プロセスは良い迷惑だな。
0509デフォルトの名無しさん
2013/01/20(日) 01:10:31.44"馬鹿が書いたプログラムの終了間際の無意味なfreeの所為で"
"ページアウトさせられてしまう他プロセスは良い迷惑だな。"
);
0510デフォルトの名無しさん
2013/01/20(日) 06:13:42.670511デフォルトの名無しさん
2013/01/20(日) 08:37:13.280512デフォルトの名無しさん
2013/01/20(日) 08:57:20.820513デフォルトの名無しさん
2013/01/20(日) 09:44:06.19お前らバカが書いたソフトが再利用される可能性は皆無だから安心しろ。
0514デフォルトの名無しさん
2013/01/20(日) 10:17:58.63っていうかこう書かないと大量ネスト＋解放箇所分散化で悲惨だと思う
goto使わない教の人ってどう書いてるんだ？
FILE *fp = 0;
char *p = 0;
：
if (some_error) goto LABEL;
LABEL:
if (fp) fclose(fp);
if (p) free(p);
：
0515デフォルトの名無しさん
2013/01/20(日) 10:25:09.98実際に必要だったブロックで、終了時のfreeを省略したために出ただけ
なんで無視。」とか確認するだけでも無駄だな。
freeを省略してもいいって人はリークチェッカとか使わないんだろうか。
free(NULL)は無問題
よってfree()をあえて書く必要はない信者といえどもそれくらいは知っている
fclose(NULL)はアウトだからラッパをかます
0518デフォルトの名無しさん
2013/01/20(日) 10:47:46.82do {
if (some_error) break;
} while(0);
とかじゃね？
俺はそのパターンの時はgoto使う派だけど。
0519デフォルトの名無しさん
2013/01/20(日) 11:27:27.79そのために数秒止めるようなコード書く馬鹿はCを使うべきじゃない
0520499
2013/01/20(日) 12:12:28.75一番思いつくのは、WindowsでGUIのプログラムを使って、
終了を選択したのに、ハードディスクがくるくる回って、
Windowsキーを押してもスタートメニューが開かないような常態。
あと、gccなんかでカーネルとか馬鹿でかいプログラムを
コンパイルするときなんか、全く無駄な処理で時間をつぶしたくは
ないですよね。
0521デフォルトの名無しさん
2013/01/20(日) 13:24:54.880522デフォルトの名無しさん
2013/01/20(日) 13:25:50.08該当部分を関数にしてreturnってのもあるけど
それだけの為にってのはなあ
0523デフォルトの名無しさん
2013/01/20(日) 13:33:52.36かなり特殊なケースだが、そもそも終了に限らず動作自体遅くて
しょうがないだろう。
本当にそういう条件で動かす必要のあるアプリなら、終了時の
freeどうこう以前にもっと考えなきゃならんことがあるだろ。
0524デフォルトの名無しさん
2013/01/20(日) 14:05:00.20それはお前の経験値が不足しているだけ。
0525デフォルトの名無しさん
2013/01/20(日) 14:21:46.060526デフォルトの名無しさん
2013/01/20(日) 14:28:50.680527デフォルトの名無しさん
2013/01/20(日) 14:57:11.400528デフォルトの名無しさん
2013/01/20(日) 15:02:44.080529デフォルトの名無しさん
2013/01/20(日) 15:10:53.58バカには無理だろうけど。
0530デフォルトの名無しさん
2013/01/20(日) 15:21:33.750531デフォルトの名無しさん
2013/01/20(日) 15:36:05.36おまえが、「何GBもメモリ確保して終了まで開放しないようなアプリ」の例を挙げれば良いだけの話。
もちろんソースつきでな。
0532デフォルトの名無しさん
2013/01/20(日) 15:37:43.68結論出るわけがないんだけどね。
0533デフォルトの名無しさん
2013/01/20(日) 15:37:55.13とりあえず、そういう分野があるということはご理解いただけたみたいですね。
例えば有限体積法なんかでごりごり連立一次方程式を解こうとすると、
最初にがーっとメモリを確保してそれを最後まで使い続けます。
HPCっていうそこそこ大きい市場もあるんだからそれほど特殊とはいえないと
思うんだけど。
連立一次方程式の解放ならそれほど複雑なメモリは取得しないけど、
コンパイラの構文木なんかをプロセス終了時にちまちま解体してたら
あほっぽいよね。
0534デフォルトの名無しさん
2013/01/20(日) 15:40:57.65リプレイ？
相手の言い分は例外と決めつけるだけの単純な作業じゃん。
劣化コピーにもなっていない。
0535デフォルトの名無しさん
2013/01/20(日) 15:43:23.440536デフォルトの名無しさん
2013/01/20(日) 15:48:56.83KVストアなんて全部その類。ソースはキーワードさえわかればバカのお前でも検索できるだろ。
0537デフォルトの名無しさん
2013/01/20(日) 15:49:04.53ウィンドウ右上のペケボタンを押したときのexit処理の前にも全てのオブジェクトを
解放して回るの ?
0538デフォルトの名無しさん
2013/01/20(日) 15:53:52.15execveする時の為にスタティックな領域も用意しておいて、そこにコピーするんだって。
0539デフォルトの名無しさん
2013/01/20(日) 15:58:35.52言えるんだろうな。品質悪そうだ。
0540デフォルトの名無しさん
2013/01/20(日) 16:00:36.46それをいちいちページアウトされてしまうような環境で実行して、しかも
終了の時間が重要なんて状況はとても一般的とは言えんだろう。
0541デフォルトの名無しさん
2013/01/20(日) 16:06:45.33KVM ?
ひょっとして KVS のことか？
KVM でも KVS でも良いんだが、「終了まで解放しない」と言うソースを出してみなよ。
どうせ「ぐぐればわかる」と言って逃げるんだろうけど。
0542デフォルトの名無しさん
2013/01/20(日) 16:14:00.79そういうのは、ライブラリがやってくれるよ。たぶん。ほとんど待機しないですぐにとじたりする。
自分で用意したボタンをおしたときのほうがおそいことがある
0543デフォルトの名無しさん
2013/01/20(日) 16:20:04.810544デフォルトの名無しさん
2013/01/20(日) 16:20:54.74今時 GUI アプリで malloc( ) , free( ) 使う方が特殊だと思うのは、俺だけか？
0545デフォルトの名無しさん
2013/01/20(日) 16:36:24.31やっぱ、お前バカだ。ｗｗｗ
freeしたらどこにデータ持つんだよ。
0546デフォルトの名無しさん
2013/01/20(日) 16:42:05.56はいはい、ごたくはいいからソース出してみなよ。
0547デフォルトの名無しさん
2013/01/20(日) 16:54:29.36http://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 こいつは終了しても解放しない。ｗ
0548デフォルトの名無しさん
2013/01/20(日) 17:02:55.99プロセス空間に散らばったメモリブロックをfreeして回るのに時間がかかると
いうことだったと思ったが？疎行列に特化したアルゴリズムならちまちま
メモリを確保してもおかしくないが、その場合、確保するばかりで増える
一方だとしたらなんか変だな。
コンパイラの構文木の方は、それこそコンパイル中に何度でも作っては
捨てるから廃棄ルーチンは当然書くと思うが？それをわさわさ終了時だけ
呼ばないとか不自然なことするか？
0549デフォルトの名無しさん
2013/01/20(日) 17:05:34.98なぜなら、時間がかかるのであれば、対策しているはずだから。
freeが必要なのは、プロセス終了時だけではないのですよ？
アプリが起動している時にこそ、たくさんのfreeが行われてるはずです。
0550デフォルトの名無しさん
2013/01/20(日) 17:08:48.68で、どれが「何GBもメモリ確保して終了まで開放しないようなアプリ」なんだ？
ついでに、どこから「終了」なのかも明示してくれ。
>>548
まあ、コンパイラの作り方にもよるけど、シンボル関係の管理表などは終了まで
追加するのみで廃棄しないこともありえる。
ただ、俺は知らないけど、何ＧＢものメモリを確保するらしいから、それは >>524
とかがソース付きで示してくれるんだろうよ (w
0551デフォルトの名無しさん
2013/01/20(日) 17:16:58.410552デフォルトの名無しさん
2013/01/20(日) 17:17:49.830553デフォルトの名無しさん
2013/01/20(日) 17:18:45.10> 解説してやろうか? 有料で。
解説できない言い訳乙 (w
0554デフォルトの名無しさん
2013/01/20(日) 17:20:55.070555デフォルトの名無しさん
2013/01/20(日) 17:22:12.410556デフォルトの名無しさん
2013/01/20(日) 17:23:06.890557デフォルトの名無しさん
2013/01/20(日) 17:25:34.880558デフォルトの名無しさん
2013/01/20(日) 17:27:06.30XPまでのWindowsは、ウィンドウ最小化しただけでワーキングセット最小化するし
この辺読んだら
ttp://nyaruru.hatenablog.com/entries/2007/10/10
0559デフォルトの名無しさん
2013/01/20(日) 17:28:06.02さっさと出しなおせ。
0560デフォルトの名無しさん
2013/01/20(日) 17:29:51.37emacsとspiceはexitが呼ばれるまで。
linuxはreboot()が呼ばれるまで。
0561デフォルトの名無しさん
2013/01/20(日) 17:30:35.81バカには理解できないからそれは不可能。ｗｗ
0562デフォルトの名無しさん
2013/01/20(日) 17:31:22.46自分がバカで出せないから不可能？
わかります。
0563デフォルトの名無しさん
2013/01/20(日) 17:33:24.620564デフォルトの名無しさん
2013/01/20(日) 17:34:30.48100%まったく理解していないよねｗ
0565デフォルトの名無しさん
2013/01/20(日) 17:35:43.89だからfreeは必要。
はい論破ｗ
0566デフォルトの名無しさん
2013/01/20(日) 17:38:10.04行儀の悪いプログラム書く奴ってそういうの使ったことないんだろ
0567デフォルトの名無しさん
2013/01/20(日) 17:39:56.790568デフォルトの名無しさん
2013/01/20(日) 17:52:09.18メモリ検査には触れずに都合のいいレスにだけ食いつくような特徴ある行動する人
0569デフォルトの名無しさん
2013/01/20(日) 17:53:43.27連立一次方程式の解法は最初から最後までメモリを確保したままの例で
ということで出しました。
連立一次方程式の解法はたしかに、物理メモリ上で
すむように計算の大きさを制御するけれど、
問題によっては、仮想記憶を使いたくなるようなシチュエーションも
出るのではないでしょうか ?
レアケースかも知れないけれど、存在するって言うことで、
で、仮想記憶を使わないとしても、俺の実際見ただけでも、数万回のmallocを
やってる例もあって、もっと細かいオブジェクトをたくさん使う分野なら、
何千万のオブジェクトをもっても不思議じゃないでしょ。
それを、exit前にちまちま回収する?（回収してすぐに廃棄）
freeはそんなに簡単な処理じゃなく、結構な時間がかかるんじゃないかな
終了の時間が重要じゃないってのは、そういうのはバッチファイル
でやるから、全体の実行時間が多少伸びても、コーヒーでも飲んどけ
ってこと ?
そうは言っても、無駄なものは無駄だよね。
あと、GUIをかませて、MicrosoftWordを使ってる機械で動くようさせられた
こともあります。
この場合、計算->ワードに書く->ページアウト->シミュレータを終了
するとexit前にfreeした場合、ページインが発生しますね。
0570デフォルトの名無しさん
2013/01/20(日) 17:54:36.86「俺のコードはそんなツールじゃ判断できないぜ！」
「この糞コーディングルールは××の場合に○○だから完全じゃない。
俺はそんなルールに縛られないぜ！」
と言って、どうでもいいところの改善にこだわったりする。
0571デフォルトの名無しさん
2013/01/20(日) 17:54:50.50#ifdef MTRACE
cleanup_things();
#endif
とでもすればいいだけじゃね
0573デフォルトの名無しさん
2013/01/20(日) 17:59:31.81これはひどい
怒られたとこは全部切っとけばおとなしくなるね
でもお願いだから君はプログラム組まないでね
0574デフォルトの名無しさん
2013/01/20(日) 17:59:50.86参照していない大きな領域をexit前にfreeするとページインが
発生して数ミリ秒程度処理が遅くなる、という話をしています。
どのみちexit処理でページインしてしまうんですけどね。
0575デフォルトの名無しさん
2013/01/20(日) 18:00:53.13-Wallでwarningが出ないこと、って条件を付けたら
Makefileから-Wallを消した人に似ている。
0576デフォルトの名無しさん
2013/01/20(日) 18:01:19.00> 発生して
それが間違い。
その場合にページインは発生しない。
0577デフォルトの名無しさん
2013/01/20(日) 18:01:36.32こいつ適当に別人のレスをつなぎ合わせて反論に困ったレスをなかったことにし始めたぞ
0578デフォルトの名無しさん
2013/01/20(日) 18:01:58.26意味わかってる？
「切る」んじゃなくて、解放処理を＊全て＊実装して、cleanup()でそれを呼ぶ
ただしMTRACEが定義されているときだけ
mtraceでチェックしたいときはMTRACEを定義してコンパイルすればいい
MTRACEを未定義にすればそれは含まれないので、不要な解放処理を
リリース版から削除できる
0579デフォルトの名無しさん
2013/01/20(日) 18:02:27.11ファイルを読みこまなくてもいいのと同じ。
0580デフォルトの名無しさん
2013/01/20(日) 18:03:19.02つまり、freeを書く必要はある、ということを認めるわけですね。
0581デフォルトの名無しさん
2013/01/20(日) 18:03:28.81意味わかってる？
constキャストと同じことだよそれ？
0582デフォルトの名無しさん
2013/01/20(日) 18:04:37.58俺は別に俺はfree()を書くことに反対してないけど……
0583デフォルトの名無しさん
2013/01/20(日) 18:05:31.42どこがどう同じなのかもう少し詳しく
0584デフォルトの名無しさん
2013/01/20(日) 18:05:42.72{
Rect* rc = new Rect(x, y, w, h); // freeしたら負けなので絶対しないこと
}
0585デフォルトの名無しさん
2013/01/20(日) 18:11:30.18コードに嫌悪感を抱いてるのか
cleanup()を有効にした状態でプログラムが正常に動作しリークも検出されないなら
確保したリソースをきちんと追跡できていることは確認できるだろ
というか一定程度以上複雑なプログラムならプールでも使って、最後にプールを
削除するかしないか程度の差でしかない筈だが
(EmacsのようなLisp処理系ならガーベージコレクタを実装するわな）
0586デフォルトの名無しさん
2013/01/20(日) 18:27:09.290587デフォルトの名無しさん
2013/01/20(日) 18:54:04.320588デフォルトの名無しさん
2013/01/20(日) 18:55:57.25（終了のために解放処理を行う）と。
そういう人ならWindowのペケボタンを押したときのなんかの処理にも
freeが必要って言っても納得できる。
10年前のfjとこのスレの議論でfree絶対派（exit前でも回収する必要ないのに
わざわざfreeする派）の言うことで納得できたのは
1. mallocとfreeは対で使えと言っておかないと、freeが必要な場合でも
. freeしないど低脳が俺の周りにいるんだよ。無い頭使わずfreeしろ !!
2. mtraceを使うから。
なんだけど、あと他にあるかな ?
0589デフォルトの名無しさん
2013/01/20(日) 19:01:26.05mallocされたメモリがプロセスの終了時に返却される保障はない。
0590デフォルトの名無しさん
2013/01/20(日) 19:09:53.41「保障」とか使ってるバカは知らなくてもしょうがないけどね。
0591デフォルトの名無しさん
2013/01/20(日) 19:12:57.22だいたいいいと思うよ、ただ俺の場合、1.は「周りが低脳」というより
自分の頭も楽にするためだな。
どうでもいいことにこだわってわざわざプログラミング難しくして
どうすんの？って感じ。
本当に必要な要件にはそれなりの対応があるわけだし。
0592デフォルトの名無しさん
2013/01/20(日) 19:14:39.69規格通りの環境しか使ったことない初心者は気楽でいいですね。
0593デフォルトの名無しさん
2013/01/20(日) 19:17:41.04わかって解放しない横着者はともかく、「規格です」とかいって解放しないバカが沸くから
必ず解放しなければならない、ということにしておいたほうが都合がいい。
0594デフォルトの名無しさん
2013/01/20(日) 19:19:08.24規格外の超例外まで持ち出して必死ですねｗ
0595デフォルトの名無しさん
2013/01/20(日) 19:21:09.240596デフォルトの名無しさん
2013/01/20(日) 19:22:28.250597デフォルトの名無しさん
2013/01/20(日) 19:55:29.67そんなことは関係ないんだよ。ユーザーの時間単価をなめるなと。
客先に急ぐときに終了が遅いソフトってスゲーイライラするのも知らないのか？
会社から与えられるPCが十分なスペックだとは限らないこともしらないのか？
「そんな会社に勤めるなよ」なんていう馬鹿がいそうな気がするが、作る側の論理？
自己満足でそんなことを強制されるなんてたまったもんじゃねーよ。
free()命の話を読んでいると、free()だけじゃなくほかにも無駄なことをやりすぎているような気がするんだよな。
fjの頃にもこんなスレッドがあったけれど、これだけPCの性能が上がっているにもかかわらず、しかもソフト自体の
機能はそれほど変わらないのに、なんで未だに速度面で不満があるものがたくさんあるんだ。
っていうのが両方の立場にいる俺の意見だな。
0598デフォルトの名無しさん
2013/01/20(日) 20:09:16.51> emacsとspiceはexitが呼ばれるまで。
どこの exit( ) ？
まさか、一箇所しかないとか思ってないよね？
> linuxはreboot()が呼ばれるまで。
さすがにバカすぎるから、こっちは見逃してやるよ (w
0599デフォルトの名無しさん
2013/01/20(日) 20:56:08.58560ではないんだが
> どこの exit( ) ？
> まさか、一箇所しかないとか思ってないよね？
一箇所でもあれば、freeせずにexitする場合も存在するということになるが
free絶対必要でemacs, spiceはその理念に則っているって言うなら
(598がそう言ってるかどうかは別として)全てのexit前にメモリの解放処理
が必要になってくるよ。
ぶっちゃけmtraceを公開しているGNUのプロダクトもexit前のfreeなんて
ほとんどやってないんじゃないの ?
だれか、確かめてよ << 他力本願
>> linuxはreboot()が呼ばれるまで。
> さすがにバカすぎるから、こっちは見逃してやるよ (w
結構、本質的な問題だと思うけど、
プロセスなりカーネルの動作なりが終了して、全てが白紙になる前に、
無駄なfreeをするのは必要かって議論でしょ ?
プロセスの終了とカーネルの終了のこの問題での本質的な違いはあるの ?
0600デフォルトの名無しさん
2013/01/20(日) 21:09:21.87>>>598
> 一箇所でもあれば、freeせずにexitする場合も存在するということになるが
で、どれが「何GBもメモリ確保して終了まで開放しない」のって聞いてるんだけど、
理解してる？
>プロセスの終了とカーネルの終了のこの問題での本質的な違いはあるの ?
malloc( )/free( ) がどのレイヤーで実装されているか確認しようよ。
0601デフォルトの名無しさん
2013/01/20(日) 21:24:41.31お前やっぱりバカ。ｗｗｗ
どこから呼ばれようとexit()は一つ
> さすがにバカすぎるから、こっちは見逃してやるよ (w
翻訳すると降参ってことね。
0602デフォルトの名無しさん
2013/01/20(日) 21:42:05.50>どこから呼ばれようとexit()は一つ
翻訳すると降参ってことね (w
linux の方は、>>600 見てから書いてる？
見てないならまだしも、見てたら単なるアホになってるぞ。
0603デフォルトの名無しさん
2013/01/20(日) 21:42:38.27バカは話に割り込んでくるな
0604デフォルトの名無しさん
2013/01/20(日) 22:06:38.75おまえはsignalでも使って割り込んでろ
0605デフォルトの名無しさん
2013/01/20(日) 22:34:29.64お前本当にバカなんだな。どこから呼ぼうとexitは一つなんだから、
exitを明示的/非明示的を問わず、呼んでるところのすべてって意味に決まってんだろ。
ここまで解説しなきゃわからない。バカには限界値が無いようだ。ｗｗｗ
> linux の方は、>>600 見てから書いてる？
> 見てないならまだしも、見てたら単なるアホになってるぞ。
kmalloc/kfreeはmalloc/freeじゃないってか? ｗｗｗ バーカ。バーカ。バーカ。バーカ。
0606デフォルトの名無しさん
2013/01/20(日) 22:53:26.69具体的に聞くとこういう返ししか出来ないところが、哀れだな。
0607デフォルトの名無しさん
2013/01/21(月) 00:24:55.010608デフォルトの名無しさん
2013/01/21(月) 01:17:35.52ここで聞いても答えはでんだろ
他の人の意見を聞くならまだしも
お前が信じるかどうかなんて知ったことじゃねえ
0609デフォルトの名無しさん
2013/01/21(月) 01:34:08.16> > 一箇所でもあれば、freeせずにexitする場合も存在するということになるが
>
> で、どれが「何GBもメモリ確保して終了まで開放しない」のって聞いてるんだけど、
> 理解してる？
うーーん、それはソースを追ってみないことにはわからないけど、
少なくとも何GByteもメモリを確保したのを解放っていうコストが無い
（数10MByte分のコスト）場合ですら、exit前のreeを行わない、
コストは0ではない以上、全く得るものの無いexit前のfreeなんかを
行うことはただの無駄だという判断なんではないかな。
んで、数GByteという話は、あくまで悪い事例を挙げたもので
そんなコストがなくても無駄なコストを避けるって一例になるんでは
ないだろうか。
っていうか、常識的に、わざわざ時間のかかる数GByteの解放は
しこしこfreeするのに、数MByteの場合はそれを省略するなんて
考えられる ?
GNU Emacsの開発陣がfree絶対派だったら全てのexitの前にfree
してるって
0610デフォルトの名無しさん
2013/01/21(月) 01:50:54.48ここはひとつ線香の一本でも上げがてら名残り惜しんでやれよw
0611デフォルトの名無しさん
2013/01/21(月) 02:00:59.79> >プロセスの終了とカーネルの終了のこの問題での本質的な違いはあるの ?
>
> 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の中身を整理するぐらい無駄。
これが、本質的に変わらないでしょって書いた意味です。
ダングリングやリークを起こさないという地震があるの？
>>50 でいいんじゃない？
0613デフォルトの名無しさん
2013/01/21(月) 12:10:19.27たぶんだけど、必要と言ってる人は感覚的にそのように書いちゃうくせがもう出来上がってるから
端的に質問すると（書くもんだって反射的になるから）あんまよくないかもね
0614デフォルトの名無しさん
2013/01/21(月) 13:51:39.290615デフォルトの名無しさん
2013/01/21(月) 20:13:54.620616デフォルトの名無しさん
2013/01/21(月) 20:16:13.030617デフォルトの名無しさん
2013/01/21(月) 20:22:16.210618デフォルトの名無しさん
2013/01/21(月) 20:30:45.040619デフォルトの名無しさん
2013/01/21(月) 23:54:41.280620デフォルトの名無しさん
2013/01/22(火) 00:27:03.11コスト最重要視するなら、アセンブラでゴリゴリ書けば？
もうそういう時代じゃないんだよ。
0621デフォルトの名無しさん
2013/01/22(火) 05:16:23.03まずfree()を実行することでスワップインすることはない。
なぜなら、メモリを管理している領域と
メモリの実態は別だから。
メモリを管理している領域は頻繁に参照されるから
常にメモリに乗っている状態。
メモリのスピードは一般的なパソコンで
1GB/s〜10GB/sでるんだから
どんなに効率悪いメモリの使い方をしていたとしても
アプリ終了の最後の一回に1秒未満の時間が加わるだけ。
0622デフォルトの名無しさん
2013/01/22(火) 08:39:33.94それだと終了後に長い間ディスクアクセスがなんたらかんたらと言い出しかねんぞ
0623デフォルトの名無しさん
2013/01/22(火) 08:45:08.40終了時にデータ保存するアプリかなんかだろ？
freeをやめたら、長いディスクアクセスが
なくなるというコードを持ってきたら
話聞いてやるよｗ
0624デフォルトの名無しさん
2013/01/22(火) 11:12:37.51配列を解放するためにポインタ配列にアクセスしないといけない。
それがポインタを持ったリスト構造だったりした日には
解放する為にポインタを辿らねばならず、それ自体のコストが馬鹿にならない。
なので、コスト節約のためにfree()省略と言うのも判らんではない。
0625デフォルトの名無しさん
2013/01/22(火) 11:46:55.24実装によっては、管理データはmallocが返したポインタの前にくっついてるじゃん。素人乙。
0626デフォルトの名無しさん
2013/01/22(火) 20:44:46.580627デフォルトの名無しさん
2013/01/22(火) 21:01:49.99あっ
0628デフォルトの名無しさん
2013/01/22(火) 21:29:59.970629デフォルトの名無しさん
2013/01/22(火) 21:33:14.56ヒープの大半がページアウトした状況も含めて終了に要する時間が重要な
要件だったとしたら、そんな構造のデータを終了直前まで大量に保持してる
コードを書いてる時点でダメだろ。
アホなコードを書いたらアホな対策が有効(ただし効果は限定的)ってだけ。
0630デフォルトの名無しさん
2013/01/22(火) 21:58:59.95一般的な例だと議論に持ち込めないから極端な設定でっちあげて優位に立ちたいんかね。
0631デフォルトの名無しさん
2013/01/22(火) 22:11:04.04ここで聞いても答えはでんだろ
他の人の意見を聞くならまだしも
お前が信じるかどうかなんて知ったことじゃねえ
0632デフォルトの名無しさん
2013/01/22(火) 22:14:26.53本人は軽い気持ちで言ったんだろうが、まさか10年後に
まだ真に受けてる奴がいるとは思わなかったろうｗ
0633デフォルトの名無しさん
2013/01/22(火) 22:20:07.53Windows XPまたはそれ以前という糞OSではそれ全然「極端な例」じゃないから
0634デフォルトの名無しさん
2013/01/22(火) 22:26:28.73すぐ終了するのに解放処理書くの面倒だから書かねーんだよ。
工数は増える、バグが混入する可能性も増える。良い事はあまりない。
終了時に遅くなるなんてのはどうでもいい。
0635デフォルトの名無しさん
2013/01/22(火) 22:38:43.43fjは、今でも細々ながら続いてるが？
0636デフォルトの名無しさん
2013/01/22(火) 22:54:34.42それも長時間アクセスしない場合だろ？つまり、
・大量にメモリを抱えたまま長時間アクセスせず
・終了時にもfree以外にアクセスする必要はなく
・しかし終了に要する時間だけは重要
この3条件が揃って初めて成り立つ議論なわけだ。
そもそもWindowsだと、立ち上げたままのアプリを時間をおいて
操作するだけでディスクアクセスで一呼吸待たされたりするが、
終了時のページインのコストなんかにこだわってる人はそっちは
目をつぶるのかい？
0637デフォルトの名無しさん
2013/01/22(火) 23:05:37.88>・しかし終了に要する時間だけは重要
誰もそんな話言ってないだろ、なんでそう曲解するんだか
少しでもベターなユーザエクスペリエンスを提供したいと考えるなら、
改善可能なところは改善したいと考えるもんじゃないのか
終了前のfree云々はあくまでその中の一つでしかな
0638デフォルトの名無しさん
2013/01/22(火) 23:16:13.28そのポイントがずれてるんじゃないか？ってことだ。
0639デフォルトの名無しさん
2013/01/22(火) 23:26:16.83ユーザーエクスペリエンスの改善にはつながらない。
なぜなら、freeを無くすことで改善されるという
実証コードが存在しないから。
机上の空論、いつまで続けるの？
0640デフォルトの名無しさん
2013/01/22(火) 23:52:45.48freeしない方はする方より確実に早い。違うというなら実証コード出してみろ。ｗ
0641デフォルトの名無しさん
2013/01/22(火) 23:53:37.50freeしない方はする方より確実に速い。違うというなら実証コード出してみろ。ｗ
0642デフォルトの名無しさん
2013/01/22(火) 23:57:31.63存在しないからだしようがないでしょ？
まあ普通にfree消しても何も変わらなかったとだけは言っておく。
コード欲しい？
int main() {
void *ptr = malloc(ものすごく大きい値);
/* free(ptr); */
return 0
}
これだけだけどね。free入れても入れなくても変わんない。
0643デフォルトの名無しさん
2013/01/23(水) 00:11:35.63直近20レスくらいプリントアウトしたものを近くの人に見せて、
「この中でバカは誰？」って訊いてみるといいぞ。
0644デフォルトの名無しさん
2013/01/23(水) 00:28:17.60どうすればいい？ >>643
0645デフォルトの名無しさん
2013/01/23(水) 00:56:25.98本当にやったのか。そりゃ訊かれた人も困ったろう。
0646デフォルトの名無しさん
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;
}
0647デフォルトの名無しさん
2013/01/23(水) 01:53:54.10単純実行した速度の話はまた、別の話題のような？
0648デフォルトの名無しさん
2013/01/23(水) 03:10:03.72ほとんどが再帰呼び出しのコストだな。
10000000段ものコールスタック
いったいスタックどれくらい消費するつもりだよｗ
0649デフォルトの名無しさん
2013/01/23(水) 07:38:22.36別に再帰をループに書き直しても速度差はあるけど？
0650デフォルトの名無しさん
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
0651デフォルトの名無しさん
2013/01/23(水) 09:04:21.45破棄するときのことを考えずに書いて後でハマるパターンだろ。
オブジェクトの生成破棄なんてどこでも必要になるんだから定形的に書いておけば
いいのに、いちいち「この場合は必要、この場合は不要」なんてやってるから
余計なバグを増やすんだと思うぞ。
0652デフォルトの名無しさん
2013/01/23(水) 09:25:12.87終了直前にfreeするためだけに、不要なデータ構造にして、不要なコード書いて、
バグ作りこむ可能性を高くする。
バカのやる事。
0653デフォルトの名無しさん
2013/01/23(水) 09:55:36.71初心者脱出できねえのは
0654デフォルトの名無しさん
2013/01/23(水) 12:50:06.99> 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); */
みたいにしたら?
0655デフォルトの名無しさん
2013/01/23(水) 14:38:59.16> 終了直前にfreeするためだけに、不要なデータ構造にして、不要なコード書いて
もう何言ってるか、自分でも分かってないだろ？
ただ口答えしたいためだけに、屁理屈つけてゴネてるとしか見えん
0656デフォルトの名無しさん
2013/01/23(水) 15:53:40.680657デフォルトの名無しさん
2013/01/23(水) 18:46:12.46freeしたらバグ増える
なんて言っているバカとは仕事したくないな
0658デフォルトの名無しさん
2013/01/23(水) 19:33:33.05解放処理だけは特別とか考えるバカは死んだ方がいい。
0659デフォルトの名無しさん
2013/01/23(水) 19:39:52.47freeしたらバグるってのは設計できていない証だから
0660デフォルトの名無しさん
2013/01/23(水) 19:42:39.75解放処理でバグがでるのは、獲得した領域の扱いそのもののミスなのでかなり致命的。
解放処理でバグが出るやつのソースはすべてにおいて信頼できないクズソースであると認識すべし。
0661デフォルトの名無しさん
2013/01/23(水) 20:42:13.06freeいらない派が低脳な理由がわかったよ
・int dummy[100]; // これがあるとなぜか上手く動く
・//free(p); // これをやると上手く動かないからコメントアウト
0662デフォルトの名無しさん
2013/01/23(水) 20:45:08.57くらいに思っていたほうがよさそうだな。
要は動けばＯＫの人たちということが分かった。
0663デフォルトの名無しさん
2013/01/23(水) 21:03:54.110664デフォルトの名無しさん
2013/01/23(水) 21:10:24.13バグを0に出来る設計。 ｗｗｗｗ
天才現る。 ｗｗｗｗ
0665デフォルトの名無しさん
2013/01/23(水) 21:11:13.50正常系の終了と異常系の終了の区別も付けられないんだなfreeいらない派
0666デフォルトの名無しさん
2013/01/23(水) 21:11:46.660667デフォルトの名無しさん
2013/01/23(水) 21:13:27.63そんな奴が農業やったら作付で領域破壊ｗ
0668デフォルトの名無しさん
2013/01/23(水) 21:16:29.09freeしない設計とは>>646でいえばfree_l()が不要になるという事だからな。
0669デフォルトの名無しさん
2013/01/23(水) 21:16:56.06図書館で本借りても、
返す時に間違えて別の本返しちゃうかもしれないから
返さないで借りパクしちゃうの？
0670デフォルトの名無しさん
2013/01/23(水) 21:18:27.880671デフォルトの名無しさん
2013/01/23(水) 21:19:33.14バカのたとえはたとえになっていない。ｗｗｗ
OSがまとめて回収する機能は図書館で言うとどういう仕組みに該当するんだ? ｗｗｗ
0672デフォルトの名無しさん
2013/01/23(水) 21:20:04.18どうせ督促状来るからそれまでいいやと開き直るタイプらしい
0673デフォルトの名無しさん
2013/01/23(水) 21:20:05.08free_lを呼ばないとmtraceが怒るので、検収に通りません。
0674デフォルトの名無しさん
2013/01/23(水) 21:20:29.27お前らのようなバカは晒しアゲが必定。
0675デフォルトの名無しさん
2013/01/23(水) 21:21:09.79司書さんが自宅を襲撃します。
0676デフォルトの名無しさん
2013/01/23(水) 21:21:31.000677デフォルトの名無しさん
2013/01/23(水) 21:21:37.86SIGKILLじゃなかったらシグナル捕まえてfreeしてるんですね
0678デフォルトの名無しさん
2013/01/23(水) 21:22:25.01バカ晒しあげ
0679デフォルトの名無しさん
2013/01/23(水) 21:27:00.51>OSがまとめて回収する機能は図書館で言うと
行政破たんによる図書館の廃止
0680デフォルトの名無しさん
2013/01/23(水) 21:28:53.53でた、ツールの奴隷。ｗｗ
本末転倒って言葉を知らないんだろうな。ｗｗ
0681デフォルトの名無しさん
2013/01/23(水) 21:30:34.90メモリリークや破壊がないことの証明に苦しんだことのない
アマチュアの言い分だな
0682デフォルトの名無しさん
2013/01/23(水) 21:31:47.450683デフォルトの名無しさん
2013/01/23(水) 21:31:56.47なんでSIGKILLｗ
SIGTERMなら捕まえることはあるよ。サーバーを安全に停止させるためとか。
0684デフォルトの名無しさん
2013/01/23(水) 21:32:20.39プログラミングごっこではあまり使わないかもねｗ
0685デフォルトの名無しさん
2013/01/23(水) 21:35:27.85それこそアマチュアレベルｗｗ
0686デフォルトの名無しさん
2013/01/23(水) 21:38:17.830687デフォルトの名無しさん
2013/01/23(水) 21:42:09.08>>1
>前提１：一般的なC言語（GC搭載していない）
0688デフォルトの名無しさん
2013/01/23(水) 21:43:31.63バカ晒しあげ
0689デフォルトの名無しさん
2013/01/23(水) 21:43:32.86本の中身を領域破壊でめちゃくちゃにしてるので
返したくても返せません。
そうそう自前でラッパを書けばいいこと。バグが怖いからfree()しないって？爆笑
0691デフォルトの名無しさん
2013/01/23(水) 21:48:29.60ラッパ書いて自分でメモリ管理作っちゃう人ですか？
0692デフォルトの名無しさん
2013/01/23(水) 22:01:14.570693デフォルトの名無しさん
2013/01/23(水) 22:02:25.860694デフォルトの名無しさん
2013/01/23(水) 22:03:53.16freeを満足に書けない人ｗ
0695デフォルトの名無しさん
2013/01/23(水) 22:07:53.190696デフォルトの名無しさん
2013/01/23(水) 22:09:27.02free楽勝とか言ってるバカはおもちゃプログラムしか書いたことないんだろ。ｗｗｗ
0697デフォルトの名無しさん
2013/01/23(水) 22:12:56.26free複雑とか言っているバカは単なるオナニー野郎
0698デフォルトの名無しさん
2013/01/23(水) 22:14:49.980699デフォルトの名無しさん
2013/01/23(水) 22:16:32.580700デフォルトの名無しさん
2013/01/23(水) 22:17:36.290701デフォルトの名無しさん
2013/01/23(水) 22:19:01.380702デフォルトの名無しさん
2013/01/23(水) 22:20:35.49わかるわ〜それ
0703デフォルトの名無しさん
2013/01/23(水) 22:20:38.920704デフォルトの名無しさん
2013/01/23(水) 22:22:54.90連結リストでダブルポインタとか素人かよｗｗｗ
0705デフォルトの名無しさん
2013/01/23(水) 22:24:46.41freeいらないっていう主張だったとは。
0706デフォルトの名無しさん
2013/01/23(水) 22:27:57.47> SIGTERMなら捕まえることはあるよ。サーバーを安全に停止させるためとか。
もちろん安全に停止させるためにfreeしたんですよね？
0707デフォルトの名無しさん
2013/01/23(水) 22:36:37.470708デフォルトの名無しさん
2013/01/23(水) 22:38:11.42メインスレッド側でね。ハンドラはフラグ立てるだけ。
0709デフォルトの名無しさん
2013/01/23(水) 22:43:24.89そういえばQzとかいうチンカスがこの意味不明な用語使ってたな。ｗｗｗ
0710デフォルトの名無しさん
2013/01/23(水) 22:46:35.40＞ダブルポインタ? double *の事か? ｗｗｗ
＞ダブルポインタ? double *の事か? ｗｗｗ
0711デフォルトの名無しさん
2013/01/23(水) 22:46:46.520712デフォルトの名無しさん
2013/01/23(水) 22:48:39.58ポインタの理解が微妙でfreeするとバグるから
freeいらないっていう主張だったとは。
の事実からは逃れられない
0713デフォルトの名無しさん
2013/01/23(水) 22:49:26.96底辺ではふつうに使う用語なのか? ｗｗｗ
0714デフォルトの名無しさん
2013/01/23(水) 22:50:36.57とびっきりのバカだな。ｗｗｗ
0715デフォルトの名無しさん
2013/01/23(水) 22:50:43.020716デフォルトの名無しさん
2013/01/23(水) 22:51:48.350717デフォルトの名無しさん
2013/01/23(水) 22:56:06.79お前の俺用語を公開しろよ
0718デフォルトの名無しさん
2013/01/23(水) 22:58:59.980719デフォルトの名無しさん
2013/01/23(水) 23:13:16.63規格書にもそう書いてあるが、底辺じゃダブルポインタと呼んでるのか。
底辺向けの書籍にでも書いてあるのか? ｗｗｗ
なんて書籍だ?
0720デフォルトの名無しさん
2013/01/23(水) 23:16:44.720721デフォルトの名無しさん
2013/01/23(水) 23:18:30.19struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;
0722デフォルトの名無しさん
2013/01/23(水) 23:19:13.83で、どの底辺書籍にそう書いてあるんだ? ｗｗｗ
0723デフォルトの名無しさん
2013/01/24(木) 00:01:40.880724デフォルトの名無しさん
2013/01/24(木) 00:47:00.03なら確保・解放の個数を減らせばいい。
例えば 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);
とする。
0725デフォルトの名無しさん
2013/01/24(木) 07:40:21.23malloc/freeの無い環境ならやるかも
0726デフォルトの名無しさん
2013/01/24(木) 08:30:01.55* 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
* 解放処理楽勝と豪語しているバカは下の確保処理より簡単に書け。
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;
バカだから出来るわけないよね。ｗｗｗ
0727デフォルトの名無しさん
2013/01/24(木) 08:32:20.36バカは問題設定すらまともにできないらしい。ｗｗｗ
> 例えば int型[12][34] 配列を確保・解放する場合…
自分で設定した仕様に対し
> d = (int **) malloc(sizeof(int *) * 12);
> for (i = 0; i < 12; i++) d[i] = (int *) malloc(sizeof(int) * 34);
既に仕様通りに出来ていない。 ｗｗｗ
さすが底辺。ｗｗｗｗ
0729デフォルトの名無しさん
2013/01/24(木) 22:42:31.61for (struct l *p = root, *q; p; q = p, p = p->next, free(q));
0730デフォルトの名無しさん
2013/01/25(金) 09:01:27.69「free楽勝とか言ってるのは、C言語を知らないバカな初心者です」という事を示す自爆レスか 。
バカ哀れ。ｗｗｗｗｗｗｗｗｗ
int (*d)[12][34] = malloc(sizeof(*d));
こっちの方が遥かに簡潔だろう。ｗｗｗｗｗｗｗｗｗｗｗｗ
>>729
;で区切らず,で区切れば簡潔。 ｗｗｗｗ 小学生並みの浅知恵 ｗｗｗｗｗｗｗｗｗ
0731728
2013/01/25(金) 20:22:06.21半信半疑だったけどやってみたら、、、
ttp://ideone.com/VmS6al
久しぶりに勃起した。
mallocの後にfree最高。
0732デフォルトの名無しさん
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];
使ってるのが多い。誰が流行らしたんだ? 最初に使いだしたバカ。死んでしまえ。ｗｗｗ
0733デフォルトの名無しさん
2013/01/25(金) 21:49:43.43配列の要素数があらかじめ分かっていないと使えない方法
さすがに>727はメモリ確保が多すぎてメモリが細切れになりそう(本来なら一度の確保で十分)
>731
式と演算子を理解していれば、あたり前田のクラッカー
0734デフォルトの名無しさん
2013/01/25(金) 22:44:11.60このスレのバカ召喚性能は異常。ｗｗｗ
> 配列の要素数があらかじめ分かっていないと使えない方法
お題通りに整数で書いたけど、この知ったかバカは可変長配列知らないらしい。 ｗｗｗｗ
それともC89を未だに使い続けている原始人ですか? ｗｗｗ
0735デフォルトの名無しさん
2013/01/25(金) 23:00:16.03C99から使えるようになった
一部のコンパイラでは拡張機能として使えたけど
もちろんC89をいまだに使いつづけている原始人ですが何か
gccのフラグは-ansi -std=c89 -pedanticですが何か
-ansiと-pedanticは不要だけどね何か
0736デフォルトの名無しさん
2013/01/25(金) 23:08:06.88前半について、何のことかと思い>732のURLを見たが両方共だめなやり方しか紹介されていない
少なくとも僕が一度の確保で十分と言った方法ではない
いやー、最近はポインタもまともに扱えない人が多いな
0737デフォルトの名無しさん
2013/01/25(金) 23:14:08.94Linuxや*BSDのカーネルいじれないポンコツ ｗｗｗ
後付けの言い訳は墓穴掘るだけだぞ。 ｗｗｗ
0738デフォルトの名無しさん
2013/01/25(金) 23:18:59.80> 少なくとも僕が一度の確保で十分と言った方法ではない
それはひょっとしてバカ(>>724)が「じゃなくて」って言った方か? ｗｗｗ
0739デフォルトの名無しさん
2013/01/25(金) 23:22:30.94ひさしぶりに規格ガチ準拠スレの興奮を思い出した
0740デフォルトの名無しさん
2013/01/25(金) 23:30:49.30いや、それは2度確保しているから両方共だめだろ
まぁ、考え方は「じゃなくて」に近いかな
0741デフォルトの名無しさん
2013/01/26(土) 00:27:02.8432 bitアプリで2Gまでのファイルしか扱えないポンコツ ｗｗｗ
0742デフォルトの名無しさん
2013/01/26(土) 01:35:25.060743デフォルトの名無しさん
2013/01/27(日) 01:13:52.26ということが証明されたのがよほど堪えているようだ。
一人レスを流そうと必死なのが涙を誘うｗ
0744デフォルトの名無しさん
2013/01/27(日) 01:43:13.40free必須派 == freeなんか楽勝 == 実はバカ素人 じゃん。 ｗｗｗｗ
バカ必死。ｗｗｗｗ
0745デフォルトの名無しさん
2013/01/27(日) 01:46:43.81* 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
* 解放処理楽勝と豪語しているバカは下の確保処理より簡単に書け。
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;
バカだから出来るわけないよね。ｗｗｗ
0746デフォルトの名無しさん
2013/01/27(日) 01:59:06.21バカ必死晒し
0747デフォルトの名無しさん
2013/01/27(日) 02:54:07.43ああ、freeバカじゃなくてそれ以下のバカか。ｗｗｗ
別スレでも絡んできたバカだろ ｗｗｗ
0748デフォルトの名無しさん
2013/01/27(日) 04:10:08.880749デフォルトの名無しさん
2013/01/27(日) 04:45:06.280751デフォルトの名無しさん
2013/01/27(日) 09:33:34.85素直にexitしとけばバグ作る事もないのに。ｗｗｗ
アマゾンギフト10万円分でバグ教えてあげるよ。ｗｗｗ
0753デフォルトの名無しさん
2013/01/27(日) 10:14:33.960754デフォルトの名無しさん
2013/01/27(日) 10:24:11.13お前もバカだろ。ｗｗｗｗ
(終了直前の)不要なfree処理を書いてバグの可能性を高くするのはバカのやる事といっている。
違いわかるかな? でもバカだからわからないよね。ｗｗｗｗ
うんこQzは目視で楽勝に発見できるバグをなおしてから出直しな。ｗｗｗ
バグが怖いからfree()しないって？爆笑
0756デフォルトの名無しさん
2013/01/27(日) 10:44:17.75あの誰にも相手にされてないうんこラッパの事か? ｗｗｗｗ
あの程度でバグを検出できると思ってるから、お前はダメなんだよ。ｗｗｗ
このレクチャーは無料で良いぞ。ｗｗｗ
0757デフォルトの名無しさん
2013/01/27(日) 11:38:05.28ってことなんだな。こんな単純な処理でバグを入れ込むとかｗｗｗ
まさにクズ人間ｗｗｗ
0758デフォルトの名無しさん
2013/01/27(日) 11:45:42.71怖いからやらないレベルなので小学生どころか幼稚園児だな
0759デフォルトの名無しさん
2013/01/27(日) 12:39:10.10それでもバカだからバグ作りこむんだよな。ｗｗｗｗ
freeバカ惨め ｗｗｗｗ
0760デフォルトの名無しさん
2013/01/27(日) 12:54:39.65バカとしか言えないバカ惨め (w
0761デフォルトの名無しさん
2013/01/27(日) 13:19:44.15バカすぎる。ｗｗｗｗｗ
0762デフォルトの名無しさん
2013/01/27(日) 13:20:49.370763デフォルトの名無しさん
2013/01/27(日) 13:22:29.51Drowって何やねん
Drawか
0765デフォルトの名無しさん
2013/01/27(日) 13:46:06.870766デフォルトの名無しさん
2013/01/27(日) 13:50:19.21それを含めて解放のコストですけど。
樹状に作られたリンクが途中でくっついていたり、
ループしてたりすると解放も単純じゃないんだけど
で、それをちまちま解放していくのがめんどいから
mallocでごっそりメモリをとって、プログラムのほうで
メモリ管理をして、解放するときはまとめてfree
って、それってmmapでOSからメモリをとってきて
メモリ管理をしてくれるmalloc/freeとまったく同じことしてるじゃん
屋上屋を重ねるってまさにこのことだね
0767デフォルトの名無しさん
2013/01/27(日) 13:51:24.40本日一番のバカ。ｗｗｗｗ
0768洒落のわからん馬鹿がいるな
2013/01/27(日) 14:03:13.81>>767
0769デフォルトの名無しさん
2013/01/27(日) 14:07:13.49終了時のfreeのみ問題にしているのは、
それ以外のfreeは確保した領域を再利用するための*必要な*freeだから
終了時のfreeはただ単純に無駄だから
まぁ、mtraceを通すためっていうのはわかる。
ただ、mtraceを通すためだけにfreeするのって
コンパイラを通すために○○するっていうのと精神に於いて変わらないような。
mtraceはここのmallocはfreeしなくてもいいですよって指示与える機能はないの ?
指示するよりfree書いちゃったほうが速いと言われるんだろうが
0770デフォルトの名無しさん
2013/01/27(日) 14:13:54.25言いたいことは分かるが
最後の一文は余計だな
同一関数内でmalloc()とfree()を呼ぶことはあまりないと思うんだよなぁ
lintさんはちゃっかり警告してくるけど
malloc()とfree()をラップするような、いわゆるオブジェクト指向をサポートする言語で言うところのコンストラクタとディストラクタを作っておけば開放漏れは防げるでしょ
再三、連結リストが話題に出ているけど、free()不要と言う人は、時間のかかるプロセスが要素を確保して、開放せずにまた別の要素を確保しつづけるの
プロセスがゾンビ化したらfree()とか関係ないけど
0771デフォルトの名無しさん
2013/01/27(日) 14:23:15.02>ただ、mtraceを通すためだけにfreeするのって
>コンパイラを通すために○○するっていうのと精神に於いて変わらないような。
さすがにその理解力じゃ世の中渡るの辛いだろうな…
0772デフォルトの名無しさん
2013/01/27(日) 14:51:33.76作るでしょ。それがデータ構造の設計。
コストの問題でプロセス終了前に解放を省くってのはあり得るけど、
解放処理がバグっているってのはあり得ない。正常系だしね。
それは実力が足りていないかテストが足りていないかの問題で、
プロセス終了前の解放を省くこととはまったくの無関係。
スレッドタイトルを見る限りは、プログラム終了直前のfree() を省くかどうかを問題にしているわけではないからねえ。
0774デフォルトの名無しさん
2013/01/27(日) 15:10:05.20＞お前もバカだろ。ｗｗｗｗ
自分がバカという自覚はあるようですね？
早く反論しなくちゃとあせってミスするのが得意なようで。
0775デフォルトの名無しさん
2013/01/27(日) 15:41:44.16主張を捻じ曲げる事でしか反論できなくなった。バカ。ｗｗｗｗ
目視で簡単に見破られるバグ乱発しなくなってから出直しな。
テメーのうんこプログラムのバグ片手以上は晒しあげた記憶があるぞ。ｗｗｗ
未だにシグナルハンドラバグ入りで絶賛放置中だろ。ｗｗｗ
>>774
お前日本語わからない。バカ。ｗｗｗ
異常なバカ召喚性能を誇るこのスレに召喚されたバカ共の一部という意味。 ｗｗｗ
それより、お前「本日一番のバカ」だろ。↓こいつ ｗｗｗ
From: [760] デフォルトの名無しさん <sage>
Date: 2013/01/27(日) 12:54:39.65
>>759-760
バカとしか言えないバカ惨め (w
0776760: >>774 じゃねーし
2013/01/27(日) 15:46:11.96> お前「本日一番のバカ」だろ。↓こいつ ｗｗｗ
ツボ突いたみたいだな (w
0777デフォルトの名無しさん
2013/01/27(日) 15:46:44.280778デフォルトの名無しさん
2013/01/27(日) 15:52:38.79From: [760] デフォルトの名無しさん <sage>
Date: 2013/01/27(日) 12:54:39.65
>>759-760
バカとしか言えないバカ惨め (w
0779デフォルトの名無しさん
2013/01/27(日) 15:57:35.04>>776
0780デフォルトの名無しさん
2013/01/27(日) 15:58:54.59From: [760] デフォルトの名無しさん <sage>
Date: 2013/01/27(日) 12:54:39.65
>>759-760
バカとしか言えないバカ惨め (w
0781デフォルトの名無しさん
2013/01/27(日) 15:59:46.89// 起動時に一度しか呼ばれないと思って作った関数
void safe_func(){
malloc(100000);
}
void onTick(){
safe_func(); // 安全な関数だから何回呼んでも問題ないよね まさか中でメモリ確保して放置してるわけがない
}
扱いに細心の注意が必要だった。
0782デフォルトの名無しさん
2013/01/27(日) 16:08:27.19ああ、Win95か98で、アイコンかなんかの小さいGDIを解放していなくて
空きリソースが微妙に減っていってそのうちシステムが落ちるとかいう
バグを思い出した。
0783デフォルトの名無しさん
2013/01/27(日) 16:09:28.01そんなことこのスレで言ってるのはバカのお前だけ。ｗｗｗ
またfreeバカの知能の低さが実証されてしまった。ｗｗｗｗ
0784デフォルトの名無しさん
2013/01/27(日) 16:10:40.90Windows7でもGDIリークは健在で
2週間くらい再起動してないとexplorer.exeが上限の9999になるよ
0785デフォルトの名無しさん
2013/01/27(日) 16:11:22.69プッ
0786デフォルトの名無しさん
2013/01/27(日) 16:12:35.770787デフォルトの名無しさん
2013/01/27(日) 16:12:40.69free()必要・不要とで実際にプログラム書いてみて、出来を判定すればそれで十分だろ
基準は、実効速度・バグの少なさ・保守性(可読性)とかにして
例えば、Linuxに標準で付いている/usr/share/dict/のwordsをケースインセンシティブに始めの一文字がブレークするごとに、単語の文字数が小さくASCII辞書順に別のファイルに出力するプログラムとか
0788デフォルトの名無しさん
2013/01/27(日) 16:34:21.76int 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;
}
0789デフォルトの名無しさん
2013/01/27(日) 16:37:01.42底辺用語使ってるC言語の解説書籍はあるのかないのかはっきりしろよ。>>700 ｗｗｗ
0790デフォルトの名無しさん
2013/01/27(日) 16:45:41.450791デフォルトの名無しさん
2013/01/27(日) 16:58:33.48ダブルポインタ ｗｗｗｗ
ダブルポインタ ｗｗｗｗ
ダブルポインタ ｗｗｗｗ
ダブルポインタ ｗｗｗｗ
0792デフォルトの名無しさん
2013/01/27(日) 17:16:32.10まあ土日だからしょうがないわな
0793デフォルトの名無しさん
2013/01/27(日) 17:24:21.130794デフォルトの名無しさん
2013/01/27(日) 18:01:31.95File I/O With Double Pointer?
http://www.cplusplus.com/forum/general/60351/
>>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 秒）
0796デフォルトの名無しさん
2013/01/27(日) 18:44:34.55困った時のぐぐる頼みｗｗｗ
だからお前は底辺なんだよｗｗｗ
0797デフォルトの名無しさん
2013/01/27(日) 18:48:32.59ほんとバカだな。ｗｗｗ
実際にはこんなまとめて確保なんかしないだろ。ｗｗｗ
常識的には徐々に増えていくものだ。
簡潔な解放処理を例にあげただけだぞ。ｗｗｗ
そんなことも読み取れない底辺バカ。ｗｗｗ
0798デフォルトの名無しさん
2013/01/27(日) 18:49:17.96根拠出したら反論できなくなってあせりだしたか
バカは大変だな
0799デフォルトの名無しさん
2013/01/27(日) 18:53:05.97言いたいことも伝えられない発達障害のその脳ミソじゃ
コミュニケーション取れなくて生きるの辛いだろうな
とりあえず晒しとくか
0800デフォルトの名無しさん
2013/01/27(日) 18:54:09.19きちんと書籍になっているものを持って来いよ。ｗｗｗ
0801デフォルトの名無しさん
2013/01/27(日) 18:55:52.38馬鹿じゃねーのばーか。
0802デフォルトの名無しさん
2013/01/27(日) 18:56:31.110803デフォルトの名無しさん
2013/01/27(日) 18:56:32.75参考書籍：ぐぐる検索
ｗｗｗ
0804デフォルトの名無しさん
2013/01/27(日) 19:00:20.19https://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 =
もうそろそろ土下座して謝る時が来たようだぜ？
0805デフォルトの名無しさん
2013/01/27(日) 19:02:16.40なんと1860件も書籍で使われてる例が見つかる！
これって重複ないのか？
検索結果プレビューを見る限り、
同じ本がリストアップされてないようにみえる。
うわっ！こんなに、書籍で使われてる！
0806デフォルトの名無しさん
2013/01/27(日) 19:02:36.940807デフォルトの名無しさん
2013/01/27(日) 19:03:17.940808デフォルトの名無しさん
2013/01/27(日) 19:04:07.87そこでなんで、"ダブルポインタ"で
日本語の書籍を調べようと思わんの？
0809デフォルトの名無しさん
2013/01/27(日) 19:04:21.86お前はぐぐって出てさえすればどんな用語でも通用すると思ってんの？ｗｗｗ
底辺が適当に底辺用語を書いたのが拾われているだけかもしれんぞ。ｗｗｗ
まさかぐぐって出てきた用語を日常で使ってないよな。ｗｗｗ
２ちゃんねる語を日常で使うくらい恥ずかしいことだぞ。ｗｗｗ
0810デフォルトの名無しさん
2013/01/27(日) 19:05:32.35ん？ 英語の書籍で使われてる用語は
普通に使われていると解釈していいでしょ？
土下座まだ？
0811デフォルトの名無しさん
2013/01/27(日) 19:05:40.41底辺向けの娯楽書籍が引っかかっただけだぞ。ｗｗｗ
それらの書籍になんの権威があるんだ。ｗｗｗ
0812デフォルトの名無しさん
2013/01/27(日) 19:06:46.53中身見たから確かなことだよ。
http://www.amazon.co.jp/Object-Oriented-Programming-Kaleidoscope-Robert-Lafore/dp/0672323087
みろ、星すらついていない。
0813デフォルトの名無しさん
2013/01/27(日) 19:07:15.50底辺バカはほんとにバカなんだな。ｗｗｗ
0814デフォルトの名無しさん
2013/01/27(日) 19:10:13.67なんで、日本のamazonで調べるんだよｗ
Double pointerという用語がでてくる
「Object-Oriented Programming in C++ 」が
娯楽書籍かどうか、頭冷やしてよく考えてみろ。
https://www.google.co.jp/search?tbm=bks&;amp;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
0815デフォルトの名無しさん
2013/01/27(日) 19:12:43.83>>719の通り、規格書レベルではまだ見つけられないようだな。ｗｗｗ
0816デフォルトの名無しさん
2013/01/27(日) 19:13:32.29無限といってもいいほどある本の中から
使われてる証拠を簡単に見つけ出すことが出来るんだ。
本当の底辺はてーへんだなｗ
0817デフォルトの名無しさん
2013/01/27(日) 19:14:36.48この事実は揺るがない。ｗｗｗ
お前、amazon.com で買い物したことないのか？
http://www.amazon.com/Object-Oriented-Programming-C-4th-Edition/dp/0672323087/
0819デフォルトの名無しさん
2013/01/27(日) 19:22:08.62これで認めないとかちょっと頭おかしいと思う。
それにこの本だけじゃなくて、1840冊も使用例が見つかってるのを
お忘れなく。
https://www.google.co.jp/search?tbm=bks&;q="double+pointer"
書籍 約 1,890 件 （0.13 秒）
free() 不要派＝バグが怖くてfree()ができない free() 不能派、であることがばれちゃったので他のそこはかとない根拠を求めて日夜努力しているのですね敬服の限りです
あとスレタイ読んでね。
0821デフォルトの名無しさん
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
0822デフォルトの名無しさん
2013/01/27(日) 19:26:35.34楽しすぎｗｗｗ
0823デフォルトの名無しさん
2013/01/27(日) 19:29:08.82オライリーｗｗｗ
底辺の間で結構人気があるらしいね。ｗｗｗ
でどこの規格書に由来しているの？ｗｗｗ
0824デフォルトの名無しさん
2013/01/27(日) 19:31:51.28> まさか根拠に自己出版レベルの娯楽書籍を持ち出すとか、
「自己出版」なんて用語は認めんｗｗｗ
>>823
え？ オライリー知らないの？ そういうレベルの人だね。
「二重のポインタ」という言葉に規格書を要求するって
頭おかしいと思う。
0825デフォルトの名無しさん
2013/01/27(日) 19:35:43.42オライリーの本を神聖化してるのは底辺ぐらい。
0827デフォルトの名無しさん
2013/01/27(日) 19:37:59.63オライリーよりも・・・頭がいい？
オライリーは人の名前じゃないよ。
0828デフォルトの名無しさん
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.
0829デフォルトの名無しさん
2013/01/27(日) 19:57:26.10wiki answersを信用してどうするの？ｗ
0830デフォルトの名無しさん
2013/01/27(日) 20:00:44.44What 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;
0831828
2013/01/27(日) 20:03:07.86wiki.answersしらんの？
wikipedia作った人が、wikipediaと同じ概念で作った
wikiと同じように信頼出来る、
だれでも投稿できるFAQシステムなんだけど？
0832デフォルトの名無しさん
2013/01/27(日) 20:13:36.54その回答を書いた、 Avsharathってだれなん？
どれくらい権威がある人？
素人にしか見えないんだが、書籍に対抗させようと
してるぐらいだ、書籍以上の何かを
お前は示せるんだろう？
0833デフォルトの名無しさん
2013/01/27(日) 20:27:16.68> * 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
と言ったわけだが、C(C++でもいいけど)言語解説書籍が一つも出てこないな。
検索しか能の無いバカ底辺が必死で探して出てこないって事は、やっぱ無いんじゃないの。 ｗｗｗ
0834デフォルトの名無しさん
2013/01/27(日) 21:03:08.39自然と生まれることもあるんだよ。
間違った使い方（つまり正しい使い方が存在する）ものは誤用でいいが、
新しく生まれた言葉は誤用にはならない。
これだけ多くの本で使われてる言葉だ。
一体お前は何を求めているのだ？
0835デフォルトの名無しさん
2013/01/27(日) 21:05:04.08ポインタがある言語共通のプログラミング用語だよ。
0836769
2013/01/27(日) 21:09:30.18どいういうこと?
理解力のない自分に教えていただきたい。
終了直前のfreeの意義って
mtraceにで警告でないようにする、
社内規定がそうなっている、（上のK社のもしもし向けアプリの話とか)
以外にあるのかな ?
わかってて書くmtraceを通すためのfreeとそうでないコンパイラを通すための
○○ではわかってるかどうかがちがうというなら、書き方が悪かった。
0837デフォルトの名無しさん
2013/01/27(日) 21:20:24.080838デフォルトの名無しさん
2013/01/27(日) 21:22:35.87ダブルポインタって書いてある、底辺向け以外の本はまだ？
評価が高い本でも、底辺向け本はいくら集めても無駄だよ。
0839デフォルトの名無しさん
2013/01/27(日) 21:23:04.42つまり、必死で探したけどなかったってわけね。ｗｗｗ
>>835
> ポインタがある言語共通のプログラミング用語だよ。
って、Cから派生した以外の言語でポインタのポインタが使えるのってどれだよ。
0840デフォルトの名無しさん
2013/01/27(日) 21:24:22.73↓
評価が高い本にも書いてある。
↓
くやしい
↓
そんな本は全部糞だ。底辺向けの本なんだ。
↓
発作おさまる。
0841デフォルトの名無しさん
2013/01/27(日) 21:37:46.97やっぱりヘボだ。ｗｗｗｗ
> 確保は線形的、解放は再帰的かいな？
確保時のforは列挙だろ。バカヘボ。 ｗｗｗ
while (gets(s)) add_str(s, top);
論理的には同じ。 これでadd_treeが再帰で書かれていても「確保は線形」とかいうのか? バカすぎる ｗｗｗ
0842デフォルトの名無しさん
2013/01/27(日) 21:41:19.80> * 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
0843デフォルトの名無しさん
2013/01/27(日) 21:41:55.10https://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,
0844デフォルトの名無しさん
2013/01/27(日) 21:50:15.12> * 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
それOopの解説書。バカにはわからないらしい。ｗｗｗｗ
0845デフォルトの名無しさん
2013/01/27(日) 21:51:21.82知ってるよｗわざとだよｗおせよーよ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
0846デフォルトの名無しさん
2013/01/27(日) 21:55:48.52↓
どうしよう！
↓
発作再開
0847デフォルトの名無しさん
2013/01/27(日) 21:58:11.330848デフォルトの名無しさん
2013/01/27(日) 22:03:46.26著者この人? キミたちにぴったりの書籍みたいだね。いや人種差別するわけじゃないけど ｗｗｗｗ
http://in.linkedin.com/pub/arpita-gopal/22/247/253
0849デフォルトの名無しさん
2013/01/27(日) 22:03:50.83おせよーよって何語だよｗｗｗ
0850デフォルトの名無しさん
2013/01/27(日) 22:05:07.56freeの処理がうまくつくれなくてバグりそうだからfreeいらないと
いっていた事実からは逃れられない！
0851デフォルトの名無しさん
2013/01/27(日) 22:08:06.07いつそんな事いった? ねつ造すんじゃねーぞ。バカ。ｗｗｗｗ
0852デフォルトの名無しさん
2013/01/27(日) 22:11:09.32顔真っ赤にして発狂してるのはなぜですか？
トラウマだからですか？理解できないからですか？
0853デフォルトの名無しさん
2013/01/27(日) 22:14:34.48free必須バカはまず以下に回答するように。 ｗｗｗｗ
* 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
* 解放処理楽勝と豪語しているバカは下の確保処理より簡単に書け。
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;
バカだから出来るわけないよね。ｗｗｗ
0854デフォルトの名無しさん
2013/01/27(日) 22:16:37.12「ダブルポインタ」って言われて「double *」と勘違いして作って
怒られた経験があるんだよ。その時いくら規格書を持って反論しても
聞いてもらえなくて、俺のほうが全然優秀なのに笑いものにされてしまった
つらい過去があるんだよ。ｗｗｗ
0855デフォルトの名無しさん
2013/01/27(日) 22:17:40.67「ダブルポインタ」は「ダブルポインタが無い言語は欠陥言語」とか言ってるバカがいて
その言葉を見るだけで腹がよじれるほど笑うので過剰反応になるのはしょうがない。ｗｗｗ
0856デフォルトの名無しさん
2013/01/27(日) 23:25:43.36まあいいけどな
0857デフォルトの名無しさん
2013/01/27(日) 23:32:19.80もう一回貼ってやるよ。 宿題ちゃんとやれよ。底辺バカ。ｗｗｗ
free必須バカはまず以下に回答するように。 ｗｗｗｗ
* 「ダブルポインタ」とかいう底辺用語を使用しているC言語解説書籍を示せ。
* 解放処理楽勝と豪語しているバカは下の確保処理より簡単に書け。
struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;
バカだから出来るわけないよね。ｗｗｗ
0858デフォルトの名無しさん
2013/01/27(日) 23:45:37.130859デフォルトの名無しさん
2013/01/28(月) 00:04:56.97人間の進歩って難しいね。
0860デフォルトの名無しさん
2013/01/28(月) 00:29:03.94自分で墓穴堀り返すのは趣味なのか
0861デフォルトの名無しさん
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);
}
0862デフォルトの名無しさん
2013/01/28(月) 00:32:56.53まあ、もともとの主張は「java に参照渡しが存在しないのは致命的だ」なんですけれどもねえ。
http://toro.2ch.net/test/read.cgi/tech/1313183984/403
0864デフォルトの名無しさん
2013/01/28(月) 00:59:34.31elseワロタ
列挙的だろーが線形的だろーが意味するところはおんなじだろう？
言葉尻を捕らえて差異があるかのように大騒ぎするのはもうやめようね
0866デフォルトの名無しさん
2013/01/28(月) 08:10:01.52free楽勝とか豪語しているのは底辺バカという事が実証されたようだな。ｗｗｗｗ
お題「簡単に書け」を「短くかけ」とか勝手に変更したうえ、お題には無かった
「判定」操作を加えて複雑にした上に、バグ作りこんでる。 ｗｗｗｗｗ
バカの極み。ｗｗｗｗｗ
>>865
やっぱりバカだ。ｗｗｗ
free_lはデータ構造に対する操作。forは入力データに対する操作。
free_lと対比させるなら、データ構造に対する(insert)操作ということになるが、
これは無名のブロック
{ struct l *p = malloc(sizeof(struct l)); p->next = root; root = p; }
が該当する。そしてこれは先頭に追加していくので再帰構造にする必要が無い。
下らねーことに言いがかり付けてんじゃねーよ。チンカス。
0867デフォルトの名無しさん
2013/01/28(月) 13:22:40.69やっぱテンプレート使えないと面倒かね。
Cのプリプロセスだけ使うオプションみたいに、
C++のテンプレートまで処理を行うオプションないのかな。
0868デフォルトの名無しさん
2013/01/28(月) 20:02:41.78C++のスマートポインタはできるのかどうかわからんけど、演算子
オーバーロードがないから似ても似つかないものになりそう。
0869デフォルトの名無しさん
2013/01/28(月) 22:07:21.91struct l *p = root;
root = p ? p->next : p;
free(p);
0870デフォルトの名無しさん
2013/01/28(月) 22:32:09.44root = p ? p->next : NUL;
free(p);
まずスレッドタイトル嫁。プロセス終了直前に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
再帰のオーバーヘッドは馬鹿にならないね。
0872デフォルトの名無しさん
2013/01/29(火) 09:41:31.200874デフォルトの名無しさん
2013/01/29(火) 12:37:44.50void free_l(struct l * restrict p) {
struct l *next = p->next;
free(p);
if (next)
free_l(next);
}
バカのいいがかりなんて所詮この程度の事。 バカには意味わからないだろうけどな。ｗｗｗ
0875デフォルトの名無しさん
2013/01/29(火) 12:50:52.54キチガイのやることです
0876デフォルトの名無しさん
2013/01/29(火) 12:58:33.48天才には簡単な問題ですので必ず逃げないで答えてください
スタックサイズが8MBのとき、このfree_l関数で解放可能な連結リストは
最大何個連結可能でしょうか？
アーキテクチャは好きに選んでいいですよ
0877デフォルトの名無しさん
2013/01/29(火) 13:05:55.37void free_l(struct l *pp) {
for (struct l *p = pp; p; p = pp) {
pp = p->pNext;
free (p);
}
}
は正しいでしょうか？
0878デフォルトの名無しさん
2013/01/29(火) 13:09:29.22美しくないです
0879デフォルトの名無しさん
2013/01/29(火) 14:21:00.03予想通りバカにはわかっていない。 ｗｗｗｗ
0880デフォルトの名無しさん
2013/01/29(火) 14:31:53.180881デフォルトの名無しさん
2013/01/29(火) 14:33:48.540882デフォルトの名無しさん
2013/01/29(火) 14:35:32.20顔真っ赤にして罵倒して逃げることしかできない朝鮮人のような
あなたを見ることができて、私は満足しましたから
0883デフォルトの名無しさん
2013/01/29(火) 14:38:37.80解放処理を簡単に書くコンテストで負けて。しかも参加者はみんなバグってるというおまけつき。 ｗｗｗｗ
>>874を理解せずに勝利宣言。 ｗｗｗｗｗ
生きてくのつらくないか? 底辺バカ ｗｗｗｗ
0884デフォルトの名無しさん
2013/01/29(火) 14:41:33.76答えられるならばの話ですけど
0885デフォルトの名無しさん
2013/01/29(火) 14:42:41.02制限なし。ｗｗｗ
これでいいのか。 ｗｗｗ
0886デフォルトの名無しさん
2013/01/29(火) 14:47:24.52スレ違いで申し訳ない質問です。
> void free_l(struct l * restrict p) {
引数1個で restrict って効果ありますか？
0887デフォルトの名無しさん
2013/01/29(火) 14:50:55.82ああ、コピペの時の単なるゴミだ。 意味ないね。
0888デフォルトの名無しさん
2013/01/29(火) 15:11:31.24なんだよ。バカに釣られて答えちまったぜ。 ｗｗｗｗ
>>867
> Cにも参照カウントベースのスマートポインタを実装できないものかな。
> やっぱテンプレート使えないと面倒かね。
>
> Cのプリプロセスだけ使うオプションみたいに、
> C++のテンプレートまで処理を行うオプションないのかな。
能無しだとは思っていたが、まさかアンカーすらまともにうてないとは予想の斜め上だったぜ。 ｗｗｗ
>>885は>>876への回答な。 ｗｗｗｗ
息してるか？ バカ。ｗｗｗｗ
0889デフォルトの名無しさん
2013/01/29(火) 15:16:19.970890デフォルトの名無しさん
2013/01/29(火) 15:24:04.07http://pastebin.com/4pBPEWBG
読めなくて良かったな。バカ。 ｗｗｗｗｗ
読めてたら憤死するところだぞ。 ｗｗｗｗ
0891デフォルトの名無しさん
2013/01/29(火) 15:27:35.57回答ありがとう。コピペミス了解。
(出来れば見分けやすいよう、行末に「。 ｗｗｗｗ」を付けてくださいｗ)
0892デフォルトの名無しさん
2013/01/29(火) 15:30:30.12ｗｗｗｗはバカを相手にするとき。
0893デフォルトの名無しさん
2013/01/29(火) 15:39:12.99さすが天才のｗｗｗさんですね
0894デフォルトの名無しさん
2013/01/29(火) 15:46:06.580895デフォルトの名無しさん
2013/01/29(火) 15:50:18.570896デフォルトの名無しさん
2013/01/29(火) 16:02:26.60ここから俺の自演
0897デフォルトの名無しさん
2013/01/29(火) 16:07:24.29>>874で警告しといてあげたのに。ｗｗｗｗｗ
> バカのいいがかりなんて所詮この程度の事。 バカには意味わからないだろうけどな。ｗｗｗ
やっぱり、バカにはわからなかったようだね。コンパイラ程度の知能があればよかったのにね ｗｗｗｗ
ところで>>876の回答>>885はあってんの? 出題者は採点しろよ。 ｗｗｗｗ
0898デフォルトの名無しさん
2013/01/29(火) 16:14:23.10それとも、*nextはスタックを消費しないってこと？
0899デフォルトの名無しさん
2013/01/29(火) 16:39:16.63証拠 → 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だな。
せっかく↓警告しといてあげたのにね。
> バカのいいがかりなんて所詮この程度の事。 バカには意味わからないだろうけどな。ｗｗｗ
0900デフォルトの名無しさん
2013/01/29(火) 16:49:15.780901デフォルトの名無しさん
2013/01/29(火) 16:59:41.77予定外のバカも釣れたようだが。ｗｗｗ
問題に答えたんだからとっとと採点しろよ。 バカ。ｗｗｗｗ
0902デフォルトの名無しさん
2013/01/29(火) 17:00:44.99どの規格書に書いてあるの？
0903デフォルトの名無しさん
2013/01/29(火) 17:03:41.08憐れすぎる
0904デフォルトの名無しさん
2013/01/29(火) 17:15:21.16Qzやお前らのようなバカより頭のいいコンパイラが存在する事を示せればそれで十分。ｗｗｗｗ
コンパイラより劣る脳しか持ってないバカはコンパイラの奴隷やってろ。 ｗｗｗｗ
>>903
おら、とっとと採点しろよ。 ｗｗｗｗ
0905デフォルトの名無しさん
2013/01/29(火) 17:19:37.240906デフォルトの名無しさん
2013/01/29(火) 17:20:52.57採点まだ〜〜〜〜? ｗｗｗ
0907デフォルトの名無しさん
2013/01/29(火) 17:44:32.030908デフォルトの名無しさん
2013/01/29(火) 18:10:05.87気負いこんでかかってきたのに、あっさり撃退されちゃった気分はどう? ｗｗｗｗ
バカみじめすぎる。ｗｗｗｗ
このバカが憤死したら下らねーことに粘着したてめーの責任だ。うんこQz てめーも殉死しろ。
0909デフォルトの名無しさん
2013/01/29(火) 18:12:05.83この展開は予想済みです
0910デフォルトの名無しさん
2013/01/29(火) 18:15:39.18意味は完全には理解しきれていないようですけどね
言葉と経験則的に理解しているというところでしょうか
0911デフォルトの名無しさん
2013/01/29(火) 18:19:01.220912デフォルトの名無しさん
2013/01/29(火) 19:05:58.840913デフォルトの名無しさん
2013/01/29(火) 19:50:29.00いいえ
0914デフォルトの名無しさん
2013/01/29(火) 21:13:35.37ゴミコードで勝ち誇っている>>874がいるスレはここですか？
>>874みたいなコード書いてりゃ、そりゃfreeすべきでないと言い出すわな
いつクラッシュするか分からんから
0915デフォルトの名無しさん
2013/01/29(火) 21:22:00.720916デフォルトの名無しさん
2013/01/29(火) 21:27:39.380917デフォルトの名無しさん
2013/01/29(火) 21:30:33.26体を張ってんな。
こんなバグ作るのこいつくらいだけど。
0918デフォルトの名無しさん
2013/01/29(火) 21:33:23.31末尾再帰もしらないで向かってきた>>876をほめてやれ。ｗｗｗｗ
>>914
free_lの中でいちいち比較するのは無駄なので、普通はfree_lを呼び出すラッパを作って
それで確認する。今回はNULLじゃない事が保証されてるので全部省略。
バカだね。 それくらいわかれよ。 ｗｗｗｗ
>>915
必死で向かってきたバカのお友達はみんな討死しているぞ。>>861とか。ｗｗｗｗ
本日のバカ一番は>>876。 明日は誰だろう。ｗｗｗｗ
0919デフォルトの名無しさん
2013/01/29(火) 21:46:57.73というか自演下手だな。そんなにスムーズに流れたら誰だってわかるぞ。
0920デフォルトの名無しさん
2013/01/29(火) 21:52:20.380921デフォルトの名無しさん
2013/01/29(火) 21:54:04.93お前がバカ杉で見事に引っかかったから自演だと思われてるぞ。 ｗｗｗ
まだ生きてるか? ｗｗｗｗ 憤死してもおかしくないよなあ。ｗｗｗｗ
0922デフォルトの名無しさん
2013/01/29(火) 21:58:11.43それとも、>>876を陥れるためにうんこQzが仕組んだ罠だとでも？ ｗｗｗｗ
0923デフォルトの名無しさん
2013/01/29(火) 21:58:27.03でたよ得意の思い込み
0924デフォルトの名無しさん
2013/01/29(火) 22:01:10.09突っ込まれたら急きょ前提条件を付け加えて
「そんな前提条件すら気づかないバカ。ｗｗｗ」
とレスするだけの簡単なお仕事です。
0925デフォルトの名無しさん
2013/01/29(火) 22:03:35.37rootだけNULLチェック飛ばす意味ねーだろ馬鹿か
0926デフォルトの名無しさん
2013/01/29(火) 22:03:47.52Win-Winのいい関係じゃないか。
0927デフォルトの名無しさん
2013/01/29(火) 22:03:53.36NULLになるパスが存在するとでも。 ｗｗｗｗ
0928デフォルトの名無しさん
2013/01/29(火) 22:05:58.78というラッパを作るってこと？
確かに期待通りに動くけど、それってfree_lのバグをごまかしてるだけじゃん。
0929デフォルトの名無しさん
2013/01/29(火) 22:06:16.19エラーチェックのNULL判定とリスト終端NULL判定は意味合いが違わないかな？
0930デフォルトの名無しさん
2013/01/29(火) 22:10:12.18lisperから言わせて貰うと がんばれ
0931デフォルトの名無しさん
2013/01/29(火) 22:12:21.95rootはNULLじゃない事が確定している。よって省略。 わかる? バカにはわかんないかな ｗｗｗｗ
0932デフォルトの名無しさん
2013/01/29(火) 22:14:40.080933デフォルトの名無しさん
2013/01/29(火) 22:14:47.91コンパイラの最適化がたまたま勝手に修正してくれただけで、
コンパイラやオプション次第ではスタックオーバーフローする危険なソースで
あることには変わりない。
0934デフォルトの名無しさん
2013/01/29(火) 22:16:29.76struct l *p = malloc(sizeof(struct l));
p->next = root;
root = p;
}
こんな感じにループ回数を変数nに一般化したあと、
n < 1 な値が入ってきたときにバグが顕在化するんですね。
0935デフォルトの名無しさん
2013/01/29(火) 22:18:57.550936デフォルトの名無しさん
2013/01/29(火) 22:20:59.41これも素人くさい
プロなら
sizeof(*p)
だな
0937デフォルトの名無しさん
2013/01/29(火) 22:25:44.87何故わざわざと再帰にしたか考えてみな。ｗｗｗｗ
わからないだろうな。バカには ｗｗｗｗｗ
なんか謎の文字列もついてるし。 ｗｗｗｗ
0938デフォルトの名無しさん
2013/01/29(火) 22:26:08.190939デフォルトの名無しさん
2013/01/29(火) 22:28:06.56・freeいる派完全勝利
・freeいらない派のくさおが発狂、レスを流すのに必死
0940デフォルトの名無しさん
2013/01/29(火) 22:29:28.16教祖のうんこQzすらfreeしなくていいと日和ってるぞ。ｗｗｗｗ
0941デフォルトの名無しさん
2013/01/29(火) 22:32:59.100942デフォルトの名無しさん
2013/01/29(火) 22:33:35.33-O0 -S
0943デフォルトの名無しさん
2013/01/29(火) 22:35:31.49無駄に再帰しているソースはレビューすら通らない。
これが現実。
0944デフォルトの名無しさん
2013/01/29(火) 22:36:02.37おしまい。
0945デフォルトの名無しさん
2013/01/29(火) 22:37:40.99> まずスレッドタイトル嫁。プロセス終了直前にfree() が必要かどうかを
> 論じるスレではない。
まぁでも、main以外と書いてあるし、main以外のexit前ならなんとか
スレの範疇かと。
このスレにはプロセス終了直前のfreeは無駄なごみでしかないってことを
理解できない方もいらっしゃるみたいだし。
QZ...ですらプロセス終了直前のfreeは必要ないって思っているってことでいい ?
再帰のオーバーヘッドが大きいって行ってるけど、
それを含めて無駄な解放の、後始末のコストなんじゃない ?
今回の例はあくまで簡潔な例として作られたもので、
例えばn個の枝を持つツリー構造だったら再帰でやっちゃうわけで
再帰で書けば自然なのをわざわざループに書き直すことを考えたら
自明に消せれるfreeは最初っから書かなきゃいいじゃんって思うんだけど。
あと、再帰のオーバーヘッドが消せようがなんだろうが無駄なfreeのコストは
ゼロじゃない。
ただ単に無駄なコストなのに。
0946デフォルトの名無しさん
2013/01/29(火) 22:41:57.29最後にまとめて解放するくらいならプロセスの終了に任せれば、って
話になるのはそのため。
mtraceの話も出てるけど、リストだろうがツリーだろうが、使っていると
認識している箇所だけを正しく解放していって、最後に何が残るかを
見ないとリークしてるかどうかなんてわからないだろ。
最後にツリーまとめて消してみたら全部消えたのでリークしてません、
なんてことにはならないんだから。
そこに解放したつもりになっているデータが連結されているかどうか
というのが重要なのに。
0947デフォルトの名無しさん
2013/01/29(火) 22:45:04.830948デフォルトの名無しさん
2013/01/29(火) 22:47:30.660949デフォルトの名無しさん
2013/01/29(火) 22:47:59.75まとめて消して消えるならリークしてないだろ。バカか。
0950デフォルトの名無しさん
2013/01/29(火) 23:03:18.74> そもそも最後にまとめて解放すればいいという設計がおかしいんだよ。
そうは言っても本質的にプロセスの最後まで持ち続けてるデータだって
あるんだもん。
こういう場合はどうかな ?
画像の色調を変化させたり、輪郭を抽出したり、そういうソフトで
ワーキングエリアにデータを入れてるとして、ユーザが終了を指示したとき
いちいち、mallocした領域をfreeしてから終了する ?
0951デフォルトの名無しさん
2013/01/29(火) 23:13:25.530952デフォルトの名無しさん
2013/01/30(水) 01:05:12.90スレ立てな
0953デフォルトの名無しさん
2013/01/30(水) 01:22:33.92その手のソフトなら、アンドゥ実装したり、起動したまま今のファイルを捨てて、
違うファイルを読み込んだりするだろうから、どうせ領域解放の処理は必要になる。
でかいファイルを読み込んで終了させた時に、解放にとんでもなく時間がかかってる
と言うのがわかればあえて解放しないようにするかもしれないけど、まずは普通に
解放するように作る。
そもそもそういう状況なら、読み込みはもっと時間かかってるはずだし。
0954デフォルトの名無しさん
2013/01/30(水) 08:23:22.57fj思い出したわｗ
0955デフォルトの名無しさん
2013/01/30(水) 11:55:15.87freeをやめてreallocにすればいんじゃね？
0956デフォルトの名無しさん
2013/01/30(水) 14:11:21.93ObjectiveCのNSなんとかPoolみたいなので一括解放させる。
そのままlibcのmalloc/freeスタイルでやるとかない。
0957デフォルトの名無しさん
2013/01/30(水) 21:39:04.52・freeいる派完全勝利
・freeいらない派のくさおが発狂、レスを流すのに必死
・freeいらない派のくさおがバグ付スタックオーバフローソースを作成、
身をもってfreeは危険だと主張
・freeいらない派のくさおが自演を開始、自画自賛を始める
・freeいらない派のくさおが自演を指摘され遁走 ←いまここ
0958950
2013/01/30(水) 21:41:16.97立てたお
mallocの後にfree不要と言うバカいるの?Part2
http://toro.2ch.net/test/read.cgi/tech/1359549517/
スレ名が長かったのでmain以外って入れれなかったのがすみません。
0959950
2013/01/30(水) 21:54:05.58>>953
了解した。
>>954
自転車置き場の屋根だったっけ?
そんな感じのもんだいだからじゃない ?
リークさせちゃいけないってのは大前提なはずだし、
exit前のfreeを書くか書かないかなんてスタイルの問題で
どっちでもいいことじゃん
0960デフォルトの名無しさん
2013/01/30(水) 23:20:27.27ソース出せというので出してやったのに。読めないバカですな。ｗｗｗ
たとえばemacs。 解放処理は実装してるけど、終了時の解放なんかしてない。
>>957
かなり悔しかったようだな。>>876 だから忠告してやったのに。ｗｗｗｗ
一日経った今でも爆笑。 ｗｗｗｗｗｗ
> From: [876] デフォルトの名無しさん <sage>
> Date: 2013/01/29(火) 12:58:33.48
>
> ここでｗｗｗさんに問題です
> 天才には簡単な問題ですので必ず逃げないで答えてください
>
> スタックサイズが8MBのとき、このfree_l関数で解放可能な連結リストは
> 最大何個連結可能でしょうか？
>
> アーキテクチャは好きに選んでいいですよ
0961デフォルトの名無しさん
2013/01/30(水) 23:33:57.26953さんは個人の方針を書いただけでしょう。
ソースを出せと言った方とは別の人では?
あまり攻撃的な書き方は感心できませんよ。
0962デフォルトの名無しさん
2013/01/30(水) 23:39:56.650963デフォルトの名無しさん
2013/01/31(木) 00:20:03.34立て乙
しかしmain以外削除に悪意を感じる
0964950
2013/01/31(木) 00:45:05.16すまん。
Part2と入れるためにはどこか削除しなくてはならなかったんだ。
「malloc/free問題」とかスレタイを全く変えようかとも思ったんだが
なるべく前スレの雰囲気を残したかったし、刺激的なタイトルの方が
いいかなとも思い「mallocの後にfree不要と言うバカいるの?」というのは
そのまま残しました。
で、元スレの1さんの「main以外」っていう思いは元スレの1を最初のほうに
貼り付ければ、読んでくれるかな。と思いこうしました。
もたもたして2getできなくてすみません。
個人的にはこの「main以外」っていうのは非常に重要な要素で、
元スレの1さんは多分この手の議論はfjなりで経験していて、
exit前のfreeガーってのは既に考慮して、「main以外」なり
「例外中の例外は除く」になったんだと思う。
個人的には、その「例外中の例外」とはなんなのか、
その「例外」とされるものをどういう立場の人がどういう考えで
「例外」として扱うのか、扱わないのかが知りたいと思っている所存です。
でも、そんなスレ立ティストの思いにスレが左右されないように、
できるだけ中立的になるように立てたつもりですが、
お気に召さなかったら申し訳ありません。
0965デフォルトの名無しさん
2013/01/31(木) 01:23:29.13削除して立てなおさないと
0966デフォルトの名無しさん
2013/01/31(木) 07:51:08.33終了直前以外でfree不要と言うバカいるの？2人目
http://toro.2ch.net/test/read.cgi/tech/1359585842/
0967デフォルトの名無しさん
2013/01/31(木) 10:23:57.62なんで「main以外」抜くんだ？
0968デフォルトの名無しさん
2013/01/31(木) 10:32:57.59ところがmain以外でもexitを呼ぶことは可能。
したがって「main以外」とするのは不適切。
mallocを抜いたのは文字数制限
0969デフォルトの名無しさん
2013/01/31(木) 10:39:09.71人命に関わるシステムにご都合主義持ち込まれると迷惑だから。。
0970デフォルトの名無しさん
2013/01/31(木) 10:47:17.33どういう理論だよ。 ｗｗｗｗ
0971デフォルトの名無しさん
2013/01/31(木) 13:52:10.91例えばMISRA-Cに触れるとか
0972デフォルトの名無しさん
2013/02/04(月) 15:53:57.740973デフォルトの名無しさん
2013/02/04(月) 16:01:00.75久しぶり〜 ぬこちゃんは強くなったかな？
へ-ﾍ
ﾐ*´ｰ｀ﾐ
〜(,_ｕｕﾉ
0974デフォルトの名無しさん
2013/02/04(月) 21:03:04.66mew/deleteのサンプル
0975デフォルトの名無しさん
2013/02/05(火) 22:50:05.38Linux/Windowsで、同じ動作をするのかね？
仮に、malloc(0)とした場合、動作が異なるしね。
Linuxだと、nullが返るけど、Windowsなら、nullじゃない。
これが、何十万回も呼ばれ、かつ、連続稼働するようなシステムでも
freeが不要なのか？
環境依存、コンパイラの仕様を把握した上での議論なのか？
なんか、スレの流れからすると違和感があるのだけど？
あと、OSが32/64bitなのか明確じゃないし。
プロセスが確保できる上限値に至る可能性がある要求があった場合の
考慮も欠如している。
それでも、free()は、不要なのか？
0976デフォルトの名無しさん
2013/02/05(火) 23:22:46.150977デフォルトの名無しさん
2013/02/06(水) 02:23:02.90それよりは、freeしないでおいて、メモリ不足になった方がマシ。
…ってこと？
0978デフォルトの名無しさん
2013/02/06(水) 14:18:41.52きみ何言ってんの？ｗ
0979デフォルトの名無しさん
2013/02/06(水) 15:35:45.860980デフォルトの名無しさん
2013/02/06(水) 19:10:56.440981デフォルトの名無しさん
2013/02/06(水) 21:14:57.74> これが、何十万回も呼ばれ、かつ、連続稼働するようなシステムでも
> freeが不要なのか？
freeが全く必要ないって言っている人はほとんどいないと思う。
議論になっているのはexit直前のfreeのように
あっても全く影響のないフリーを書くべきかどうかということ。
> 環境依存、コンパイラの仕様を把握した上での議論なのか？
特に規定はされていない。
なので、Unix or Windows用に書いたプログラムを組み込み用に
移植するから・・・という話も出てくる。
それはそれで実り多い議論だと思う。
> あと、OSが32/64bitなのか明確じゃないし。
それは何か違いが出てくるのだろうか ?
浅学なので教えてほしい。
> プロセスが確保できる上限値に至る可能性がある要求があった場合の
> 考慮も欠如している。
そのことが議論になっていないのは、そうなる前にfreeしろってのが
自明だからだと思う。
> それでも、free()は、不要なのか？
個人的な意見だがfreeは必要でない*場合もある*と思う。
レス数が950を超えています。1000を超えると書き込みができなくなります。