EffectiveC++改訂2版 第17項〜第21項 - dogatana's diary
17項 AcceleratedC++でも何度も注意されていた「自己代入」のチェック。ほとんどの場合、this と &rhs の比較で判定すれば良い。 エイリアシングの可能性を考慮しなければいけない理由 効率：代入は非常にコストがかかる操作になる場合がある 安全：間違いを犯さないようにする。代入時に古いリソースを破棄するが、新しいリソース割り当て際に古いリソースが必要なことがある。 18項 完全でしかも最小限のクラスインタフェース クライアントが普通やりたいと思うようなことは、何でもできる 関数の数が可能な限り切り詰められていて、関数同士で機能がオーバーラップしていない 関数が一杯詰まったインタフェースの技術的な欠点 インタフェースに含まれる関数の数が多ければ多いほど、クライアントにとって理解し難いものになる 大きいインタフェースは保守が難しい 必要以上に長いクラス定義、プロジェクトの存続期
EffectiveC++改訂2版 14項〜第16項 - dogatana's diary
第14項 継承で利用する基底クラスの仮想デストラクタの話。AcceleratedC++でもおなじみ。 第15項 代入演算子。これもAcceleratedC++でおなじみ。 よくある間違い operator= の戻り値を void にする operator= の戻り値を const オブジェクトのリファレンスにする 代入演算子を定義するときは、常に *this のリファレンスを戻すこと。 第16項 派生クラスでの代入演算子の定義の方法。AcceleratedC++では単独クラスのみだったので、このケースについては初めて。派生クラスで基底クラスの operater=() を呼び出す。 class Derived: public Base { Derived& operator=(const Derived& rhs) { if (this != &rhs) { Base::operator=(
EffectiveC++改訂2版 第9項〜第13項 - dogatana's diary
第9項 メンバ関数の定義による隠蔽の話。50項では継承関係の中での話しだが、ここでは operator new() の話。 第10項 63ページにあるBLOCK_SIZEの定義はなぜか1項では「古い」とされている形式。 かつ、ここの説明での operator delete() の形式も古い形式の可能性がある。これはEffectiveC++ 改訂2版を読み始める - dogatanaの日記に関連する話。 第11項〜12項 このあたりはさらっと。 第13項 C++のルールによれば、クラスのメンバは、そのクラスで宣言された順番に初期化される。 これは薄っすら覚えているが、実際に確認してみる。 #include <iostream> //他のクラスのprivteデータメンバで使われるもの class DataClass { public: DataClass(int n = 0): data(n)
EffectiveC++ 改訂2版を読み始める - dogatana's diary
本棚に埋もれていた第2版をこれまでの復習を兼ねて読み始める。 第3版に比べ、Cからの移行の章があったりして時代を感じさせますね。こちら側が丁度良い位なのが淋しいですが。 1項から7項 このあたりはすいすい読み進められる。 8項 非メンバ、メンバのnew/deleteを作成するときの話。 非メンバ operator new では0バイトの要求への対応が必要 非メンバ operator delete は簡単 メンバ operator new では渡されたサイズと自クラスのサイズとの比較が必要 メンバ operator delete では渡されたサイズと自クラスのサイズとの比較が必要 と、ここまで良いのだが、メンバの配列版を作ってみたらVC2005とg++とで動きが違う。 次のソースで実行してみる。 #include <iostream> class TestClass { public: Te
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
