//ISO-8859
char a = 'A';
unsigned char b = reinterpret_cast<unsigned char const &>(a);
char c = reinterpret_cast<char const &>(b);

std::cout << c << std::endl; //sicher 'A' als Ausgabe?

Wenn du das const& bei beiden reinterpret_casts weglässt wirds vielleicht was

Dann kompiliert es gar nicht erst...

Mal 'ne ganz doofe Frage:

Soo doof kann die Frage gar nicht sein, wenn es widersprüchliche Antworten gibt.

Tachyon schrieb:

Ist das hier wohl definiert:

//ISO-8859
char a = 'A';
unsigned char b = reinterpret_cast<unsigned char const &>(a);
char c = reinterpret_cast<char const &>(b);

std::cout << c << std::endl; //sicher 'A' als Ausgabe?

Ich sag mal ja. Ich wüsste nicht, warum das nicht klappen sollte. Normalerweise sollten einem da die Alarmglocken anspringen, da Du mit dem reinterpret_cast<T&> ganz schnell §3.10/15 verletzen kannst. Aber hier verwendest Du char und 3.10/15 macht für char eine Ausnahme. Außerdem darf man jedes POD-Objekt über unsigned char* "untersuchen". Nach meinem Verständnis ist garantiert, dass jedes Bitmuster ein gültiger unsigned char-Wert ist (garantiert keine Füllbits).

Anders herum wäre das möglicherweise problematischer, also unsigned char -> char -> unsigned char (per reinterpret_cast<T&>), da ein unsigned char mit Wert 128 ein ungültiges char-Bit-Muster sein könnte ("negative Null" in der Sign+Magnitude-Darstellung). Bin mir da aber nicht sicher. Dein Beispiel sollte jedenfalls problemfrei sein.

yahendrik schrieb:

Aber wäre es nicht besser, einen static_cast<char> bzw. static_cast<unsigned char> anzuwenden?
Ich habe es jetzt mit den mir zur Verfügung stehenden Compilern getestet und auch immer die "erwartete" Ausgabe erhalten, aber der Umweg über die Referenz sieht irgendwie ...komisch aus.

Versuch es mal mit einer größeren "Zahl", also z.B. ä.

Mal 'ne ganz doofe Frage:
Ist das hier wohl definiert:

//ISO-8859
char a = 'A';
unsigned char b = reinterpret_cast<unsigned char const &>(a);
char c = reinterpret_cast<char const &>(b);

std::cout << c << std::endl; //sicher 'A' als Ausgabe?

Wohldefiniert (5.2.10/10). Da unsigned char das gleiche Alignment hat wie char, kann hier nichts schiefgehen.
3.10/15 spielt hier gar keine Rolle, da ja nicht mittels b auf den Wert von a zugegriffen wird (was in diesem speziellen Fall allerdings unproblematisch wäre, da Zugriffe über unsigned char immer zulässig sind).

/* C */
char blub = 'Ä';
unsigned char u_blub = *((unsigned char*)&blub);
char blub2 = *((char*)&u_blub);

// C++
char foo = 'ä';
unsigned char bar = *(reinterpret_cast<unsigned char*>(&foo));
char foo2 = *(reinterpret_cast<char*>(&bar));

oder?

also zumindest funktioniert das immer...

@camper:
Bist du sicher dass das mit den Referenzen OK geht?
Ich hätte hier Zeiger verwendet...

sorry, falsch gelesen, ich meinte so etwas wie

char a = 'A';
const unsigned char& b = reinterpret_cast<unsigned char const &>(a);
const char& c = reinterpret_cast<char const &>(b);

Ohne Referenzinitialisierung steht da nat. im Anschluss zum Cast eine l-zu-rvalue Konvertierung, mithin ein Zugriff, für den 3.10/15 zuständig ist.

Ansonsten ist das genau so wie ich das auch immer tun würde. Zum Einen hat das Ganze nichts mit Zeigern als Solchen zu tun, zudem funktioniert die Zeigervariante nicht, sobald ein überladener &-Operator im Spiel ist.
Ich habe nichts gegen die C-Variante, dort geht das nicht anders; für C++ sieht reinterpret_cast+Zeiger immer ein wenig wie gewollt und nicht gekonnt aus.

@camper:
Bist du sicher dass das mit den Referenzen OK geht?
Ich hätte hier Zeiger verwendet...

5.2.10 §10 beschreibt ja gerade die Sache mit den Referenzen. Allerdings ist da von lvalues und casts auf T& und nicht auf T const & die Rede. Ich bin mir da nicht sicher, ob const von §2 abgedeckt wird.

Danke auf jeden Fall erstmal.

mMn. ist das ein Fall für memcpy() bzw. Kopieren mittels "unsigned char*".

Also kurz gesagt, ich hätte es so gemacht wie DrakoXP (C++ Variante).

Der überladene operator & ist ja kein Ding bei eingebauten Typen wie char/unsigned char.

Außerdem darf man jedes POD-Objekt über unsigned char* "untersuchen".

Man darf auch jedes Objekt (bzw. seinen Speicher -- auch nicht-PODs) über unsigned char* überschreiben.
Von daher vermute ich mal dass man auch nicht-PODs über unsigned char* untersuchen darf.

