www.mikrocontroller.net

Forum: PC-Programmierung Grundlagen zu Datentypen


Autor: Rocker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe große Schwierigkeiten mit den verschiedenen Datentypen in C++. 
Im Internet findet man Beispiele sowohl in Unicode als auch in 
Multibyte. Wenn ich nun mitten in einem Programm stecke und zufällig 
einen lehrreichen Beispielcode im "anderen" Format finde, geht der Ärger 
los...
Ich begegne auch immer wieder API-Funktionen, die zwar LPSTR 
zurückliefern, aber anscheinend die Zeichen in Byte-Form speichern, also 
kein Unicode. Das ist natürlich ungünstig, wenn man sich zu Beginn für 
Unicode entschieden hat.

Kennt jemand eine gute Informationsquelle für Anfänger im Internet, wo 
kurz und knackig die verschiedenen Datentypen und auch die Umwandlungen 
erklärt werden?

Quellen gibt es ja genug, aber ich habe so meine Probleme mit dem 
Verständnis...die folgende Erklärung habe ich Beispielsweise für die 
Funktion c_str() gefunden:

"The returned array points to an internal location with the required 
storage space for this sequence of characters plus its terminating 
null-character, but the values in this array should not be modified in 
the program and are only granted to remain unchanged until the next call 
to a non-constant member function of the string object."

Ok, also ein Null-Terminiertes Array mit dem Inhalt des String.
Ich frage mich jedoch, warum die Werte in dem Array nicht verändert 
werden sollten und was es nun genau mit dieser garantierten 
Unversehrtheit der Werte bis zum nächsten ominösen Funktionsaufruf auf 
sich hat?

Mit freundlichen Grüßen,
Rocker

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rocker schrieb:
> Ich begegne auch immer wieder API-Funktionen, die zwar LPSTR
Übe an gescheitem C++-Code und nicht an dem, was Microsoft darunter 
versteht. Deren Typenkatastrophe ist schlimm.

> "The returned array points to an internal location with the required
> storage space for this sequence of characters plus its terminating
> null-character, but the values in this array should not be modified in
> the program and are only granted to remain unchanged until the next call
> to a non-constant member function of the string object."

> Ok, also ein Null-Terminiertes Array mit dem Inhalt des String.
Genau, ein klassischer C-String.

> Ich frage mich jedoch, warum die Werte in dem Array nicht verändert
> werden sollten
Sie gehören dir nicht, ganz banal.

> und was es nun genau mit dieser garantierten
> Unversehrtheit der Werte bis zum nächsten ominösen Funktionsaufruf auf
> sich hat?
Das heißt: Wenn du dir mit c_str() den C-String liefern lässt und z.B. 
in einer char*-Variablen festhälst:
string EinCppString = ...;
char *s = EinCppString.c_str();
Dann ist der Inhalt des Arrays, auf das 's' nun zeigt (eben dein 
C-String) nur so lange korrekt (heißt hier: entspricht dem, was 
'EinCppString' auch enthält), so lange nicht neuerlich auf 
'EinCppString' herumgeackert wird.

Du führst ja eine Redundanz ein: Einerseits weiß 'EinCppString' 
natürlich über seinen Inhalt Bescheid, der in irgendeiner Form verwaltet 
wird. Mittels c_str() forderst du nun aber eine möglicherweise gänzlich 
andere Darstellung des Inhaltes an, d.h. schlimmstenfalls kopiert 
'EinCppString' seinen Inhalt, um ihn dir dann irgendwie anders 
aufbereitet zur Verfügung zu stellen.
Wenn du nun an der Kopie herumfummelst, kriegt das Original das nicht 
mit. Wenn du am Original herumfummelst, kriegt die Kopie das nicht mit 
(denn sie müsste ja z.B. wieder neu aufbereitet werden usw.) -> Deshalb 
nur gültig, bis zum nächsten Fummeln an 'EinCppString'.

