Javas byte in C++(11) - ein char-Wrapper

knivil

Projektideen gibt es wie Sand am mehr. Z.b. billige Webkam kaufen und und auf das Aquarium richten. Bewegung der Fische verfolgen lassen. Alternativ auf die Strasse richten und Autos tracken. Idee stammt nicht von mir, das Thema kam hier im Forum mal auf.

Alternativ Handgestenerkennenung, oder erstmal bis zum Punkt: Livestream einlesen, Hand und Fingerkuppen extrahieren, etc. ....

krümelkacker

Ich finde auch, dass nicht deutlich rauskommt (abgesehen vom Spaßfaktor), warum du das gemacht hast.

Hacker schrieb:

Ist der Code vollständig standardkonform (bspw. der reinterpret_cast)?

Sieht auf den ersten Blick falsch aus. Der interessante Teil ist doch:

signed char some_byte;
some_inputstream >> reinterpret_cast<short&>(some_byte);

bzw

unsigned char some_byte;
some_inputstream >> reinterpret_cast<unsigned short&>(some_byte);

Erklär mal, wie kommst du drauf, dass das okay wäre. Du versaust dir hier ja den automatischen Speicher, da sizeof(char) typischerweise kleiner als sizeof(short) ist.

Ich denke, du wolltest eher so etwas schreiben:

int value;
some_inputstream >> value;
if (value<SCHAR_MIN || value>SCHAR_MAX) {
  Überlauf irgendwie abfangen/signalisieren
  da die Zuweisung im else-Teil sonst UB hervorrufen würde
} else {
  signed char some_byte = value;
  ...
}

hustbaer

Es geht ihm darum dass beim "Rausschiften" eines char/signed char/unsigned char mit Wert 50 nicht 50 am Schirm steht sondern irgend ein blöder Buchstabe.

Ich finde das übrigens auch immer wieder sehr bekloppt, vor allem weil es auch signed char und unsigned char betrifft.
Fragt man sich wozu es char dann überhaupt als 3. Typen gibt.

Kellerautomat

Das einfachste dürfte wohl sein, die Operatoren selbst für signed char und unsigned char zu überladen. Ich glaube, die sind laut Standard nicht definiert.

Bashar

Kellerautomat schrieb:

Das einfachste dürfte wohl sein, die Operatoren selbst für signed char und unsigned char zu überladen. Ich glaube, die sind laut Standard nicht definiert.

Leider doch. 27.6.1.2.3§10, 27.6.2.5.4 (C++98)

Hacker schrieb:

Verdammt nochmal, Leute, es sind Sommerferien und ich hab einfach nix zum Programmieren. Ich könnte locker 10 Stunden am Tag dafür nehmen. Aber ich weiß nicht wofür.

renn 200km

Shade Of Mine

Sollte das nicht per manipulator lösbar sein?

Das ist mit static_cast<int> lösbar.

Kellerautomat

Bashar schrieb:

Leider doch. 27.6.1.2.3§10, 27.6.2.5.4 (C++98)

Dann dürfte das hier doch eigentlich nicht kompilieren, oder? http://ideone.com/aU6po

dot

Wieso sollte das nicht kompilieren? Das tut genau das, was es laut Standard soll (char, signed char und unsigned char sind verschiedene Typen)...

Kellerautomat

Mehrfachdefinition und so...

dot

Wo siehst du da eine Mehrfachdefinition? Deine operator << liegen im global Namespace...

Kellerautomat

Kellerautomat schrieb:

Ich glaube, die sind laut Standard nicht definiert.

->

Bashar schrieb:

Leider doch. 27.6.1.2.3§10, 27.6.2.5.4 (C++98)

dot

Die sind aber im namespace std...

Kellerautomat

Na dann. Wo ist dann das Problem? Operatoren überladen und fertich.

camper

dot schrieb:

Die sind aber im namespace std...

Die Streamklassen auch...

hustbaer

ODR ist kein Problem eben wegen std:: vs. ::.

Es "dürfte" nicht kompilieren, weil der std::operator << über ODL gefunden wird, und es daher ambiguous sein sollte.

Es kompiliert trotzdem, weil der std::operator << ein Template ist, und bei der Overload-Resolution non-Template gegenüber Template vorgezogen wird.

Sobald man die eigenen Operatoren auch zu Templates macht schnalzt es auch wie erwartet:

http://ideone.com/jz6ik

Kellerautomat schrieb:

Na dann. Wo ist dann das Problem? Operatoren überladen und fertich.

Ich sehe es schoh als Problem, wenn es in der Standard-Library einen passenden Operator gibt, der gefunden wird, aber nicht das tut was man will.
Dadurch hast du nämlich keine Möglichkeit dahinterzukommen, wenn irgendwo Code kompiliert wird, der die eigenen Operatoren nicht "sieht" - weil das entsprechende File nicht inkludiert wurde. Der Compiler meldet nix, das Ergebnis ist aber falsch.

Alles bäh.

Ethon

Man hätte von Anfang an Zeichentypen und Integertypen etwas separieren sollen.
char ist die Kurzform für Charakter oder? Wieso speichere ich kleine Zahlen als "Zeichen"? Was wäre, wenn ein exotischer Rechner existieren würde, der Zeichen aus irgendwie nicht numerisch Speichert, sondern zb spezielle Zeichenregister hat?

Man hätte ja zb einem Typen small einführen können. wchar_t nutzt ja auch niemand als Integerersatz.

Shade Of Mine

Ethon schrieb:

Man hätte von Anfang an Zeichentypen und Integertypen etwas separieren sollen.

Das "Problem" was wir hier haben betrifft lediglich die Implementierung der stream Klassen und sonst nichts.

Mit boost::format oder printf, etc. gibt es dieses "Problem" garnicht.
Und auch die stream Klassen bieten eine Loesung dafuer an: iomanip

Ethon

Ich verstehe trotzdem nicht, wieso man kleine Zahlen als "Zeichen" speichert.