トップページ⇒tech
986コメント256KB

C言語のことは<46>

■ このスレッドは過去ログ倉庫に格納されています
0001激しく未定義とするNGNG
まず問題を冷静に吟味してCの話か否かをはっきりさせてから質問しろ。
むしろ質問する前にWEBで検索するのが常識だ。

GUIなどの標準Cではできない事の質問は使用している開発環境のスレへ行け。
ソース丸投げ、宿題、書籍 は専門の別スレがあるのでそこへ行け。

コンパイラを探しているなら >>2 を見よ。

上記を逸した場合の結果は激しく未定義とする。

C FAQ 日本語訳
http://www.catnet.ne.jp/kouno/c_faq/c_faq.html
Cプログラマ必読 ・プログラミング言語C(通称　K&R)
http://www.amazon.co.jp/exec/obidos/ASIN/4320026926/

前スレ
http://pc3.2ch.net/test/read.cgi/tech/1038405432/
0153デフォルトの名無しさんNGNG
>>151
禿げ
0154デフォルトの名無しさんNGNG
>>151-152
エラーチェックとエラーハンドリングは別物ということを理解してるか ?
0155デフォルトの名無しさんNGNG
>>154
ネタですか？
0156デフォルトの名無しさんNGNG
>>155
理解できてない奴、一匹目。
0157デフォルトの名無しさんNGNG
あさしゃんを夜にする時点で間違っている。
0158デフォルトの名無しさんNGNG
>>157
あさしゃんは夜にできないだろ…
0159デフォルトの名無しさんNGNG
>>155
いいえ、シャリです。
0160デフォルトの名無しさんNGNG
>>157
夜にする あさしゃん って...。
0161デフォルトの名無しさんNGNG
>>151 >>152 >>154
知ったかぶらないでちゃんと説明しろ。
0162デフォルトの名無しさんNGNG
>>161
教えを乞う者の態度とは思えんが・・・。

エラーハンドリングは、プログラムの仕様だ。
プログラムの実行時に発生する可能性がある異常値をあらかじめ想定して、捕捉し、
それに応じた復帰／終了処理をする。

アサーションは、プログラムが仕様／意図通りに動いているかどうかを確かめるものだ。
エラーハンドリング漏れや論理エラー等の、プログラムの実行時に許容できない異常値を
捕捉する。
仕様／意図通りに動いている事が確認できればそれはもう必要無いので、リリースビルド
には含めない。

エラーハンドリングは仕様書に現われる、アサーションは現われない。
0163154NGNG
>>161
エラーチェック: エラー状態かテストすること。
エラーハンドリング: エラー状態時にしかるべき処理を行うこと。

ASSERT() が行うのは、エラーハンドリングの方。
だから、>>151 がなに言ってるか俺にはさっぱりわからん。
0164デフォルトの名無しさんNGNG
>>163
assert()は「しかるべき処理」は行わないだろ。
少なくともユーザから見た場合。
0165デフォルトの名無しさんNGNG
>>162
それで具体的にどういうものがエラーハンドリングになってどういうものがアサーションになるのだ？
0166名無しさん＠ＸＥｍａｃｓNGNG
>>162
なんでこの人はエラーチェックをエラーハンドリングに脳内変換してるの？
0167デフォルトの名無しさんNGNG
>>166
どのへんがそうなのか教えてくれないか？
0168デフォルトの名無しさんNGNG
>>162
ASSERT() マクロにも仕様と言うものがあることを知らんのか ?
ちなみに、リリースビルドでも同じような動作をする VERIFY() マクロもあるぞ。

>>164
プログラマから見たときの話に決まってるだろ。
元々発生しないと思っているんだからさ。
0169デフォルトの名無しさんNGNG
>>165
アサーションは、仕様通りに動いていれば本来必要の無いチェックをする。
例えば、リンクリストの意図しないリンク切れとか。
もともとアサーションはまともなデバッガが無い時代のものだから、今使う事は
あまり無いはず。

エラーハンドリングは、例えばファイルが開けなかったとか、実行時に起こり得る
ものをトラップする。
0170デフォルトの名無しさんNGNG
> ASSERT() マクロにも仕様と言うものがあることを知らんのか ?

は？
0171デフォルトの名無しさんNGNG
>>168
VERIFY() なんての C にあった？
0172165NGNG
俺がどちらを使うかはっきりしている場合をあげておく。

