回答編集履歴
2
追記
test
CHANGED
|
@@ -19,3 +19,55 @@
|
|
|
19
19
|
|
|
20
20
|
|
|
21
21
|
コードを眺めただけで原因がわかる確率を上げるにはそれに応じた経験が必要です。コードを眺める必要がないとはいっていません。眺めることは必要ですがそれだけで解決できるは限らないということです。ソースを見てもわからなければ次にすべきはプログラムのデバッグです。デバッグにも経験は必要ですが、それがうまく行えないなら質問するより先にデバッグの経験を積むべきと思います。
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
追記：回答コメントを拝見すると、質問者さんはやはりデバッグをどうすべきか戸惑っている印象でした。それを解説したようなサイトをあまり見ないので少しデバッグのtipsめいたものをコメントしてみます。
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
###何を考えるべきか
|
|
32
|
+
|
|
33
|
+
ライブラリーの仕様やCの言語仕様などに充分な確信がない状態の段階ではソースを眺めるだけで原因を特定するのはまず無理です。なぜならバグが起こっている典型的な状況は「プログラマーのこう動くはずだという思い込み」に起因しているからです。「間違ったことを思い込んでいる」のですからそれに自分で気づけないのは当然です。
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
デバッグを学ぶ際には「自分がそうだと思っていること」を疑うことが肝心です。
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
例１： fscanfで読み込んだ結果はこうなるはず＝＞本当にそうか疑う
|
|
42
|
+
|
|
43
|
+
例２： strtokで1行に4つの要素を切り出せるはず＝＞本当にそうか疑う
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
###何を確認するか
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
疑うことができたならそれが実際にどうなっているかを確認します。デバッグプリントの利点は「こうなっているはず」という**推測**を「実際にそうなっている」という**事実**に変えられることです。
|
|
52
|
+
|
|
53
|
+
|
|
54
|
+
|
|
55
|
+
例１は実際にfscanfの結果をデバッグプリントすればはっきるするでしょう。場合によっては「行末の見えない空白文字」などに翻弄されることがあるでしょうから
|
|
56
|
+
|
|
57
|
+
`printf("%s\n", buffer);`ではなく、
|
|
58
|
+
|
|
59
|
+
`printf("'%s'\n", buffer);`とするなどの工夫も有効です。こうしたこともデバッグtipsの一つです。(だれでもデバッグに苦労した経験から、こうした工夫は自然に思いつくものです)
|
|
60
|
+
|
|
61
|
+
|
|
62
|
+
|
|
63
|
+
例２は「1つ目、2つ目、・・・の切り出し結果を全てデバッグプリントする」とヒントが得られるでしょう。4つトークンがあるはずという予測で例えば2つ目の切り出し結果が「あ！行末まで2つ目のトークンとして読み込まれてる！」といった具合に予想とは違っている事実がわかるからです。
|
|
64
|
+
|
|
65
|
+
|
|
66
|
+
|
|
67
|
+
こうして「こうなるはず」という点を一つ一つ確認するくせをつけてください。知識が充分でないうちは確認することも多く大変面倒なのですがその訓練さえ積めば、コードの内容により確信を持つことができるようになり自然にデバッグプリントの量も減り、最後にはまったくデバッグせずとも書いたコードが一発で動くようになっていきます。それは保証します。
|
|
68
|
+
|
|
69
|
+
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
こういうふうにデバッグをしても、「なぜそうなるかわからない」というこｔもあるでしょう。その場合にこそ「こうデバッグした結果、こういう事実がわかった。でもなぜかわからない」と質問しましょう。今の状態の質問よりはずっとアドバイスが得られやすくなるでしょう。
|
1
誤記訂正
test
CHANGED
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
13
|
-
そうした場合、やはり「デバッグプリントによる調査」のが必要になるでしょう。デバッグプリントを入れすぎると結果が大量に出すぎてこれまたわからなくなることもあります。そういう場合はさらに「デバッグプリントを出すタイミングを工夫する」といったことも必要かも知れませ。
|
|
13
|
+
そうした場合、やはり「デバッグプリントによる調査」のが必要になるでしょう。デバッグプリントを入れすぎると結果が大量に出すぎてこれまたわからなくなることもあります。そういう場合はさらに「デバッグプリントを出すタイミングを工夫する」といったことも必要かも知れません。
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
@@ -18,4 +18,4 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
コードを眺めただけで原因がわかる確率を
|
|
21
|
+
コードを眺めただけで原因がわかる確率を上げるにはそれに応じた経験が必要です。コードを眺める必要がないとはいっていません。眺めることは必要ですがそれだけで解決できるは限らないということです。ソースを見てもわからなければ次にすべきはプログラムのデバッグです。デバッグにも経験は必要ですが、それがうまく行えないなら質問するより先にデバッグの経験を積むべきと思います。
|