Autor: Matthias H. (experimentator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ich habe große Schwierigkeiten mit den verschiedenen Datentypen in C++.
> Im Internet findet man Beispiele sowohl in Unicode als auch in
> Multibyte. Wenn ich nun mitten in einem Programm stecke und zufällig
> einen lehrreichen Beispielcode im "anderen" Format finde, geht der Ärger
> los...
> Ich begegne auch immer wieder API-Funktionen, die zwar LPSTR
> zurückliefern, aber anscheinend die Zeichen in Byte-Form speichern, also
> kein Unicode. Das ist natürlich ungünstig, wenn man sich zu Beginn für
> Unicode entschieden hat.

Erst einmal ganz grundsätzlich:

- Die Programmiersprachen C und C++ kennen eigentlich keine Strings, 
sondern nur eine Möglichkeit, Zeichenkonstanten anzugeben, die 
automatisch durch ein Zeichen mit dem Wert 0 (ASCII: NUL) abgeschlossen 
werden. Alles andere ist in Bibliotheken implementiert, z. B. die 
C-Standardbibliothek (Funktionen wie strcpy()) oder die C++-STL (z. B. 
die Klasse std::string).

- Sogenannte C-Strings oder "nullterminierte Strings" sind entweder 
solche Zeichenkonstanten oder Variablen im gleichen Format bzw. Zeiger 
darauf.
Beispiel:
char* abc = "ABC";
Das definiert ein konstantes Character-Array von 4(!) Zeichen, nämlich 
A, B, C und einem 0-Byte, und einen Zeiger mit Namen abc darauf.

- Der Bezeichner LPSTR stammt aus einer Microsoft-Bibliothek und ist 
kein Standard.

- In C sind ursprünglich nur einfache Zeichen definiert, z. B. im 
ASCII-Standard. Der ASCII-Standard legt nur 7-Bit-Zeichen bis 127 fest, 
z. B., daß ein A als das Zeichen Nummer 65 codiert wird.

Wenn man Umlaute oder Sonderzeichen braucht, die nicht Bestandteil des 
zugrundeliegenden Zeichensatzes wie ASCII sind, dann muß man sich 
überlegen, wie man diese codiert. Da gibt es verschiedene Ansätze:

1. Codepages (z. B. ISO-8859-1): Man behält 1 Byte pro Zeichen bei, aber 
sagt, welche Bedeutung die Zeichen über 127 haben sollen, z. B. als 
welche Zahl ich ein Ü codiere.
Wenn irgendwo im Internet (E-Mails, Foren, ...) kaputte Umlaute 
auftauchen, dann ist der Grund meistens ein Problem mit Code pages.
Codepages sollte man für neuere Projekte nicht mehr verwenden, es sei 
denn, man hat z. B. ein Embedded-System, dessen Display sowieso nur 8 
Bits pro Zeichen erlaubt oder so.

2. Multi-Byte-Zeichensätze, immer noch mit Code pages. Das wurde z. B. 
für asiatische Sprachen benutzt, verwenden mehrere Bytes pro Zeichen und 
ist weitestgehend überholt.

3. Unicode: Dort hat man sich zusammengesetzt und sich überlegt, wie man 
die Zeichen praktisch sämtlicher Sprachen der Welt ohne Codepage-Chaos 
codieren kann. Herausgekommen ist eine Codierung, die in älteren 
Unicode-Versionen jedem Zeichen eine 16-Bit-Zahl und in neuen 
Unicode-Versionen eine 32-Bit-Zahl zuordnet.
Dabei sind die unteren 127 Zeichen identisch mit dem ASCII-Zeichensatz.

Da 16 oder 32 Bits sehr unhandlich sind (ein "char" hat je nach 
Plattform meist nur 8 Bit), hat man sich verschiedene Codierungen 
überlegt. Die gebräuchlichsten sind:

UTF-8: Dabei wird ein Zeichen variabel mit 1 bis 3 Bytes (in neueren 
Unicode-Versionen max. 4) dargestellt. Weil UTF-8 eine echte Obermenge 
von ASCII ist, kann man es wie ASCII bearbeiten, solange keine 
Sonderzeichen vorkommen (zum ersten Experimentieren vielleicht in 
Ordnung, aber ein fertiges Programm, das man herausgibt, sollte damit 
rechnen!).

UTF-16: Dabei wird ein Zeichen mit 2 Bytes (in neueren Unicode-Versionen 
2 oder 4) dargestellt.

UTF-32: Dort wird jedes Zeichen in 4 Bytes dargestellt.

Bei Unicode muß man also wissen, mit welcher Unicode-Variante man es zu 
tun hat. Am gebräuchlichsten und meiner Meinung nach meistens am 
handlichsten ist UTF-8, auch UTF-16 sieht man öfters, z. B. bei Java.

> Quellen gibt es ja genug, aber ich habe so meine Probleme mit dem
> Verständnis...die folgende Erklärung habe ich Beispielsweise für die
> Funktion c_str() gefunden:
>
> "The returned array points to an internal location with the required
> storage space for this sequence of characters plus its terminating
> null-character, but the values in this array should not be modified in
> the program and are only granted to remain unchanged until the next call
> to a non-constant member function of the string object."
>
> Ok, also ein Null-Terminiertes Array mit dem Inhalt des String.
> Ich frage mich jedoch, warum die Werte in dem Array nicht verändert
> werden sollten und was es nun genau mit dieser garantierten
> Unversehrtheit der Werte bis zum nächsten ominösen Funktionsaufruf auf
> sich hat?

Das bedeutet folgendes:

Wenn die Funktion c_str() (wahrscheinlich eher eine "Methode" einer 
Stringklasse wie std::string, oder?) aufgerufen wird, dann muß die 
Funktion einen Zeiger auf einen Speicherbereich liefern, in dem die 
Zeichen des Strings plus ein NUL-Zeichen stehen.
Dazu muß sie unter Umständen den String in einen neuen, größeren 
Speicherbereich kopieren, um Platz für das NUL-Zeichen zu schaffen.

Die Funktion kümmert sich selbst um die Verwaltung dieses 
Speicherbereichs. Darum darf der Aufrufer diesen Speicherbereich nur 
lesen, aber nicht freigeben (free()/delete) und nicht verändern, sonst 
ist das Verhalten undefiniert.
Nehmen wir zum Beispiel an, die Funktion würde einen Zeiger auf eine 
interne Datenstruktur des Strings zurückliefern und der Aufrufer würde 
diesen Speicherbereich ändern - dann würde sich auch der String ändern!
Es könnte auch zum Beispiel theoretisch sein, daß die Bibliothek als 
Optimierung einen Zeiger auf eine Konstante zurückliefert. Bei modernen 
Betriebssystemen mit Speicherschutz (wohl eher weniger bei 
Mikrocontrollern) könnte das dazu führen, daß das Betriebssystem das 
Programm beendet, anderenfalls wäre undefiniertes Verhalten die Folge.
Darum ist diese Methode als "const" deklariert, damit man das nicht 
versehentlich tut.

Und Du darfst den Rückgabewert dieser Funktion oder Methode nur so lange 
benutzen, bis die nächste Methode an diesem Stringobjekt aufgerufen 
wird, die nicht "const" ist. Wenn Du z. B. an den String etwas anfügst, 
dann ist der Rückgabewert des vorigen Aufrufs von c_str() ab diesem 
Zeitpunkt undefiniert und c_str() muß erneut aufgerufen werden, wenn der 
Wert das nächste mal gebraucht wird.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.