Mein Problem mit den Umlauten

[Mxt]

Also um die Sache mal von meiner Seite aus abzuschliessen:

Ich stimme Peter darin zu, dass man für diese Aufgabe mit entsprechenden Bibliotheken besser bedient wäre. Da der Fragesteller mit QtCreator auf dem PC arbeitet, nicht mit einem Mikrocontroller, wären dazu die Datei- und Stringklassen von Qt sicher gut geeignet.

Die Unicode-Geschichte ist ein typisches Beispiel dafür, dass sich die Mikrocontrollerprogrammierung und die auf den "großen" Betriebssystemen schon etwas unterscheidet. "Einfaches C" kann auf den komplexen Systemen schnell in so einem Minenfeld landen, wie wir es in diesem Thread gesehen haben.

Was der Fragesteller nicht erwartet hatte, ist das für den GCC etwas in einfachen Anführungszeichen, abhängig vom Inhalt ein char oder int sein kann. Das wusste ich auch nicht. Die anderen C++ Compiler sehen das anders.

[HaWe]

Ein typisches Problem für die Portierbarkeit:

typedef struct
  {
    unsigned char c
    unsigned int i;
  } s_foo;

Ich gehe mal davon aus, dass char 8-Bit und int 16-Bit haben.

schon wieder lese ich hier was über int und 16 bit und "einfach davon ausgehen".... tstststs...
das geht hier mit Sicherheit schnell schief!

auf dem Raspi hat int 32 bits , also int == int32_t
will man exakt 16 bit int, muss man short verwenden - oder eben int16_t.
auch word hat hier übrigens 32 bits.

und char ist auf ARM-Plattformen häufig unsigned char, während es auf AVR Plattformen häufig signed char ist!

Auch auf dem Arduino Due (ARM Cortex M3) gilt das automatisch !!

und werden aus einem FILE * stream (Datei als SD-File oder von stdin) Zeichen gelesen, sind es signed int, keine unsigned int, denn es gibt hier auch negative Werte, während der erweiterte ASCII-Zeichensatz (0...255) unsigned char ist !!


Mein Tipp:
vergesst doch einfach mal die alten Datentypen.

per gpp und Arduino sind die C11-Datentypen bereits implementiert,
bei gpp für Raspi muss man bei Raspbian per Hand includen:
#include <stdint.h>

dann weiss man, was man hat.


ps,
für Buchstaben gibt es bei Raspi C++ auch den Datentyp
wchar_t
mit 8-16 bit, der alle "chars" aufnimmt, seien es uint8_t oder int16_t.

Datentyp wchar_t
Der Datentyp char ist nicht in der Lage, die Zeichensätze aller nationaler Sprachen zu repräsentieren. Um zum Beispiel auch mit dem japanischen Zeichensatz umgehen zu können, ist dieser Datentyp "zu klein".

Die Darstellung beliebiger landesspezifischer Zeichensatze kann mit Hilfe des Datentyps wchar_t (wide characters) vorgenommen werden, der mit ANSI-C eingeführt wurde.
Die Definition des Datentyps erfolgt in der Header-Datei stddef.h.

wchar_t ist ebenso wie char, int, ... ein integraler Datentyp.

Literale vom Typ wchar_t besitzen folgende Gestalt

L'..'

http://www2.informatik.uni-halle.de/...c/c_wchar.html

s.a. http://www.raspberry-projects.com/pi...mory/variables

[Mxt]

schon wieder lese ich hier was über int und 16 bit und "einfach davon ausgehen".... tstststs...

Mein Tipp:
vergesst doch einfach mal die alten Datentypen.

#include <stdint.h>

dann weiss man, was man hat.

+1


wchar_t ist der native Typ des Betriebssystems für wide characters. Unter Windows sind das 2 Byte, unter Linux 4, wie oben in den Ausgaben gezeigt. (Schreibweise L"...").

Dann gibt es in neuerem C++ noch char32_t, Schreibweise U"...", sollten eigentlich überall 4 Bytes sein.

Mit kleinem u"..." ist es eigentlich char16_t, wie wir oben gesehen haben unter Linux trotzdem 4 Bytes, unter Windows sind es 2.

[HaWe]

