Копіювання конструкцій з неініціалізованими членами

Чи дійсно копіювати структуру, частина членів якої не ініціалізована?

Я підозрюю, що це не визначена поведінка, але якщо так, то це робить залишати будь-яких неініціалізованих членів структури (навіть якщо ці члени ніколи не використовуються безпосередньо) досить небезпечно. Тож мені цікаво, чи є щось у стандарті, що це дозволяє.

Наприклад, чи дійсно це?

struct Data {
  int a, b;
};

int main() {
  Data data;
  data.a = 5;
  Data data2 = data;
}

Так, якщо неініціалізований член не є непідписаним вузьким символьним типом, або std::byteкопіювання структури, що містить це невизначене значення, з неявно визначеним конструктором копій, є технічно невизначеним поведінкою, як і для копіювання змінної з невизначеним значенням того ж типу, оскільки з [dcl.init] / 12 .

Це стосується тут, оскільки неявно генерований конструктор копій, за винятком unions, визначений для копіювання кожного члена окремо, як би шляхом прямої ініціалізації, див. [Class.copy.ctor] / 4 .

Це також є предметом активного випуску CWG 2264 .

Я вважаю, що на практиці у вас із цим не виникне жодних проблем.

Якщо ви хочете бути впевненими на 100%, використання std::memcpyзавжди має чітко визначену поведінку, якщо тип тривіально копіюється , навіть якщо члени мають невизначене значення.

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

struct Data {
  int a{}, b{};
};

int main() {
  Data data;
  data.a = 5;
  Data data2 = data;
}

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

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

Сигналізація NaN можлива для типів з плаваючою точкою, а на деяких платформах цілі числа можуть мати уявлення про пастку.

Однак для тривіально копіюваних типів можна memcpyскопіювати необроблене подання об'єкта. Це зробити безпечно, оскільки значення об'єкта не інтерпретується, а натомість копіюється необроблена послідовність байтів представлення об'єкта.

У деяких випадках, наприклад описаний, стандарт C ++ дозволяє компіляторам обробляти конструкції будь-яким способом, яким їхні клієнти вважатимуть найбільш корисними, не вимагаючи, щоб така поведінка була передбачуваною. Іншими словами, такі конструкції викликають "Невизначене поведінку". Однак це не означає, що такі конструкції мають бути «забороненими», оскільки стандарт C ++ явно відмовляється від юрисдикції щодо того, які добре сформовані програми можуть «робити». Хоча я не знаю жодного опублікованого документа з обґрунтуванням стандарту C ++, той факт, що він описує не визначене поведінку, як це робиться у C89, напрошував би передбачуваний сенс подібний: "Невизначена поведінка дає ліцензію виконавця не вловлювати певні програмні помилки, які є складними. поставити діагноз.

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

Крім того, є деякі ситуації, коли може бути найбільш ефективним, щоб неініціалізовані дані поводилися недетерміновано. Наприклад, наведено:

struct q { unsigned char dat[256]; } x,y;

void test(unsigned char *arr, int n)
{
  q temp;
  for (int i=0; i<n; i++)
    temp.dat[arr[i]] = i;
  x=temp;
  y=temp;
}

якщо код за низхідним потоком не піклується про значення будь-яких елементів x.datчи y.datіндекси яких не були вказані arr, код може бути оптимізований до:

void test(unsigned char *arr, int n)
{
  q temp;
  for (int i=0; i<n; i++)
  {
    int it = arr[i];
    x.dat[index] = i;
    y.dat[index] = i;
  }
}

Таке підвищення ефективності було б неможливим, якби програмісти temp.datперед копіюванням вимагали чітко записати кожен елемент , у тому числі і тих, хто не переймався б цим.

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

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

Оскільки всі члени групи Dataпримітивних типів, data2отримають точну "побітну копію" всіх членів data. Таким чином, значення data2.bбуде точно таким же, як значення data.b. Однак точного значення data.bнеможливо передбачити, оскільки ви не ініціалізували його явно. Це залежатиме від значень байтів у області пам'яті, виділеної для data.