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でした：

  標準レイアウト共用体に共通の初期シーケンスを共有する複数の標準レイアウト構造体が含まれ、この標準レイアウト共用体タイプのオブジェクトに標準レイアウト構造体の1つが含まれている場合、任意の共通初期シーケンスを検査することが許可されています標準レイアウトの構造体メンバーの。§9.2/ 19：対応するメンバーにレイアウト互換のタイプがあり、どちらのメンバーもビットフィールドではないか、1つ以上の初期シーケンスの幅が同じビットフィールドである場合、2つの標準レイアウト構造体は共通の初期シーケンスを共有しますメンバー。

• Cにいる間（C99 TC3-DR 283以降）、これを行うことは合法です（これをもたらしたPascal Cuoqに感謝します）。ただし、読み取った値が読み取られた型に対して無効である（いわゆる「トラップ表現」）場合、未定義の動作が発生する可能性があります。それ以外の場合、読み取られる値は実装定義です。

• C89 / 90はこれを不特定の動作（Annex J）の下で呼びかけ、K＆Rの本はその実装は定義されていると述べています。K＆Rからの引用：

  これが共用体の目的です-いくつかのタイプのいずれかを合法的に保持できる単一の変数。[...]使用法に一貫性がある限り：取得したタイプは、最後に保存されたタイプでなければなりません。ユニオンに現在格納されているタイプを追跡するのはプログラマの責任です。何かが1つのタイプとして格納され、別のタイプとして抽出される場合、結果は実装に依存します。

• StroustrupのTC ++ PLからの抜粋（私の強調）

  ユニオンの使用は、データの互換性のために不可欠です[...] 「型変換」に誤用されることがあります。

何よりも、この質問（私の質問以来、タイトルは変更されていません）は、共用体の目的を理解することを意図して提起されました。たとえば、コードの再利用のための継承の使用はもちろんC ++標準で許可されていますが、C ++言語の機能として継承を導入する目的や本来の意図ではありません。これが、アンドレイの答えが受け入れられたままである理由です。

労働組合の目的はかなり明白ですが、なぜか人々はそれをかなり頻繁に見逃します。

unionの目的は、同じメモリ領域を使用して異なる時間に異なるオブジェクトを格納することでメモリを節約することです。それでおしまい。

ホテルの部屋のようなものです。さまざまな人々が重なり合っていない期間住んでいます。これらの人々は会うことはなく、一般にお互いについて何も知りません。部屋のタイムシェアリングを適切に管理することにより（つまり、異なる人々が1つの部屋に同時に割り当てられないようにすることで）、比較的小さなホテルは、比較的多数の人々に宿泊施設を提供できます。のためです。

それこそ、組合が行うことです。プログラム内のいくつかのオブジェクトが値ライフタイムが重複しない値を保持していることがわかっている場合は、これらのオブジェクトをユニオンに「マージ」して、メモリを節約できます。ホテルの部屋の各瞬間に最大1つの「アクティブな」テナントがあるのと同じように、組合はプログラムの各瞬間に最大で1つの「アクティブな」メンバーを持っています。「アクティブな」メンバーだけが読み取ることができます。他のメンバーに書き込むことにより、「アクティブ」ステータスをその他のメンバーに切り替えます。

なんらかの理由で、このユニオンの本来の目的は、まったく異なるもので「オーバーライド」されました。ユニオンの1つのメンバーを記述し、別のメンバーを通してそれを検査します。この種のメモリの再解釈（別名「タイプパニング」）は、共用体の有効な使用法ではありません。通常、未定義の動作につながり、C89 / 90で実装定義の動作を生成すると説明されています。

編集：タイプのパンニング（つまり、あるメンバーを書き込んでから別のメンバーを読み取る）の目的でユニオンを使用することは、C99標準のテクニカルコリジェンダの1つでより詳細な定義が与えられました（DR＃257およびDR＃283を参照）。ただし、正式にこれがトラップ表現を読み取ろうとして未定義の動作が発生するのを防ぐことはできないことに注意してください。

unionを使用して、次のような構造体を作成できます。これには、実際に使用されているunionのコンポーネントを示すフィールドが含まれています。

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

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

言語の観点からは、動作は未定義です。プラットフォームが異なれば、メモリの配置やエンディアンの制約も異なる可能性があることを考慮してください。ビッグエンディアンマシンとリトルエンディアンマシンのコードは、構造体の値を異なる方法で更新します。言語の動作を修正するには、すべての実装で同じエンディアン（およびメモリ配置の制約...）を使用して使用を制限する必要があります。

C ++を使用していて（2つのタグを使用している）、移植性を本当に気にしている場合は、構造体を使用して、uint32_tビットマスク操作でフィールドを受け取り、フィールドを適切に設定するセッターを提供できます。Cでも関数を使用して同じことができます。

編集：私はAProgrammerが投票の回答を書き留めて、これを閉じることを期待していました。一部のコメントで指摘されているように、エンディアンは標準のほかの部分では各実装に何をするかを決定させることによって処理され、配置とパディングも異なる方法で処理できます。ここで、AProgrammerが暗黙的に参照する厳密なエイリアシングルールは、ここで重要なポイントです。コンパイラーは、変数の変更（または変更の欠如）を仮定することができます。共用体の場合、コンパイラーは命令を並べ替えて、各色成分の読み取りをcolor変数への書き込みに移動できます。

