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

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

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

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

2 ：デフォルトの名無しさん：2013/01/30(水) 21:42:04.63

ここまでのまとめ
・freeいる派完全勝利
・freeいらない派のくさおが発狂、レスを流すのに必死
・freeいらない派のくさおがバグ付スタックオーバフローソースを作成、
　身をもってfreeは危険だと主張
・freeいらない派のくさおが自演を開始、自画自賛を始める
・freeいらない派のくさおが自演を指摘され遁走　←いまここ

3 ：デフォルトの名無しさん：2013/01/30(水) 21:42:28.73

前スレ1

1 名前：デフォルトの名無しさん[sage] 投稿日：2012/11/13(火) 22:12:13.29
前提１：一般的なC言語（GC搭載していない）
前提２：main関数は除く
前提３：関数実行後すぐに終了するとは限らない
前提４：関数は何度も使われることがある

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

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

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

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

4 ：デフォルトの名無しさん：2013/01/30(水) 21:44:23.19

freeいる派の主な主張
・mtraceが通らないとか論外
・対にするようにしておかないと悪癖が身に付く
・そもそも最後にまとめて解放すること自体が論外

freeいらない派の主な主張
・freeでバグる可能性があるから解放したくない
・プロセスの終了処理に黙って解放されるほうが終了処理がはやい

5 ：デフォルトの名無しさん：2013/01/30(水) 22:06:09.81

なんかスレ立てたら賢者モードになっちゃったよ。
前スレで議論してたのがうそみたい。

ところで、Perl、Python、RubyなんかのP言語が猛威をふるい
Javaなんかもガベコレ積んでるし、
Windowsアプリの主要開発言語もC#になろうかとしている今、

今後、手動でメモリ確保、メモリ解放しなきゃならない環境ってのは
どういうのが残るかなぁ

AppleのObjective-C、組み込み開発、ドライバ、OS等のハードに直結した部分
数値計算とかそういう純粋に速度が要求される分野

思いついたのはこのくらいなんだけど
他にないかなぁ

6 ：デフォルトの名無しさん：2013/01/30(水) 22:15:43.17

Objective-Cは最近は手動じゃないっぺ。

7 ：デフォルトの名無しさん：2013/01/30(水) 23:29:05.06

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

8 ：デフォルトの名無しさん：2013/01/31(木) 06:30:05.64

freeする前に終了しちゃえばいいさ

9 ：デフォルトの名無しさん：2013/01/31(木) 07:58:46.76

「main 以外」なんだからねっ！
不毛な議論しちゃダメ、絶対。

ところで、exit 適用時も議論対象外に、入りますか？

10 ：デフォルトの名無しさん：2013/01/31(木) 10:16:50.76

「main以外」抜いたここは別スレだろ

11 ：デフォルトの名無しさん：2013/02/01(金) 03:11:22.90

こっちが本スレで向こうが隔離スレでしょ
この議論はUNIXの"悪習"が元凶のような気がしてきた

12 ：デフォルトの名無しさん：2013/02/01(金) 21:24:43.72

ぶっちゃけ2000年問題と同レべの手抜き習慣

13 ：デフォルトの名無しさん：2013/02/01(金) 23:42:42.74

俺もOS評価するときにOS再インスコが
必要になったらPCの電源をブチっと
落とすけど、そんな感じ？

14 ：デフォルトの名無しさん：2013/02/02(土) 09:39:47.82

使い捨てのプログラムで、コンパイラみたいな一度走って終わりのプログラムなら、
全部mallocしっぱなし、ってこともある。時と場合による。

15 ：デフォルトの名無しさん：2013/02/02(土) 10:41:02.65

"main以外"を抜いて、また１からやり直したいのか？>>1は

16 ：デフォルトの名無しさん：2013/02/02(土) 10:42:00.23

>>13
どっちかというと、再インストール関係なしに「もうディスクにアクセスする必要が
ないことがわかっているから」といってrebootのかわりにリセット押すのが近いだろう。

17 ：デフォルトの名無しさん：2013/02/02(土) 23:13:35.87

スレチだが、
sprintf(buf,…);
len=strlen(buf);
という低脳なコードを久しぶりに見たw

18 ：デフォルトの名無しさん：2013/02/02(土) 23:27:39.79

946 ：デフォルトの名無しさん：2013/01/29(火) 22:41:57.29
そもそも最後にまとめて解放すればいいという設計がおかしいんだよ。
最後にまとめて解放するくらいならプロセスの終了に任せれば、って
話になるのはそのため。

mtraceの話も出てるけど、リストだろうがツリーだろうが、使っていると
認識している箇所だけを正しく解放していって、最後に何が残るかを
見ないとリークしてるかどうかなんてわからないだろ。

最後にツリーまとめて消してみたら全部消えたのでリークしてません、
なんてことにはならないんだから。
そこに解放したつもりになっているデータが連結されているかどうか
というのが重要なのに。

947 ：デフォルトの名無しさん：2013/01/29(火) 22:45:04.83
こりゃまた大きな釣り針だな。ｗｗｗ

948 ：デフォルトの名無しさん：2013/01/29(火) 22:47:30.66
くさお悔しくて絶好調だな

949 ：デフォルトの名無しさん：2013/01/29(火) 22:47:59.75
>>946
まとめて消して消えるならリークしてないだろ。バカか。

19 ：デフォルトの名無しさん：2013/02/03(日) 00:20:47.51

>>17
それやったことあります。汚物見せてごめんなさい。

20 ：デフォルトの名無しさん：2013/02/03(日) 06:27:33.11

>>17
そういうコードが必要な場合もある。
どういう場合かは、あんたには分からんだろうがね。

21 ：デフォルトの名無しさん：2013/02/03(日) 06:33:39.57

100%ありません

22 ：デフォルトの名無しさん：2013/02/03(日) 06:45:51.40

>>21
1行目と2行目でbufの内容が変わることは100%あり得ない

と思ってんだろ？素人君

23 ：デフォルトの名無しさん：2013/02/03(日) 07:38:05.86

>>22
はい。100%あり得ません。
bufが共有であるならセマフォなり何らかの排他をしないのは単なるバグです。

24 ：デフォルトの名無しさん：2013/02/03(日) 08:04:22.63

>>17
俺も数えるのめんどくさくてやってしまいそうだが。正解は？

25 ：デフォルトの名無しさん：2013/02/03(日) 08:20:18.25

>>23
あれを見た瞬間にその「単なるバグ」の可能性にまで気づくかどうかの問題
後出しでは意味なし

26 ：デフォルトの名無しさん：2013/02/03(日) 08:34:17.19

>>25
>そういうコードが必要な場合もある。

じゃあ後出しでない回答を期待します。
逃げたければ逃げてもいいですよ。

27 ：デフォルトの名無しさん：2013/02/03(日) 08:38:32.01

>>26
もう答えはでている
あんたが理解できていないだけだ

28 ：デフォルトの名無しさん：2013/02/03(日) 08:39:16.13

>>24
len = sprintf(buf,…);

29 ：デフォルトの名無しさん：2013/02/03(日) 08:47:16.68

「低脳」
草生やし
卑屈で低レベルな煽り

…まともに相手する必要を認めず。

30 ：デフォルトの名無しさん：2013/02/03(日) 08:49:45.14

>>29
敗北宣言ありがとうございますｗ

31 ：デフォルトの名無しさん：2013/02/03(日) 08:52:06.97

議論を勝ち負けで考えているかぎり
お前らの勝ちは一生ありえないよ。

32 ：デフォルトの名無しさん：2013/02/03(日) 09:47:06.42

>>22
そもそも2行目が不要なことを理解できない低脳君乙。

33 ：デフォルトの名無しさん：2013/02/03(日) 10:01:05.79

> スレチだが、と言って、脈絡もなく>>17を投下したのはこのスレの
異常に高いバカ召喚性能を使いたかったからだろ。ｗｗｗｗ
釣られたバカが>>22 ｗｗｗｗ

34 ：デフォルトの名無しさん：2013/02/03(日) 10:16:26.71

いつもの草男がだんだん本性を現してきました

35 ：デフォルトの名無しさん：2013/02/03(日) 10:36:32.83

つられたバカが悔しがってるな。ｗｗｗｗ
なんでバカって簡単につられるんだろう。あっ、バカだからか。ｗｗｗｗ

36 ：デフォルトの名無しさん：2013/02/03(日) 10:42:10.53

>>22がバカだからくさおだろう

37 ：デフォルトの名無しさん：2013/02/03(日) 10:55:25.21

>>22が書きそうなコード
if(p!=NULL)free(p);

38 ：19：2013/02/03(日) 11:20:12.04

>>37
> if(p!=NULL)free(p);

それも、いま知るまでやっていました…

39 ：デフォルトの名無しさん：2013/02/03(日) 11:41:14.21

>>38
基地外スレであんまり真面目ぶると、逆に工作員認定される

40 ：デフォルトの名無しさん：2013/02/03(日) 11:51:22.60

sprintfは使用禁止。バカしか使わない。ｗｗｗｗ
釣られた>>22 バカすぎｗｗｗｗ

> From: [22] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 06:45:51.40
>
> >>21
> 1行目と2行目でbufの内容が変わることは100%あり得ない
>
> と思ってんだろ？素人君

41 ：デフォルトの名無しさん：2013/02/03(日) 12:03:02.08

↑くさお書き込みテンプレ

42 ：デフォルトの名無しさん：2013/02/03(日) 12:04:11.64

>>38
freeにNULLを与えた時の動作が標準化されたのはC89からだったはずだから、
20年くらい前のソースならそのように書かれていても不思議じゃない。

作ったライブラリが予想もしない所で使われるかもしれないから、
freeしろとかほざいているfreeバカは、NULL与えるとSEGVする環境(SystemV)に
持って行かれるかもしれないからチェックしろとか言わないのか? ｗｗｗｗ

43 ：デフォルトの名無しさん：2013/02/03(日) 12:23:57.18

終了時にメモリ解放してくれるのはどのC言語の規格書に書いてるの？

44 ：デフォルトの名無しさん：2013/02/03(日) 12:24:37.29

＞freeにNULLを与えた時の動作が標準化されたのはC89からだったはずだから、
馬鹿死ね
K&R1 からだ

realloc(NULL, size); がmalloc(size) と等価にならないかわいそうなバグがある処理系が存在した話であればこれは有名

45 ：デフォルトの名無しさん：2013/02/03(日) 12:42:04.81

>>37
コンパイラが最適化してくれるので問題ありません。

46 ：デフォルトの名無しさん：2013/02/03(日) 13:37:59.35

>>45
しない
コンパイラからはfree() は単なる一つの関数にしかみえない
p が 0 のとき free(p) はなにもしないことは、コンパイラはしらない
勉強不足だ、これではwww野郎やQZすらの相手にもならない

死ね

47 ：デフォルトの名無しさん：2013/02/03(日) 13:42:43.89

>>46
素人乙

48 ：デフォルトの名無しさん：2013/02/03(日) 13:46:41.46

>>46
コンパイラがライブラリの仕様を把握していないと矛盾が生じます。
printfが書式文字列に従って値を表示することをしらなければ出せない
はずの、書式文字列と引数があっていないときのwarningを出せます。
同じように、if(!p)free(p)という悪しき慣例があることも知っています。

49 ：デフォルトの名無しさん：2013/02/03(日) 13:47:08.31

>>47
ではfree(0)を省いてくれる処理系を挙げてみよ

できないのなら市ね

50 ：デフォルトの名無しさん：2013/02/03(日) 13:48:21.26

>>48
＞書式文字列と引数があっていないときのwarningを出せます。
ほう、それはgccだねこれは一本とられた。よく頑張ったね。

51 ：デフォルトの名無しさん：2013/02/03(日) 13:50:06.53

>>49
なんでfreeのほうを省くの？バカなの？死ぬの？

52 ：デフォルトの名無しさん：2013/02/03(日) 13:51:19.74

>>50
×それはgccだね
○俺はgccしか知らない

53 ：デフォルトの名無しさん：2013/02/03(日) 13:53:28.26

本日の大バカ晒しage

49 ：デフォルトの名無しさん：2013/02/03(日) 13:47:08.31
>>47
ではfree(0)を省いてくれる処理系を挙げてみよ

49 ：デフォルトの名無しさん：2013/02/03(日) 13:47:08.31
>>47
ではfree(0)を省いてくれる処理系を挙げてみよ

49 ：デフォルトの名無しさん：2013/02/03(日) 13:47:08.31
>>47
ではfree(0)を省いてくれる処理系を挙げてみよ

49 ：デフォルトの名無しさん：2013/02/03(日) 13:47:08.31
>>47
ではfree(0)を省いてくれる処理系を挙げてみよ

54 ：デフォルトの名無しさん：2013/02/03(日) 13:59:20.99

>>51
const char *p = NULL;
free(p);

だったら最適化でfree(p)を消してくれるかもねｗ

55 ：デフォルトの名無しさん：2013/02/03(日) 14:03:19.10

逆に、mallocがNULLを返したかチェックしない人多いよね。
LinuxではNULLが返ってくることはないというのが理由らしいんだけど。

56 ：デフォルトの名無しさん：2013/02/03(日) 14:07:34.43

成功した振りして使用時に落ちるの何とかして欲しい

57 ：デフォルトの名無しさん：2013/02/03(日) 14:11:47.93

OOM Killerで他のプロセスが殺されるとか、糞仕様すぎる。

58 ：デフォルトの名無しさん：2013/02/03(日) 14:23:36.91

>>44
> 馬鹿死ね
> K&R1 からだ
古い規格に詳しいな、ジジイ。で、それが何か? ｗｗｗｗ

59 ：デフォルトの名無しさん：2013/02/03(日) 14:29:16.84

反論できなくなると開き直る

60 ：デフォルトの名無しさん：2013/02/03(日) 14:35:03.61

>>46
お前がオレさまの相手をするのは、バカすぎて無理。ｗｗｗｗｗ
うんこQzからかって遊ぶだけにとどめておけ。ｗｗｗｗ

その処理系のライブラリが
inline void free(void *p)
{
if (p)
read_free(p);
}

という実装だったら、
> if(p!=NULL)free(p);
はコンパイラが最適化できる。ｗｗｗｗ

61 ：デフォルトの名無しさん：2013/02/03(日) 14:44:15.39

>>59
> realloc(NULL, size); がmalloc(size) と等価にならないかわいそうなバグがある処理系が存在した話であればこれは有名
「これは有名」の「これ」とは何かね? ｗｗｗｗ
バカの文章は読みにくい。ｗｗｗｗ

62 ：デフォルトの名無しさん：2013/02/03(日) 14:50:20.19

>>45
コンパイラが最適化してくれるというのは、そうかも知れない。
でも、しないかもしれない。
また、それは可読性を下げてまでやるべき事ではないと思うがな。
もしかして IOCCC に出品するつもりとか？

そして、やり方としては、無茶な仕事を下請けへ丸投げするのと
全く同じなんだよね。

技術的な裏付けは何にも無いけど、彼奴等に投げておけば
何とかするだろう、レベルの発想。

63 ：デフォルトの名無しさん：2013/02/03(日) 15:10:49.37

>>62
えっと、if文１個式１つで可読性が悪くなるとか、
頭悪いんですか？悪いんですね。

64 ：デフォルトの名無しさん：2013/02/03(日) 15:16:54.70

>>55
そうなのか？少なくともヒープとして使えるメモリ空間使い果たせば返ってくるだろ。
>>56,57
vm.overcommit_memory あたりでググってみるといいかも。
ただでっかいメモリ空間を使っているプロセスから fork & exec していたりする時は注意。

65 ：デフォルトの名無しさん：2013/02/03(日) 15:20:11.25

それは↓を言う前に言うべきだったね。ｗｗｗｗ
自信たっぷりに否定した後で、可能な事を示されてからじゃ遅い。ｗｗｗｗ
お前はヘボなんだよ。ｗｗｗｗヘボ同士でうんこQzと絡んでるのがお似合い。ｗｗｗｗ

本日のバカｗｗｗｗ
> From: [46] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 13:37:59.35
>
> >>45
> しない
> コンパイラからはfree() は単なる一つの関数にしかみえない
> p が 0 のとき free(p) はなにもしないことは、コンパイラはしらない
> 勉強不足だ、これではwww野郎やQZすらの相手にもならない
>
> 死ね

>>45は前スレのオレの真似をして煽っただけだろう。
十中八九inlineで最適化なんて思いついていない中防。。
そんなのに釣られてバカ晒す事になった>>46が憐れでならない。ｗｗｗｗｗ

66 ：デフォルトの名無しさん：2013/02/03(日) 15:21:08.32

全ては、その１個の積み重ねなのだよ。

67 ：デフォルトの名無しさん：2013/02/03(日) 15:22:16.73

>>62
呼ばなくていいなら関数呼び出しは少ないほうがいい場合もある。
そういう意味でif (p) free(p)は、意味はある。
機械語にしたところでfreeを呼ぶためにレジスタにロードするので
zeroチェックはそのついでで行うことができるし、ifのほうは
大したペナルティにはならない。

68 ：デフォルトの名無しさん：2013/02/03(日) 15:26:10.39

freeがinlineになっているクソな処理系ってなんだよ。

69 ：デフォルトの名無しさん：2013/02/03(日) 15:28:33.30

