PPPUC++#11.5

c++ reading

9.6 Operator overloading

      • ここも書く事ないなー
  • とりあえずほぼ全ての言語で定義された使い方なら演算子の挙動をUDT毎に設定できる
  • 例によってやり過ぎはいかんよ、という忠告

9.7 Class interfaces

  • 実装とIFの分離は重要
    • じゃあ何故structが・・・って言おうと思ったら Mr.Sがセルフツッコミしてる・・・w
  • それはいいけど、じゃあ良いIF設計ってどんなのですか？
    1. I/Fを完全に
    2. I/Fを最小に
    3. 準備運動は必ずすること（コンストラクタ）
    4. 後片付けはちゃんとすること（デストラクタ）
    5. 良い子を優遇すること（immutable/constなメンバ関数)
    6. コピーをサポート（または禁止）すること
    7. 型を使った引数チェックを可能にしておくこと
  • とかが基本方針
  • 最初の二つは「可能な限り小さく、しかし小さすぎず」というやつ
    • 小さい方がわかりやすいし覚えやすいしエラー探索もしやすいけど、小さければ良いってもんでもない
  • 多数のpublicはカオスへの入口
    • 関数もデータも。データの方がヒドい
9.7.1 Argument types
  • 引数の型を使って引数の順序チェックをやってしまうという手口
  • この例では Dateオブジェクトのコンストラクタで monthを間違えないようにMonth列挙型を使うとか
  • これなら 4,5が 4月5日か5月4日か迷わなくてよいよねー
      • うーん、「4月ってより Date::aprのほうがわかりやすいでしょ♡」とかせまられてもなあ・・・
      • さすがだアメリカ人。さすがだMr.S
    • まあ確かに有効なときもあるだよね
    • コンパイラがエラーチェックできる、と。。。。。そのためにかかる手間がハンパ無い気もするけど
  • あと、 Data.marでないのは Month列挙型がオブジェクトのものではなくクラスのものだから
    • 名前空間とかクラスのスコープを明示するときは :: をつかう
  • 理想的には全てのエラーがコンパイル時にわかるべき。実行時になんていくない
    • 実行時のエラーはコードを人間が「探さ」なきゃだわだし、下手したらチェックコードを「書か」なきゃだわだし
  • いやおいMr.S、、だからってあんた Yearクラスを・・・
    • いやー
      • というのはあんまり意味ないねーという話だった a sigh of relief....
  • 結局、Yearクラスの導入は引数の位置はチェックできても範囲エラーは実行時。あんまり意味ない
  • 常にこういったバランスを考えるのが重要
    • 「至高のメニュー」とか「究極のメニュー」いうな
    • ヴォルテールの格言 "The best is the enemy of the good." まさに。
  • ついでにstatic constの説明。クラス内で定数書く場合の常套。こうすると確保されるのが１つだけ、すなわちシングルトンであることが保証できる、とか。
    • そもそも const にしてしまうと、直接初期化ができないですしね。。。
    • 正直これは別に static 書かなくても const だけでイージャンとかD&E読むまでは思ってたのですが *1、 C++の場合
class A {
  const int val;
public:
  A(int a) : val(a) {}
};
    • とかできてしまうので、その区別が必要なのですね。
      • immutableとかのほうが。やっぱ設計が（ry
9.7.2 Copying
  • コピーコンストラクタとかコピー代入の話をするのかと思いきやそれは 14, 18章までおあずけ、とか。
  • 言いたかったのはデフォルトではまるまるコピーだよって話だけらしい
  • ここまでの例も結構無節操にコピーしまくり、と言う話は出てないw
    • 参照返しやポインタ返しという無間地獄へようこそ・・・という話になってしまうからか

*1:D&Eにもしれっと「委員会で否決された」という話が書いてあるだけですが・・