Призначення об'єднань в C і C ++

Раніше я зручніше використовував спілки; сьогодні я насторожився, коли прочитав цей пост і дізнався, що це код

union ARGB
{
    uint32_t colour;

    struct componentsTag
    {
        uint8_t b;
        uint8_t g;
        uint8_t r;
        uint8_t a;
    } components;

} pixel;

pixel.colour = 0xff040201;  // ARGB::colour is the active member from now on

// somewhere down the line, without any edit to pixel

if(pixel.components.a)      // accessing the non-active member ARGB::components

насправді невизначена поведінка, тобто читання від члена профспілки, відмінне від недавно написаного, призводить до невизначеної поведінки. Якщо це не призначене використання профспілок, що таке? Чи може хтось, будь ласка, пояснити це детально?

Оновлення:

Я хотів уточнити кілька речей заднім числом.

• Відповідь на запитання не однакова для C та C ++; моя необізнана молодша власна особа позначила це як C і C ++.
• Переглянувши стандарт C ++ 11, я не зміг однозначно сказати, що він вимагає доступу / перевірки неактивного члена профспілки невизначений / не визначений / визначений реалізацією. Все, що я міг знайти, - § 9.5 / 1:

  Якщо об'єднання стандартного макета містить кілька структур стандартного макета, які мають спільну початкову послідовність, і якщо об'єкт цього типу об'єднання стандартного макета містить одну із структур стандартного компонування, дозволяється перевіряти загальну початкову послідовність будь-якої членів структури стандартної верстки § 9.2 / 19: Дві структури стандартного макету мають спільну початкову послідовність, якщо відповідні члени мають типи сумісних з компонуванням і будь-який з членів є бітовим полем або обидва є бітовими полями однакової ширини для послідовності однієї або більше початкових члени.

• Перебуваючи в C, ( C99 TC3 - DR 283 і далі) це законно ( завдяки Паскалю Куоку за те, що це підняло ). Однак спроба зробити це все ж може призвести до невизначеної поведінки , якщо прочитане значення виявиться недійсним (так зване "представлення пастки") для типу, через який він читається. В іншому випадку значення читання визначається реалізацією.

• C89 / 90 назвав це не визначеним поведінкою (додаток J), а книга K&R говорить, що його реалізація визначена. Цитата від K&R:

  Це мета об'єднання - єдиної змінної, яка може законно містити будь-який з декількох типів. [...] до тих пір, поки використання буде послідовним: отриманий тип повинен бути типом, який останнім часом зберігається. Відповідальність програміста слідкує, який тип зберігається в союзі; результати залежать від реалізації, якщо щось зберігається як один тип і витягується як інший.

• Витяг з Stroustrup's TC ++ PL (міна акценту)

  Використання спілок може бути суттєвим для сумісності даних [...], іноді неправильно використовуваних для "перетворення типу ".

Перш за все, це запитання (назва якого залишається незмінним з мого запитання) було поставлено з наміром зрозуміти мету об'єднань І не на те, що стандарт дозволяє, наприклад, Використання успадкування для повторного використання коду, звичайно, дозволено стандартом C ++, але це не було ціллю або початковим наміром запровадити спадщину як особливість мови C ++ . Саме тому відповідь Андрія продовжує залишатися прийнятою.

Мета спілок досить очевидна, але люди чомусь її дуже часто пропускають.

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

Це як номер у готелі. У ньому живуть різні люди протягом періодів, що не перетинаються. Ці люди ніколи не зустрічаються і взагалі нічого не знають один про одного. Правильно керуючи тимчасовим розподілом номерів (тобто, переконуючись, що різні люди не призначаються одночасно до однієї кімнати), порівняно невеликий готель може забезпечити розміщення відносно великої кількості людей, що саме це готелі є для.

Саме це і робить союз. Якщо ви знаєте, що кілька об’єктів у вашій програмі містять значення з неперекритими значеннями життя, тоді ви можете "об'єднати" ці об'єкти в об'єднання і таким чином зберегти пам'ять. Так само, як у готельному номері максимум один «активний» орендар у кожний момент часу, профспілка має максимум одного «активного» члена у кожен момент програмного часу. Читати може лише "активний" член. Входячи в інший член, ви перемикаєте "активний" статус на цей інший член.