>>64
linux上でman mallocをよく読め。

70 ：デフォルトの名無しさん：2013/02/03(日) 15:32:20.46

>>67
NULLがzeroだなんて誰が決めたの？

71 ：デフォルトの名無しさん：2013/02/03(日) 15:36:01.30

ところで明日振り替え休日で休みだよね。

72 ：デフォルトの名無しさん：2013/02/03(日) 15:36:42.91

NULLは（仮に機械表現が全ビット0でなかったりしても）コンパイラ（言語）の上では0だよ？
そんなことも知らずにこんなスレで暴れようと思ってるの？

73 ：デフォルトの名無しさん：2013/02/03(日) 15:44:50.31

>>60
＞その処理系のライブラリが inline void free(void *p)
お前も馬鹿か？
標準ライブラリがソースで提供されているとでも？
普通はobjやlibではないか？
そんなバイナリをインラインにできるとでも？

死ね

74 ：デフォルトの名無しさん：2013/02/03(日) 15:46:58.24

>>73
#include <stdlib.h>

75 ：デフォルトの名無しさん：2013/02/03(日) 15:49:07.30

>>61
やさしい日本語しかよまない／よめない馬鹿なんだね、指示詞を敢えて差し込むのはよくやること
＞前項の目的を達するため､陸海空軍その他の戦力は**これを**保持しない。
＞国の交戦権は**これを**認めない。

>> realloc(NULL, size); がmalloc(size) と等価にならないかわいそうなバグがある処理系が存在した話であればこれは有名
>「これは有名」の「これ」とは何かね? ｗｗｗｗ
「realloc(NULL, size); がmalloc(size) と等価にならないかわいそうなバグがある処理系が存在した話」
だね

死ね

76 ：デフォルトの名無しさん：2013/02/03(日) 15:50:47.38

>>74
死ね

77 ：デフォルトの名無しさん：2013/02/03(日) 15:52:02.57

>>71
ということにしたいのですね:-P

78 ：デフォルトの名無しさん：2013/02/03(日) 15:54:38.10

len = sprintf(buf, "%c", 0)
len => 1
strlen(buf) => 0

79 ：デフォルトの名無しさん：2013/02/03(日) 15:56:25.84

>>75
で、それが、
「freeにNULLを与えた時の動作が規定されたのはC89ではなくてK&R1だ」となんの関係があるんだ? ｗｗｗｗ

80 ：デフォルトの名無しさん：2013/02/03(日) 15:59:48.45

しかしこのネタは昔から盛り上がるんだけれど、リアルで素のmallocをアプリレベルでそんなに呼ぶものなのか?

組み込み云々言っている奴もいたけれど、俺が関わってきた範囲では分断の問題で直接使うことはないな。
素のmalloc/freeは遅くて使い物にならないって環境って場合もあったけど。
最近はRAM自体はそこそこのっている環境も多いんでスタック増やして、C99にして可変長配列使うっていう手で
かなりの部分が楽になった。

人命云々言っている奴、プロセスの概念がある世界ならば、なるべくプロセスの寿命を短くするって方向も
考えたほうがいいぞ。最初からmalloc/freeだけに限らずバグの全くない大規模なプログラムなんて
妄想だと思ってシステム作ると、頑強なものができるから。

81 ：デフォルトの名無しさん：2013/02/03(日) 16:09:57.63

マルチスレッドだと、スタックサイズが固定になるのでautoにでかいのを置くことは
必然的に避ける事になる。これ位は常識だぞ。ｗｗｗｗ

> 最初からmalloc/freeだけに限らずバグの全くない大規模なプログラムなんて
free楽勝と豪語しているfree必須バカは全くバグのないプログラムを作れるらしいぞ。ｗｗｗｗ

82 ：デフォルトの名無しさん：2013/02/03(日) 16:14:07.11

>>69
>>65のどの部分がおかしいか教えてくれ。マジでわからん。
vm.overcommit_memory=2 でも malloc が成功しても実際には使えないことがあるってことか?

83 ：デフォルトの名無しさん：2013/02/03(日) 16:14:49.26

>マルチスレッドだと、スタックサイズが固定になる

無知発見ｗ

84 ：デフォルトの名無しさん：2013/02/03(日) 16:15:58.26

＞リアルで素のmallocをアプリレベルでそんなに呼ぶものなのか
＞素のmalloc/freeは遅くて使い物にならないって環境って場合もあったけど

自分が特殊な環境にいたと自負してる時点で1行目が死んでるよ

85 ：デフォルトの名無しさん：2013/02/03(日) 16:18:17.34

>>82
はい。
Linuxの楽観的メモリ管理はその程度ではどうにもなりません。

86 ：デフォルトの名無しさん：2013/02/03(日) 16:20:58.63

>>83
あっそ、pthreadでもWin32でもスレッド生成時のスタックサイズを超える事は出来ないけど、
それを伸ばしてくれるスレッドライブラリってどれだよ。ｗｗｗ

87 ：デフォルトの名無しさん：2013/02/03(日) 16:22:02.44

>>82
いや、常識的にユーザーにその設定書き換えてくださいとは言えないだろ…
root権限ないとだめだし自分のプログラムだけに影響するわけでもないし

88 ：デフォルトの名無しさん：2013/02/03(日) 16:22:30.71

>>81
> マルチスレッドだと、スタックサイズが固定になるのでautoにでかいのを置くことは
> 必然的に避ける事になる。これ位は常識だぞ。ｗｗｗｗ

おいおい、組み込みの世界だと元々スタック1Kとかふつーだったのが、それを64Kにすれば
楽できるとかそういうレベルの話だよ。

89 ：デフォルトの名無しさん：2013/02/03(日) 16:23:37.58

>>86
>スレッド生成時のスタックサイズを超える事は出来ない

生成時には可変であることを認めましたね？おバカさんｗ

90 ：デフォルトの名無しさん：2013/02/03(日) 16:25:47.94

死ねの人は息してる？ｗ

91 ：デフォルトの名無しさん：2013/02/03(日) 16:27:24.50

>>79
関係ないね。この超有名な話と混同しているのではないかと勘繰っただけでね
死ね

92 ：デフォルトの名無しさん：2013/02/03(日) 16:29:53.55

>>80
確かに素のmalloc()/free() を直にソースに散らばらせるのは好ましくないね
QZですらアロケータ経由だったようだし
昔のlisp処理系ではタイプごとにアロケータを別に準備していたようだねセル用とかね64KiBのシステム用だったけれど

93 ：デフォルトの名無しさん：2013/02/03(日) 16:30:48.52

>>55
32ビットだとメモリ空間は4Gだろ。32ビットlinuxでmalloc(1M)を繰り返すと、
4097回目には何が返ってくる?
ああ、返さずに自殺という選択肢もあるか。

94 ：デフォルトの名無しさん：2013/02/03(日) 16:31:17.25

>>81
>free楽勝と豪語しているfree必須バカは全くバグのないプログラムを作れるらしいぞ。ｗｗｗｗ
楽勝とはいっていないがmalloc()/free()くらいは完全に管理できるだろうねアロケータを準備したりしてね
お前はそれができないからmalloc()/free()を使わないんだろう？
死ね

95 ：デフォルトの名無しさん：2013/02/03(日) 16:32:12.21

>>86
スレッド生成時には好きに変えられるんだ馬鹿
死ね

96 ：デフォルトの名無しさん：2013/02/03(日) 16:33:35.98

（このままじゃくさおが生霊に殺されそう…）

97 ：デフォルトの名無しさん：2013/02/03(日) 16:34:36.64

>>90
憲法すら読んだことがないとはねえ
中卒？

98 ：デフォルトの名無しさん：2013/02/03(日) 16:40:00.25

>>89
CreateThreadは引数でスタックサイズ与えるんだから自明の事。ｗｗｗ
pthreadしか知らないバカか。ｗｗｗｗｗ

99 ：デフォルトの名無しさん：2013/02/03(日) 16:43:17.30

>>98
自明なのに「マルチスレッドだと、スタックサイズが固定になる」
って言いきった人がいるらしいですよｗ
生成時にいくらでも変えられるのにどのへんが固定なんでしょうねｗ

100 ： ◆QZaw55cn4c ：2013/02/03(日) 16:44:08.32

炎上学習法が効果的に利いていますね

101 ：デフォルトの名無しさん：2013/02/03(日) 16:44:14.74

１．スタックサイズは固定だよバカ
２．（１へ）生成時に設定できるよ
３．（２へ）生成時に設定できるの知らないのかバカ

３は２に対してどのような作用を及ぼしているんだろう
さすがに草生やさないと会話できないだけあって文盲過ぎる

102 ：デフォルトの名無しさん：2013/02/03(日) 16:44:31.10

>>93
ちゃんとポインタが返ってきますよ。
楽観的ですから、使うときにはあいてるかもしれないですしね。

103 ：デフォルトの名無しさん：2013/02/03(日) 16:46:05.71

くさおはどうして日本語が不自由なの？

104 ：デフォルトの名無しさん：2013/02/03(日) 16:47:41.81

>>103
頭が不自由だからですよ。

105 ：デフォルトの名無しさん：2013/02/03(日) 16:48:20.91

>>98
pthreadもスタックサイズくらい変えられるが。

106 ：デフォルトの名無しさん：2013/02/03(日) 16:57:20.49

くさお敗走ｗｗｗｗｗｗ

107 ：デフォルトの名無しさん：2013/02/03(日) 16:59:38.11

>>94
お前やっぱりバカだ。ｗｗｗｗ
freeするにはfreeする対象を列挙する必要があるんだが。ｗｗｗｗ
free楽勝と豪語していたfree必須バカのお仲間は単純な連結リストでもバグってたぞ。ｗｗｗｗ

>>99
シングルスレッドなら必要に応じてOSが伸ばしてくれるが、マルチスレッドでは生成した後は固定。わかるかバカ。ｗｗｗｗ

>>81を読んでスレッド生成時のスタックサイズが固定と読むバカがいるとは思わなかった。ｗｗｗ
これからバカ相手に書くときはもっと気を付けよう。ｗｗｗｗ

108 ：デフォルトの名無しさん：2013/02/03(日) 17:00:13.09

スレッドのスタックサイズを変えるという話で
スレッドが動き出してから変えると認識した人
初めて見たわ。
スタックサイズを変えるなんて100%生成時しかあり得ないだろ。

109 ：デフォルトの名無しさん：2013/02/03(日) 17:05:53.43

>>107
君、スレに貼った超短いコードがいくつもバグってたよね？

110 ：デフォルトの名無しさん：2013/02/03(日) 17:08:01.36

>>109
freeを書くとバグるからfreeをやめよう、という宗教の教祖様ですから。

111 ：デフォルトの名無しさん：2013/02/03(日) 17:13:05.67

>>109
バグったのは
http://toro.2ch.net/test/read.cgi/tech/1359585842/12
だけだが。

>>108
(シングルスレッドなら)メインスレッドのスタックは動き出してから自動的に伸びるだろ。
お前ら決定的に力量不足。言い換えればバカ。ｗｗｗ

112 ：デフォルトの名無しさん：2013/02/03(日) 17:16:24.52

さすが力量マンの書くコードは力量が見て取れるナー
http://toro.2ch.net/test/read.cgi/tech/1359585842/12

113 ：デフォルトの名無しさん：2013/02/03(日) 17:21:54.48

mainの引数の仕様もしらんのか、こいつ。

114 ：デフォルトの名無しさん：2013/02/03(日) 17:44:02.24

>>111
直したつもりの奴でいいからさ
http://toro.2ch.net/test/read.cgi/tech/1359585842/15

argcが0以上をチェックする目的と
argv[0]を"-exit"と比較する意味を説明してくれ

115 ：デフォルトの名無しさん：2013/02/03(日) 17:46:07.76

おーい、このバカ(>>113)が何言ってるのか翻訳してくれ。ｗｗｗｗ
ANSI C99 5.1.2.2.1 Program Startupの↓これ以外の事なのか?
バカ同士ならわかるだろ。ｗｗｗ

int main(int argc, char *argv[]) { /* ... */ }
or equivalent;9) or in some other implementation-defined manner.
--
9) Thus, int can be replaced by a typedef name defined as int, or the type of argv can be written as
char ** argv, and so on.

116 ：デフォルトの名無しさん：2013/02/03(日) 17:49:14.79

>>103
憲法も読んだことないんですって

117 ：デフォルトの名無しさん：2013/02/03(日) 17:49:49.96

>>107
>シングルスレッドなら必要に応じてOSが伸ばしてくれる
本当か？

118 ：デフォルトの名無しさん：2013/02/03(日) 17:58:22.92

>>114
特別だぞ。バカ。ｗｗｗｗ

> argcが0以上をチェックする目的と
5.1.2.2.1 Program startup
2 If they are declared, the parameters to the main function shall obey the following
constraints:
The value of argc shall be nonnegative

> argv[0]を"-exit"と比較する意味を説明してくれ
free必須バカが正常系はfreeしろ、シグナル終了などの異常系はfreeしなくていい
例外とかいってるから、異常系ではないexecveで終了してみた。ｗｗｗｗ

119 ：デフォルトの名無しさん：2013/02/03(日) 18:03:56.79

>>118
argv[0] って普通プログラムの名前とかパスとかが入っているんですよね？これって環境依存？

120 ：デフォルトの名無しさん：2013/02/03(日) 18:09:59.75

>>119
procfs使ってるんだから環境依存に決まってんだろ。バカ。ｗｗｗｗｗ
mainのargvにはexecveに与えたものが渡される。そんな事も知らないで言いがかり付けてんのかよ。ｗｗｗｗ

121 ：デフォルトの名無しさん：2013/02/03(日) 18:15:54.29

execveで呼ばれたときにargv[0]は"/proc/???/exe"みたいなのなるだろ、つってんだよ

122 ：デフォルトの名無しさん：2013/02/03(日) 18:17:14.77

なんねーよ。バカ。ｗｗｗｗｗ
なんねーよ。バカ。ｗｗｗｗｗ
なんねーよ。バカ。ｗｗｗｗｗ
なんねーよ。バカ。ｗｗｗｗｗ
なんねーよ。バカ。ｗｗｗｗｗ
なんねーよ。バカ。ｗｗｗｗｗ
なんねーよ。バカ。ｗｗｗｗｗ
なんねーよ。バカ。ｗｗｗｗｗ
なんねーよ。バカ。ｗｗｗｗｗ
なんねーよ。バカ。ｗｗｗｗｗ

123 ：デフォルトの名無しさん：2013/02/03(日) 18:18:38.59

また一匹伝説のバカが生まれる瞬間に立ち会ってしまった。ｗｗｗｗ

124 ：デフォルトの名無しさん：2013/02/03(日) 18:21:29.24

argcがネガチブだったら、何もしないで終了した方がいいと思うの

125 ：デフォルトの名無しさん：2013/02/03(日) 18:29:59.18

nonnegativeって規格で決まってるんだからダメだろ。バカ。ｗｗｗｗ
それにexecveのargvになに渡すとネガティブになるんだよ。ｗｗｗｗｗ

"-exit"渡さないという方法もあるだろうけど、それで動くか確信持て
なかったので確実に動く"-exit"渡した。ｗｗｗｗ

126 ：デフォルトの名無しさん：2013/02/03(日) 18:33:05.42

今日も予定外かつ規格外のバカが釣れた。ｗｗｗｗ
こういうバカがfree楽勝。バグなんか作らないと豪語している。笑うしかないな。ｗｗｗｗｗ

> From: [121] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:15:54.29
>
> execveで呼ばれたときにargv[0]は"/proc/???/exe"みたいなのなるだろ、つってんだよ

127 ：デフォルトの名無しさん：2013/02/03(日) 18:34:13.45

gcc -o "-exit"

128 ：デフォルトの名無しさん：2013/02/03(日) 18:35:47.81

流れ追ってなくてよく分からないけど
http://toro.2ch.net/test/read.cgi/tech/1359585842/15
みたいなプログラム書く人が規格外のバカだっていうのはわかった

129 ：デフォルトの名無しさん：2013/02/03(日) 18:39:35.71

freeでバグるためなら、どんな阿呆で無意味なソースでも書いて見せます。

130 ：デフォルトの名無しさん：2013/02/03(日) 18:42:51.19

http://kazmax.zpp.jp/cmd/e/execve.2.html
execveでargv作ってるんだから0番目が-exitでもおかしくないんじゃないか
正常系か異常系かと言われたら作った人の頭が異常系だな

131 ：デフォルトの名無しさん：2013/02/03(日) 18:43:33.07

>>128-129
悔しそうだな。今度は自演という事にしないのか? ｗｗｗｗ
も一回、反芻しようっと。ｗｗｗｗ

> From: [121] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:15:54.29
>
> execveで呼ばれたときにargv[0]は"/proc/???/exe"みたいなのなるだろ、つってんだよ

132 ：デフォルトの名無しさん：2013/02/03(日) 18:48:17.85

execveでargv[0]を引数にして動作を振り分けるなんというキチガイな
実装を、有名なOSSの実装で１つでも出せるなら認めてやろう。

133 ：デフォルトの名無しさん：2013/02/03(日) 18:50:48.24

>>132
ヒント：マルウエア

134 ：デフォルトの名無しさん：2013/02/03(日) 18:51:40.81

>>132
BusyBox