私が定期的に遭遇する最も一般的な使用法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;

場合によっては、名前でアクセスするのが最も明確な方法です。その他の場合、特に軸がプログラムで選択されている場合は、数値インデックスで軸にアクセスする方が簡単です。xの場合は0、yの場合は1、zの場合は2です。

あなたが言うように、これは厳密に定義されていない動作ですが、多くのプラットフォームで「動作」します。共用体を使用する本当の理由は、バリアントレコードを作成することです。

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;

litlleメモリの場合、この構造はすべてのメンバーを持つ構造体よりも少ないメモリを使用します。

ちなみに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がunionの安全なバージョンを実装し、未定義の動作をできるだけ防ぐように設計されています。

そのパフォーマンスは構成体と同じですenum + union（スタックも割り当てられます）。ただし、enum:) ではなく型のテンプレートリストを使用します。

動作は未定義かもしれませんが、それは単に「標準」がないことを意味します。すべての適切なコンパイラは、パッキングとアラインメントを制御するための#pragmaを提供していますが、デフォルトが異なる場合があります。デフォルトは、使用する最適化設定によっても異なります。

また、ユニオンはスペースを節約するためだけのものではありません。これらは、型パンニングを使用して最新のコンパイラーを支援できます。あなたがreinterpret_cast<>すべての場合、コンパイラはあなたが何をしているのかについて仮定を立てることができません。それはあなたのタイプについて知っていることを捨てて、そして最初からやり直さなければならないかもしれません（CPUクロック速度と比較して最近は非常に非効率的なメモリへのライトバックを強制します）。

技術的には未定義ですが、実際にはほとんどの（すべての）コンパイラはreinterpret_cast、ある型から別の型への使用とまったく同じように扱い、その結果、実装が定義されます。私はあなたの現在のコードで眠りを失うことはありません。

ユニオンの実際の使用のもう1つの例として、CORBAフレームワークは、タグ付きユニオンアプローチを使用してオブジェクトをシリアル化します。すべてのユーザー定義クラスは1つの（巨大な）ユニオンのメンバーであり、整数識別子はデマーシャラーにユニオンの解釈方法を指示します。

他の人はアーキテクチャの違いに言及しています（リトル-ビッグエンディアン）。

変数のメモリは共有されているため、1つに書き込むと他の変数が変化し、型によっては値が無意味になるという問題を読みました。

例えば。union {float f; int i; } バツ;

xiへの書き込みは、その後xfから読み取る場合は意味がありません。フロートの符号、指数、または仮数コンポーネントを確認するために意図したものでない限り、

アラインメントの問題もあると思います。いくつかの変数をワードアラインメントにする必要がある場合、期待した結果が得られない可能性があります。

例えば。union {char c [4]; int i; } バツ;

仮に、一部のマシンでcharをワード境界で整列させる必要がある場合、c [0]およびc [1]はiとストレージを共有しますが、c [2]およびc [3]は共有しません。

1974年に文書化されたC言語では、すべての構造体メンバーが共通の名前空間を共有し、「ptr-> member」の意味は「ptr」にメンバーの変位を追加し、メンバーのタイプを使用して結果のアドレスにアクセスすることとして定義されました。この設計により、異なる構造定義から取得されたメンバー名で同じオフセットを持つ同じptrを使用できるようになりました。プログラマーは、さまざまな目的でその機能を使用しました。

構造体メンバーに独自の名前空間が割り当てられると、2つの構造体メンバーを同じ変位で宣言することができなくなりました。言語に共用体を追加すると、以前のバージョンの言語で使用可能であったのと同じセマンティクスを実現することが可能になりました（ただし、名前を囲んでいるコンテキストにエクスポートできないため、検索/置換を使用してfoo-> memberを置き換える必要があったかもしれませんfoo-> type1.memberに）。重要なことは、共用体を追加した人々が特定のターゲットの使用法を念頭に置いていることではなく、以前のセマンティクスに依存していたプログラマーが目的を問わず、それを達成できる手段を提供することでした。彼らがそれを行うために異なる構文を使用しなければならなかったとしても、同じ意味論。

ユニオンを使用できる主な理由は2つあります。

1. あなたの例のように、異なる方法で同じデータにアクセスする便利な方法
2. 異なるデータメンバーが1つしか「アクティブ」にできない場合にスペースを節約する方法

1ターゲットシステムのメモリアーキテクチャがどのように機能するかを知っていることに基づいて、コードを短く書くためのCスタイルのハックです。すでに述べたように、実際には多くの異なるプラットフォームを対象としない場合は、通常はそれを回避できます。一部のコンパイラでは、パッキングディレクティブも使用できるようになっていると思います（構造体でも使用できます）。

2.の良い例は、COMで広く使用されているVARIANT型にあります。

他の人が述べたように、列挙型と結合され、構造体にラップされた共用体は、タグ付き共用体を実装するために使用できます。実用的な使い方の1つは、Rustを実装することです。Rust 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;
}