ストラウストラップのプログラミング入門(10) 第5章のつづき

『ストラウストラップのプログラミング入門』を読む。今日は、第5章の5.5から5.8まで。

第5章のテーマは「エラー」。

印象に残ったところ

エラーチェックの処理を書く場所

呼び出し側で描くか、呼び出される側で書くか、という問題。

次の説明は、呼び出される側の関数内部で、チェックできない、あるいは、しないケースの理由についての、分かりやすい説明だと思う。

関数での引数のチェックは簡単に思えるが、必ずしも行われないのはなぜか。
（中略）

関数定義を変更できない

呼び出される側の関数ではエラーが発生した場合にどうすればよいかわからない

呼び出される側の関数ではどこから呼び出されたのかわからない

パフォーマンス

# 本文には、それぞれの理由がもう少し詳しく書いてある。

より多くのプログラムによって、不特定の文脈で利用されるコードであればあるほど、この制約は大きくなるんだろうと思った。たとえば、ライブラリやフレームワークなど。

ランタイムエラー

ランタイムエラーを出してみようという呼びかけが本文に出てくるので、従った。

なんだこれ。

R6010

abort() has been caled

［再試行］ボタンを押すとクラッシュする。

エラーの詳細は、次のページにある…と思いきや、載ってない。

C Run-Time Errors R6002 through R6035 and Warning CRT1001 http://msdn.microsoft.com/en-us/library/6f8k7ad1.aspx

abortって、これかな。

abort http://msdn.microsoft.com/en-us/library/k089yyh0.aspx

妥当性の確認

プログラムの機能性に関する妥当性担保の話。そういう単語は出てこないけど。

妥当性を確認するにあたって厳密である必要はない。十分な推測をすれば、それでよい。

たとえば、性能テストのためのリソースプランニングでは、この考え方をする。プロジェクトのスケジュール見積りでも、そうかもしれない。

機能性に関しても、妥当性の確認についての考え方は同じらしい。ただ、「そこそこ妥当」という線引きは、それなりに経験がないと難しいけれども。

まあそれはそれとして、妥当性の確認を習慣の問題として取り上げている点と、どこまでやるかという問題に言及している点は、凄い本だと思った。

C++の文法関連

注意: C++の言語仕様を自分はほとんど知らないので、以下の記述は間違いを含む可能性があります。

(1)Javaとの違い

型のオブジェクトは「new」と書かなくても生成される
catch句の括弧の中に書くクラスは、変数名を省略できる
「その他の例外をすべてキャッチ」することができる

catch に続く ( ) には、関数の仮引数のような感じで、キャッチする例外オブジェクトの型と名前を記述します。ただし、名前については特に使うつもりがなければ省略できます。
http://www.geocities.jp/ky_webid/cpp/language/025.html

(2)入力エラーチェック

入力エラーをチェックするために、cinそのもの（戻り値）を評価してもいいらしい。

if(cin){

}else{

}

しかし、cinやcin.good()を使った入力エラーと比べると、cin.fail()の方が直感的で、やりたいことが明確だ。それに、cin.good()はif(!cin.good())のように使うと思われるが、健康上の理由により否定の!演算子は避けたい（目にやさしくない）。また、cin.bad()はbadしかチェックしないが、cin.fail()ならbadもfailもチェックしてくれる。ゆえに、cin.fail()を使うことが望ましい。

…という仮説をでっち上げたけど、実際には何が正しいのか分からない。検索した感じでは、「goodを使う」とする言説を多く見かけた。