135 ：デフォルトの名無しさん：2013/02/03(日) 18:53:17.95

>>132
ksh, zsh, ash, bash, .... ｗｗｗｗｗ
雑魚過ぎる。ｗｗｗｗ

136 ：デフォルトの名無しさん：2013/02/03(日) 19:10:42.81

なんかバカ相手の炎上学習教室開いてる気がしてきた。ｗｗｗｗ
お前らバカすぎる。ｗｗｗｗ

> From: [121] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:15:54.29
>
> execveで呼ばれたときにargv[0]は"/proc/???/exe"みたいなのなるだろ、つってんだよ

> From: [132] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:48:17.85
>
> execveでargv[0]を引数にして動作を振り分けるなんというキチガイな
> 実装を、有名なOSSの実装で１つでも出せるなら認めてやろう。

137 ：デフォルトの名無しさん：2013/02/03(日) 19:21:07.96

煽ればキチガイが必死になって回答してくれるのでいろいろ捗るなｗ

138 ：デフォルトの名無しさん：2013/02/03(日) 19:30:08.03

よく >>137 みたいな事言う奴がいるけど、
そんなに自分の無能っぷりを自慢したいのだろうか？

139 ：デフォルトの名無しさん：2013/02/03(日) 19:36:33.65

>>138
その無能にいいように利用されている自称有能な人たちｗ

140 ：デフォルトの名無しさん：2013/02/03(日) 19:37:13.54

第三者と思い込む事でなかったことにしたいんだろう。ｗｗｗｗ
free必須バカってこんなのばっかり。規格外のバカ。ｗｗｗｗ

> From: [121] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:15:54.29
>
> execveで呼ばれたときにargv[0]は"/proc/???/exe"みたいなのなるだろ、つってんだよ

> From: [132] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:48:17.85
>
> execveでargv[0]を引数にして動作を振り分けるなんというキチガイな
> 実装を、有名なOSSの実装で１つでも出せるなら認めてやろう。

141 ：デフォルトの名無しさん：2013/02/03(日) 19:44:04.88

>>139
そこの認識がが根本的に違うんだな。
答える奴等は、思っているよりずっと軽やかなのだよ。

野良猫に餌をやったからといって、
餌をやった人が野良猫の奴隷だとは言えないだろ？

142 ：デフォルトの名無しさん：2013/02/03(日) 20:07:32.46

そうやって奴隷の自覚のないまま奴隷にするのが
俺のテクニックだ。

143 ：デフォルトの名無しさん：2013/02/03(日) 20:12:34.93

>>142
なら、もっと愛嬌を磨くとよい。
そうやって生きていく場合、これが生命線だよ。
まあ頑張れ。

144 ：デフォルトの名無しさん：2013/02/03(日) 20:16:22.26

バカがついに崩壊したか。ｗｗｗｗ
freeは必須とか言ってるバカ、まだ生存してるのか? ｗｗｗｗ
大分踏みつぶしたけど。ｗｗｗｗｗ

145 ：デフォルトの名無しさん：2013/02/03(日) 22:43:43.90

ヒント：free派に便乗した炎上学習者にくさおが操られてるだけ

146 ：デフォルトの名無しさん：2013/02/03(日) 23:00:31.96

にくさおｗ

147 ：デフォルトの名無しさん：2013/02/03(日) 23:15:03.11

肉竿ってなんだか卑猥

148 ：デフォルトの名無しさん：2013/02/03(日) 23:27:57.26

～炎上学習者にくさお伝説～

＞バカがついに崩壊したか。ｗｗｗｗ
＞freeは必須とか言ってるバカ、まだ生存してるのか? ｗｗｗｗ
＞大分踏みつぶしたけど。ｗｗｗｗｗ

↑完全に乗せられています

149 ：デフォルトの名無しさん：2013/02/04(月) 02:01:32.79

もう面倒だから free(malloc(size)); でいいじゃん。

150 ：デフォルトの名無しさん：2013/02/04(月) 09:10:32.85

free必要なプログラムのうちの1%で
freeしてもしなくてもいい希少な例を
頑張って考えたところで、残り99%では
必要なことはまったく崩せていないんだけどね。
単に希少な特異な例を持ち出してクイズを
やっているに過ぎない。

151 ：デフォルトの名無しさん：2013/02/04(月) 09:22:50.67

バカはあのクイズの意味を理解していない。ｗｗｗｗ
↓こんなこといってるバカだから理解できないのは当然と言えば当然だが。ｗｗｗｗ

> From: [121] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:15:54.29
>
> execveで呼ばれたときにargv[0]は"/proc/???/exe"みたいなのなるだろ、つってんだよ

152 ：デフォルトの名無しさん：2013/02/04(月) 11:32:59.54

悔しい時の話題そらし
どこのスレでも同じだな

153 ：デフォルトの名無しさん：2013/02/04(月) 11:44:30.00

踏みつぶされたゴミ虫がなんかほざいてるようだな。ｗｗｗｗｗ

> From: [121] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:15:54.29
>
> execveで呼ばれたときにargv[0]は"/proc/???/exe"みたいなのなるだろ、つってんだよ

154 ：デフォルトの名無しさん：2013/02/04(月) 13:50:04.92

>>152
もう話題をそらす余裕さえ無くなってるみたいだな

155 ：デフォルトの名無しさん：2013/02/04(月) 15:15:48.34

よほど話題を変えて欲しいらしい。まあ無理もないが。ｗｗｗｗ

> From: [121] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:15:54.29
>
> execveで呼ばれたときにargv[0]は"/proc/???/exe"みたいなのなるだろ、つってんだよ

156 ：デフォルトの名無しさん：2013/02/04(月) 15:58:28.44

これをコピペすることだけが心の支えなんだな

157 ：デフォルトの名無しさん：2013/02/04(月) 16:50:59.90

158 ：デフォルトの名無しさん：2013/02/04(月) 18:50:06.57

頭が悪いからよく分からないんだけど、ここまでで>>4から何か進展があった？

159 ：デフォルトの名無しさん：2013/02/04(月) 22:28:51.21

ないよ

160 ：デフォルトの名無しさん：2013/02/04(月) 22:30:11.74

>>156
今までの流れから察すると自分の中で負けを認めてしまったときからコピペになる

161 ：デフォルトの名無しさん：2013/02/04(月) 22:30:28.84

臭夫の脳の腐乱がどんどん進んでいるという意味では進展あるな

162 ：デフォルトの名無しさん：2013/02/04(月) 22:54:42.89

163 ：デフォルトの名無しさん：2013/02/04(月) 23:12:56.14

>>159
そうか。

知識の無い人を見つけて上機嫌のくさおでいいから
exec系の話なのかargvを綺麗にする話なのか分からないけど
要旨をまとめてくれないか

164 ：デフォルトの名無しさん：2013/02/04(月) 23:16:28.41

>>163
むりやり
ファック
ユー

165 ：デフォルトの名無しさん：2013/02/04(月) 23:27:23.95

argvを汚くする話ならしてたな

166 ：デフォルトの名無しさん：2013/02/05(火) 02:29:25.10

>>163
頭が悪いバカにはわからない。ｗｗｗｗ
自分でまとめてみろ。添削してやるから。ｗｗｗｗ

167 ：デフォルトの名無しさん：2013/02/05(火) 12:54:03.95

マロックなん？エムアロックなん？

168 ：デフォルトの名無しさん：2013/02/05(火) 12:58:23.06

>>167
ttp://kotonoha.cc/no/6489
要するに「どっちでも好きな方で」

169 ：デフォルトの名無しさん：2013/02/05(火) 13:01:30.61

確実な意思疎通を優先するならエムアロック

170 ：デフォルトの名無しさん：2013/02/05(火) 13:20:07.26

オム・アンコなん？オマンコなん？

171 ：デフォルトの名無しさん：2013/02/06(水) 22:06:38.19

フリーなん？エフリーなん？

172 ：デフォルトの名無しさん：2013/02/10(日) 14:54:02.29

v8のjavascriptのGabageCollectionは
実際にメモリが足りなくなるまでは発動されないよ
process.exit(0);で終了するとGCされないまま終了するwww

条件付free不要派の勝利www

173 ：デフォルトの名無しさん：2013/02/10(日) 15:00:32.02

そもそもガベコレが頻繁に行われたからと言って、
メモリの断片化が解消されるとは限らないからな。
どうせあとで確保出来なくなるなら何もしてないのと一緒。
free するだけ時間の無駄。

174 ：デフォルトの名無しさん：2013/02/10(日) 19:03:48.57

突然javascriptとかGCを持ち出す自演とか涙ぐましいね

175 ：デフォルトの名無しさん：2013/02/10(日) 19:07:06.60

LinuxだってGCするじゃん。

176 ：デフォルトの名無しさん：2013/02/10(日) 22:31:07.24

最近話題の OOM killer ですか

177 ：デフォルトの名無しさん：2013/02/13(水) 07:45:53.85

>>172
草生やす前にスペルミス直そうな

178 ：デフォルトの名無しさん：2013/02/13(水) 17:26:58.71

>>177
草の数が増えるだけだぞ
なにしろ白痴なんだから

179 ：デフォルトの名無しさん：2013/02/14(木) 00:23:41.37

くさおだろ捕まったの

180 ：デフォルトの名無しさん：2013/02/14(木) 01:25:46.49

そういやあらわれないね

181 ：デフォルトの名無しさん：2013/02/15(金) 20:24:21.30

完　全　に　く　さ　お　終　了

182 ：デフォルトの名無しさん：2013/02/15(金) 20:59:42.95

free("くさお")

183 ：デフォルトの名無しさん：2013/02/15(金) 21:08:09.10

freeしない派だから終身刑だろ
死ねばOSが解放してくれるんじゃね

184 ：デフォルトの名無しさん：2013/02/15(金) 21:25:57.53

踏みつぶされるのが怖くて反論できなくなったfree必須バカ。ｗｗｗ
かかってこいよ。チンカス。ｗｗｗ

> From: [121] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:15:54.29
>
> execveで呼ばれたときにargv[0]は"/proc/???/exe"みたいなのなるだろ、つってんだよ

185 ：デフォルトの名無しさん：2013/02/15(金) 21:28:16.69

↑※キーワードに反応して遠隔操作でコピペしています

186 ：デフォルトの名無しさん：2013/02/16(土) 04:06:17.19

まだ続いてるのか？　だったらfreeはなんのためにあるんだ？って聞いてやれよｗｗ

187 ：デフォルトの名無しさん：2013/02/16(土) 04:40:14.39

>>186
またバカが踏みつぶされるために向かってきた。ｗｗｗ
> The free function causes the space pointed to by ptr to be deallocated,
> that is, made available for further allocation.

freeは何のためにあるって書いてある? ｗｗｗ

188 ：デフォルトの名無しさん：2013/02/16(土) 08:46:40.95

面接で落とされてまた戻ってきたのか

189 ：デフォルトの名無しさん：2013/02/16(土) 09:08:49.69

また返り討ちか。バカｗｗｗ

> From: [121] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 18:15:54.29
>
> execveで呼ばれたときにargv[0]は"/proc/???/exe"みたいなのなるだろ、つってんだよ

> From: [186] デフォルトの名無しさん <sage>
> Date: 2013/02/16(土) 04:06:17.19
>
> まだ続いてるのか？　だったらfreeはなんのためにあるんだ？って聞いてやれよｗｗ

190 ：デフォルトの名無しさん：2013/02/16(土) 09:18:49.76

freeするとバグるよぉ、怖いよぉっていうのを自分に納得させるために
まず使わないトリッキーな方法を選りすぐって欺瞞を並べてます。
所詮は自分が獲得したメモリを自分の実装で管理しきれない無能。
図書館から本を借りパクしても、死ねば遺品整理で誰かが返してくれる方式。

191 ：デフォルトの名無しさん：2013/02/16(土) 09:31:39.89

free楽勝と豪語しているfree必須バカの作品ｗｗｗｗ

http://toro.2ch.net/test/read.cgi/tech/1352812333/861
> From: [861] デフォルトの名無しさん <sage>
> Date: 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);
> }

192 ：デフォルトの名無しさん：2013/02/16(土) 09:38:22.25

http://toro.2ch.net/test/read.cgi/tech/1352812333/795
> From: [795] ◆QZaw55cn4c <sage>
> Date: 2013/01/27(日) 18:28:41.06
>
> >>788
> >>646
> for (i = 0; i < 10000000; i++) { struct l *p = malloc(sizeof(struct l)); p->next = root; root = p; }
>
> void free_l(struct l *p) {if (p->next) free_l(p->next); free(p); }
>
> 確保は線形的、解放は再帰的かいな？
> あえて曲げてんのか？解放も普通に書けよ
>
> >>794
> いっぱいあるねえ
> https://www.google.com/search?q=%22double+pointer%22+linux
> 約 9,060 件（0.13 秒）

193 ：デフォルトの名無しさん：2013/02/16(土) 09:39:50.95

http://toro.2ch.net/test/read.cgi/tech/1352812333/874
From: [874] デフォルトの名無しさん <>
Date: 2013/01/29(火) 12:37:44.50
>
> バカがうるさいので書き直してやるよ。ｗｗｗ
> void free_l(struct l * restrict p) {
> struct l *next = p->next;
> free(p);
> if (next)
> free_l(next);
> }
>
> バカのいいがかりなんて所詮この程度の事。バカには意味わからないだろうけどな。ｗｗｗ

194 ：デフォルトの名無しさん：2013/02/16(土) 09:40:52.34

くさおは能力ないからちゃんとした議論ができなくて実のない話ばっかだな

195 ：デフォルトの名無しさん：2013/02/16(土) 09:41:06.20

http://toro.2ch.net/test/read.cgi/tech/1352812333/876
> From: [876] デフォルトの名無しさん <sage>
> Date: 2013/01/29(火) 12:58:33.48
>
> ここでｗｗｗさんに問題です
> 天才には簡単な問題ですので必ず逃げないで答えてください
>
> スタックサイズが8MBのとき、このfree_l関数で解放可能な連結リストは
> 最大何個連結可能でしょうか？
>
> アーキテクチャは好きに選んでいいですよ

196 ：デフォルトの名無しさん：2013/02/16(土) 09:42:41.37

http://toro.2ch.net/test/read.cgi/tech/1352812333/885
From: [885] デフォルトの名無しさん <>
Date: 2013/01/29(火) 14:42:41.02
>
> >>884
> 制限なし。ｗｗｗ
> これでいいのか。ｗｗｗ

197 ：デフォルトの名無しさん：2013/02/16(土) 10:07:12.68

極論に走っているのが無能の証拠。

198 ：デフォルトの名無しさん：2013/02/16(土) 13:43:00.26

>>190
使い捨てのプラスチック食器を使ってバーベキューを
楽しんでいると考えてください。

この食器は耐久性があるので、さっと洗って何回でも使えます。
さっと洗うのがfree、再度利用するのがmallocと考えてください。

何回でも洗って使えるので、限られた量の食器でも永続的に
バーベキューを楽しむことができます。

そうは言ってもバーベキューの時間も終わりがきます。

あなたはどうするでしょうか ?

汚れたプラスチック食器を洗って整頓して、再度利用できる状態まで
整理してからゴミ袋に放り込むのでしょうか ?

でしたらfree絶対派です。

どうせ廃棄するのだからと
テーブルの上からゴソっとごみ袋に放り込むのでしょうか ?

でしたらfreeは必要でない場合もある派です。

199 ：デフォルトの名無しさん：2013/02/16(土) 14:11:24.26

「食器はセルフサービスです。使ったお皿は洗ってもとの場所に返しておいてください。」
という張り紙を書くか、
「...ただし終了前は洗わずに返してかまいません。終了するときには主催者から
アナウンスがありますので、注意して聞いてください。」
という張り紙を書くか。

200 ：デフォルトの名無しさん：2013/02/16(土) 18:44:44.00

http://toro.2ch.net/test/read.cgi/tech/1352812333/884
> From: [884] デフォルトの名無しさん <sage>
> Date: 2013/01/29(火) 14:41:33.76
>
> 別にちゃんと>>867を答えてもらってもいいですよ
> 答えられるならばの話ですけど

201 ：デフォルトの名無しさん：2013/02/16(土) 18:51:39.31

http://toro.2ch.net/test/read.cgi/tech/1352812333/889
From: [889] デフォルトの名無しさん <sage>
Date: 2013/01/29(火) 15:16:19.97
>
> すいません、笑いすぎて息でなくて、笑い死にしそうになっていました

202 ：デフォルトの名無しさん：2013/02/16(土) 18:55:52.54

http://toro.2ch.net/test/read.cgi/tech/1352812333/899
From: [899] デフォルトの名無しさん <>
Date: 2013/01/29(火) 16:39:16.63
> >>874は末尾再帰と呼ばれる形式で、機械的に反復形式に最適化できる。
> 証拠 → http://pastebin.com/4pBPEWBGの該当部分
> .LBB0_1: # %tailrecurse
> # =>This Inner Loop Header: Depth=1
> movq (%rdi), %rbx
> callq free
> testq %rbx, %rbx
> movq %rbx, %rdi
> jne .LBB0_1
> 全くスタックは消費していない。rdiがfree_lへの引数(p), rbxがnextだな。
>
> せっかく↓警告しといてあげたのにね。
> > バカのいいがかりなんて所詮この程度の事。バカには意味わからないだろうけどな。ｗｗｗ

