クラスメンバーとしての参照メンバー変数

Question 1

私の職場では、このスタイルが広く使用されているのがわかります。-

#include <iostream>

using namespace std;

class A
{
public:
   A(int& thing) : m_thing(thing) {}
   void printit() { cout << m_thing << endl; }

protected:
   const int& m_thing; //usually would be more complex object
};


int main(int argc, char* argv[])
{
   int myint = 5;
   A myA(myint);
   myA.printit();
   return 0;
}

このイディオムを説明する名前はありますか？大きな複雑なオブジェクトをコピーすることによるおそらく大きなオーバーヘッドを防ぐためだと思いますか？

これは一般的に良い習慣ですか？このアプローチに落とし穴はありますか？

Question 2

このイディオムを説明する名前はありますか？

UMLでは、これは集約と呼ばれます。メンバーオブジェクトが参照クラスによって所有されていないという点で、構成とは異なります。C ++では、参照またはポインターを使用して、2つの異なる方法で集計を実装できます。

大きな複雑なオブジェクトをコピーすることによるおそらく大きなオーバーヘッドを防ぐためだと思いますか？

いいえ、それはこれを使用する本当に悪い理由になります。集約の主な理由は、含まれているオブジェクトが含まれているオブジェクトによって所有されていないため、それらの存続期間が制限されていないことです。特に、参照されるオブジェクトの存続期間は、参照するオブジェクトの存続期間よりも長くなければなりません。それははるかに早く作成された可能性があり、コンテナの寿命の終わりを超えて存続する可能性があります。さらに、参照されるオブジェクトの状態はクラスによって制御されませんが、外部で変更できます。参照がでない場合、constクラスはその外部にあるオブジェクトの状態を変更できます。

これは一般的に良い習慣ですか？このアプローチに落とし穴はありますか？

デザインツールです。良いアイデアになる場合もあれば、そうでない場合もあります。最も一般的な落とし穴は、参照を保持しているオブジェクトの存続期間が、参照されているオブジェクトの存続期間を超えてはならないことです。参照されたオブジェクトが破棄された後に、囲んでいるオブジェクトが参照を使用する場合、未定義の動作が発生します。一般に、集約よりも構成を優先する方が良いですが、必要な場合は、他のツールと同じくらい優れたツールです。

Question 3

これは、コンストラクター注入による依存性注入と呼ばれます。クラスAは、コンストラクターへの引数として依存性を取得し、依存クラスへの参照をプライベート変数として保存します。

ウィキペディアに興味深い紹介があります。

const-correctnessについては、次のように記述します。

using T = int;

class A
{
public:
  A(const T &thing) : m_thing(thing) {}
  // ...

private:
   const T &m_thing;
};

ただし、このクラスの問題は、一時オブジェクトへの参照を受け入れることです。

T t;
A a1{t};    // this is ok, but...

A a2{T()};  // ... this is BAD.

追加することをお勧めします（少なくともC ++ 11が必要です）：

class A
{
public:
  A(const T &thing) : m_thing(thing) {}
  A(const T &&) = delete;  // prevents rvalue binding
  // ...

private:
  const T &m_thing;
};

~~とにかく、コンストラクターを変更した場合：~~

~~class A { public: A(const T *thing) : m_thing(*thing) { assert(thing); } // ... private: const T &m_thing; };~~

一時的なへのポインタがないことはほぼ保証されています。

また、コンストラクターはポインターを受け取るためA、渡すオブジェクトの存続期間に注意を払う必要があることはユーザーにとってより明確です。

やや関連するトピックは次のとおりです。

Question 4

このイディオムを説明する名前はありますか？

この使用法の名前はありません。単に「クラスメンバーとしての参照」と呼ばれます。

大きな複雑なオブジェクトをコピーすることによるおそらく大きなオーバーヘッドを防ぐためだと思いますか？

はい。また、あるオブジェクトの存続期間を別のオブジェクトに関連付けたいシナリオもあります。

これは一般的に良い習慣ですか？このアプローチに落とし穴はありますか？

用途によって異なります。言語機能を使用することは、「コースに馬を選ぶ」ようなものです。いくつかのシナリオで役立つため、すべての（ほとんどすべての）言語機能が存在することに注意することが重要です。
参照をクラスメンバーとして使用する場合、注意すべき重要な点がいくつかあります。

クラスオブジェクトが存在するまで、参照されるオブジェクトが存在することが保証されていることを確認する必要があります。
コンストラクターメンバー初期化子リストのメンバーを初期化する必要があります。遅延初期化を行うことはできません。これは、ポインターメンバーの場合に可能です。
コンパイラーはコピー割り当てoperator=()を生成しないため、自分でコピー割り当てを提供する必要があります。この=ような場合にオペレーターがどのような行動を取るかを決めるのは面倒です。したがって、基本的にクラスは割り当て不可になります。
NULL他のオブジェクトを参照することはできません。再装着が必要な場合は、ポインタの場合のように参照を使用することはできません。

ほとんどの実用的な目的では（メンバーのサイズが原因でメモリ使用量が多いことを本当に心配している場合を除き）、ポインターや参照メンバーの代わりにメンバーインスタンスを用意するだけで十分です。これにより、余分なメモリ使用量を犠牲にして、参照/ポインタメンバーがもたらす他の問題について心配する必要がなくなります。

ポインターを使用する必要がある場合は、生のポインターの代わりにスマートポインターを使用してください。それはあなたの人生をポインターではるかに楽にするでしょう。

Question 5

C ++は、クラス/構造体構造体を介してオブジェクトの存続期間を管理するための優れたメカニズムを提供します。これは、他の言語に対するC ++の優れた機能の1つです。

refまたはpointerを介してメンバー変数を公開すると、原則としてカプセル化に違反します。このイディオムにより、クラスのコンシューマーは、Aのオブジェクトの状態を、Aのオブジェクトの知識や制御がなくても変更できます。また、消費者は、Aのオブジェクトの存続期間を超えて、Aの内部状態への参照/ポインターを保持することができます。これは悪い設計です。代わりに、クラスをリファクタリングして、共有オブジェクトへの参照/ポインターを保持し（所有していない）、コンストラクターを使用して設定することができます（ライフタイムルールの義務化）。共有オブジェクトのクラスは、場合によってはマルチスレッド/同時実行をサポートするように設計されている場合があります。

Question 6

メンバーの参照は通常、悪いと見なされます。彼らはメンバーのポインターと比較して人生を困難にします。しかし、それは特に珍しいことではなく、特別な名前のイディオムやものでもありません。エイリアシングです。