コンポーネントやライブラリなどの関数・メソッド内での
引数のチェックにはアサーションを使ってはならない。

コンポーネントやライブラリなどの関数・メソッドを呼び出す前の
引数のチェックにはアサーションを使う。
0173デフォルトの名無しさんNGNG
> アサーションは、仕様通りに動いていれば本来必要の無いチェックをする。

配列境界のチェックなんてのもあるな。
0174デフォルトの名無しさんNGNG
> コンポーネントやライブラリなどの関数・メソッドを呼び出す前の
> 引数のチェックにはアサーションを使う。

引数をチェックするという仕様がプログラムに求められているなら、その場合は
アサーションを使ってはならない。
0175名無しさん＠ＸＥｍａｃｓNGNG
この議論の原点って>>146だよね？
エラーハンドリングは>>151が勝手に持ち出した話だろ？
0176名無しさん＠ＸＥｍａｃｓNGNG
>>174
もう少しよく読んだら？
0177デフォルトの名無しさんNGNG
>>170
規格書ぐらい読めよ。どう言う処置をするかが書いてあるよ。

>>171
> VERIFY() なんての C にあった？
ごめんよ、ANSI-C にはなさそう。VC++ の方言のようだ。
0178デフォルトの名無しさんNGNG
>>172
理由は ?
0179デフォルトの名無しさんNGNG
つまり、アサーションってのはプログラム実行時にブレークして
「えっとこの時点ではこの変数はこうなっているはずだよなぁ」って
確認するような感じに使うってことでいい？
引数のチェックに使うのはもってのほかなんだね。
0180165NGNG
>>178
アサーション使ってリリース時にアサーションが消えている状態で
コンポーネントやライブラリが不正な引数で呼び出されたら困るだろ。
0181デフォルトの名無しさんNGNG
>>176
もう少しくわしく書こうか？
関数・メソッドを呼び出す引数をチェックするという仕様がプログラムに
求められているなら、その場合はアサーションを使ってはならない。

>>179
正解。
0182デフォルトの名無しさんNGNG
>>179
そりゃブレークポイント。
(そう言えば、>>169 も、「もともとアサーションはまともなデバッガが無い時代のものだから」とかほざいてたな...。こんな香具師ばかりかよ...。)

一応意図は >>162 の...
> アサーションは、プログラムが仕様／意図通りに動いているかどうかを確かめるものだ。
> エラーハンドリング漏れや論理エラー等の、プログラムの実行時に許容できない異常値を捕捉する。

で合ってると思う。(ただしここだけね。)
0183デフォルトの名無しさんNGNG
> コンポーネントやライブラリが不正な引数で呼び出されたら困るだろ。

そういう論理エラーはデバッグの段階で完全に取り除いとけ。
アサーションはそのためにある。
0184デフォルトの名無しさんNGNG
182 も、アサーションが何故リリースビルドで消えるか理解していない一人か・・・
0185名無しさん＠ＸＥｍａｃｓNGNG
>>181
>コンポーネントやライブラリなどの関数・メソッド内での
>引数のチェックにはアサーションを使ってはならない。
当然これが守られてる場合の話だろ？
2重にチェックする気？
0186デフォルトの名無しさんNGNG
>>179
禿同。何のために、デバッグしてんだよ。

でも、実際にそう言う状況があるから、>>135 みたいな話が出てくるんだろ。
0187デフォルトの名無しさんNGNG
>>185
すまん、あなたがどんな主張を持っていて、どのレスをどう解釈してそう逝っているのか
わかんなくなってきたよ。
0188186NGNG
>>186
すまん、>>179 じゃねーや。

>>183
> 禿同。何のために、デバッグしてんだよ。
> でも、実際にそう言う状況があるから、>>135 みたいな話が出てくるんだろ。

だったよ。
0189デフォルトの名無しさんNGNG
>>184
理由は ?

(あー、ウザイ。ちゃんと理由も一緒に書けよ。)
0190デフォルトの名無しさんNGNG
「完全にデバッグする｣なんてできるわけがねぇだろｱﾌｫ（ｗ
0191名無しさん＠ＸＥｍａｃｓNGNG
>>183
ライブラリ作る側の話でしょ？
ライブラリのユーザがライブラリ関数をおかしな引数で呼び出しても
暴走しないようにしとくのが普通じゃない？