203 ：デフォルトの名無しさん：2013/02/16(土) 19:03:00.89

KKCのyou is a big fool man.に匹敵する爆笑ログの解説編ｗｗｗｗ

>>192
free必須バカの先頭をつっぱしるウンコQzが再帰で書いた事に言いがかりをつける
その後、末尾再帰に簡単に書き換えられる事に気づかずに粘着して煽る。

>>193
バカのうんこQzにもわかるように末尾再帰に書き直してやる。

>>195
末尾再帰を知らない前スレ一番のバカ、爆笑ログの主人公876が引っかかる。ｗｗｗｗ

>>200
勝利を確信して煽る。ｗｗｗ

>>196
煽りに乗ってみる。ｗｗ

>>201
更なる勝利を確信したもよう。ｗｗｗ

>>202
末尾再帰の種明かし。ｗｗｗｗ
そして、876は逃亡。ｗｗｗｗ

204 ：デフォルトの名無しさん：2013/02/16(土) 19:08:19.54

自作自演を誇らしげに語られても。

205 ：デフォルトの名無しさん：2013/02/16(土) 19:16:41.30

アスペ顔のデブくさお再来か

206 ：デフォルトの名無しさん：2013/02/16(土) 19:18:26.84

解放処理で不具合が出たり処理食われるから解放処理は用意しないという論調だけど
この人は全ての解放処理を書かないつもりなのか？
終了直前以外は必要に応じて書くなら結局用意しないといけないと思うんだけど

207 ：デフォルトの名無しさん：2013/02/16(土) 20:58:22.35

>>206
別にバグが混入するからって言うのが主目的じゃないよ。
ただ、無駄だから。

なんで無駄だといけないの ?
と問われると、まぁ、無駄な処理を記述するとバグが入る可能性が
増えるし....となる。

無駄なごみを書いたっていいじゃんって言われればそうなんだけど、
他人に強制しないでね。

> この人は全ての解放処理を書かないつもりなのか？

必要な解放処理はもちろん書くし、使うよ。

> 終了直前以外は必要に応じて書くなら結局用意しないといけないと思うんだけど

まず、本質的にプロセスと寿命が等しいオブジェクトというのが存在する。
この場合、オブジェクト（のメモリ）の解放ということは起こりえないので
解放処理を記述することはない。

次に、別に解放処理を書いたからといって使わなければならないということはない。
例えば、イメージデータを保持する領域なんかは、イメージの削除処理などで
解放処理が利用されるが、別にプログラムの終了のときに解放処理を行う必要は
ない。

208 ：デフォルトの名無しさん：2013/02/16(土) 21:33:01.38

>>207
だから解放処理が作れるとか作れないとか速いとか遅いとかはこのスレで論ずる事ではないよねという話

209 ：デフォルトの名無しさん：2013/02/16(土) 21:37:39.32

何を論じるの？

210 ：デフォルトの名無しさん：2013/02/16(土) 22:02:26.79

>>207
> 必要な解放処理はもちろん書くし、使うよ。

これはfree必要派だな。結局free不要と言う奴なんていなかった

なんか、ごちゃごちゃもめてる様に見えたのは前提条件とか
例外的なケースのすり合わせが出来てないだけだったのか

211 ：デフォルトの名無しさん：2013/02/16(土) 22:58:23.31

>>204
KKC以来の醜態は自演という事にしてごまかすしかないよなあ。ｗｗｗ

>>210
いかなる場合でもfreeしろという狂信的なfree必須バカがいる。

212 ：デフォルトの名無しさん：2013/02/16(土) 23:16:32.58

いかなる場合もfreeしないってのとじゃ話は別なわけだが。

つーか、数学のレベルでいえば、保育園レベルだなｗ　free関数の使い道おしえてくれよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

213 ：デフォルトの名無しさん：2013/02/17(日) 00:12:34.88

> いかなる場合もfreeしないってのとじゃ話は別なわけだが。
そんな事はオレも含めて誰も一回も言っていないぞ。ｗｗｗ
爆笑ログさらされて壊れた? ｗｗｗｗ

KKCのyou is a big fool man.に匹敵する爆笑ログの解説編ｗｗｗｗ

>>192
free必須バカの先頭をつっぱしるウンコQzが再帰で書いた事に言いがかりをつける
その後、末尾再帰に簡単に書き換えられる事に気づかずに粘着して煽る。

>>193
バカのうんこQzにもわかるように末尾再帰に書き直してやる。

>>195
末尾再帰を知らない前スレ一番のバカ、爆笑ログの主人公876が引っかかる。ｗｗｗｗ

>>200
勝利を確信して煽る。ｗｗｗ

>>196
煽りに乗ってみる。ｗｗ

>>201
更なる勝利を確信したもよう。ｗｗｗ

>>202
末尾再帰の種明かし。ｗｗｗｗ
そして、876は逃亡。ｗｗｗｗ

214 ：デフォルトの名無しさん：2013/02/17(日) 00:17:34.29

まあ、free関数の使い道が提示できないだけでおまえの圧倒的敗北が確定なわけだが。

215 ：デフォルトの名無しさん：2013/02/17(日) 00:50:36.98

>>187
とっくに出しているが。英語は読めないか。さすがバカ。ｗｗｗｗ

KKCのyou is a big fool man.に匹敵する爆笑ログの解説編ｗｗｗｗ

>>192
free必須バカの先頭をつっぱしるウンコQzが再帰で書いた事に言いがかりをつける
その後、末尾再帰に簡単に書き換えられる事に気づかずに粘着して煽る。

>>193
バカのうんこQzにもわかるように末尾再帰に書き直してやる。

>>195
末尾再帰を知らない前スレ一番のバカ、爆笑ログの主人公876が引っかかる。ｗｗｗｗ

>>200
勝利を確信して煽る。ｗｗｗ

>>196
煽りに乗ってみる。ｗｗ

>>201
更なる勝利を確信したもよう。ｗｗｗ

>>202
末尾再帰の種明かし。ｗｗｗｗ
そして、876は逃亡。ｗｗｗｗ

216 ：デフォルトの名無しさん：2013/02/17(日) 01:04:13.26

バカにされたくさお発狂中age

217 ：デフォルトの名無しさん：2013/02/17(日) 01:31:10.56

何度みても笑える。ｗｗｗｗ

KKCのyou is a big fool man.に匹敵する爆笑ログの解説編ｗｗｗｗ

>>192
free必須バカの先頭をつっぱしるウンコQzが再帰で書いた事に言いがかりをつける
その後、末尾再帰に簡単に書き換えられる事に気づかずに粘着して煽る。

>>193
バカのうんこQzにもわかるように末尾再帰に書き直してやる。

>>195
末尾再帰を知らない前スレ一番のバカ、爆笑ログの主人公876が引っかかる。ｗｗｗｗ

>>200
勝利を確信して煽る。ｗｗｗ

>>196
煽りに乗ってみる。ｗｗ

>>201
更なる勝利を確信したもよう。ｗｗｗ

>>202
末尾再帰の種明かし。ｗｗｗｗ
そして、876は逃亡。ｗｗｗｗ

218 ：デフォルトの名無しさん：2013/02/17(日) 03:47:01.93

こいつ誰と戦ってんだ

219 ：デフォルトの名無しさん：2013/02/17(日) 09:32:46.14

プログラマーって寂しい奴ばっかなの？

220 ：デフォルトの名無しさん：2013/02/17(日) 10:46:00.43

マだけにはなりたくないよね

221 ：デフォルトの名無しさん：2013/02/17(日) 12:01:52.97

>>217は特殊な人です。
一般的とは思わないでください。

222 ：デフォルトの名無しさん：2013/02/17(日) 12:06:25.96

>>218
QZとだよ

223 ：デフォルトの名無しさん：2013/02/17(日) 12:08:00.33

>>218
戦いではない。バカを一方的になぶっているだけだ。ｗｗｗｗ

224 ：デフォルトの名無しさん：2013/02/17(日) 14:31:13.77

>>218
他人を納得させられるような議論ができなくて「俺以外全員バカ」モードに入った

225 ：デフォルトの名無しさん：2013/02/17(日) 14:32:54.62

>>223
泣いてるのお前一人だぞ

226 ：デフォルトの名無しさん：2013/02/17(日) 14:59:06.71

>>224-225
↓こんな醜態さらしてそんなに悔しい? バカなんだからだまってりゃよかったのに。ｗｗｗ

KKCのyou is a big fool man.に匹敵する爆笑ログの解説編ｗｗｗｗ

>>192
free必須バカの先頭をつっぱしるウンコQzが再帰で書いた事に言いがかりをつける
その後、末尾再帰に簡単に書き換えられる事に気づかずに粘着して煽る。

>>193
バカのうんこQzにもわかるように末尾再帰に書き直してやる。

>>195
末尾再帰を知らない前スレ一番のバカ、爆笑ログの主人公876が引っかかる。ｗｗｗｗ

>>200
勝利を確信して煽る。ｗｗｗ

>>196
煽りに乗ってみる。ｗｗ

>>201
更なる勝利を確信したもよう。ｗｗｗ

>>202
末尾再帰の種明かし。ｗｗｗｗ
そして、876は逃亡。ｗｗｗｗ

227 ：デフォルトの名無しさん：2013/02/20(水) 21:35:05.54

・・・

228 ：デフォルトの名無しさん：2013/02/21(木) 03:43:09.19

おまえはfreeどころかmallocも使うなアホ

229 ：デフォルトの名無しさん：2013/03/24(日) 16:40:22.40

実際、最大要素数さえ決めりゃmalloc使わなくても大概のデータ構造は作れるのよね

230 ：デフォルトの名無しさん：2013/03/24(日) 16:47:10.01

大概の、じゃなくて、なんでも、だよ。
その代わりユーザーには何の理由もなく受け付けるデータ量の上限、みたいな制限が加えられる。

231 ：デフォルトの名無しさん：2013/04/09(火) 12:16:59.06

どこかの関数で巨大なmalloc()をして、もうその関数では必要なくなってもfree()
しないでメモリが足りなくなるとかの危険性は？

もちろんfree()してもメモリが足りなくならないという保証はないけど、少なくとも
free()した領域は再利用される

232 ：デフォルトの名無しさん：2013/04/09(火) 12:53:53.95

>>231
このスレは、そういう場合の話ではない

233 ：デフォルトの名無しさん：2013/04/13(土) 22:17:23.81

>>232
スレタイくらい読めボケカス

234 ：デフォルトの名無しさん：2013/04/14(日) 00:08:23.17

移植性とかいっても今時free必要なOSなんて無いから

235 ：デフォルトの名無しさん：2013/04/14(日) 16:39:02.13

そもそも俺freeしないとどう困るか理解してないから

236 ：デフォルトの名無しさん：2013/04/21(日) 19:36:14.85

困るまで free してはならない

237 ：デフォルトの名無しさん：2013/04/22(月) 04:31:27.17

環境依存

MS-DOSは、シングルタスク。
プロテクトモードで実行中にメモリでエラーで終了…
メモリ不足でもはやエディタも起動できないとか
リセットボタンをおすしかない

238 ：デフォルトの名無しさん：2013/04/23(火) 00:17:07.69

freeしない奴は糞してケツを拭かない食糞民族と同じ。

239 ：デフォルトの名無しさん：2013/04/28(日) 02:47:36.83

なんてことだ、俺たちは「どうせ風呂入ればうんこ落ちるし風呂入る前にうんこ拭かなくていいよね」派と戦っていたのか・・・

240 ：デフォルトの名無しさん：2013/06/05(水) 12:38:51.14

exitすればおｋ

241 ：デフォルトの名無しさん：2013/06/07(金) 12:06:28.26

ループ構造が完全にないなら開放不要だろ。

蓄積するから問題なんだから。。

＞free()した領域は再利用される
これメモリが分断されまくりの領域が本当に再利用されるのか？

242 ：デフォルトの名無しさん：2013/06/07(金) 13:33:45.82

freeした時に隣が開いてれば一緒の領域にする、ぐらいは当然やってるよ。
仮にランダムにalloc/freeして、その結果「分断されまくり」になるというデータでもあるわけ？

243 ：デフォルトの名無しさん：2013/06/07(金) 14:03:16.35

>>242
http://ja.wikipedia.org/wiki/Malloc
> IA-32アーキテクチャでのアロケータの実装には一般にヒープまたはデータセグメントが使用されている
> （セグメント方式）。アロケータがメモリを確保するとき、ヒープに未使用領域がない場合はヒープを拡張
> することでメモリを確保する。
>
> ヒープ方式はフラグメンテーションという問題がある。どのようなメモリ確保方式でもヒープではフラグメン
> トが発生する。つまり、ヒープ上に飛び飛びに使用中領域と未使用領域が存在することになる。優秀な
> アロケータはヒープを拡張する前に未使用領域を再利用しようとする。しかし性能問題があるため、リア
> ルタイムシステムでは代わりに「メモリプール」という方式を使う必要がある（特定サイズのメモリブロック
> のプールを予め用意しておく方式）。

244 ：デフォルトの名無しさん：2013/06/07(金) 15:07:51.77

「 IA-32アーキテクチャでの」なんていう無意味な修飾を先頭に付けてる時点で、その執筆者は全く信用できない。

245 ：デフォルトの名無しさん：2013/06/07(金) 15:33:53.68

>>244
君が信頼できる内容に書き換えてもいいんだよ

246 ：デフォルトの名無しさん：2013/06/07(金) 18:12:08.82

mallocも実装したことないやつが語ってんのかよ。
アーキテクチャにほぼ関係ないだろ。Cで実装できるだし。

なにが君が信頼できる内容に書き換えてもいいんだよだアホが。

247 ：デフォルトの名無しさん：2013/06/07(金) 18:16:11.80

>>246
お前がが実装したフラグメントしないmallocが、世界中の全てのプログラマで使われてるなら問題ないが、
フラグメントするmallocを使ってる人が多数いるってことに気づけ

248 ：デフォルトの名無しさん：2013/06/07(金) 18:25:52.26

だからfreeしないのか？ｗ

どんな実装でもメモリ不足でぶっとぶわアホ。

freeしろ。

249 ：デフォルトの名無しさん：2013/06/07(金) 18:32:07.16

> フラグメントするmallocを使ってる人が多数いるってことに気づけ

具体的にどのプラットフォームのlibcがそうなっているのか言ってみろよ。
多数ってもしかして、1, 2, たくさん、って意味かw

250 ：デフォルトの名無しさん：2013/06/07(金) 18:39:12.06

>>249
glibc。
はい、論破。

251 ：デフォルトの名無しさん：2013/06/07(金) 19:20:14.08

「俺様用語で定義するところのフラグメント」について語ってるなコイツw

252 ：デフォルトの名無しさん：2013/06/07(金) 19:27:28.26

mallocは使い方を誤るとフラグメントが起きるから、
なるべく起きないようプログラムを設計すべきだな。

253 ：デフォルトの名無しさん：2013/06/07(金) 22:13:39.69

>>249
glibc。
はい、論破。

254 ：デフォルトの名無しさん：2013/06/07(金) 23:19:40.35

恥ずかしすぎる

255 ：デフォルトの名無しさん：2013/06/08(土) 00:01:45.59

mallocの実装もできないようなゴミはgnucとかつかってんじゃねーよ。

glibc使ってるようなザコは、1度mallocで大量メモリ確保したあと自作のmallocで管理しろ。

256 ：デフォルトの名無しさん：2013/06/08(土) 10:15:22.94

>>243
英語版から引き継いでるな。
しかも「すなわち」と訳すべき or を「あるいは」と訳してる（爆笑）

257 ：デフォルトの名無しさん：2013/06/08(土) 13:13:50.33

>>255
真のザコw

258 ：デフォルトの名無しさん：2013/06/10(月) 09:36:45.07

おれはループの中に含まれないmallocはfreeしなくてもいいと思うよ

259 ：デフォルトの名無しさん：2013/06/10(月) 21:51:08.78

でも、free() しようと思えばできるけど、いちいち書くのはめんどくさいていう立場でしょう？

260 ：デフォルトの名無しさん：2013/06/10(月) 22:10:56.15

freeして害になることは何一つない
freeしなくて良い条件を必死で探して屁理屈を垂れ流すのは、
1円安く物を買うために10km先まで行くようなもの
つまり、視野狭窄馬鹿の自己満足に過ぎない

261 ：デフォルトの名無しさん：2013/06/10(月) 22:12:32.75

必死だな

262 ：デフォルトの名無しさん：2013/06/10(月) 22:19:01.91

>>261
今どきそんな幼稚園レスして恥ずかしくないのか？
2ch黎明期じゃあるまいし

263 ：デフォルトの名無しさん：2013/06/11(火) 00:04:55.16

>>260
散々既出だと思うけど、アプリ終了時の場合は自分でfreeするよりOSに任せたほうが早い場合もあるでしょ。
mallocしたメモリがswapされていた場合とか。

264 ：デフォルトの名無しさん：2013/06/11(火) 10:36:17.87

>>260
「複雑なデータ構造のときに、mainからreturnする前に一生懸命freeしてまわるのがコードの無駄だし時間の無駄」

というのはうなずける。

265 ：デフォルトの名無しさん：2013/06/11(火) 11:04:20.06

