#諸言
学習履歴全体のリンク
https://qiita.com/shigural/private/444b991293e5ab1b40af
#本文
##More Effective C++（第3版）
###基本
####1.ポインタと参照の違い
1.ポインタはnullを指しうるが、参照は必ずオブジェクトを指す
2.ポインタは再代入の可能性があるが、参照は初期化された時のオブジェクトを常に指す
一般に、なにか指し示すものがあることをわかっている場合、他のものは指し示したくない場合には参照を、それ以外にはポインタを使うべきである
####2.C++スタイルのキャストを愛用する（Effective C++で既出）
C型よりC++型スタイルのキャストを利用するべきである
####3.配列をポリモルフィズム的に扱ってはいけない
具象クラスを別の具象クラスから派生すると配列のサイズが不定になる可能性があるので、してはならない
####4.根拠のない省略時コンストラクタを避ける（プログラミング言語C++で既出）
不要なばあいには自動的に作られるコンストラクタなどは削除するべきである
###演算子
####5.ユーザ定義の変換関数に気をつけよう
不要ならば変数を暗黙に型変換するような関数を作らないほうが良い
####6.インクリメントとデクリメントの演算子で前置形式と後置形式を区別する
++aはaをインクリメントしてから値を返し、a++はその逆である。
特に理由がない限りは高速である前置インクリメントを利用するべきであり、後置インクリメントを自分で実装するには前置インクリメントを利用して実装するべきである
####7.&&, ||, あるいは,をオーバーロードしない
&&, ||, , はいずれもC++に組み込みとしての定義があり、プログラマはその動作を再現できる保証がないのでオーバーロードするべきでない
####8.newとdeleteの別の意味を理解する
newとdeleteをカスタマイズするとき、「どのようにするか」は変更できるが「何をするか」は言語で定められている
###例外
####9.リソースリークを防ぐためにデストラクタを使う（Effective C++で既出）
リソース漏れをふせぐためにデストラクタでdeleteを行う
####10.コンストラクタでのリソースリークを防ぐ（Effective C++で既出）
スマートポインタでリソース管理するとリソース漏れのリスクがなくなる
####11.デストラクタから発生した例外を抑える（Effective C++で既出）
デストラクタで例外を投げるとリソース漏れを呼び得るので、例外を投げてはならない
####12.例外発生の仕方と引数渡しや仮想関数呼び出しの違いを理解する
■自明なため簡略化
例外処理は関数呼び出しと大きく異なる
####13.参照渡しで例外を受け取る
■難解であるため略
####14.例外仕様を賢く用いる
■難解であるため略
####15.例外処理のコストを理解する
例外が発生したときには発生しなかったときの5～10%の処理時間増加が起こる。
また、例外を含むコードは含まないコードより5～10%のプログラム容量増加が起こる
###効率
####16.80-20規則を覚えておこう
プログラムの処理コストは全体の20%が80%の割合を占める。
よって、プログラムをプロファイルして高速化することで効果は劇的であり、通常の部分をプログラミングするときにはほとんど効率について考える必要がない
####17.遅延評価の仕様を検討する
得られた結果の一部だけが必要な場合には遅延評価が効率的である。（その実装方法は載っていない）
遅延評価の効率化としていくつかの例がある
#####参照回数計測
コピーコンストラクタにおいて、ポインタを共有して参照を数えておく方法。
shared_ptrと同じ実装
#####読み出しと書き込みを区別する
項目30で述べるプロキシークラスにより、読み込みと書き出しのどちらが使われるか確定してからコピーを行う方法がある
#####遅延フェッチ
■難解であるため略
#####式の遅延評価
例えば行列の計算で、(2,4)の数値を読みたいとすれば他の部分は計算する必要がない
必要な箇所が決まってからそこだけを計算するのが遅延評価である
####18.予想される計算のコストを償却する
遅延評価と逆に、結果がほとんど必ず必要な場合には過剰積極評価を行う
具体的にはキャッスの実装や余分な配列確保が挙げられる
####19.テンポラリオブジェクトの由来を理解しよう