Ich schaue mir gerade die Unions in C an und sehe mit Freude,das nun auch C sich des Konzeptes von Pascal annähert, mit einer Verbesserung. Tatsächlich wird bei Diskussioneen C vs. Pascal immer der Nachteil von C von vielen C Porgrammierern als großer Vorteil gefeiert..interessanterweise werde aber mit vielen Neuerungen in C diese so hochgefeierten "Vorteile" entschärft. Bei den Unions z.B. das die Pointerarien in C nicht mehr zwingend erforderlich sind. Es gibt natürlich auch Unterschiede zu Types in Pascal..logisch..Unions sollen ja auch ein komplett neues Konzept sein, was ja auch nicht schlecht sein muss. https://www.learn-c.org/de/Unions
kein gast schrieb: > das nun auch C sich des Konzeptes von Pascal annähert Nun? ? Was genau soll denn hier neu sein?
Häh? C-Unions entsprechen sog. "varianten Records" in Pascal.
kein gast schrieb: > das nun > auch C sich des Konzeptes von Pascal annähert kein gast schrieb: > interessanterweise werde aber mit vielen Neuerungen in C Bitte was? Neuerungen in C? Unions? Hast du die letzten 40 Jahre geschlafen, oder wie?
Also ich dachte, das unions bereits im Original K&R drin sind. Mein Buch liegt aber zuhause, da kann ich nicht nachschlagen. Wer das aber jetzt erst merkt, der muß wirklich sehr lange geschlafen haben, oder ein sehr langsame Lesegeschwindigkeit besitzen.
kein gast schrieb: > Bei den Unions z.B. das die Pointerarien in C nicht mehr zwingend > erforderlich sind. Du meinst type punning? Das geht mit Unions auch nicht.
A. S. schrieb: > Du meinst type punning? Das geht mit Unions auch nicht. Doch, ab C99 ist das erlaubt - nicht jedoch in C++.
kein gast schrieb: > Tatsächlich wird bei Diskussioneen C vs. Pascal immer der Nachteil von > C von vielen C Porgrammierern als großer Vorteil > gefeiert.. Was ist denn "der Nachteil von C"? > interessanterweise werde aber mit vielen Neuerungen in C diese > so hochgefeierten "Vorteile" entschärft. Was für Neuerungen? Wenn du tatsächlich das Type Punning meinen solltest: Das ist seit 20 Jahren in C erlaubt. > Bei den Unions z.B. das die Pointerarien in C nicht mehr zwingend > erforderlich sind. Was meinst du mit "Pointerarien"? Nop schrieb: > A. S. schrieb: > >> Du meinst type punning? Das geht mit Unions auch nicht. > > Doch, ab C99 ist das erlaubt - nicht jedoch in C++. Allerdings hab ich nie verstanden, was da so toll dran sein soll. Warum soll ich mir extra einen neuen Typ definieren, da meine Werte rein und wieder rauskopieren, nur um da eine Typumwandlung zu machen? Ein Cast ist doch viel einfacher.
:
Bearbeitet durch User
kein gast schrieb: > Ich schaue mir gerade die Unions in C an und sehe mit Freude,das nun > auch C sich des Konzeptes von Pascal annähert, mit einer Verbesserung. Ja, endlich ist es soweit: Es gibt ab sofort (d.h. seit ca. 45 Jahren) Unions auch in C. In Pascal (dort Variant-Records genannt) gibt es sie allerdings schon ein paar Jahre länger. In Ur-C von 1972 gab es weder Structs noch Unions. Die Structs kamen 1973, die Unions noch etwas später. Pascal hatte die Variant-Records schon seit Beginn, also ca. 1970. Man fragt sich natürlich, warum Ritchie mit der Einführung der Unions so lange gewartet hat, obwohl er sie aus Algol 68 (auf dem C teilweise basiert) bereits gekannt haben musste. Eine Erklärung könnte die folgende sein: (Untagged) Unions verleiten zu Schmuddeloptimierungen in Form von Type-Punning, wofür sie eigentlich nicht gedacht sind. Vielleicht wollte Ritchie seine Nutzer von solch zweifelhaften Techniken abhalten. Nachdem er aber gesehen hatte, dass sogar Pascal, das damals als der neue Weg zur sauberen Programmierung angepriesen wurde, solche Dinge anstandslos zuließ, konnte er die Unions ruhigen Gewissens auch in C einführen ;-)
Rolf M. schrieb: > Ein Cast > ist doch viel einfacher. Type Punning ist mit Casts überhaupt nicht in demselben Maße möglich.
Yalu X. schrieb: > Vielleicht wollte > Ritchie seine Nutzer von solch zweifelhaften Techniken abhalten Ich weiß es zwar auch nicht, wieso und warum, ich halte aber die Erklärung eines einfachen Weges zur Polymorphie für möglich. Der Diskriminator ist allerdings extern.
Rolf M. schrieb: > Allerdings hab ich nie verstanden, was da so toll dran sein soll. Warum > soll ich mir extra einen neuen Typ definieren, da meine Werte rein und > wieder rauskopieren, nur um da eine Typumwandlung zu machen? Macht man ja nicht nur eigens wegen der Typumwandlung. Stell Dir vor, Du hast ein struct aus 4 Byte-Typen. Wenn Du das in eine Union mit uint32_t packst, kannst Du einige Operationen wie Nullen, Kopieren, Vergleichen mit fest definierten Konstanten, Ausmaskieren und Vergleichen nur bestimmter Bytes usw. mit einer 32bit-Operation über den uint32_t machen. Insbesondere wird das struct dann auch immer ein dafür passendes Alignment haben. Muß man natürlich mit der Endianess aufpassen bzw. die Konstanten ebenfalls über das Byte-struct definieren. > Ein Cast ist doch viel einfacher. Type punning durch pointer casting geht in vielen Fällen gar nicht, da undefined behaviour, und direkt casten kannst Du nur Basisdatentypen.
Hallo, PittyJ schrieb: > Also ich dachte, das unions bereits im Original K&R drin sind. Ist so (deutsche Ausgabe von 1983, die wiederum die Übersetzung der englischen Ausgabe von 1977 ist). rhf
Roland F. schrieb: > Ist so (deutsche Ausgabe von 1983, die wiederum die Übersetzung der > englischen Ausgabe von 1977 ist). > > rhf Ja, aber die m.M.n. nutzlose Variante. Wenn man einen Unionmember setzt darf man nicht durch den anderen drauf zu greifen. (Ich sage nutzlos, da ich mir ausser type punning eigentlich keine andere Anwendung für unions vorstellen kann) Und insbesondere wenn ma C als 'aufgepimpten' Assembler betrachtet: das AX register setzt sich aus AH und AL zusammen (beim x86). Dies zu modellieren passt perfekt auf type punning mit union. D.h. z.B. für einen Prozessoremulator.
Dumdi D. schrieb: > (Ich sage nutzlos, da ich mir ausser type punning eigentlich keine > andere Anwendung für unions vorstellen kann) Ja doch: du hast Telegramme, Kommandos oder NV-daten von n Bytes, die Du (per ptr) übergibst, aber je nach Typ mit unterschiedlichen Inhalten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.