C言語の話題のみ取り扱います。C++の話題はC++スレへ。
上級者専用です。10,000行程度のソースを扱えない人は以下スレへ。
C言語なら俺に聞け
https://mevius.5ch.net/test/read.cgi/tech/1519046038/
適宜以下を使用してください。
https://paiza.io/
https://ideone.com/
http://codepad.org/
C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf
C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html
C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/
JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
C言語相談室(上級者専用)
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん (ワッチョイ 139f-Cjmv)
2018/03/02(金) 22:48:03.65ID:2Cs+DkMh0102デフォルトの名無しさん (ワッチョイ 954f-kiUO)
2018/08/26(日) 21:06:39.43ID:ik1BtrwR0 >>99
サイズの問題がないのならallocaを使うことに問題はない。
mallocより遅くなる理由もないので。
ただ、普通に組めば分かるが、
> malloc や free を多発させる
ってのがあり得ない。
仮にこれがallocaで有効に代用出来るとするなら、再帰下降パーサ等、「再帰」が必要になるが、
再帰下降パーサの場合はインミュータブルでよく、元の文書をオフセット付きで参考して終わりだ。
再びallocaすることはない。
同様に、ループでパースするのなら、ループの外でmallocして十分な領域を確保し、
そこに上書きで使うことになる。だからmalloc/freeは1回ずつで済む。
もう一度言うが、allocaはスタックだから、「再帰」しないと領域を追加出来ない。
この使い方は普通無いし、君もやって無いと思うよ。
でも、普通のmallocを全部allocaで代用しても、サイズ以外の問題は無いから、可能ならそれでもいい。
サイズの問題がないのならallocaを使うことに問題はない。
mallocより遅くなる理由もないので。
ただ、普通に組めば分かるが、
> malloc や free を多発させる
ってのがあり得ない。
仮にこれがallocaで有効に代用出来るとするなら、再帰下降パーサ等、「再帰」が必要になるが、
再帰下降パーサの場合はインミュータブルでよく、元の文書をオフセット付きで参考して終わりだ。
再びallocaすることはない。
同様に、ループでパースするのなら、ループの外でmallocして十分な領域を確保し、
そこに上書きで使うことになる。だからmalloc/freeは1回ずつで済む。
もう一度言うが、allocaはスタックだから、「再帰」しないと領域を追加出来ない。
この使い方は普通無いし、君もやって無いと思うよ。
でも、普通のmallocを全部allocaで代用しても、サイズ以外の問題は無いから、可能ならそれでもいい。
103デフォルトの名無しさん (ワッチョイ 954f-kiUO)
2018/08/26(日) 21:08:26.06ID:ik1BtrwR0 > alloca は SP をズラすだけの非常に高速な実装になってるんじゃないかと想像してるから
これはその通り。
> 最初から論理最大サイズ固定のバッファで良くね?
これもその通り。上記ループなら普通これで行く。
それがスタック上で問題になるサイズならmalloc/freeが1回ずつ必要になる。
だから君の今の実装>>75もさほど悪いわけでもない。
今風の「実装を外に漏らさない」方針なら子関数でmalloc/freeやallocaすることになる。
おそらくそれで考えているのだと思うが、元々のCの思想はそれとは違い、
char* buff = (char*)malloc( ... ); // または char buff[2048]; 等
while (....) {
parse_func(buff, .... );
}
free(buff);
として外側で確保し、それをparse_funcに渡す。
これにより、変数の寿命とスタックの動作を一致させ、freeし忘れもなくなる。
この方法だと、allocaで毎回「SP をズラすだけ」すらする必要なく、parse_func内は最速になる。
(allocaを毎回繰り返すよりも速い)
これはその通り。
> 最初から論理最大サイズ固定のバッファで良くね?
これもその通り。上記ループなら普通これで行く。
それがスタック上で問題になるサイズならmalloc/freeが1回ずつ必要になる。
だから君の今の実装>>75もさほど悪いわけでもない。
今風の「実装を外に漏らさない」方針なら子関数でmalloc/freeやallocaすることになる。
おそらくそれで考えているのだと思うが、元々のCの思想はそれとは違い、
char* buff = (char*)malloc( ... ); // または char buff[2048]; 等
while (....) {
parse_func(buff, .... );
}
free(buff);
として外側で確保し、それをparse_funcに渡す。
これにより、変数の寿命とスタックの動作を一致させ、freeし忘れもなくなる。
この方法だと、allocaで毎回「SP をズラすだけ」すらする必要なく、parse_func内は最速になる。
(allocaを毎回繰り返すよりも速い)
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【地震速報】青森県で震度6強 沿岸部に津波警報 ★4 [ぐれ★]
- 【速報】高市総理が官邸入り [Hitzeschleier★]
- 「日の丸にバツ印」掲げた大学生 あいまいな国旗損壊罪に「怖い」 The Mainichi [少考さん★]
- 高市内閣「支持」64%「不支持」19% NHK世論調査 ★2 [少考さん★]
- 【芸能】岡田紗佳、新幹線でありえない迷惑客に遭遇 自分の席に荷物が「ここ私の席ですって言っても…」 [冬月記者★]
- 【音楽】BARBEE BOYS・KONTAが事故で四肢麻痺を公表、新体制で活動は継続 [少考さん★]
- ぺこーら、地震で同僚が次々配信を止めるなか強行し続けるので悪目立ちするwww [268244553]
- 巨大地震 [957955821]
- 【速報】高市早苗、起床 [779938112]
- 早く世界滅べ
- つるの剛士「名古屋も揺れています。とにかく慌てずに落ち着いて行動しましょう!」 [594040874]
- 青森・東北町で陥没した道路に車が転落 [256556981]
