Использование Союза в ООП

Question

Союзы могут использоваться как тип, как класс и структура (с некоторыми ограничениями). Он может иметь функции-члены. Его можно использовать как конструкцию ООП.

Как я понимаю, профсоюзы были только что импортировали и C++, чтобы поддерживать обратную совместимость с C.
Во всех этих лет программирования я никогда не использовал союз, как я хотел бы использовать класс или структуру как ООП конструкции.

Существует ли практическое использование Союза как конструкции ООП (а не только как тип данных), или это просто какая-то рудиментарная часть языка, которая никогда не бывает полезной?

---

EDIT:
Стандарт определенно позволяет профсоюзу действовать как ООП конструкции. Он допускает функции-члены в союзах. После компиляции кода и работает и совместим со стандартом:

union A 
{ 
    int a; 
    int k; 

    void doSomething(){} 

}; 

int main() 
{ 
    A obj; 
    int i = obj.a; 
    obj.doSomething(); 
    return 0; 
} 

Почему стандарт позволяет функции члена в союзе, если он не должен действовать как ООП конструкции?
Пожалуйста, ответьте на вопросы по конкретным аргументам и, пожалуйста, воздержитесь от ответа Я так не думаю, без веских аргументов Почему?

Answer 1

No, объединение не является конструкцией OO.

Единственной важной особенностью OO является полиморфизм, но объединения не могут участвовать в отношениях наследования (не могут быть базой другого типа, не могут иметь базы) или иметь виртуальные функции. Единственная цель объединения - предоставить тип данных, а не объект .

Answer 2

Мой личный взгляд - «нет».

Исторически сложилось, что C разрешил разработчикам доступ на низкоуровневый доступ к хост-системе, обеспечивая доступ к памяти очень гибкими способами. Предоставляя конструкцию для обработки той же области памяти, что и разные типы данных, эта гибкость была сделана еще проще.

Но трудно понять, как это можно классифицировать как объектно-ориентированную конструкцию любого типа.

Answer 3

я думаю нет.

союзы не имеет отношения к Ориентация объекта.

C++ никогда не заявляет, что намерен поддерживать только OO. C++ не поддерживает от начала несколько парадигмы (между тем: процедурной, функциональным, порождающим, объектно ориентированной)

C++ 11 поддерживает «свободных союзы», но я не вижу никакого использования с ОО точки зрения

В зависимости по авторам ориентации объекта необходимы следующие вопросы:

• удостоверения
• наследование/роды ЛМЗС
• polymorphy
• инкапсуляция

В случае союзов первый вопрос является действительным. Объединение может быть идентифицировано (по его адресу, например)

НЕТ концепции Наследование доступно для профсоюзов.

Можно утверждать, что данные являются полиморфными в союзе, но эта интерпретация далека от того, что оо считает полиморфным. Объединение не может иметь виртуальную функцию, которая была бы почти бесполезна без наследования. И это сломает макет памяти.

инкапсуляция в союзе. Однако из-за ограничений я не ожидаю полезных приложений для этого случая. Если бы я был признателен за ссылку

С помощью этого набора функций я бы назвал «абстрактный тип данных» (ADA) подходящим термином.

Answer 4

В качестве конструкции низкого уровня объединение полезно тогда, когда ваши данные имеют разные интерпретации и типы, основанные на контексте. В этом смысле он помогает вам сохранить ваши объекты меньше, чем если бы вы сохраняли разные поля, которые не могут существовать одновременно.

Действительно ли это относится к ООП? Вид, я думаю ...

-

Один хак люди делают с ними доступа разные байты с разными именами (типичные примеры, чтобы иметь объединение 4 байта R, G, B, A и один 32-битный целочисленный цвет), но это потенциально опасно https://stackoverflow.com/a/1582389/278842.

Answer 5

Это не хорошая практика, но предположим, что вы могли бы сделать большую гарантию, что только одно поле будет активным:

class multi_type { 
private: 
    bool unit_is_float; 
    union { 
     float float_member; 
     int int_member; 
    }; 
public: 
    multi_type(bool is_float) : unit_is_float(is_float) {} 
    bool isFloat() { return unit_is_float; } 
    bool isInt() { return !unit_is_float; } 
    float& getFloat() { 
     if (!isFloat()) throw std::logic_error("not a float"); 
     return float_member; 
    } 
    int& getInt() { 
     if (!isInt()) throw std::logic_error("not an int"); 
     return int_member; 
    } 
}; 

отформатированный быть кратким, не очень.

Допустимое приложение может быть в какой-то библиотеке разбора, где язык, подлежащий анализу, может иметь разные типы токенов, которые могут быть определены только во время выполнения. Это альтернатива использованию void * s.

Answer 6

От Microsoft help:

объединение C++ является ограниченной формой типа класса. Он может содержать доступ к спецификаторам (общедоступным, защищенным, приватным), данным элемента и членам , включая конструкторы и деструкторы. Он не может содержать виртуальных функций или статических данных. Он не может использоваться в качестве базового класса , и он не может иметь базовые классы. Доступ по умолчанию для членов в союзе является общедоступным.

Возможно даже соединение шаблонов (см., Например, Templates - The Complete Guide).В этом смысле соединения обеспечивают почти идентичные степеньинкапсуляция.

Несмотря на все эти синтаксические ограничения, объединения заполняют небольшое отверстие способами разлома системы типа C++. Рассмотрим эти свободные корреспонденцию:

class/struct with virtual functions <--> dynamic_cast 
class/struct without virtual functions <--> static_cast 
union         <--> reinterpret_cast 

полиморфизм все о взломе системы типа безопасным и контролируемым образом. Классы и структуры разбивают систему типов во времени. С помощью виртуальных функций мы можем разбить систему типов во время выполнения; без виртуальных функций мы можем сделать это во время компиляции (особенно с шаблонами). Союзы, с другой стороны, могут разбить систему типов на месте. Обратите внимание, что полиморфизм и инкапсуляция идут рука об руку: все, что подлежит изменению, скрыто от пользователя (либо через vtables, либо во время компиляции, либо путем переинтерпретации данных).

Достаточно ли этого, чтобы обозначить союзы как часть стиля программирования OO, кажется для меня вопросом вкуса.