Посилання на змінні члени як члени класу

На своєму робочому місці я бачу цей стиль, який широко використовується: -

#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;
}

Чи існує назва, що описує цю ідіому? Я припускаю, що це для запобігання можливим великим накладним витратам на копіювання великого складного об'єкта?

Це загалом хороша практика? Чи є у цього підходу підводні камені?

Чи існує назва, що описує цю ідіому?

В UML це називається агрегацією. Він відрізняється від композиції тим, що об’єкт-член не належить референтному класу. У C ++ ви можете реалізувати агрегування двома різними способами, за допомогою посилань або покажчиків.

Я припускаю, що це для запобігання можливим великим накладним витратам на копіювання великого складного об'єкта?

Ні, це було б дійсно поганою причиною використовувати це. Основною причиною агрегації є те, що вміщений об'єкт не належить вміщуваному об'єкту, і, отже, їх життєвий цикл не пов'язаний. Зокрема, час життя об’єкта, на який посилається, повинен пережити той, на який йде посилання. Можливо, він був створений набагато раніше і міг жити після закінчення терміну служби контейнера. Крім того, стан об'єкта, на який посилається, не контролюється класом, але може змінюватися зовні. Якщо посилання немає const, тоді клас може змінити стан об'єкта, який живе поза ним.

Це загалом хороша практика? Чи є у цього підходу підводні камені?

Це інструмент проектування. У деяких випадках це буде гарна ідея, в деяких - ні. Найбільш поширеною помилкою є те, що час життя об’єкта, що містить посилання, ніколи не повинен перевищувати час життя об’єкта, на який посилається. Якщо об'єкт, що включає, використовує посилання після знищення об'єкта, на який посилається, у вас буде невизначена поведінка. Загалом краще віддати перевагу композиції, а не агрегації, але якщо вона вам потрібна, це такий же хороший інструмент, як і будь-який інший.

Це називається введенням залежностей за допомогою введення конструктора : клас Aотримує залежність як аргумент для свого конструктора і зберігає посилання на залежний клас як приватну змінну.

У Вікіпедії є цікавий вступ .

Для коректності правильності я б написав:

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що їм потрібно звертати увагу на час життя об’єкта, який вони передають.

Дещо пов’язані теми:

• Чи слід віддавати перевагу вказівникам чи посиланням у даних учасників?
• Використання посилання як членів класу для залежностей
• GotW # 88
• Заборонити прив'язку rvalue через конструктор до посилання const члена

Чи існує назва, що описує цю ідіому?

Для цього використання немає назви, воно просто відоме як "Посилання як член класу" .

Я припускаю, що це для запобігання можливим великим накладним витратам на копіювання великого складного об'єкта?

Так, а також сценарії, коли ви хочете пов’язати час життя одного об’єкта з іншим об’єктом.

Це загалом хороша практика? Чи є у цього підходу підводні камені?

Залежить від вашого використання. Використання будь-якої мовної функції подібно до "вибору коней на курси" . Важливо зазначити, що кожна ( майже вся ) мовна функція існує, оскільки вона корисна у деяких сценаріях.
Є кілька важливих моментів, на які слід звернути увагу при використанні посилань як учасників класу:

• Вам потрібно переконатися, що згаданий об’єкт гарантовано існуватиме доти, поки не існує об’єкт вашого класу.
• Вам потрібно ініціалізувати елемент у списку ініціалізатора елемента конструктора. Ви не можете мати ледачу ініціалізацію , яка може бути можливою у випадку члена покажчика.
• Компілятор не генерує призначення копії, operator=()і вам доведеться надати його самостійно. Трудно визначити, які дії вчинитиме ваш =оператор у такому випадку. Отже, в основному ваш клас стає недоступним .
• Посилання не можуть бути NULLзроблені або зроблені для посилання на будь-який інший об'єкт. Якщо вам потрібна перестановка, тоді це неможливо з посиланням, як у випадку з покажчиком.

Для більшості практичних цілей (якщо ви насправді не стурбовані великим використанням пам'яті через розмір члена), достатньо мати лише екземпляр члена, замість вказівника або члена посилання. Це економить вам багато турбот щодо інших проблем, які члени посилання / покажчика приносять із собою, хоча за рахунок додаткового використання пам'яті.

Якщо вам потрібно використовувати вказівник, переконайтеся, що ви використовуєте розумний вказівник замість необробленого вказівника. Це значно полегшить вам життя за допомогою покажчиків.

C ++ забезпечує хороший механізм управління часом життя об'єкта за допомогою класів / структурних конструкцій. Це одна з найкращих можливостей C ++ перед іншими мовами.

Коли у вас є змінні члена, виставлені через ref або покажчик, це в принципі порушує інкапсуляцію. Ця ідіома дозволяє споживачеві класу змінювати стан об’єкта A, не маючи при цьому жодного знання або контролю над ним (A). Це також дозволяє споживачеві триматися за посилання / вказівник на внутрішній стан А, поза часом життя об'єкта А. Це поганий дизайн. Натомість клас може бути рефакторований, щоб утримувати ref / покажчик на спільний об'єкт (не володіти ним), і їх можна встановити за допомогою конструктора (Надати правила часу життя). Клас спільного об'єкта може бути розроблений для підтримки багатопоточності / паралельності, залежно від обставин.

Посилання на членів зазвичай вважаються поганими. Вони ускладнюють життя порівняно з покажчиками членів. Але це не особливо незвично, і це не якась спеціальна ідіома чи річ. Це просто псевдонім.