>>187
>>172 とだいたい同じだと思う。
ライブラリ関数の中で、渡された引数をチェックするのにはassertは使わない。
ライブラリ関数に渡した引数がおかしな値になってないかを確認するのにはassertを使う。
0192デフォルトの名無しさんNGNG
>>189
論拠はこれ。

> 「もともとアサーションはまともなデバッガが無い時代のものだから」とか
> ほざいてたな...。こんな香具師ばかりかよ...。)
0193名無しさん＠ＸＥｍａｃｓNGNG
あ >>191 の最後
s/渡した/渡す/

てか実際はassertなんか使わないので>>192にも同意。
0194デフォルトの名無しさんNGNG
>>191
だから、呼ばれる側じゃなくて、呼ぶ側でちゃんとデバッグしておけって話だろう。
0195デフォルトの名無しさんNGNG
>>192
これがどうかしたか ? デバッガとアサーションって用途が違うぞ。
0196デフォルトの名無しさんNGNG
195 は、アサーションはデバッグのためにするものだという事を知らないのか？
0197デフォルトの名無しさんNGNG
>>194
だから呼ばれる側はアサーションを使わないでエラーにしろって。
動作が正しく行われるのをモニタリングするため使うのがアサーションで
呼ぶ側で追加でやる処理だろ。
0198デフォルトの名無しさんNGNG
0199デフォルトの名無しさんNGNG
んで、アサーションに引っかかるようなバグが
最終製品で残ってたとき、-DNDEBUGしてあると
何がうれしいんだ？
0200名無しさん＠ＸＥｍａｃｓNGNG
>>199
アサーションに引かかったらデバグするでしょ普通。。。
0201デフォルトの名無しさんNGNG
バグの究明が早くなる。
0202デフォルトの名無しさんNGNG
>>200
「全部バグが取りきれた｣という保証は永遠に得られないだろ？
0203デフォルトの名無しさんNGNG
>>201
「遅くなる｣の間違いだろ。
0204デフォルトの名無しさんNGNG
>>196
> 195 は、アサーションはデバッグのためにするものだという事を知らないのか？

お前アフォだろ ?

アサーションはデバッグのためにする。
デバッガもデバッグのために使う。

だから、デバッガがあればアサーションは要らないって言うのか ?

お前のデバッガは、引数の範囲とかをちゃんと理解して要所要所で、エラーチェックしてくれんのか ?
そんなデバッガがあるなら、俺も使いたいもんだよ。

