C++のためのAPIデザイン 7章〜12章

C++のためのAPIデザイン

一気に最後まで。
IT技術者なら知っておきたい ストレージの原則と技術 が入手できないとブークスから連絡きた。2週間待たせてふざけるなよ？次何読もうかな。

第7章 パフォーマンス

できるだけ前方宣言を使用してヘッダのインクルードを減らす。

C++0xだと定数を返す関数で配列サイズを指定できるらしい。

constexpr int GetSize(int elems) { return elems * 2; }

double myTable[GetSize(2)];

最近のCPUではメモリのレイテンシが最大のパフォーマンスネックになっているから変数を詰める。

コピーオンライトでオブジェクトのコピーを後回しにする。

第8章 バージョン管理

後方互換性
前バージョンのAPIと同じ機能を提供するAPI。ユーザに何も変更させずに前バージョンのAPIと完全に置き換えることができる。

前方互換性
将来版のAPIで記述したクライアントコードが、変更せずに旧版のAPIでコンパイルできる。
ユーザが以前のリリースにダウングレードしてもコードを変更せずに済む。
前方互換性の維持は大変。

第9章 ドキュメント

使用方法だけじゃなくサンプリコードも書けよ。Doxygen使えよという話。

第10章 テスティング

ホワイトボックステストとブラックボックステストを組み合わせたグレーボックステストというテストがあるらしい。

privateコードをテストするために、クラスにSelfTest()メソッドを追加する方法がある。

コードカバレッジツールは使ったことがないな。

第11章 スクリプト記述

Boost Pythonという、Pythonバインディングを作るBoostライブラリがあるらしい。もっと早く知りたかった…

第12章 拡張性

プラグインと継承、テンプレートを使ってクライアントが拡張できる仕組みを作る話。

ポリシーベースのテンプレートとか再帰のテンプレートはモダンすぎるのでやめてください。

---

GoFのデザインパターンより現場寄りで実践的な本だった。More Effective C++やModern C++ designみたいな言語の凝ったテクニックだけではなくて、APIの設計を目的にした良書だと思う。

ただ、自分でお金と時間を消費して日頃からソフトウェアの本を読んでいる人は既に知っていることが多いかも。
ひどいクラス・関数を作り続けてるような人が読むべきなんだが、そういう人は自分からこういった本はまず読まないというジレンマ。
いい本を読むと、この本の内容をあいつの頭にddしてやりたいとか思う人は少なくないはず…