ただfreeするだけならともかく、構造体の中にポインタがあってそれを全部たどってると、
スラッシング起こすアプリとか、実際あるね。

266 ：デフォルトの名無しさん：2013/06/11(火) 12:40:03.49

そういうプログラムは通常実行中も論外なのでは。

267 ：デフォルトの名無しさん：2013/06/11(火) 12:41:14.78

mainからreturnの前のfreeは、自己満足に過ぎないよね

268 ：デフォルトの名無しさん：2013/06/11(火) 14:22:12.07

>>266
実行中は仮想空間を食い潰してしまわないためにはfreeせざるをえないかもしれない。
Oracle JVM みたいにメモリ使用量を指定できるなら、それ使って実メモリのサイズに
抑えておくのが常道。

269 ：デフォルトの名無しさん：2013/06/11(火) 21:45:13.42

>>266
まあ、必死に考えた無理矢理の例なので、暖かい目で見てやってください。

270 ：デフォルトの名無しさん：2013/06/11(火) 22:09:58.38

具体的に反論できない人を生温かく見守るスレでつねw

271 ：デフォルトの名無しさん：2013/06/11(火) 22:12:40.96

なら、具体例出してみなよ (w

272 ：デフォルトの名無しさん：2013/06/12(水) 13:34:50.19

不定量だが必ず確保される。
プログラム終了まで必要。

以上の場合はfreeしないかもね。
単なる手抜き以上の理由は無いが。

273 ：デフォルトの名無しさん：2013/06/12(水) 13:37:12.12

コンパイラみたいに1回走って終わりのプログラムなら、いらんよ。
最初のほうの手続きで確保して、後のほうでも使う、とかいうデータだと、
malloc/freeの対応が簡単じゃなくなるし。

274 ：デフォルトの名無しさん：2014/06/08(日) 19:18:18.10 ID:y9fg5iny

プロセスが終了したあとのメモリの開放って何かの規格に入ってんの？

275 ：デフォルトの名無しさん：2014/06/08(日) 23:12:22.86 ID:bkCTLeYU

>>274
普通のOSならそうする、くらいとしか
MS-DOS ですらプロセスで取得したメモリブロックを回収にまわるから、それをしないOSは, MS-DOS 以下ということで

276 ：デフォルトの名無しさん：2014/06/08(日) 23:20:13.12 ID:0ybo3LG4

POSIXの場合、メモリはプロセスにひっついてるものだから、プロセスが消えたら消える。

メモリはいいけど、プロセス間通信のための資源とかで、プロセスとは独立に生存する
ものについてはダメだから、注意する必要があるね。

277 ：デフォルトの名無しさん：2014/06/09(月) 17:59:41.28 ID:zFo/cDF8

＞プロセス間通信のための資源とか
参照カウンタ見て上手くやってくれてるんじゃないの？

278 ：デフォルトの名無しさん：2014/06/09(月) 22:41:25.12 ID:0wp3BeLp

man ipcrm

279 ：デフォルトの名無しさん：2014/06/29(日) 22:57:20.87 ID:7osONbHL

mainだって普通の関数なんだから、プロセス起動時以外にもコード中で呼び出される可能性はある
つまりmainからreturnした直後にプログラムが終了してOSがメモリ回収するとは限らない

280 ：デフォルトの名無しさん：2014/06/30(月) 00:10:01.85 ID:DSrnNHZo

重箱の隅つつくと普通ではないな。return省略していいっていう特別扱い

281 ：デフォルトの名無しさん：2014/06/30(月) 09:54:32.09 ID:lJxnkRTG

(暗黙的なスタートアップから以外の)main()の呼び出しは未定義じゃなかったっけ?

282 ：デフォルトの名無しさん：2014/06/30(月) 11:46:32.05 ID:9KK/EJtO

C++では明確に禁止。
Cでも、ふつうはやらないほうがいい。

そして、いずれにしろプロセスが終了すればプロセスが持っていた資源はOSが回収するので、
>>279 の言っていることは屁理屈にすらなっていない。

283 ：デフォルトの名無しさん：2014/06/30(月) 22:02:19.05 ID:Jqyj17b9

なんか意味があるかって言われると何も言えないけど、
確かにCだとmain()を呼ぶことはできるんだね。
ttps://ideone.com/hII5Pp

284 ：デフォルトの名無しさん：2014/06/30(月) 22:05:05.58 ID:9KK/EJtO

コードゴルフでループを書くよりもmainを再帰で呼ぶほうが短くなる、という技がある

285 ：デフォルトの名無しさん：2014/06/30(月) 22:07:48.77 ID:Jqyj17b9

>>284
確かにmain()を再帰呼び出しして確認してもよかったね
というか、適当ソースだからどうでもいいけど、我ながらreturnなしのint hoge()って。。

286 ：デフォルトの名無しさん：2014/07/07(月) 21:15:24.61 ID:KBtb6NQy

要約すると、メモリーが貴重な時代は終わった。終了が早いのが正義。freeいらね。

287 ：デフォルトの名無しさん：2014/07/23(水) 06:53:50.72 ID:aSrmdrCP

>>282
普通は回収されるとはいえC/C++自体にその保証は無いけどね。>>274-275
>>286
自前でメモリ管理を再発明するなら別だが、確保と開放を繰り返す場合は必要。

288 ：デフォルトの名無しさん：2014/07/24(木) 07:55:56.40 ID:vS77S6P+

うん。言語では保証されてないね。
OS無しの環境を使ってるならね。

289 ：デフォルトの名無しさん：2014/07/24(木) 21:52:53.95 ID:rO5lcI/m

hosted environment なら保証されてなかったっけ？

290 ：デフォルトの名無しさん：2014/09/27(土) 01:05:41.54 ID:ZCazcpui

例外的にfreeを使わないのが正しい判断でそうしてる場合であっても、freeを記述した
上でコメントアウトしておくとか、条件コンパイルでfreeを有効にも無効にも切り替え
られるようにしとかないと、まともなコードとして信用はできないな。

291 ：デフォルトの名無しさん：2014/09/27(土) 01:46:12.43 ID:z3mF+ujQ

ちゃんと free() できないくせに「free() を省略している」と主張するとか、面の皮が厚いですね

292 ：デフォルトの名無しさん：2014/09/27(土) 09:52:04.78 ID:lv9b6q1l

LinuxはOSが完璧だからFreeの必要がないが、Windowsはバグが多いので
必ずFreeしなければならないと犬板で言ってた。

293 ：デフォルトの名無しさん：2014/09/27(土) 10:27:03.26 ID:2YkqVza8

>>292
Windows にバグが多いかどうかは別にして、必ず free すればいいと思ってる犬板の奴はアホとしか思えない

294 ：デフォルトの名無しさん：2014/09/27(土) 11:23:46.58 ID:XmLrUZPb

エプロンおねえさん以上の知能の持ち主がなにかおしゃってますね

295 ：デフォルトの名無しさん：2014/09/27(土) 14:31:25.00 ID:lJpImKEe

Windowsで注意が必要なのはリソースとかで、
Linuxでも複数プロセスが共有する名前付きの資源とかは注意しなけりゃならんことに
変わりはない。

296 ：デフォルトの名無しさん：2014/09/27(土) 14:42:06.10 ID:2hDhGVr5

free()すらめんどくさがるやつはプログラミングすんな
以上

297 ：デフォルトの名無しさん：2014/09/27(土) 14:54:47.52 ID:0IvxL3Y7

不要なOSでまで馬鹿正直にfreeしてたらクソ遅いだけじゃん
意味無いどころか害悪

http://cpplover.blogspot.jp/2014/09/cp4320039tb.html

298 ：デフォルトの名無しさん：2014/09/27(土) 16:09:33.54 ID:XmLrUZPb

メモリの確保と開放がちぐはぐでバギーなことしたいならご自由に

299 ：デフォルトの名無しさん：2014/09/27(土) 17:14:03.74 ID:lJpImKEe

ちぐはぐにしないために、許容可能な場合は「freeしない」というポリシーを決めるわけです。
まったく何もわかってないバカということを露呈していただいてありがとう御座います。

一生そのレベルのバカでいてくださいね。使い物にならないプログラマが増えて爆死してけば、
使えるプログラマの給料が上がりますのでw

300 ：デフォルトの名無しさん：2014/09/27(土) 17:15:50.18 ID:XmLrUZPb

乙女のポリシーかなんかですか？

301 ：デフォルトの名無しさん：2014/09/27(土) 17:42:35.54 ID:BQj/liI5

ポリシーって書ける俺かっけーって奴でしょ w

302 ：デフォルトの名無しさん：2014/09/27(土) 17:48:52.13 ID:lJpImKEe

流石バカ

303 ：デフォルトの名無しさん：2014/09/27(土) 17:50:51.69 ID:DE3jcZJu

freeしないのは自由だし、必要ない場面があるのも確かだけど、イチイチそんな事例を列挙してポリシー()化する程のメリットがない

304 ：デフォルトの名無しさん：2014/09/27(土) 17:51:04.65 ID:kqLVip0H

freeが省略可能かどうか、事前あるいは局所的に判断できるようなあまり一般的ではない
ケースのためにわざわざ妙なポリシーを設定するのはセンス無いと思う。
あるいは、何か変更する毎に「前にここで省略したfreeがまた必要になってないか」って
気にしながらプログラミングするんだろうか。

305 ：デフォルトの名無しさん：2014/09/27(土) 18:33:38.97 ID:t2PIgPlE

許容可能な場合は～
とか、ポリシーでもなんでもないだろ
どういう場合に許容可能とするかを書かないと意味がない
そのレベルの奴なので温かくスルーしてやりなよ w

306 ：デフォルトの名無しさん：2014/09/27(土) 19:02:44.41 ID:lv9b6q1l

>>297が言いたいのは、Linuxは糞速いのでプログラム内から解放すると一日たっても終了
しない解放処理が、システムに任せると1nsで終わるということだと思います。
前から思ってたけど、glibcって糞ですよね。
libc5サイコーってLinux板で言ってました。

307 ：デフォルトの名無しさん：2014/09/27(土) 20:22:12.59 ID:XmLrUZPb

cp使って大量で大容量のバックアップする人いるんだ
へー

308 ：デフォルトの名無しさん：2014/09/27(土) 20:27:29.57 ID:lv9b6q1l

>>307
いますよー。
しかも、オプションなんて気にしないのです。

309 ：デフォルトの名無しさん：2014/09/27(土) 20:38:54.53 ID:lJpImKEe

デーモン類みたいな動かしっぱなしにするプログラムで、どんどんメモリを確保して手放さなかったら
困るけど、コンパイラみたいにどうせすぐ終わるプログラムで、今時なら100Mぐらいに収まるとかなら
どうでもいいだろ。その程度の想像力も判断力も無い奴が「温かくスルー」とか、能天気でいいよなw

あと、直接freeするわけじゃないけど、GCのある言語で終了前にGCが走るような場合、確保しまくった
メモリ空間を全部なめて回るからスラッシングが起きてマシンが劇重になることがある。
そんな場合も、本当に解放すべきリソースがあるのでなければ、とっとと_exitしてしまえばいい。

310 ：デフォルトの名無しさん：2014/09/27(土) 20:47:14.49 ID:M7lcZRBS

必要かどうかを判断したり適切かどうかをチェックしたりする人的コストがムダ

311 ：デフォルトの名無しさん：2014/09/27(土) 21:05:07.76 ID:y/Ez5wR8

スマートポインタ作ればいいだけやで

312 ：デフォルトの名無しさん：2014/09/27(土) 22:19:47.14 ID:Jgs7UTKm

ぼくが書くような小規模のプログラムはfreeが必要なほどメモリ食わない
そしてメモリを逼迫するまえにプログラム自体が終了する
いつもfree書くけど書き忘れてもあんしん！！

313 ：デフォルトの名無しさん：2014/09/27(土) 22:35:10.84 ID:lv9b6q1l

bashがfreeしないくらいだから、必要ないんじゃない？

314 ：デフォルトの名無しさん：2014/09/27(土) 22:45:58.39 ID:2YkqVza8

>>309
> どうでもいいだろ。

能天気乙 w

315 ：デフォルトの名無しさん：2014/09/27(土) 22:48:39.13 ID:dBgfCEST

今どきのOSではプロセス殺せば
ヒープなんて勝手に開放されるから
リソースのなかではある意味一番
リークしてもダメージの少ない
類いではあるよね

ヒープ以外のリソース開放には無力どころか
RAIIがしにくくなる分害悪にすらなる
GC付言語がこうまで持て囃されている
現実は不思議すぎる

316 ：デフォルトの名無しさん：2014/09/28(日) 01:10:09.70 ID:sHyLw6pq

> 能天気乙 w

極端な話、メモリが100M越えたら強制終了でも構わないアプリ、なんてのもいくらでも考えられるが、
そういうのも全部「能天気乙 w」って攻撃するんだなw

ただのバカだった、で終了。

317 ：デフォルトの名無しさん：2014/09/28(日) 02:36:06.63 ID:ri3k0THz

>>299
「許容可能な場合は」←これ省略する馬鹿が居るからfreeしろって言われるんだよ。
>>303-304
開放処理が負荷になるケースのためにexit用の開放処理を一式再実装するとか、
通常の開放処理の中でexit確定フラグ見て開放処理をスキップするとか…面倒くさいね。
開放処理の負荷がヤバイことになるってケースが想定されない限りやりたくねぇわ。
>>309
cpの開放処理コストも普通に使う分には「どうでもいいだろ。」って言われそうやね。
>>315
徐々にリークが増えてく場合、仮想メモリ空間なりスワップ領域なり食いつぶして死ぬ。
ていうかオブジェクト開放時にリソースも開放する設計にしとけばリソースも回収できる。
GCは俺も余り好きじゃないが、GCがメモリだけ回収してリソース回収しないって認識は流石に…

318 ：デフォルトの名無しさん：2014/09/28(日) 02:56:51.92 ID:MgcGxJig

>>317
そりゃ、プログラム終了までに開放すれば良いような、ヒープみたいなリソースなら良いけど、ファイルにしろDBにしろ他のプロセスなどと共用するリソースは、必要なくなったら即時開放が必須だろう。

319 ：デフォルトの名無しさん：2014/09/28(日) 07:40:32.09 ID:YI897KP6

今の時代だとGC搭載のプログラムで動かしまくってるからなぁ
メモリなんてほぼ無限
Cのような言語で組まれたものならfreeしなくても大差ないくらいだよなぁ
でも入れるけど

320 ：デフォルトの名無しさん：2014/09/28(日) 08:12:04.95 ID:fth8YQlj

>>316
ただのバカ乙 w

321 ：デフォルトの名無しさん：2014/09/28(日) 10:18:03.79 ID:sfiCrzAs

> ていうかオブジェクト開放時にリソースも開放する設計にしとけばリソースも回収できる。
> GCは俺も余り好きじゃないが、GCがメモリだけ回収してリソース回収しないって認識は流石に…
↑ こいつ最高のバカ
メモリの使用状況をトリガーとするGCでメモリ以外のリソースも管理するとか。死ねゴミクズ。

322 ：デフォルトの名無しさん：2014/09/28(日) 11:05:15.19 ID:yTX/1oq/

>>309
win31時代の話をされても

323 ：デフォルトの名無しさん：2014/09/28(日) 11:07:23.91 ID:yTX/1oq/

>>321
GC はメモリ回収しかしないと思うよ、OSリソース回収は自分で書かないとね
C# や Java にもデストラクタがあったほうがよかったと思うことがしばしば

324 ：デフォルトの名無しさん：2014/09/28(日) 11:08:13.02 ID:57+mjdrX

メモリリークもゴミみたい思える大きさだから、freeしなくてもいいって？

325 ：デフォルトの名無しさん：2014/09/28(日) 11:12:12.60 ID:yTX/1oq/

リークを定義できない人間がfree()不要論を朗誦しているんですよ

326 ：デフォルトの名無しさん：2014/09/28(日) 11:52:29.34 ID:FAkptdZZ

keep it simple stupid を誤解釈すると free不要になるのかも知れない

327 ：デフォルトの名無しさん：2014/09/28(日) 11:56:57.44 ID:WvBy1dAf

レベル0: 常にfreeを書かない
レベル1: 常にfreeを書く
レベル2: 条件に合わせてfreeを省略すべきときだけ省略する

328 ：デフォルトの名無しさん：2014/09/28(日) 13:53:02.44 ID:RpCDBRzc

ま、この場合のkissは「常にfreeする」か「一切freeしない」のどちらかだろうな
ハイブリッドにするのは最適化に近いので、最後の手段としたい

329 ：デフォルトの名無しさん：2014/09/28(日) 14:11:49.10 ID:sHyLw6pq

>>328 そんな単純なことすら理解できず教条的に「freeしろ」と叫ぶだけのバカが、
まだこんなに多いとわかった、ってのが収穫だな。

330 ：デフォルトの名無しさん：2014/09/28(日) 15:07:03.68 ID:RpgaQOqc

ポリシー君乙 w

331 ：デフォルトの名無しさん：2014/09/28(日) 16:34:11.76 ID:yTX/1oq/

>>329
君、free() が不要な例と絶対に必要な例とをコードで示してくれないか？

332 ：デフォルトの名無しさん：2014/09/28(日) 17:17:57.68 ID:57+mjdrX

楽（らく）したいだけの人だから、答えられ...

333 ：デフォルトの名無しさん：2014/09/28(日) 17:24:58.28 ID:SkMDQSso

mallocしたら必ずfreeという決まりは手抜きだったってことですかね。
解放の必要性を吟味して決めなければならないという事でしょうか。

334 ：デフォルトの名無しさん：2014/09/28(日) 17:26:58.87 ID:SkMDQSso

これはRAIIは原則禁止したほうが良い。
言語にGCを組み込むのは禁止したほうが良い。

こういったことでしょうかね。

335 ：デフォルトの名無しさん：2014/09/28(日) 17:28:24.15 ID:sfiCrzAs

freeしなくても良いか検討した上でfreeしないのだから、
ボンクラはガタガタ言うな。

と言うこと。

336 ：デフォルトの名無しさん：2014/09/28(日) 17:34:34.94 ID:SkMDQSso

開放忘れは指摘するべきではないということですかね。

337 ：デフォルトの名無しさん：2014/09/28(日) 17:37:26.24 ID:57+mjdrX

わからない（わかってない）人に
間違ってます
とか言うと怒りますから
言わないほうがいいでしょうね

338 ：デフォルトの名無しさん：2014/09/28(日) 19:08:55.44 ID:SkMDQSso

>>337
間違ってます。

339 ：デフォルトの名無しさん：2014/09/28(日) 19:30:37.85 ID:lwUZotcA

>>332
> 楽（らく）したいだけの人

検討したつもりになってるだけの人の可能性もあるぞ w

340 ：デフォルトの名無しさん：2014/09/29(月) 00:58:09.40 ID:3GxNQMYW

>>337
それは真実だけど、そこを頑張らないと

341 ：デフォルトの名無しさん：2014/09/29(月) 00:59:53.42 ID:xSX/Gj/Z

社会性ないから無理

342 ：デフォルトの名無しさん：2014/09/29(月) 07:47:22.78 ID:wd4qvqdb

>>341
＞社会性
「貴重なご意見感謝いたします」「鋭意善処して参ります」と放言して気分すっきりさっぱりする能力のことですね

343 ：デフォルトの名無しさん：2014/09/30(火) 12:17:08.51 ID:v0Hutm1t

Windowsは必ずFreeしないとクラッシュすると犬板で言ってた。
データ消えて大変だったらしい。

344 ：デフォルトの名無しさん：2014/09/30(火) 21:27:53.75 ID:GBpQF1/L

UNIXでは非rootはリソースを使い切れないとかあるし、
コミットチャージを使い切ると次にメモリ確保しようとした奴が失敗する(たいていはそいつが死ぬ)から、
まぁ分からんでもないけど……OOMで無差別殺人されてるLinuxのユーザがそれを言うかね？

345 ：デフォルトの名無しさん：2014/09/30(火) 22:12:00.11 ID:N6uFkPfQ

OOMキラーは一定のルールで重要なものを残すようになってるから
無差別殺人じゃないぞ。そんな基礎的なことも知らんのかね？

346 ：デフォルトの名無しさん：2014/09/30(火) 23:27:55.38 ID:j0qHbCkI

そりゃ無差別殺人者だって本当に相手を選ばないことないからな
弱そうな奴とか、特定の人種とか

347 ：デフォルトの名無しさん：2014/09/30(火) 23:57:18.37 ID:Z3ryMPKI

殺されないように、プログラムの先頭でおまじないを唱えよう。

348 ：デフォルトの名無しさん：2014/10/01(水) 13:45:52.76 ID:n9ZGXeJV

いや一番ため込んでる富豪を狙い撃ちするんじゃね

349 ：デフォルトの名無しさん：2014/10/03(金) 11:53:06.51 ID:8OTaypIY

C heap is cheap

350 ：デフォルトの名無しさん：2014/10/04(土) 09:03:51.86 ID:X8tclADN

C's heap is not cheap but smple..

351 ：デフォルトの名無しさん：2014/10/04(土) 16:22:32.12 ID:nRIrCQg7

freeしたいやつはして、したくないやつはしなければいい
それだけ
以上
終了
おつおつ

352 ：デフォルトの名無しさん：2014/10/04(土) 18:14:13.44 ID:j+aw4iLv

ちゃんと free( ) できない奴って、いつも最後はその結論だね w

353 ：デフォルトの名無しさん：2014/10/04(土) 19:34:40.00 ID:WpG7hkwu

教条主義者による断末魔の煽りって、いつもこうだよねw

354 ：デフォルトの名無しさん：2014/10/04(土) 19:58:41.25 ID:ugcUiR2p

挙げ句の果てに
system("ls -l ./prog"); えいっ

355 ：デフォルトの名無しさん：2014/10/04(土) 22:12:06.07 ID:X8tclADN

い、extern は要らない子ぉっ！！

356 ：デフォルトの名無しさん：2014/10/04(土) 22:25:18.34 ID:j+aw4iLv

>>353
おうむ返ししかできなくて悔しいね w

357 ：デフォルトの名無しさん：2014/10/04(土) 22:57:28.17 ID:WpG7hkwu

ワンパターン・バカがそれを言うと趣があるな

358 ：デフォルトの名無しさん：2014/10/04(土) 23:15:41.65 ID:8UXXAPps

ワンパターン・バカ = いつものおうむ返し w

359 ：デフォルトの名無しさん：2014/10/04(土) 23:19:29.91 ID:j+aw4iLv

>>357
お前か言うと重いなあ
そろそろお薬飲んだ方がいいんじゃないかな w

360 ：デフォルトの名無しさん：2014/10/05(日) 00:25:31.58 ID:FZuSwsnO

芸人の持ちネタにそこまで過敏にならなくても‥

361 ：デフォルトの名無しさん：2014/10/05(日) 00:31:49.02 ID:6amJApcn

あんたらもしかして頭は悪めな方？？

>>351で終了だお

362 ：デフォルトの名無しさん：2014/10/05(日) 07:09:36.34 ID:fbEOqD5u

無限ループ乙

363 ：デフォルトの名無しさん：2014/10/09(木) 18:57:30.60 ID:vRdoCwIm

標準のアロケータは万能じゃないから、カバーしきれない用途は自前で用意するって
話なんだけど、freeするのはアホって話で>>1000目指すよ。
用意いいかい？

364 ：デフォルトの名無しさん：2014/10/09(木) 20:36:35.27 ID:9/qS7Lgu

おっけー

365 ：デフォルトの名無しさん：2014/10/09(木) 20:53:58.60 ID:tOThY/oR

>>363
free/delete しないのなら自前のアロケータなんか要らないのでは？じゃんじゃん malloc() すればいいだけの話

366 ：デフォルトの名無しさん：2014/10/09(木) 23:16:03.38 ID:vRdoCwIm

せやな。
RAM512KBでも普通に動いてたしな、16GBも有ったら解放する必要あらへん。

知ってるか？
16GBは64億個の0と64億個の1が有るのや、合わせて128億個やで。
128億という数は、地球上に有るすべての砂の数より多いねんで。
こんなん使い切れるわけあらへんしな。

367 ：デフォルトの名無しさん：2014/10/10(金) 00:31:13.03 ID:sOr9aeNy

一人ではね。

368 ：デフォルトの名無しさん：2014/10/10(金) 04:16:27.17 ID:KCO91E8u

人間だけでも70億人以上いるらしいんだが
世界の砂ってそんなに少ないのか

369 ：デフォルトの名無しさん：2014/10/10(金) 07:42:18.41 ID:JpN3UDQu

てか、GCって駄目じゃね？

GCあってもメモリリーク問題解決してないやん
なら、最初から自分で管理するという教育をした方が良くね？

370 ：デフォルトの名無しさん：2014/10/10(金) 08:11:32.03 ID:Npcpt0Da

freeしたいやつはして、したくないやつはしなければいい
それだけ
以上
終了
おつおつ

371 ：デフォルトの名無しさん：2014/10/10(金) 08:30:54.00 ID:kwgAp7cQ

>>368
冷静かつ的確な指摘すぎてﾜﾛﾀ

372 ：デフォルトの名無しさん：2014/10/10(金) 12:50:29.54 ID:4Jxm1TDD

>>370
また、無限ループか
free() できない奴のアホさが滲み出てるな w

373 ：デフォルトの名無しさん：2014/10/10(金) 18:16:01.82 ID:Xd6YjWLK

そりゃ何を free() していいのか、何を free() しなくていいのか、わかっていないからね‥

374 ：デフォルトの名無しさん：2014/10/11(土) 01:03:15.48 ID:ZmK/zNnJ

freeしない生き方を選択したとき、精神は解放されるんやで。
覚えとき。

375 ：デフォルトの名無しさん：2014/10/11(土) 06:58:25.56 ID:BpoU1i8h

>>374
C/C++ を諦めて C# に行くんですね
もう帰ってこないでね w

376 ：デフォルトの名無しさん：2014/10/11(土) 09:22:03.50 ID:8nW7oHJ6

>>370
いやこれでまじで終了だろ

377 ：デフォルトの名無しさん：2014/10/11(土) 09:33:07.63 ID:Qk2dzUbv

>>374
非マの生き方を選択したとき、精神は解放されるんやで。
達者でな。

378 ：デフォルトの名無しさん：2014/10/11(土) 09:42:45.54 ID:/AOb9xWD

クラスの中に放り込んで管理してるから、freeしたくなくても勝手にfreeされるんだが

379 ：デフォルトの名無しさん：2014/10/11(土) 10:00:29.43 ID:BpoU1i8h

>>376
はいはい、終わりだからもう来るなよ

380 ：デフォルトの名無しさん：2014/10/11(土) 11:44:11.01 ID:8nW7oHJ6

>>379
おまえもなー

381 ：デフォルトの名無しさん：2014/10/11(土) 12:39:02.40 ID:povbJtsL

>>380
うざ、来るなって言われてるのに、free もできないバカはこれだから

382 ：デフォルトの名無しさん：2014/10/11(土) 13:20:27.24 ID:oD37Hh5X

おまえのようなバカが他で暴れないようにするためにこのスレがあるんだよw

383 ：デフォルトの名無しさん：2014/10/11(土) 13:55:55.55 ID:BpoU1i8h

>>382
>>380

384 ：デフォルトの名無しさん：2014/10/11(土) 16:47:40.65 ID:8nW7oHJ6

(´・ω・｀)

385 ：デフォルトの名無しさん：2014/10/12(日) 14:14:14.69 ID:n4H9xNXC

ネバーエンディングストーリー♪

386 ：デフォルトの名無しさん：2014/10/12(日) 14:29:10.77 ID:sv4A2Uaz

>>384
まだいたのかよ w

387 ：デフォルトの名無しさん：2014/10/12(日) 14:33:27.20 ID:HHh3+SMY

>>386
>>383 ID: BpoU1i8h

388 ：デフォルトの名無しさん：2014/10/12(日) 15:18:47.16 ID:sv4A2Uaz

>>387
俺は終わりだとかは言ってないけど？
free が必要かどうかの区別もつかないバカはこれだから w

389 ：デフォルトの名無しさん：2014/10/12(日) 15:30:56.77 ID:63mVogyM

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

390 ：デフォルトの名無しさん：2014/10/12(日) 15:35:01.76 ID:HHh3+SMY

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

391 ：デフォルトの名無しさん：2014/10/12(日) 15:46:26.73 ID:yWo9u0cs

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

392 ：デフォルトの名無しさん：2014/10/12(日) 16:02:22.91 ID:sv4A2Uaz

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

393 ：デフォルトの名無しさん：2014/10/12(日) 16:04:41.38 ID:HHh3+SMY

>>392
ワロタｗ

394 ：デフォルトの名無しさん：2014/10/13(月) 00:21:10.29 ID:Kelszug8

free必須教の第一信徒はQz

395 ：デフォルトの名無しさん：2014/10/13(月) 08:15:56.25 ID:BlK6LuSG

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

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

一行で済む。

396 ：デフォルトの名無しさん：2014/10/13(月) 08:39:15.72 ID:qVWnI3+v

RAID 6 ってつよいの？

397 ：デフォルトの名無しさん：2014/10/13(月) 10:04:05.65 ID:XwZMSYHG

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

398 ： ◆QZaw55cn4c ：2014/10/13(月) 10:04:24.56 ID:PPv6Llzm

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

399 ：デフォルトの名無しさん：2014/10/13(月) 10:49:30.16 ID:7i+sJhXA

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

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

400 ：デフォルトの名無しさん：2014/10/13(月) 10:57:56.36 ID:/QBpY+Db

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

401 ：デフォルトの名無しさん：2014/10/13(月) 11:04:25.31 ID:yDwfk/q+

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

402 ：デフォルトの名無しさん：2014/10/13(月) 11:08:58.83 ID:qVWnI3+v

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

ゆえに必死

403 ：デフォルトの名無しさん：2014/10/13(月) 11:28:22.88 ID:XwZMSYHG

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

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

404 ：デフォルトの名無しさん：2014/10/13(月) 11:30:56.35 ID:BlK6LuSG

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

405 ：デフォルトの名無しさん：2014/10/13(月) 11:58:25.05 ID:AG4RYcUu

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

406 ：デフォルトの名無しさん：2014/10/13(月) 12:19:26.06 ID:93elBZWE

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

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

407 ：デフォルトの名無しさん：2014/10/13(月) 12:24:50.21 ID:XwZMSYHG

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

408 ：デフォルトの名無しさん：2014/10/13(月) 12:27:56.27 ID:HMQ6z8sD

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

409 ：デフォルトの名無しさん：2014/10/13(月) 12:45:44.40 ID:BlK6LuSG

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

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

410 ：デフォルトの名無しさん：2014/10/13(月) 12:45:52.23 ID:zxgBYiLP

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

411 ：デフォルトの名無しさん：2014/10/13(月) 12:49:47.31 ID:7i+sJhXA

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

412 ：デフォルトの名無しさん：2014/10/13(月) 12:53:11.61 ID:BlK6LuSG

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

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

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

413 ：デフォルトの名無しさん：2014/10/13(月) 13:03:24.91 ID:HMQ6z8sD

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

414 ：デフォルトの名無しさん：2014/10/13(月) 13:10:03.92 ID:KgL42j04

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

415 ：デフォルトの名無しさん：2014/10/13(月) 13:25:54.46 ID:BlK6LuSG

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

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

416 ：デフォルトの名無しさん：2014/10/13(月) 13:30:14.38 ID:HMQ6z8sD

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

417 ：デフォルトの名無しさん：2014/10/13(月) 13:35:35.68 ID:5jSvrI4w

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

418 ：デフォルトの名無しさん：2014/10/13(月) 13:39:26.77 ID:BlK6LuSG

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

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

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

419 ：デフォルトの名無しさん：2014/10/13(月) 13:49:04.48 ID:BlK6LuSG

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

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

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

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

420 ：デフォルトの名無しさん：2014/10/13(月) 13:57:39.07 ID:HMQ6z8sD

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

421 ：デフォルトの名無しさん：2014/10/13(月) 14:02:09.69 ID:BlK6LuSG

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

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

422 ：デフォルトの名無しさん：2014/10/13(月) 14:03:38.82 ID:BlK6LuSG

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

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

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

423 ：デフォルトの名無しさん：2014/10/13(月) 14:04:57.87 ID:TJgILaGW

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

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

424 ：デフォルトの名無しさん：2014/10/13(月) 14:08:05.29 ID:BlK6LuSG

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

425 ：デフォルトの名無しさん：2014/10/13(月) 14:14:40.53 ID:xQhnOcQ3

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

426 ：デフォルトの名無しさん：2014/10/13(月) 14:16:56.04 ID:BlK6LuSG

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

427 ：デフォルトの名無しさん：2014/10/13(月) 14:19:29.20 ID:BlK6LuSG

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

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

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

428 ：デフォルトの名無しさん：2014/10/13(月) 14:50:19.38 ID:jkBcuCq4

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

429 ：デフォルトの名無しさん：2014/10/13(月) 14:53:17.45 ID:PPv6Llzm

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

430 ：デフォルトの名無しさん：2014/10/13(月) 14:54:54.53 ID:PPv6Llzm

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

431 ：デフォルトの名無しさん：2014/10/13(月) 15:33:08.72 ID:2IfdctYm

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

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

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

432 ：デフォルトの名無しさん：2014/10/13(月) 16:11:24.20 ID:XwZMSYHG

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

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

433 ：デフォルトの名無しさん：2014/10/13(月) 16:16:53.59 ID:BlK6LuSG

GNU製品はホント糞だな。

434 ：デフォルトの名無しさん：2014/10/13(月) 16:17:20.12 ID:7i+sJhXA

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

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

435 ：デフォルトの名無しさん：2014/10/13(月) 16:23:42.16 ID:BlK6LuSG

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

436 ：デフォルトの名無しさん：2014/10/13(月) 16:29:31.58 ID:xQhnOcQ3

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

437 ：デフォルトの名無しさん：2014/10/13(月) 16:33:17.28 ID:BlK6LuSG

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

438 ：デフォルトの名無しさん：2014/10/13(月) 17:13:00.13 ID:HMQ6z8sD

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

439 ：デフォルトの名無しさん：2014/10/13(月) 17:36:51.42 ID:Okyxmr/t

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

440 ：デフォルトの名無しさん：2014/10/13(月) 17:39:47.21 ID:xQhnOcQ3

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

441 ：デフォルトの名無しさん：2014/10/13(月) 17:57:02.26 ID:XfBY1GST

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

おっさん感激 !!

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

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

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

442 ：デフォルトの名無しさん：2014/10/13(月) 18:06:04.38 ID:7i+sJhXA

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

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

443 ：デフォルトの名無しさん：2014/10/13(月) 18:11:11.64 ID:BlK6LuSG

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

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

444 ：デフォルトの名無しさん：2014/10/13(月) 18:15:57.06 ID:BlK6LuSG

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

ということだろ？

445 ：デフォルトの名無しさん：2014/10/13(月) 18:19:35.33 ID:XwZMSYHG

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

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

446 ：441：2014/10/13(月) 18:24:11.09 ID:XfBY1GST

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

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

447 ：デフォルトの名無しさん：2014/10/13(月) 18:27:48.36 ID:7i+sJhXA

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

448 ：441：2014/10/13(月) 18:32:16.15 ID:XfBY1GST

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

449 ：デフォルトの名無しさん：2014/10/13(月) 18:33:33.08 ID:BlK6LuSG

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

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

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

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

450 ：デフォルトの名無しさん：2014/10/13(月) 18:36:40.23 ID:PPv6Llzm

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

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

451 ：デフォルトの名無しさん：2014/10/13(月) 18:38:39.11 ID:BlK6LuSG

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

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

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

452 ：デフォルトの名無しさん：2014/10/13(月) 18:39:27.83 ID:PPv6Llzm

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

453 ：デフォルトの名無しさん：2014/10/13(月) 18:46:38.76 ID:BlK6LuSG

>>452

454 ：デフォルトの名無しさん：2014/10/13(月) 18:46:52.49 ID:7i+sJhXA

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

455 ：デフォルトの名無しさん：2014/10/13(月) 18:52:40.24 ID:BlK6LuSG

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

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

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

456 ：デフォルトの名無しさん：2014/10/13(月) 18:59:10.36 ID:MgPuSkFo

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

457 ：デフォルトの名無しさん：2014/10/13(月) 19:06:21.99 ID:MgPuSkFo

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

458 ：デフォルトの名無しさん：2014/10/13(月) 19:15:48.89 ID:BlK6LuSG

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

459 ：448：2014/10/13(月) 19:19:27.66 ID:XfBY1GST

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

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

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

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

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

460 ：デフォルトの名無しさん：2014/10/13(月) 19:24:40.28 ID:PPv6Llzm

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

461 ：デフォルトの名無しさん：2014/10/13(月) 19:27:50.10 ID:BlK6LuSG

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

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

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

462 ：デフォルトの名無しさん：2014/10/13(月) 19:32:32.92 ID:XfBY1GST

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

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

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

463 ：デフォルトの名無しさん：2014/10/13(月) 19:36:18.84 ID:xQhnOcQ3

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

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

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

464 ：デフォルトの名無しさん：2014/10/13(月) 19:39:14.34 ID:BlK6LuSG

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

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

465 ：デフォルトの名無しさん：2014/10/13(月) 19:40:18.64 ID:BlK6LuSG

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

466 ：デフォルトの名無しさん：2014/10/13(月) 19:43:33.90 ID:7i+sJhXA

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

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

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

467 ：デフォルトの名無しさん：2014/10/13(月) 19:44:39.36 ID:HMQ6z8sD

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

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

468 ：デフォルトの名無しさん：2014/10/13(月) 19:47:00.34 ID:BlK6LuSG

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

469 ：デフォルトの名無しさん：2014/10/13(月) 20:12:51.45 ID:xQhnOcQ3

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

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

470 ：デフォルトの名無しさん：2014/10/13(月) 20:25:00.67 ID:BlK6LuSG

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

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

471 ：デフォルトの名無しさん：2014/10/13(月) 20:36:14.64 ID:FVrYA5zE

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

472 ：458：2014/10/13(月) 20:39:23.78 ID:XfBY1GST

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

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

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

473 ：デフォルトの名無しさん：2014/10/13(月) 20:42:43.81 ID:FVrYA5zE

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

474 ：デフォルトの名無しさん：2014/10/13(月) 20:51:37.45 ID:XwZMSYHG

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

475 ：デフォルトの名無しさん：2014/10/13(月) 21:03:25.09 ID:7i+sJhXA

>>474

>>411
>>434
>>435

476 ：デフォルトの名無しさん：2014/10/13(月) 21:09:11.84 ID:7i+sJhXA

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

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

477 ：デフォルトの名無しさん：2014/10/13(月) 21:09:16.45 ID:HMQ6z8sD

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

478 ：デフォルトの名無しさん：2014/10/13(月) 21:23:47.22 ID:QgIQdsn/

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

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

479 ：デフォルトの名無しさん：2014/10/13(月) 21:31:35.61 ID:7i+sJhXA

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

480 ：デフォルトの名無しさん：2014/10/13(月) 21:47:30.33 ID:QgIQdsn/

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

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

481 ：472：2014/10/13(月) 21:54:16.26 ID:XfBY1GST

>>477
> 前者は、参照の所有権をちゃんと考えないで複雑なデータ構造を作っちゃうと
> いざ壊そうと思ったときに嵌ったりバグったりする典型だね。

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

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

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

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

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

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

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

482 ：デフォルトの名無しさん：2014/10/13(月) 21:57:14.67 ID:7i+sJhXA

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

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

483 ：デフォルトの名無しさん：2014/10/13(月) 22:05:33.55 ID:QgIQdsn/

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

484 ：デフォルトの名無しさん：2014/10/13(月) 22:09:28.23 ID:Okyxmr/t

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

485 ：デフォルトの名無しさん：2014/10/13(月) 22:15:14.16 ID:6bh+5rPK

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

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

486 ：デフォルトの名無しさん：2014/10/13(月) 22:17:23.60 ID:Okyxmr/t

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

487 ：デフォルトの名無しさん：2014/10/13(月) 23:38:21.18 ID:7i+sJhXA

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

488 ：デフォルトの名無しさん：2014/10/13(月) 23:41:05.25 ID:xQhnOcQ3

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

489 ：デフォルトの名無しさん：2014/10/13(月) 23:41:20.11 ID:7i+sJhXA

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

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

490 ：デフォルトの名無しさん：2014/10/13(月) 23:42:12.91 ID:2IfdctYm

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

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

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

491 ：デフォルトの名無しさん：2014/10/13(月) 23:50:17.84 ID:7i+sJhXA

>>490
>>379

492 ：デフォルトの名無しさん：2014/10/14(火) 00:04:57.97 ID:Q5F/7GsC

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

493 ：デフォルトの名無しさん：2014/10/14(火) 00:16:00.24 ID:sqIDnjxe

>>492
チキン君乙

494 ：デフォルトの名無しさん：2014/10/14(火) 00:17:04.09 ID:Q5F/7GsC

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

495 ：デフォルトの名無しさん：2014/10/14(火) 01:48:42.60 ID:QI+gLDOE

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

496 ：デフォルトの名無しさん：2014/10/14(火) 06:32:50.32 ID:zT0VwE4n

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

497 ：デフォルトの名無しさん：2014/10/14(火) 06:34:31.53 ID:sqIDnjxe

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

498 ：デフォルトの名無しさん：2014/10/14(火) 07:21:14.97 ID:VoeXlFKz

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

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

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

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

499 ：デフォルトの名無しさん：2014/10/14(火) 08:43:00.85 ID:rLZatyKU

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

500 ：デフォルトの名無しさん：2014/10/14(火) 08:49:08.26 ID:KA+Nt7Wt

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

501 ：デフォルトの名無しさん：2014/10/14(火) 08:50:02.00 ID:KA+Nt7Wt

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

502 ：デフォルトの名無しさん：2014/10/14(火) 09:05:57.25 ID:VoeXlFKz

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

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

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

503 ：デフォルトの名無しさん：2014/10/14(火) 09:58:22.05 ID:9xoyfEkM

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

504 ：デフォルトの名無しさん：2014/10/14(火) 10:05:00.55 ID:FOfhE0DJ

てなしたやはたてやな

505 ：デフォルトの名無しさん：2014/10/14(火) 10:21:21.80 ID:KA+Nt7Wt

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

506 ：デフォルトの名無しさん：2014/10/15(水) 20:16:19.78 ID:94xVsGz9

>>503
バカ発見。

507 ：デフォルトの名無しさん：2014/10/15(水) 20:25:23.13 ID:hrBmyTxM

自己紹介乙

508 ：デフォルトの名無しさん：2014/10/16(木) 04:07:06.14 ID:7g6vpmsm

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

509 ：デフォルトの名無しさん：2014/10/16(木) 06:57:35.08 ID:KoQGXxiO

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

510 ：デフォルトの名無しさん：2014/10/17(金) 09:39:29.66 ID:O3Ha9Xaq

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

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

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

511 ：デフォルトの名無しさん：2014/10/17(金) 16:14:49.18 ID:v27NSYq1

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

512 ：デフォルトの名無しさん：2014/10/17(金) 16:21:12.12 ID:qPP0na7I

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

513 ：デフォルトの名無しさん：2014/10/17(金) 17:45:37.94 ID:O3Ha9Xaq

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

514 ：デフォルトの名無しさん：2014/10/17(金) 18:16:31.32 ID:P1joaUul

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

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

515 ：デフォルトの名無しさん：2014/10/17(金) 18:16:40.65 ID:xzFrNjz5

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

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

516 ：デフォルトの名無しさん：2014/10/17(金) 19:39:54.06 ID:lxCKNdJC

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

517 ：デフォルトの名無しさん：2014/10/17(金) 20:22:20.74 ID:OUYn97Bj

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

518 ：デフォルトの名無しさん：2014/10/17(金) 21:53:10.77 ID:xzFrNjz5

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

519 ：デフォルトの名無しさん：2014/10/18(土) 01:39:31.35 ID:/oNwCDSd

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

520 ：デフォルトの名無しさん：2014/10/18(土) 13:08:53.33 ID:36yYJ0yX

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

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

521 ：デフォルトの名無しさん：2014/10/18(土) 13:50:57.61 ID:/oNwCDSd

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

522 ：デフォルトの名無しさん：2014/10/18(土) 16:59:54.98 ID:36yYJ0yX

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

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

523 ：デフォルトの名無しさん：2014/10/18(土) 17:06:19.18 ID:/oNwCDSd

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

524 ：デフォルトの名無しさん：2014/10/19(日) 18:09:53.15 ID:9/KRJRbT

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

525 ：デフォルトの名無しさん：2014/10/20(月) 02:00:02.18 ID:jjiQL4kf

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

526 ：デフォルトの名無しさん：2014/10/20(月) 12:45:42.29 ID:4QGk34Ml

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

527 ：デフォルトの名無しさん：2014/10/20(月) 12:49:49.79 ID:6/LNQkyp

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

528 ：デフォルトの名無しさん：2014/10/20(月) 19:41:25.28 ID:WDflShpF

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

529 ：デフォルトの名無しさん：2014/10/20(月) 19:48:59.73 ID:+DF5oC/s

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

530 ：デフォルトの名無しさん：2014/10/20(月) 23:06:26.87 ID:exxFMbgq

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

531 ：デフォルトの名無しさん：2014/10/21(火) 12:31:58.89 ID:LAOYaiit

>>530を省略すると、

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

ということ。

532 ：デフォルトの名無しさん：2014/10/21(火) 12:58:58.48 ID:cxE2fch2

要約？

533 ：デフォルトの名無しさん：2014/10/21(火) 13:01:27.03 ID:FB8PDZ29

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

534 ：デフォルトの名無しさん：2014/10/21(火) 13:25:02.74 ID:LAOYaiit

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

535 ：デフォルトの名無しさん：2014/10/21(火) 13:49:27.95 ID:FB8PDZ29

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

536 ：デフォルトの名無しさん：2014/10/21(火) 17:55:34.62 ID:RumsGmel

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

537 ：デフォルトの名無しさん：2014/10/21(火) 18:51:18.50 ID:LAOYaiit

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

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

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

538 ：デフォルトの名無しさん：2014/10/21(火) 19:58:14.89 ID:FB8PDZ29

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

539 ：デフォルトの名無しさん：2014/10/21(火) 20:16:00.88 ID:7WAeJlTS

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

540 ：デフォルトの名無しさん：2014/10/21(火) 21:03:35.69 ID:c8NUu7RB

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

541 ：デフォルトの名無しさん：2014/10/21(火) 21:34:25.75 ID:FB8PDZ29

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

542 ：デフォルトの名無しさん：2014/10/21(火) 22:04:40.05 ID:RG7X7O+y

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

543 ：デフォルトの名無しさん：2014/10/22(水) 21:25:19.20 ID:9Jwqj8Ni

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

544 ：デフォルトの名無しさん：2014/10/23(木) 01:07:59.70 ID:lumgeE3v

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

545 ：デフォルトの名無しさん：2014/10/23(木) 08:36:30.18 ID:CIjfK2M+

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

546 ：デフォルトの名無しさん：2014/12/03(水) 21:28:00.02 ID:j0dAKNGZ

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

int *a = new int;

/*
aを使った処理
*/

delete a;

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

547 ：デフォルトの名無しさん：2014/12/03(水) 21:41:48.53 ID:JFY2u8h+

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

548 ：デフォルトの名無しさん：2014/12/03(水) 22:01:51.69 ID:U2a4HdIu

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

549 ：デフォルトの名無しさん：2014/12/03(水) 22:25:43.16 ID:JF624AUp

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

550 ：デフォルトの名無しさん：2014/12/04(木) 02:18:35.19 ID:wOy+480c

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

551 ：デフォルトの名無しさん：2014/12/04(木) 04:20:29.25 ID:ViSTblTx

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

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

552 ：デフォルトの名無しさん：2014/12/04(木) 07:46:58.88 ID:44/e6+B9

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

553 ：デフォルトの名無しさん：2014/12/04(木) 08:53:33.85 ID:i8WWsgkD

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

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

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

554 ：デフォルトの名無しさん：2014/12/04(木) 09:15:31.23 ID:otxDKoZc

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

555 ：デフォルトの名無しさん：2014/12/04(木) 12:56:10.33 ID:hhBXBLyI

>>554
> 必死でやせ我慢して

すまぽも知らない老害乙

556 ：デフォルトの名無しさん：2014/12/04(木) 18:22:41.52 ID:jHjIGczB

なまぽおいしいです

557 ：デフォルトの名無しさん：2014/12/04(木) 20:36:19.32 ID:e632zg1P

>>554
GC はまだ「完成された」というほどの領域に至っていない、Mark&Sweep とか　CopyGC, 世代別GC、incrementalGCなど、いろんな手法を駆使してだましだまし実装しているレベル
うそだと思うのなら、スマフォアプリを見ればよい、スマフォは定期的に再起動しないといけないレベル、iphone は定期的にiOSアップデートの方が先にやってくるようだが

558 ：デフォルトの名無しさん：2014/12/04(木) 20:49:21.59 ID:otxDKoZc

malloc/freeを確実に行う方法は完成している、とでも言うのかwwwwwwwwwww

559 ：デフォルトの名無しさん：2014/12/04(木) 20:50:13.03 ID:otxDKoZc

研究が盛んなあらゆる分野に「まだ「完成された」というほどの領域に至っていない」って
喧嘩売ってみろよw

560 ：デフォルトの名無しさん：2014/12/04(木) 21:03:43.58 ID:e632zg1P

>>558
簡単なラッパをかませばいいだけの話、それすらもできないの？

561 ：デフォルトの名無しさん：2014/12/04(木) 21:25:34.66 ID:otxDKoZc

いろんな手法を駆使してだましだまし漏れがないようにしているレベル、って言うんじゃないのか、それw

562 ：デフォルトの名無しさん：2014/12/04(木) 22:34:16.24 ID:wOy+480c

それって言語レベルで完全なGC無いと満足できませんっていってないか？

563 ：デフォルトの名無しさん：2014/12/04(木) 23:15:24.98 ID:Q4EOsLJ8

malloc/freeでバグばっかり出してる奴が「freeしない」という解決策を正当化しようとしているだけの話。

564 ：デフォルトの名無しさん：2014/12/05(金) 00:48:52.11 ID:3wjXi0Au

この感じだとバグ出す以前の問題で、deleteの使い方知らずに恥かいたJava厨なんじゃね？

565 ：デフォルトの名無しさん：2014/12/05(金) 01:39:25.94 ID:eQEw8fvn

なぜメモリを動的に確保する必要があるのか？という基本に立ち返って考えれば
不要論は論外であることに気づくだろう
注：このスレタイからわかるように近年のGCは範疇に入っていない

566 ：デフォルトの名無しさん：2014/12/05(金) 08:03:02.81 ID:F2ZjRsjm

もともと GC の話じゃないし

567 ：デフォルトの名無しさん：2014/12/05(金) 08:19:12.35 ID:2qqkLjHh

>>561
ラッパ一つを「いろんな」「駆使して」とかいうお子様レベルなの？
あと GC はまだまだだよ、Java の業務アプリを60日間起動しているとメモリ占有量が増えてきてきびきび動かなくなるとか勘弁してほしい、スマフォもイマイチだなあ

568 ：デフォルトの名無しさん：2014/12/05(金) 11:53:33.63 ID:IjAdRY0C

ほら出た、「俺様のやってる業務には」というすごく狭い世界が、世界の全てだ、みたいな人w

569 ：デフォルトの名無しさん：2014/12/05(金) 20:02:26.00 ID:2qqkLjHh

>>559
確かにFORTRAN, COBOL と並ぶ由緒正しき Lisp 様由来の GC に喧嘩を売るのはちょっと怖いが、実はすでに試みてみた‥
http://peace.2ch.net/test/read.cgi/tech/1408017352/201

570 ：デフォルトの名無しさん：2014/12/06(土) 00:13:17.80 ID:tAcOC+EO

Qzって、Lisp Schemeでケンカ吹っかけてガン無視されてるよな。

571 ：デフォルトの名無しさん：2014/12/06(土) 00:28:28.87 ID:uyZCaoW8

「胸を借りるつもりで」

572 ：デフォルトの名無しさん：2014/12/06(土) 01:08:13.40 ID:uyZCaoW8

>>547
演算子 new をオーバーロードするとき、中身は malloc() で書かざるを得ない気がする‥

573 ：デフォルトの名無しさん：2014/12/06(土) 03:30:36.01 ID:Iv1q4dyj

>>572
VirtualAllocとかOS依存のメソッド使ったり、グローバルな配列を細切れに使ったりも出来るんじゃない？
標準のAPIで書くならmallocしかないけど…
コンパイラ環境側が提供するnewを標準Cの範囲のみで書かなきゃダメな規則とか有るんだろうか？
だけどstd::threadとか標準Cにはどうやっても落とし込めないよなぁ…

574 ：デフォルトの名無しさん：2014/12/06(土) 09:58:48.26 ID:Khx/zTiJ

いやいや、freeが邪魔になるのは数少ない例外って
世界でものすごく広く使われているプログラムcpがfreeが邪魔だから
最後のfreeしなくなったでしょ

Google word2vecだって最後のfreeは省略している。

上で書いてあるJaneの例はfreeすべき例、
オブジェクトの寿命が終わったのだから。

free絶対主義者の考え方の何が、気に食わないかって
オブジェクトの寿命を意識してプログラムを組んでいないんじゃ
ないかってこと。

リークチェッカに引っかからなければプログラムの実行中
不必要なオブジェクトの領域が確保されていても気にしなさそう。

575 ：デフォルトの名無しさん：2014/12/06(土) 11:47:15.03 ID:dmb0kXdE

なぜメモリを静的にではなく動的に確保するのか？の本来の目的を考えれば
自ずと答えは出る

576 ：デフォルトの名無しさん：2014/12/06(土) 12:31:58.16 ID:ui+tbMEF

オブジェクトの寿命を意識するってのは、プログラム開始してから終了するまでの
どの期間存在するかを常に意識しろということなのかね。
プログラムの構造化によって生存区間を限定し、不要になった時点で破棄することで
大域的な知識によらずに安全に使用リソースの最小化を図るという考え方が理解できない
原始時代の人なんだろうか。
そういう人は少なくとも関数内でmalloc/freeを使うべきじゃないな。

577 ：デフォルトの名無しさん：2014/12/06(土) 12:50:41.02 ID:JydoFUaV

大域的な知識を基に最適化するのはむしろ今のトレンドだけど

オブジェクトの生存期間を意識し、場合によってはfreeしないことで
プログラムの性能を向上させる話でしょ？
cpやword2vecの例は

578 ：デフォルトの名無しさん：2014/12/06(土) 14:49:24.53 ID:ui+tbMEF

自動化ないしは意識せずにできるようにするのはな。
プログラマ自身がしこしこやるのがいったいどこのトレンドだよw

579 ：デフォルトの名無しさん：2014/12/06(土) 15:42:19.80 ID:dmb0kXdE

そういうやつは、スレチだがgcつかっとけよもう

580 ：デフォルトの名無しさん：2014/12/06(土) 18:25:26.31 ID:dOSwxHPK

cpやword2vecを書くようなプログラマと
その辺で業務システム書いてるドカタを
同じ土俵で論じるのが間違い

581 ：574：2014/12/06(土) 19:13:16.22 ID:Khx/zTiJ

>>576

>> 不要になった時点で破棄

まさしくそれ、
不要になったと判明した時点で速やかに破棄というのが大前提。

free絶対派はその意識が乏しいんじゃないかと。
なんとなくmallocとfreeは対でなければいけないから漫然と
freeしているだけなんじゃないかと。

上記のJaneの例なら
画像を破棄したらその画像で使用した領域はその時点でfree
スレッドを破棄したら、それに使った領域はその時点でfree

word2vecは入力した文書の統計情報は最後まで利用する
--> 破棄されることがないので、freeする必要がない

582 ：デフォルトの名無しさん：2014/12/06(土) 19:41:46.07 ID:ui+tbMEF

それ「最後まで利用」じゃなくて、利用終了時点の判断をネグってるだけ。

583 ：デフォルトの名無しさん：2014/12/06(土) 19:46:54.04 ID:ADt2fRJM

プロセスが確保したメモリは、プロセスを終了させても解放されず、
解放するにはコンピュータの再起動が必要となるOSが昔あったなあ。
バグではなく、OSの正規の仕様として。OSの名前忘れたけど。

そんな仕様じゃメモリをいくら積んでも足りないし、連続稼動できないじゃん！

・・・という各方面からの否定的な評価に対し、そのOSの設計者は
「メモリを十分に積まないのが問題」「定期的にリブートすればいいこと」
「メモリ資源の再利用をOSに任せようとするアプリケーション開発者の手抜き」
のようにOS側の問題ではないと一蹴してて、その主張に一理あるということで、
当時はちょっと衝撃を受けたわ。

malloc したものを free することには合理性があるけど。
その価値観に対抗するようなOS設計哲学も存在するということで。
何が正しいのか、唯一の結論を出すのは、なかなか難しいかもねえ（＾o＾）ﾉ

584 ：デフォルトの名無しさん：2014/12/06(土) 20:01:10.98 ID:5oGFUyw+

UnixのSIGKILLみたいに問答無用でプロセスが殺されたりせずに、後始末の作業が
できることがシステム全体として保証されてるなら通る理屈だけど、どうせそのような
仕掛けがあるわけじゃないだろうなw

585 ：デフォルトの名無しさん：2014/12/06(土) 22:06:14.90 ID:Iv1q4dyj

>>581
だからさぁ・・・それをfree不要とは言わないでしょ。
freeしない領域も実質プログラムの終了でfreeを代用してるだけだし、
プログラマの意図としてはfreeすべき場所を把握できているケース。
このスレはfreeも満足に使えないくせにfree不要とか言っちゃう馬鹿を断罪するスレなんだよ。

なんでそこまでして「free不要論は間違い」をfree必須教みたいに扱って敵視してんの？
発端のfree不要とか言っちゃった馬鹿が知恵つけながら粘ってるようでヤなんだけど。

>>584
そこまで行くとkillするAPIも無いとかkillする側が責任持つべきとかになるんじゃね。

586 ：デフォルトの名無しさん：2014/12/06(土) 22:10:57.01 ID:jRYa77lH

プログラムの最初から最後まで領域を優先するようなメモリはStatic使うべし。
MallocはFreeされるべき。

587 ：デフォルトの名無しさん：2014/12/06(土) 22:51:56.38 ID:dmb0kXdE

途中でfreeしてメモリを効率よく使えるようmallocするんじゃないんかと…

588 ：デフォルトの名無しさん：2014/12/06(土) 23:09:29.33 ID:jRYa77lH

Malloc自体は遅いんだよ。
Freeしなかったら蓄積してって確保できなくなるぞ。
まぁ、最近のコンピュータで困るかはわからん。

589 ：デフォルトの名無しさん：2014/12/06(土) 23:29:03.74 ID:5oGFUyw+

GCを前提としたmallocだと、極端な奴ではポインタずらして管理情報をちょこっと書くだけ、
って場合もあるけどなw

590 ：デフォルトの名無しさん：2014/12/06(土) 23:32:11.16 ID:jRYa77lH

なにそのオレオレライブラリ。

591 ：デフォルトの名無しさん：2014/12/07(日) 00:10:44.64 ID:T0oVgQBw

mallocしたメモリをGCしてくれるわけねーだろｗ

そういうやつはC++ならせめてgcnewくらい使え

592 ：デフォルトの名無しさん：2014/12/07(日) 05:38:55.41 ID:LVeISVsO

これが fopen() / fclose()、低水準なら open()/close() の話だったりすると、
プロセス終了時にオープンされているものは OS がクローズしてくれるものにもかかわらず、
「プログラム終了時の fclose() を省略しないやつは糞」というのはあまりきかないね…
ま 10万20万と fopen() するわけではないからね…

593 ：デフォルトの名無しさん：2014/12/07(日) 09:22:07.16 ID:T0oVgQBw

つーか、終了時のメモリ開放処理程度をめんどくさいとか言うやつは
もうプログラマなんか向いてねーからやめちまえよ

594 ：デフォルトの名無しさん：2014/12/07(日) 09:40:05.22 ID:r6DD4JyZ

>>593
プログラマがめんどくさいだけならいいけど、
ユーザーが遅さを体感することになるからな
ユーザビリティの観点からもプロセス終了時の明示的メモリ解放はやめるべきだ

595 ：デフォルトの名無しさん：2014/12/07(日) 09:50:23.92 ID:SIYxuRDn

>>592
「俺はmallocとfreeを使える」って所で学習が止まってしまっていて、そこまで到達したことだけが
心の支え、というオワコンプログラマが多いのさ。

596 ：デフォルトの名無しさん：2014/12/07(日) 10:04:52.37 ID:ekuZw6uY

最近のシステムではないと思うけど、ファイルの場合は排他ロックしたらシェルから見てデッドロックしたりするので解放しないという選択肢はないはず。

597 ：デフォルトの名無しさん：2014/12/07(日) 10:13:48.44 ID:RIZYWRwW

昔はOSの設計上、同時に開けるファイルハンドル数に厳しい制限があった
今はほぼ制限なしに等しくプロセス外にまで支障をきたすほどたくさんファイルを開くシステムも稀
プロセス間で同じファイルを扱うケースも実際には少ない

598 ：デフォルトの名無しさん：2014/12/07(日) 10:45:17.82 ID:mrRmmrII

たしかに MS-DOS でも1プロセス20までだったか、プロセスメモリマップにもそういうテーブルがあったね

599 ：デフォルトの名無しさん：2014/12/07(日) 10:52:54.31 ID:mrRmmrII

>>595
たしかに、きっちり malloc() と free() を対応させる技術がなく、当然必要がなくなった時点でさっさと free() することもできない、したがって free() しなくともよい判断は到底不可能という、頭の可哀相な >>558 もいることだし

600 ：デフォルトの名無しさん：2014/12/07(日) 11:05:32.98 ID:SIYxuRDn

ファイルロックの方法によるのにあっさり決めつけてしまってるあたりが、
全くわかってないことを露呈していて趣き深い。

601 ：デフォルトの名無しさん：2014/12/07(日) 13:04:46.31 ID:UwBbHZ64

ちょっとしたgcぐらい、自分で作れよ
gcnew?知るかそんなの

602 ：デフォルトの名無しさん：2014/12/08(月) 10:37:40.97 ID:SJ/ip5mJ

日本主記憶解放戦線。

603 ：デフォルトの名無しさん：2014/12/08(月) 17:49:26.49 ID:3czqE9B9

>>602
こまめにmallocしまくって自滅フラグｗ

604 ：デフォルトの名無しさん：2014/12/08(月) 18:30:17.91 ID:SJ/ip5mJ

我々はすべての主記憶を解放するまで戦い続ける。

解放すると遅い。
それは設計あるいは使用範囲が間違っているのである。

適宜開放することにより、誤りに気付く機会が与えられる。
すなわち、確保した記憶域は必ず解放されねばならない。

（主記憶解放戦線憲章より引用）

605 ：デフォルトの名無しさん：2014/12/08(月) 19:03:22.56 ID:WiG9aNiK

ムダにかっこいい系

606 ：デフォルトの名無しさん：2014/12/08(月) 22:23:08.00 ID:m6wBRCkx

>>603
こまめに free() することにどんな自滅パターンがあるというのか？お前も頭の可哀相な >>558 の同類か？

607 ：デフォルトの名無しさん：2014/12/09(火) 08:32:16.30 ID:LA65v/8c

>>593
終了時の開放は別に無くても良いと思う。

勿論反復ルーチンでは都度開放しないといずれ枯渇するから開放は当然。
GC無くても如何なる場合も開放不要、みたいな意見には賛成できない。

要はケースバイケース

608 ：デフォルトの名無しさん：2014/12/09(火) 12:52:12.55 ID:i9BKJ0vK

>>607
貴様は己の能力を過信しすぎている。

必ず解放しろ。
いいな、これは命令だ。

609 ： ◆QZaw55cn4c ：2014/12/09(火) 21:46:06.18 ID:jdnBb/7K

信者召喚ｗｗ

610 ：デフォルトの名無しさん：2014/12/09(火) 23:34:43.57 ID:i9BKJ0vK

計算指示書作成手順において、記憶域解放が省略されてはならない。

それは省略ではなく手抜きである。

少々の手抜きが計算指示全体に悪影響を及ぼすことがある。
心して作成せよ。

611 ：デフォルトの名無しさん：2014/12/10(水) 00:33:13.98 ID:Deu5ogie

サッカースタジアムは、
客がはけた後には必ず掃除されるんだから、
サポーターがゴミ拾いをする必要はない。

612 ：デフォルトの名無しさん：2014/12/10(水) 00:37:51.16 ID:8C/H0+A2

しかし同じ日に繰り返し何試合もやったら次第に人のいる場所がなくなるだろ

613 ：デフォルトの名無しさん：2014/12/10(水) 06:13:48.75 ID:115BiRn2

>>ID:i9BKJ0vK
はっはー。サタンサマー。

614 ：デフォルトの名無しさん：2014/12/13(土) 00:20:32.42 ID:pBf+dW7w

組込ソフトウェアでfreeしなかったら、起動してネットワーク接続したら3分と持たずにフリーズするかメモリ枯渇エラーのログ吐きまくるわ

615 ：デフォルトの名無しさん：2014/12/15(月) 15:05:28.38 ID:ZETjn4CW

俺の知っている、という枕詞が省略されている典型例やな

616 ：デフォルトの名無しさん：2014/12/27(土) 16:11:44.99 ID:9Rxt26Ql

free要る派
→自分でしたうんこは自分で流す派

free要らない派
→うんこしたけど、この便所二度と来ることないから俺シラネ
便所の管理人が勝手に掃除してくれるんじゃね？

と考えると、俺は断然free要る派となる

617 ：デフォルトの名無しさん：2014/12/29(月) 20:47:20.01 ID:KuYXSH39

>>616
流すまでその便所は他の人が使えないわけだが、管理人が来ないまま使える空き便所が無尽蔵にあるという前提が必要だな

618 ：デフォルトの名無しさん：2014/12/29(月) 20:53:22.95 ID:/sLHpawi

それが無尽蔵にないからswap地獄に陥るんじゃないか。

619 ：デフォルトの名無しさん：2014/12/29(月) 21:06:56.82 ID:KuYXSH39

管理人がやって来る明確な規則がイマイチわからなくて気持ち悪い

620 ：デフォルトの名無しさん：2014/12/29(月) 21:14:34.42 ID:bj0t/8Ju

大抵は「管理人仕事しろボタン」があるだろ

621 ：デフォルトの名無しさん：2015/02/06(金) 01:41:27.81 ID:b3gwE4qm

>>553
＞信者信者言うのは
自称だと思うよ
絶対というわけではなく細かい点で要不要が議論されることはあるからね

622 ：デフォルトの名無しさん：2015/02/21(土) 23:49:31.87 ID:mk77xCMU

fj.comp.lang.c++
Malloc and Free
https://groups.google.com/forum/m/#!msg/fj.comp.lang.c++/G4HRnHTdImg/pTgn9kQaMCoJ

623 ：デフォルトの名無しさん：2015/02/22(日) 21:10:43.75 ID:XKkbsrmM

>>622
懐かしい、あれから 15年かぁ

624 ：デフォルトの名無しさん：2015/02/24(火) 00:46:11.63 ID:oRO5M8st

けっこう最近（？）の話なんだ‥面子的に1990年～1995年くらいかと思っていた

625 ：デフォルトの名無しさん：2015/02/24(火) 00:57:46.90 ID:zk/7dheO

>>624
Qちゃんfjに参加してたの？
QちゃんC/C++宿題スレで勉強始めたような28才くらいの若者かと思ってたけど（煽り抜き）
意外と古くからML読んでたりしてたの？
おどろき

626 ：デフォルトの名無しさん：2015/02/24(火) 01:14:22.05 ID:oRO5M8st

>>625
＞C/C++宿題スレで勉強始めたような
この部分は当たり他ははずれ
もう7, 8年くらいにはなるな‥
成長が遅いのは頭が悪いせいから仕方がない

627 ：デフォルトの名無しさん：2015/02/24(火) 13:58:34.87 ID:T1wlJW1m

15年経っても同じような屁理屈をこねる者がいるというのは感慨深い