Anders herum wäre das möglicherweise problematischer, also unsigned char -> char -> unsigned char (per reinterpret_cast<T&>), da ein unsigned char mit Wert 128 ein ungültiges char-Bit-Muster sein könnte ("negative Null" in der Sign+Magnitude-Darstellung)

Gilt die "jedes Bitmuster OK" Garantie nur für "unsigned char" und nicht für "char"?
Würde mich jetzt etwas wundern, ich hab irgendwie in Erinnerung dass man auch mit nem "char*" jedes Objekt "untersuchen" darf - und das ginge ja nicht, wenn es für "char" ungültige Bitmuster gäbe...

@Tachyon:

mMn. ist das ein Fall für memcpy() bzw. Kopieren mittels "unsigned char*"..

Würde ich auch so machen, nur ist der Zieltyp von unsigned char -> char ein std::string , und da kann ich nicht einfach mit memcpy reinkopieren.

3.10/15 spielt hier gar keine Rolle, da ja nicht mittels b auf den Wert von a zugegriffen wird

Na klar spielt das eine Rolle. Mit b hat das nichts zu tun, aber der Ausdruck reinterpret_cast<char const&>(a) ist ein Lvalue-Ausdruck, der sich Speicher-technisch auf a bezieht, aber einen anderen Typ hat als a. 3.10/15 beschreibt und erlaubt diesen Fall (keine Aliasingprobleme bei char<->unsigned char). Und reinterpret_cast<T&>(x) ist äquivalent zu (*reinterpret_cast<T*>(&x)).

hustbaer schrieb:

Gilt die "jedes Bitmuster OK" Garantie nur für "unsigned char" und nicht für "char"?

Ich denke schon, dass das gilt. Allerdings habe ich ein Problem mit anderen Zahlendarstellungsformen für negative Ganzzahlen, die mir theoretisch zwei Nullen bieten, "+0" und "-0":

sign+magnitude  1's complement  "Wert"
--------------------------------------
   00000000        00000000      "+0"
   10000000        11111111      "-0"

Mit einem vorzeichenbehafteten char kann ich in so einem Fall anhand des Ganbzzahlwertes diese Bitmuster nicht mehr unterscheiden.

Ich gehe aber zZ davon aus, dass, falls die Maschine eine solche "komische" Zahlendarstellung verwendet, char gar nicht vorzeichenbehaftet ist. Ein vorzeichenbehaftetes char kann man sich eigentlich nur mit dem Zweierkomplement erlauben -- denke ich mal.

kk

#include <iostream>

int main()
{
        char a = 'a';
        unsigned char b = a;
        char c = b;
        std::cout << a << std::endl;
        std::cout << b << std::endl;
        std::cout << c << std::endl;
}

http://ideone.com/RCgMR

camper schrieb:

3.10/15 spielt hier gar keine Rolle, da ja nicht mittels b auf den Wert von a zugegriffen wird

Na klar spielt das eine Rolle. Mit b hat das nichts zu tun, aber der Ausdruck reinterpret_cast<char const&>(a) ist ein Lvalue-Ausdruck, der sich Speicher-technisch auf a bezieht, aber einen anderen Typ hat als a. 3.10/15 beschreibt und erlaubt diesen Fall (keine Aliasingprobleme bei char<->unsigned char). Und reinterpret_cast<T&>(x) ist äquivalent zu (*reinterpret_cast<T*>(&x)).

Ja, ich hatte das bereits korrigiert.

krümelkacker schrieb:

hustbaer schrieb:

Gilt die "jedes Bitmuster OK" Garantie nur für "unsigned char" und nicht für "char"?

Ich denke schon, dass das gilt. Allerdings habe ich ein Problem mit anderen Zahlendarstellungsformen für negative Ganzzahlen, die mir theoretisch zwei Nullen bieten, "+0" und "-0":

sign+magnitude  1's complement  "Wert"
--------------------------------------
   00000000        00000000      "+0"
   10000000        11111111      "-0"

Mit einem vorzeichenbehafteten char kann ich in so einem Fall anhand des Ganbzzahlwertes diese Bitmuster nicht mehr unterscheiden.

Ich gehe aber zZ davon aus, dass, falls die Maschine eine solche "komische" Zahlendarstellung verwendet, char gar nicht vorzeichenbehaftet ist. Ein vorzeichenbehaftetes char kann man sich eigentlich nur mit dem Zweierkomplement erlauben -- denke ich mal.

kk

Weder C noch C++ verlangen, dass die Bitkombination 10000000 (Zweierkomplement oder sign+magnitude) bzw. 11111111 (Einserkomplement) - bzw. entsprechend länger wenn chars mehr als 8 bit haben - bei vorzeichenbehafteten chars ein Zahl ist. In keinem Fall handelt es sich aber um eine Trapdarstellung, C99:6.2.6.2/5 bezieht sich nur auf Typen, die keine Zeichentypen sind.

Wenn (in einer bestimmten Implementation) Einserkomplement oder sign+magnitude verwendet wird und die obigen Objektdarstellungen eine Zahl darstellen so handelt es sich um eine negative Null. Rechenregeln und anderes dazu findet sich im C-Standard (C99:6.2.6.2/3).