Wie hieß denn noch der Datentyp ?

camper

Michael E. schrieb:

Du greifst aber nicht auf das Objekt, sondern auf einen Member des Objekts zu.

Subobjekte sind keine Objekte?

Michael E. schrieb:

Wieso?

Dazu schreib ich später noch was.

Michael E. schrieb:

camper schrieb:

Michael E. schrieb:

Nur was rauskommt, weiß man nicht Ist es Big Endian oder Little Endian? Verhält char sich wie signed char oder wie unsigned char? Warum werden die Bits in einem Char nicht in einer anderen Reihenfolge interpretiert als bei einem int-Byte? Warum ist es überhaupt definiert?

Einige dieser Fragen werden durch den Standard geklärt, andere müssen von der jeweiligen Implementation definiert werden.

Welche werden denn vom Standard geklärt?

Warum ist es überhaupt definiert?

3.9, 3.9.1

Warum werden die Bits in einem Char nicht in einer anderen Reihenfolge interpretiert als bei einem int-Byte?

Das ist eine sinnlose Frage: da bytes die kleinste adressierbare Einheit darstellen, existiert soetwas wie eine Reihenfolge von Bits innerhalb eines chars nicht, ansonsten 3.9.1/7

SeppJ

camper schrieb:

Warum werden die Bits in einem Char nicht in einer anderen Reihenfolge interpretiert als bei einem int-Byte?

Das ist eine sinnlose Frage: da bytes die kleinste adressierbare Einheit darstellen, existiert soetwas wie eine Reihenfolge von Bits innerhalb eines chars nicht, ansonsten 3.9.1/7

Nur weil du nicht auf die interne Darstellung zugreifen kannst, heißt das nicht, dass sie nicht unterschiedlich sein dürfte. Die zugrundeliegende Hardware hat schließlich nicht die Einschränkungen den Programmierers.

Michael E.

camper schrieb:

Michael E. schrieb:

Du greifst aber nicht auf das Objekt, sondern auf einen Member des Objekts zu.

Subobjekte sind keine Objekte?

Du sagst, dass du auf das gleiche Objekt zugreifst.

Warum ist es überhaupt definiert?

3.9, 3.9.1

Kannst du das bitte etwas konkretisieren?

Warum werden die Bits in einem Char nicht in einer anderen Reihenfolge interpretiert als bei einem int-Byte?

Das ist eine sinnlose Frage: da bytes die kleinste adressierbare Einheit darstellen, existiert soetwas wie eine Reihenfolge von Bits innerhalb eines chars nicht, ansonsten 3.9.1/7

Die Reihenfolge existiert sehr wohl, wie SeppJ schon bemerkt hat. Außerdem kann ich in 3.9.1/7 nicht sehen, dass die Reihenfolge festgelegt wird.

camper

Michael E. schrieb:

camper schrieb:

Michael E. schrieb:

Du greifst aber nicht auf das Objekt, sondern auf einen Member des Objekts zu.

Subobjekte sind keine Objekte?

Du sagst, dass du auf das gleiche Objekt zugreifst.

Objekte sind bestimmte Speicherbereiche. Greife ich auf den gleichen Speicherbereich zu, ist es das gleiche Objekt.

Warum ist es überhaupt definiert?

3.9, 3.9.1

Kannst du das bitte etwas konkretisieren?

Wenn die Frage konkretisiert wird.

Michael E. schrieb:

Warum werden die Bits in einem Char nicht in einer anderen Reihenfolge interpretiert als bei einem int-Byte?

Das ist eine sinnlose Frage: da bytes die kleinste adressierbare Einheit darstellen, existiert soetwas wie eine Reihenfolge von Bits innerhalb eines chars nicht, ansonsten 3.9.1/7

Die Reihenfolge existiert sehr wohl, wie SeppJ schon bemerkt hat. Außerdem kann ich in 3.9.1/7 nicht sehen, dass die Reihenfolge festgelegt wird.

Bevor ich mich auf Glatteise begebe, bitte ich um eine präzisere Fragestellung. Der Standard kennt keine Reihenfolgen von bits, nur Wertigkeiten.

Michael E.

camper schrieb:

Michael E. schrieb:

camper schrieb:

Michael E. schrieb:

Du greifst aber nicht auf das Objekt, sondern auf einen Member des Objekts zu.

Subobjekte sind keine Objekte?

Du sagst, dass du auf das gleiche Objekt zugreifst.

Objekte sind bestimmte Speicherbereiche. Greife ich auf den gleichen Speicherbereich zu, ist es das gleiche Objekt.

struct Foo
{
    int bar;
};

Foo foo;

Sind foo und foo.bar das gleiche Objekt?

Kannst du das bitte etwas konkretisieren?

Wenn die Frage konkretisiert wird.

