第5章 復習

1. コンパイル　エラー、リンク　エラー、論理エラー、ランタイム　エラー
　コンパイルエラーは型エラーと構文エラーがある。機械語を作成する前に、コンパイラがプログラムを分析して検出する。先に進むためには、プログラムが
 言語の仕様に完全に準拠している必要がある。
  リンクエラーは、コンパイルエラーの後に検出される。
 関数を別のソースファイルで定義した場合、そのソースファイルから生成されたコードを呼び出す側にリンクしないとリンクエラーになる。
  ランタイムエラーはプログラムにコンパイルエラーとリンクエラーがないと判断されてプログラムが実行された後に検出されるエラーである。
 論理エラーは、プログラマ自身が不正な結果の原因を探った結果発見されるエラーのこと。期待した動作をしないことから判明する。
2. 誤動作しているハードウェアやソフトウェアによるエラー
3. エラーのない状態であることか、少なくとも容認できないほどのエラーがない状態であること。
4. (1)ソフトウェアの構造を整理すること。(2)デバッグとテスト通じてほとんどのエラーを取り除くこと。(3)深刻なエラーは残さないようにすること。
5. デバッグは、手間ばかりかかって時間を無駄にするプログラミングの側面であるから。
6. ()が対になっていないこと。{}がついになっていないこと。文字列リテラルの両端が""で囲まれていないこと。式文が;で締めくくられていないこと。
大文字、小文字の入力ミスがあること。
7. 宣言されていない関数を呼び出そうとしていること。関数の名前が間違っていること(一個目とおなじかな？)。関数に渡す引数の個数が一致しないこと。同じく引数の型が一致しないこと。
同じく渡す順序が一致していないこと。
8. 別のコードで定義してある関数を呼び出すとしているのにその別のコードをリンクしていない場合。関数が定義されている場合。
使用される翻訳単ごとで違う型で宣言されている場合。名前と型が全く同じでなければならない(同じこと二回言ってるかな。)。
宣言はいくつあってもよいが定義は1つでなければならない。
9. プログラマが意図したとおりに実行されないこと。プログラムが書いたとおりに実行されてはいるので発見が難しい。プログラムを書く段階でミスがあるか
変数がテストされないまま使われることで生まれてしまう。
　(1)インクリメントやデクリメントをし0になってしまった変数で割ること。(2)入力された値の中の最小値を求めるプログラムで変数があらかじめ
 0で初期化されていたために、実行後に0以下の数値が入力されないかぎり最小値が0のままであること。(3)書いたつもりのことが書かれていない場合。
10. しっかりと睡眠時間をとっていないことによる集中力の低下。勘違い。プログラムがしっかりと整理されていない。なにをしたいかをはっきり理解していない。
11. テストをする。正しい答えがどのようなものか、非常に大まかであっても見当をつけること。
12. 関数を呼び出す側でエラーを処理することは、通常関数がライブラリで定義されているなど、関数に直接手出しできない場合などに行われる。呼び出される関数で
エラーを処理しなかったことで、関数を呼び出す際に呼び出す側でのエラーの処理を忘れてしまうことがある。
13. 通常はエラーのために使用できる余分な戻り値はないから。
14. if(!cin)などを使用する(?)
15. //あらかじめ
    class bad_area{};
    //などと書いておいて
    int main()//のなかで
    try{
    
      throw bad_area;//などとthrowした場合に}
    catch(bad_area//ここでそれをcatchする){
        }
     のように使う。     
16. v.size()はそのベクターの要素の個数を教えてくれるが、ベクターのインデックスは0から
始まるために、最後の要素のインデックスは要素の個数よりも1少ない。
範囲エラーでプログラムが中止する。
17. 仕事で2時間働いた人には10分、3時間働いた人には20分の休憩を与える場面で、その休憩時間を引いた時間を求めるプログラム。
事前条件:拘束されている時間は、2時間以上3時間未満であるか、3時間以上であるか。
事後条件:拘束時間が2時間以上3時間未満の時10分引かれているか、3時間以上の時20分引かれているか。
18. 通常事前条件が明記されていない場合、考えられうるすべての値に対応するものとみなされるが、辞書の検索など、複雑すぎる場合は、
事前条件をチェックするのに関数の実行よりはるかに多くの作業が必要になってしまう。
19. 関数がめちゃくちゃ短い時だけ
20. デバッグの手順
    1プログラムを書き始める時点でデバッグのことを意識する。
    2コードを書き上げる
    3プログラムをコンパイルする
    4プログラムをリンクする
    5プログラムに想定されている作業を実行する
   3から5を何度も繰り返す
21. バグ探しにかかる時間を最小限におさえられる。コードをできるだけ単純に、論理的に、的確に保つのに役立つ。コード自体がプログラマが何を期待した
ものであるかわかるよう単純であることが最も重要だが、コメントを書くことでプログラマが何を期待してコードを書いたのかがさらにわかりやすくなる。
数行のコメントで、単純かつ正確に説明できないとしたら、おそらく自分が何をしているかについて理解が十分でない証拠である。
22. 体系的に選択された大量の入力を使ってプログラムを実行し結果が期待したものになるか比べる。