>>197
状況による。呼ばれた側がいくらエラーを返していても呼び出し側が見てなきゃ何にもならない。
また、呼び出しが非常にたくさんあるなら、呼ばれた側でチェックする方が簡単。
0205名無しさん＠ＸＥｍａｃｓNGNG
>>202
そらそうだ。実際に製品として出回ってるソフトにもバグ残ってるのは
いくらでもあるよ。Windows2000も出荷時に6000ものバグ抱えてたって言うしね。
0206デフォルトの名無しさんNGNG
>>203
アサーション入れてもデバッグの助けにならないというなら
入れないほうがいいじゃん。
0207デフォルトの名無しさんNGNG
>>202
そこはそれ、豊富な経験・勘と.... 「日程」が背中を押してくれるんですよ。(w
0208デフォルトの名無しさんNGNG
>>138のホーアの言葉は、配列の添え字チェック
（Pascalだと、コンパイラオプションでon/offできるものが多かった）
の事だが、アサーションでもまあ同じ。
エラーハンドリングの話じゃないよ。
0209デフォルトの名無しさんNGNG
Windows のバグはアサーションで検知できる種類のものじゃないだろう・・・
0210デフォルトの名無しさんNGNG
うちではリリース版にもアサーション生かしてあるし、
デバッグ用シンボルつけてあるし、
コアダンプを保存するようにしてある。

Netscapeだと、「クォリティフィードバック」と呼んでいるし、
他の製品でもまあよくあるよね。
昔のMS-Cだと、よく「Compiler Internal Error」ってのを見たな。
0211デフォルトの名無しさんNGNG
>>204
> 状況による。呼ばれた側がいくらエラーを返していても呼び出し側が見てなきゃ何にもならない。
当たり前だ。呼び出し側にバグがあるんだから呼び出し側のチェック体制を強化しろよ。アサーションでも入れて。

> また、呼び出しが非常にたくさんあるなら、呼ばれた側でチェックする方が簡単。
簡単だからそっちでやるとかそういう問題じゃないだろ。
簡単だからという理由だけなら手抜きと一緒だぞ。
0212デフォルトの名無しさんNGNG
>>209
もちろん、すべてのバグがアサーションで検知できるわけではないが、
もともと誰もそんなことを主張してはいない。
0213デフォルトの名無しさんNGNG
>>211
呼び出される側にアサーション入れるのでは駄目なの？
0214デフォルトの名無しさんNGNG
> また、呼び出しが非常にたくさんあるなら、呼ばれた側でチェックする方が簡単。

アサーションは普通、どこで捕捉したかが重要だから呼び出し側でやるべきだと思うが・・・
0215デフォルトの名無しさんNGNG
>>212
(ﾟДﾟ)ﾊｧ?
じゃ、205 はどういう意味なの？
0216名無しさん＠ＸＥｍａｃｓNGNG
>>211
あのね。ライブラリとかだと呼び出す側が
厨房プログラマーだったりするかもしれないでしょ？
ほんとに分かんないのかな？それともネタ？
0217デフォルトの名無しさんNGNG
>>211
> 簡単だからという理由だけなら手抜きと一緒だぞ。

同じことが出来るんだったら簡単な方を選ぶよ。どこが手抜だ ?

1000個所から呼ばれてたら、1000個所にいちいち ASSERT() かますわけね。
はっきり言ってバカみたいだよ。
0218デフォルトの名無しさんNGNG
>>214
コアダンプの結果見れば、どこから呼び出されたかは分かるだろ。
Winじゃpost-motem debugってできないの？
0219デフォルトの名無しさんNGNG
>>213
もし呼び出され側がプログラム全体の呼び出される条件をすべてテストしており
これからの将来それが変更されないのならいいかもしれんね。
0220デフォルトの名無しさんNGNG
>>217
foo()の呼び出しをassert込みでマクロ定義すればよい。
0221デフォルトの名無しさんNGNG
>>217
同じことが出来るならね。だが同じことは出来ない。
0222デフォルトの名無しさんNGNG
ところで、この中で
「製品版でもアサーションは生かしておくべし｣
に反対してるやつってまだいるの？
0223名無しさん＠ＸＥｍａｃｓNGNG
>>215
>>205は>>202に対するレス。
バグが残ってる可能性があるからといってassertを残しておいたってあまり意味ないってこと。
本当に最後まで見付からないようなバグはassertでは捉えられないんだから。
0224デフォルトの名無しさんNGNG
>>206
-DNDEBUGすると「アサーションは何も検査しなくなる｣んだけど？
0225デフォルトの名無しさんNGNG
>>223
捉えられないとも限らないだろう。
「あまり」意味は無いかもしれないが、
取り除く意味はデバッグに関して言えば「全く｣無いだろう。
0226デフォルトの名無しさんNGNG
>>223
ああ、理解した。
0227デフォルトの名無しさんNGNG
>>223
それがなぜassertをわざわざ取り除く理由になるんだ?
0228デフォルトの名無しさんNGNG
>>220
ネタ ? 悪いけど、呼ばれた側でテストしてんのとどこが違う ? (ソース/オブジェクトとか言わないでね。)
それともマジで、ライブラリ中で引っかかっ時に、どこから呼ばれたか見方がわからんの ?

>>221
何ができないのか言ってみ。
0229名無しさん＠ＸＥｍａｃｓNGNG
>>225
いちいちチェックしてたら速度が落ちるでしょうが。
VC++とかでもdebug用とrelease用でコンパイルオプション変えれるでしょ？(。。。よね？)
デバッグのことだけ考えればいいんならこんな区別必要ないでしょうが。
0230デフォルトの名無しさんNGNG
>>228
assertに引っかかったとき表示される行番号が違う。
0231デフォルトの名無しさんNGNG
>>229
だから、そもそも「リリース用でコンパイルオプションを変えるのが間違い｣
というのが>>138の主張なのだが。
0232デフォルトの名無しさんNGNG
>>229
速度が落ちるなんて、せいぜい数十％だろ。
ハードの進歩で言って3か月分くらいか？
0233231NGNG
>>138じゃなくて
>>135ですた。
0234デフォルトの名無しさんNGNG
>>228
どんな環境でもコアダンプが利用できると主張したいわけね。
0235デフォルトの名無しさんNGNG
>>230
ぷぷっ、で、デバッグできないと...。
わかったわかった。お前は、一生そうしてな。
0236デフォルトの名無しさんNGNG

0237デフォルトの名無しさんNGNG
>>235
230じゃないけど、君の言うことがよく分からない。説明してくれる？
0238デフォルトの名無しさんNGNG
>>234
> どんな環境でもコアダンプが利用できると主張したいわけね。

まあ、できない環境もあるだろうね。
でもデバッガの環境下なら、呼び出し元ぐらいわからない ?
それもダメなら、しょうがないけどね。
0239デフォルトの名無しさんNGNG
実際、ネスケのQuality Feedback Agentが働く頻度を見れば、
出荷後でもアサーションに引っかかることはいくらでも
あると思うけど。
0240名無しさん＠ＸＥｍａｃｓNGNG
>>231
うーん私はそう思わない、としか言いようがないな。

>>232
同じ能力なら速度が早い方の製品を買うでしょ？

で、ライブラリ作る人間と使う人間は別(の可能性がある)ってのは
みんな分かってんのかなぁ？
0241デフォルトの名無しさんNGNG
Winでコアダンプみたいな死後デバッグやる方法ってある？
Dr. Watsonみたいのに頼るしかない？
0242デフォルトの名無しさんNGNG
>>237
>>238 にも書いたけど、普通のデバッグ環境なら、アサーションに引っかかった時に呼び出し元ぐらいはわかる仕組みはある。
デバッガの下にない時でも、Unix なら core, Windows ならデバッガのオンデマンド起動で呼び出し元がわかるはず。
組込みなんかのやや特殊な場合は、abort() とかでスタックダンプするとかが必要かもしれない。

と言うか、これぐらい理解してないとデバッグできないでしょ ?
0243デフォルトの名無しさんNGNG
>>240
135の主張をくつがえす充分な論拠をあなたは提供していないと
思います。アサーションを入れる場所にもよると思うけど、
私は数十％も速度が変わるとは思えない。せいぜい１０％以下でしょう。

たとえ数十％速くなったとしても、アサーションが無い場合に
エラーであることさえ気づかず黙って誤動作するソフトにしてしまう
（そしてそのバグが永久に発見されない）ような品質の低下が、
その数十％に見合うとは思えない。
0244デフォルトの名無しさんNGNG
>>241
Win は、アサーションした時に「デバッグするか ?」と聞かれるから、「はい」と答えると VC++ が起動して、それでデバッグする。
(>>242 のオンデマンド起動)
0245デフォルトの名無しさんNGNG
>>240
アサーションの速度差なんて、体感できないと思う。
0246デフォルトの名無しさんNGNG
>>244
うーん。じゃあ客先環境にもVC++をインストールしといて、
「はい」と答えてもらうの？
0247デフォルトの名無しさんNGNG
>>243
概ね同意するが、

> （そしてそのバグが永久に発見されない）ような品質の低下

これには同意できない。あと、

> その数十％に見合うとは思えない。

ゲームアプリの場合は、0.1 % でも重要な事が多い。
0248デフォルトの名無しさんNGNG
>>243
それは、難しい問題。
逆にアサーションがぼこぼこ出るようなソフトウェアが今後売れるとも思えない。
永久に発見されないバグは、問題無しと考えこともできるよ。
0249デフォルトの名無しさんNGNG
>>246
その時は、DrWatson を使えばよろし。
0250名無しさん＠ＸＥｍａｃｓNGNG
>>243
上にも書いたとおり、製品版のソフトにassertで捉えられるバグなんて
ほとんど残ってない(ようにしとかないといけない)わけで、それ以外の
バグの方が圧倒的に多いから、必ずしもassertを残しといたからって
安全性が上がるってものでもない。
当然速度との兼ね合いはトレードオフの話になるから、速度なんて
どーでもいい製品なら残しといてもいいと思うけどね。
0251デフォルトの名無しさんNGNG
>>248
ネスケはぼこぼこ出るよね。（QFA)
他のアプリは、アサーションは出ないけど「一般保護例外｣が出る（ｗ
0252デフォルトの名無しさんNGNG
>>246
つーか、客先環境でアサーションが出ること自体が問題かと...。
■ このスレッドは過去ログ倉庫に格納されています