Чомусь цю первісну мету спілки "переосмислили" чимось зовсім іншим: написання одного члена спілки, а потім перевірка його через іншого члена. Цей вид реінтерпретації пам'яті (відомий також як "тип карання") не є коректним використанням об'єднань. Це, як правило, призводить до невизначеного поведінки , описаного як створення поведінки, визначеної реалізацією в C89 / 90.

EDIT: Використання об'єднань для цілей покарання (тобто написання одного члена, а потім читання іншого) було дане більш детальне визначення в одній з Технічних виправлень до стандарту C99 (див. DR # 257 та DR # 283 ). Однак майте на увазі, що формально це не захищає вас від невдалої поведінки, намагаючись прочитати уявлення про пастку.

Ви можете використовувати спілки для створення таких структур, які містять поле, яке вказує нам, який компонент об'єднання використовується насправді:

struct VAROBJECT
{
    enum o_t { Int, Double, String } objectType;

    union
    {
        int intValue;
        double dblValue;
        char *strValue;
    } value;
} object;

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

Якщо ви використовуєте C ++ (ви використовуєте два теги) і вам дуже важливо переносимість, то ви можете просто скористатись структурою та надати сеттер, який приймає uint32_tта встановлює поля належним чином за допомогою операцій біткої маски. Те ж саме можна зробити в C з функцією.

Редагувати : Я очікував, що AProgrammer запише відповідь для голосування і закрив цю. Як зазначалося в деяких коментарях, ендіанство розглядається в інших частинах стандарту, дозволяючи кожній реалізації вирішувати, що робити, а вирівнювання та прокладка також можна обробляти по-різному. Тепер важливим моментом тут є суворі правила зшивання, на які неявно посилається AProgrammer. Компілятору дозволяється робити припущення щодо зміни (або відсутності модифікації) змінних. У випадку об'єднання компілятор може переупорядкувати вказівки та перемістити зчитування кожного компонента кольору через запис до змінної кольору.

Найбільш поширене використання, яке unionя регулярно зустрічаю, - це згладжування .

Розглянемо наступне:

union Vector3f
{
  struct{ float x,y,z ; } ;
  float elts[3];
}

Що це робить? Це дозволяє отримувати чіткий, акуратний доступ Vector3f vec;учасників за будь-яким ім'ям:

vec.x=vec.y=vec.z=1.f ;

або за допомогою цілого доступу до масиву

for( int i = 0 ; i < 3 ; i++ )
  vec.elts[i]=1.f;

У деяких випадках доступ до імені - це найяскравіша річ, яку ви можете зробити. В інших випадках, особливо коли вісь обрана програмно, легше зробити доступ до осі за числовим індексом - 0 для х, 1 для у і 2 для z.

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

union A {
   int i;
   double d;
};

A a[10];    // records in "a" can be either ints or doubles 
a[0].i = 42;
a[1].d = 1.23;

Звичайно, вам також потрібен якийсь дискримінатор, щоб сказати, який варіант насправді містить. І зауважте, що в C ++ профспілки мало використовуються, оскільки вони можуть містити лише типи POD - фактично ті, що не мають конструкторів та деструкторів.

В C це був приємний спосіб втілити щось на зразок варіанту.

enum possibleTypes{
  eInt,
  eDouble,
  eChar
}


struct Value{

    union Value {
      int iVal_;
      double dval;
      char cVal;
    } value_;
    possibleTypes discriminator_;
} 

switch(val.discriminator_)
{
  case eInt: val.value_.iVal_; break;

У часи пам’яті Літлле ця структура використовує менше пам’яті, ніж структура, яка має весь член.

До речі, як це забезпечує C

    typedef struct {
      unsigned int mantissa_low:32;      //mantissa
      unsigned int mantissa_high:20;
      unsigned int exponent:11;         //exponent
      unsigned int sign:1;
    } realVal;

для доступу до бітових значень.

Хоча це суворо невизначена поведінка, на практиці це працюватиме з майже будь-яким компілятором. Це така широко застосовувана парадигма, що будь-який поважаючий себе компілятор повинен буде зробити «правильну справу» у таких випадках. Це, безумовно, слід віддати перевагу над типовим покаранням, яке може генерувати зламаний код з деякими компіляторами.

У C ++ Boost Variant реалізує безпечну версію об'єднання, розроблену для того, щоб максимально запобігти невизначеній поведінці.

Його продуктивність ідентична enum + unionконструкції (стек також виділений тощо), але він використовує шаблон типів замість enum:)

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