char32_t und char16_t kannte ich jetzt noch nicht, sondern nur int32_t und int16_t .... oder war das ein "Verschreiber"?

[Mxt]

http://en.cppreference.com/w/cpp/lan...haracter_types

Bei den Zahlentypen gibt es einen ganzen Zoo
http://en.cppreference.com/w/cpp/types/integer


Da steht übrigens was interessantes zu char

char - type for character representation which can be most efficiently processed on the target system (has the same representation and alignment as either signed char or unsigned char, but is always a distinct type).

[HaWe]

oh ja! :-o

ich kannte allerdings nur diese Liste speziell für Raspi, kA ob diese ausschließlich ist oder ob die anderen ebenfalls schon mit drin sind:

http://www.raspberry-projects.com/pi...mory/variables

[oberallgeier]

. . . Wolltest du so etwas? . . .

Peter, vielen Dank, genau das bringt mich weiter. Danke für die viele Mühe.

[Peter(TOO)]

Hallo,

schon wieder lese ich hier was über int und 16 bit und "einfach davon ausgehen".... tstststs...
das geht hier mit Sicherheit schnell schief!

Manche hier haben verstanden, was ich geschrieben habe, andere haben den Satz aus den Zusammenhang gerissen!

Ich kenne auch noch CPUs bei denen char 9-Bit hat!
Bei K&R, stand schon in der ersten Ausgabe:
Garantiert ist nur, dass "char <= int <= Long" ist. char kann dabei aber auch 38-Bit haben.

MfG Peter(TOO)

- - - Aktualisiert - - -

@Geier,

Das war nur etwas Tipparbeit.

MfG Peter(TOO)

[HaWe]

der TO arbeitet mit GCC und 64 bit Linux, da werden ints weder 16 noch 9 bit haben. Auch 32-bit ARM Prozessoren verwenden 32 bit int.
Es ging mir nur um die Tatsache, dass 16-bit int nichts ist, wovon man JEMALS EINFACH MAL ausgehen darf, allein diese Aussage ist völlig aus der Welt. Und w_char ist darüberhinaus bei ANSI C eh der eigentliche proprietäre Zeichen-Datentyp, wo es nicht verwunderlich ist, wenn ein in ' ' eingeschlossenen Zeichen nicht 8, sondern 16 bit groß ist, insbes. wenn man von stdin liest.
(Annodazumal ist eben annodazumal, das mag alles in leipzig-einundleipzig noch anders gewesen sein: wir arbeiten meist mit C99 oder sogar C11 und gcc/gpp auf ARM oder AVR hat da auch seine eigenen Konventionen.)

[Peter(TOO)]

Hallo HaWe,

der TO arbeitet mit GCC und 64 bit Linux, da werden ints weder 16 noch 9 bit haben. Auch 32-bit ARM Prozessoren verwenden 32 bit int.
Es ging mir nur um die Tatsache, dass 16-bit int nichts ist, wovon man JEMALS EINFACH MAL ausgehen darf, allein diese Aussage ist völlig aus der Welt. Und w_char ist darüberhinaus bei ANSI C eh der eigentliche proprietäre Zeichen-Datentyp, wo es nicht verwunderlich ist, wenn ein in ' ' eingeschlossenen Zeichen nicht 8, sondern 16 bit groß ist, insbes. wenn man von stdin liest.
(Annodazumal ist eben annodazumal, das mag alles in leipzig-einundleipzig noch anders gewesen sein: wir arbeiten meist mit C99 oder sogar C11 und gcc/gpp auf ARM oder AVR hat da auch seine eigenen Konventionen.)

Du hast überhaupt nicht begriffen was ich geschrieben habe oder den Text gar nicht zu Ende gelesen!

Aber nochmals explizit für dich:

1. Bezog sich die Antwort auf die Frage des Oberallgeiers (Dies zu erkennen ist übrigens der Unterschied zwischen lesen können und Lesekompetenz).
2. Die Antwort bezog sich auf Probleme, welche sich beim Portieren von Code ergeben.
3. Um zu beschreiben was das Aligment macht, MUSS man nun mal irgendwelche Annahmen über die Bit-Grösse von Datentypen machen.

MfG Peter(TOO)