Warum ist der Zugriff auf blab[0] nicht undefiniert, wenn der letzte schreibende Zugriff auf bla war?

Michael E. schrieb:

Die Reihenfolge existiert sehr wohl, wie SeppJ schon bemerkt hat. Außerdem kann ich in 3.9.1/7 nicht sehen, dass die Reihenfolge festgelegt wird.

Bevor ich mich auf Glatteise begebe, bitte ich um eine präzisere Fragestellung. Der Standard kennt keine Reihenfolgen von bits, nur Wertigkeiten.

Warum ist Folgendes nicht möglich? Bei chars steht das höchstwertige Bit vorne im Byte, bei ints steht das höchstwertige Bit hinten im Byte. Wenn ich einen int schreibe und einen char an dieser Position lese, wurden die Wertigkeiten verändert.

camper

Michael E. schrieb:

camper schrieb:

Michael E. schrieb:

camper schrieb:

Michael E. schrieb:

Du greifst aber nicht auf das Objekt, sondern auf einen Member des Objekts zu.

Subobjekte sind keine Objekte?

Du sagst, dass du auf das gleiche Objekt zugreifst.

Objekte sind bestimmte Speicherbereiche. Greife ich auf den gleichen Speicherbereich zu, ist es das gleiche Objekt.
struct Foo
{
    int bar;
};

Foo foo;
Sind foo und foo.bar das gleiche Objekt?

Definiere: Zugriff: = entweder
1.[lesen] bestimmen des Zustandes (=Objektrepräsentation) eines Speicherbereiches (Objekt); ermittle daraus Wertrepräsentation und schließlich den Wert selbst
2. [schreiben] ausgehend von einem Wert codiere Wert- und schließlich Objektrepräsentation, festlegen des Zustandes eines Speicherbereiches (Objekt) auf diese Objektrepräsentation

Jeder Zugriff auf foo.bar, greift notwendigerweise auch auf foo zu, da foo.bar ein Teil von foo ist. Die Umkehrung gilt nur bedingt.

Warum ist der Zugriff auf blab[0] nicht undefiniert, wenn der letzte schreibende Zugriff auf bla war?

Ihrem Ursprung nach gibt es zwei Arten von undefiniert:
- solchen Dingen, zu denen der Standard sich nicht äußert,
- solchen, die ausdrücklich ausgeschlossen werden; und für die andernfalls eine Interpretation gefunden werden könnte
blab[0] hat auf jeden Fall eine bestimmten Zustand (dazwischenliegende Sequenzpunkte angenommen, etc.), und ein Zugriff auf blab[0] hängt (nur) von dessen Zustand ab. Bis hierhin muss ich hoffentlich nicht den Standard zitieren.
Es könnte sein, dass der Zugriff trotzdem ausdrücklich ausgeschlossen ist. Da ich hier nicht den gesamten Standard untersuchen kann, behaupte ich, dass eine solche Regel für die Fälle, die bisher betrachtet wurden, nicht existiert.

Warum ist Folgendes nicht möglich? Bei chars steht das höchstwertige Bit vorne im Byte, bei ints steht das höchstwertige Bit hinten im Byte. Wenn ich einen int schreibe und einen char an dieser Position lese, wurden die Wertigkeiten verändert.

Das ist möglich. Allerdings wird diese Problematik bereits durch die Frage nach Endianess erfasst (oder umgekehrt). Ich nahm natürlich an, dass du auf verschiedene Probleme hinweisen wolltest. Ich meine, Paddingbits und Traprepräsentation wurden ja auch nicht angesprochen. Ultimativ hat das ohnehin wenig mit ursprünglichen Code zu tun.

TyRoXx schrieb:

Wozu denn dieses union -Gefrickel, wenn man doch etwas ganz anderes erreichen möchte?
int i = 12;
char *p = reinterpret_cast<char *>(&i);
if (*p == 12)
	..

Weil auch das undefiniert ist (strict aliasing)

TyRoXx

asdfasd schrieb:

TyRoXx schrieb:
Wozu denn dieses union -Gefrickel, wenn man doch etwas ganz anderes erreichen möchte?
int i = 12;
char *p = reinterpret_cast<char *>(&i);
if (*p == 12)
	..
Weil auch das undefiniert ist (strict aliasing)

Ich dachte bei char eben nicht? Dann nutzt memcpy also undefiniertes Verhalten?

Bashar

Ich denke, es geht um den Typ char. Man kann ein Objekt als Sequenz von unsigned char interpretieren, aber nicht unbedingt von char.

camper

asdfasd schrieb:

TyRoXx schrieb:
Wozu denn dieses union -Gefrickel, wenn man doch etwas ganz anderes erreichen möchte?
int i = 12;
char *p = reinterpret_cast<char *>(&i);
if (*p == 12)
	..
Weil auch das undefiniert ist (strict aliasing)

Ich wage zu widersprechen.