nicht umsonst finden unions begrenzte anwendung.

Verwunderlich, da es doch der Zweck von unions ist, ein und denselben Speicherbereich mal so, mal anders zu interpretieren...

greetz, Swordfish

thordk schrieb:

nicht umsonst finden unions begrenzte anwendung.

Verwunderlich, da es doch der Zweck von unions ist, ein und denselben Speicherbereich mal so, mal anders zu interpretieren...

greetz, Swordfish

und genau das ist ja auch der grund, warum sie so selten anwendung finden. speicherbereich "mal so und mal so" zu interpretieren ist ne c/c++ eigenart. die meisten anderen sprachen setzen auf typsicherheit und lassen sowas von vornherein gar nicht zu.

es gibt durchaus trifftige gründe mal nen union einzusetzen, aber diese sind selten. mir fällt z.b. nicht ein problem ein, für das man unbedingt unions einsetzen müsste. und selbst für solche, in denen unions "praktisch" sind, würd ich anderen varianten den vorzug geben.

Ansonsten sowas:

struct my_variant {
  enum { is_int, is_double } kind;
  union {
    int int_value;
    double double_value;
  } x;
};

und genau das ist ja auch der grund, warum sie so selten anwendung finden. speicherbereich "mal so und mal so" zu interpretieren ist ne c/c++ eigenart. die meisten anderen sprachen setzen auf typsicherheit und lassen sowas von vornherein gar nicht zu.

Die "meisten anderen Sprachen" schließen ja auch nicht alle Anwendungsbereich von C, C++ ab.

thordk schrieb:

es gibt durchaus trifftige gründe mal nen union einzusetzen, aber diese sind selten. mir fällt z.b. nicht ein problem ein, für das man unbedingt unions einsetzen müsste. und selbst für solche, in denen unions "praktisch" sind, würd ich anderen varianten den vorzug geben.

Tagged Unions wären durchaus höchst interessant.

nicht umsonst finden unions begrenzte anwendung. wenn man z.b. nen int und nen double in nen union klatscht, bekommt man sehr wahrscheinlich nur blödsinn heraus, wenn man einen der beiden mit nem wert füllt und den anderen ausliest.

Was man dabei herausbekommt, ist undefiniertes Verhalten. Unions sind keine "Cast-Maschine" sondern Platz-Spar-Dinger. Ganz so lässig geht C++ mit Typen auch nicht um.

Swordfish schrieb:

thordk schrieb:

nicht umsonst finden unions begrenzte anwendung.

Verwunderlich, da es doch der Zweck von unions ist, ein und denselben Speicherbereich mal so, mal anders zu interpretieren...

Richtig. Allerdings nur in einem wohldefinierten Rahmen. Wer nen int reinschreibt, darf auch nur nen int auslesen.

es gibt durchaus trifftige gründe mal nen union einzusetzen, aber diese sind selten. mir fällt z.b. nicht ein problem ein, für das man unbedingt unions einsetzen müsste. und selbst für solche, in denen unions "praktisch" sind, würd ich anderen varianten den vorzug geben.

Warum etwas anderes verwenden, wenn das Vorhandene bereits praktisch ist? Das Problem mit unions ist doch vielmehr, dass sie so selten praktisch sind. Denn meistens will man Tagged Unions und nicht-triviale udts in einer Union. Wenn beides ncht der Fall ist (weil sich der Inhalt der Union z.B. implizit ergibt und man mit PODs gut hinkommt), was spricht dann gegen die Anwendung einer Union?

Warum etwas anderes verwenden, wenn das Vorhandene bereits praktisch ist? Das Problem mit unions ist doch vielmehr, dass sie so selten praktisch sind. Denn meistens will man Tagged Unions und nicht-triviale udts in einer Union. Wenn beides ncht der Fall ist (weil sich der Inhalt der Union z.B. implizit ergibt und man mit PODs gut hinkommt), was spricht dann gegen die Anwendung einer Union?

Könntest du das bitte noch einmal vernünftig in deutscher Sprache formulieren ?
Danke.

Könntest du das bitte noch einmal vernünftig in deutscher Sprache formulieren ?

Ist halt Fachsprache.

Tagged Union = das, was der Fragesteller wollte.
POD = plain old data, vereinfacht "alles, was keine Klasse ist"
nicht-trivialer UDT = (user-defined type), das Gegenteil eines POD

http://tutorial.schornboeck.net/union.htm

Ist das Tutorial von Shade of Mine dann in diesem Punkt falsch?

http://tutorial.schornboeck.net/union.htm

In welchem Punkt?

Also ich meine das letzte Beispiel auf der Seite. Es wurde ja gesagt das man nur den Member auslesen darf den man zuletzt geschrieben hat.

Nein, Du darfst machen, was Du willst. Nur die Sinnhaftigkeit davon kann man in Frage stellen und in seinem Tutorial weist weist Shade ja auch darauf hin, dass dieser Beispielcode nur unter gewissen Rahmenbedingungen sinnvoll ist; nämlich dann, wenn sich ein int in vier Bytes aufgliedert und ein char gleich einem Byte ist.

Nein, Du darfst machen, was Du willst.

Nicht wenn du im Rahmen des Standards bleiben willst. Dieser ist in diesem Punkt sehr klar: du darfst nur auf das Element lesend zugreifen, dass als letztes geschrieben wurde. Andernfalls hat das Programm undefiniertes Verhalten und is damit kein legales C++ (Es gibt zwei kleine Ausnahmen bzgl. unsigned chars und PODs mit gleicher "initialer Sequenz"). Das Beispiel in Shades Tutorial ist kein gültiges Standard-C++.

Konrad Rudolph schrieb:

Nein, Du darfst machen, was Du willst.

Dieser [Standard] ist in diesem Punkt sehr klar: du darfst nur auf das Element lesend zugreifen, dass als letztes geschrieben wurde.

Ups, dann nehme ich alles zurück und behaupte das Gegenteil.