Також спілки не просто для економії місця. Вони можуть допомогти сучасним компіляторам з типовим каруванням. Якщо ви reinterpret_cast<>все, компілятор не може робити припущення щодо того, що ви робите. Можливо, доведеться викинути те, що він знає про ваш тип, і почати заново (змушує записувати назад у пам'ять, що в наші дні дуже неефективно порівняно з тактовою частотою процесора).

Технічно це не визначено, але насправді більшість (усіх?) Компіляторів трактують це точно так само, як і використання reinterpret_castодного типу до іншого, в результаті якого визначено реалізацію. Я б не втрачав сон над вашим поточним кодом.

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

Інші згадували архітектурні відмінності (мало - великий ендіан).

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

напр. союз {float f; int i; } х;

Писати на xi було б безглуздо, якби потім читати з xf - хіба що це те, що ти задумав, щоб подивитися на знакові, експонентні або мантійські компоненти поплавця.

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

напр. союз {char c [4]; int i; } х;

Якщо, гіпотетично, на якійсь машині значок потрібно було вирівняти словом, тоді c [0] і c [1] поділяють сховище з i, а не c [2] і c [3].

У мові С, як це було зафіксовано в 1974 році, всі члени структури поділили загальний простір імен, і значення "ptr-> член" було визначено як додавання переміщення члена до "ptr" та отримання доступу до отриманої адреси за допомогою типу члена. Ця конструкція дозволила використовувати один і той же ptr з іменами членів, взяті з різних визначень структури, але з однаковим зміщенням; програмісти використовували цю здатність для різних цілей.

Коли членам структури було призначено власні простори імен, неможливо було оголосити двох членів структури з однаковим переміщенням. Додавання об'єднань до мови дозволило досягти тієї самої семантики, яка була доступна в попередніх версіях мови (хоча неможливість експортувати імена в контекст, що вкладається, можливо, все ще потребувала використання знаходження / заміни для заміни foo-> члена в foo-> type1.member). Важливим було не стільки те, що люди, які додали спілки, мають на увазі певне цільове використання, а скоріше, щоб вони забезпечували засоби, завдяки яким програмісти, які покладалися на попередню семантику, з будь-якою метою , все-таки зможуть досягти досягнення та ж семантика, навіть якщо для цього їм довелося використовувати інший синтаксис.

Ви можете використовувати aa Union з двох основних причин:

1. Зручний спосіб отримати доступ до одних і тих же даних різними способами, як у вашому прикладі
2. Спосіб економії місця, коли є різні члени даних, з яких лише один може бути "активним"

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

Хороший приклад 2. можна знайти у типу VARIANT, що широко використовується в COM.

Як згадували інші, об'єднання, поєднані з перерахуваннями і загорнуті в структури, можуть бути використані для реалізації позначених об'єднань. Одне практичне використання - це реалізація Rust's Result<T, E>, яка спочатку реалізована за допомогою чистого enum(Rust може містити додаткові дані у варіантах перерахування). Ось приклад C ++:

template <typename T, typename E> struct Result {
    public:
    enum class Success : uint8_t { Ok, Err };
    Result(T val) {
        m_success = Success::Ok;
        m_value.ok = val;
    }
    Result(E val) {
        m_success = Success::Err;
        m_value.err = val;
    }
    inline bool operator==(const Result& other) {
        return other.m_success == this->m_success;
    }
    inline bool operator!=(const Result& other) {
        return other.m_success != this->m_success;
    }
    inline T expect(const char* errorMsg) {
        if (m_success == Success::Err) throw errorMsg;
        else return m_value.ok;
    }
    inline bool is_ok() {
        return m_success == Success::Ok;
    }
    inline bool is_err() {
        return m_success == Success::Err;
    }
    inline const T* ok() {
        if (is_ok()) return m_value.ok;
        else return nullptr;
    }
    inline const T* err() {
        if (is_err()) return m_value.err;
        else return nullptr;
    }

    // Other methods from https://doc.rust-lang.org/std/result/enum.Result.html

    private:
    Success m_success;
    union _val_t { T ok; E err; } m_value;
}