www.mikrocontroller.net

Forum: Compiler & IDEs C++ Datentypen (Definitionen) avr-gcc


Autor: Lars Lochmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt noch ein kleineres Problem. Mein C++ Compiler klopft mir 
auf die Finger wenn ich zum Beispiel die sprintf Funktion nutzen möchte 
und als String zum Beispiel den Datentyp uint8_t definiert habe.
Kann man das auch irgendwie definieren, dass der Compiler merkt, dass es 
der gleiche Datentyp ist?
Bzw. was benutzt ihr allgemein so für Datentypen wenn ihr in C++ 
programmiert?
Ich wollte gern bei den vorgeschlagenen Datentypen im Tutorial bleiben.
Also uint8_t, uint16_t...

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke nicht, dass es sinnvoll ist, ALLE Variablen mit den uint.. 
Typen zu definieren.
Ein String besteht nun mal aus Zeichen, also char (oder wchar etc) und 
sollte damit definiert werden.
Nur für Variablen, bei denen die genaue Größe wichtig ist, und mit denen 
gerechnet wird (-> deshalb integer), bzw. Bitmanipulationen gemacht 
werden, sind die uint.. Typen sinnvoll.
Also gib Cäsar was des Cäsars ist, und definiere Deine Strings mit char.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Ursache könnte sein, daß print von signed char ausgeht - dann 
paßt uint8_t natürlich nicht. (C++ unterscheidet da sehr genau.)

Versuchs mal mit int8_t.

Interessant könnte auch noch sein, wie unint8_t definiert ist. Poste mal 
die Definition von uint8_t und den Prototyp von sprintf (wie sie im 
Headerfile deklariert ist), wenn int8_t nicht hilft.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde das ein wenig inkonsistent. Deshalb bin ich auch Klaus 
Falser's Meinung diesbezüglich:

Klaus Falser wrote:
> Ich denke nicht, dass es sinnvoll ist, ALLE Variablen mit den uint..
> Typen zu definieren.
> Ein String besteht nun mal aus Zeichen, also char (oder wchar etc) und
> sollte damit definiert werden.

Datentyp bei Zeichen also: char
Datentyp bei (normalen) 8-Bit werten: uint8_t
Datentyp bei (normalen) vorzeichenbehafteten 8-Bit werten: int8_t

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich finde das ein wenig inkonsistent.

Sehe ich auch so... Nur ist es doch sicherlich lehrreich, 
herauszufinden, warum der Compiler meckert, oder?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu wrote:

> Sehe ich auch so... Nur ist es doch sicherlich lehrreich,
> herauszufinden, warum der Compiler meckert, oder?

Weil (per definitionem, auch in C!) "char" != "signed char" !=
"unsigned char" ist.  Auch wenn char stets entweder wie signed
char oder wie unsigned char implementiert ist, ist es zu
keinem der beiden typkompatibel.  Alle drei muss man also einfach
klar auseinander halten.

Während das in C eine Warnung ist, ist es halt in C++ ein Fehler.

Die Umwandlung von char nach uint8_t passiert in der Regel exakt
einmal, an der Peripherie.  Wenn ich also eine uart_putc()-
Funktion für stdio schreibe, so bekommt die ein char rein (weil
stdio logischerweise durchweg mit char arbeitet, es sind ja
darstellbare Zeichen), und bevor ich dann das char an das
USART-Register geben kann, muss ich es halt nach uint8_t casten.
Reinzu genau umgekehrt.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na das hätte doch Lars selber herausfinden sollen... Daß du das weißt, 
ist nichts neues.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist nicht ein char entweder ein signed char oder ein unsigned char?
Welcher Fall zutrifft ist implementierungsabhängig, aber jeweils 2 Typen 
sind meiner Meinung nach identisch.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Identisch sind sie nicht. Wenn du z.B. vergleichen oder gar sortieren 
willst und Zeichen mit gesetztem oberen Bit hast, spielt das eine sehr 
große Rolle und C++ packt die Information darüber, um welchen char-Typ 
es sich handelt, in die Funktionssignatur.

Compiler haben üblicherweise eine Defaulteinstellung für den char-Typ. 
Man kann ihn aber auch per Compileroption einstellen.

Autor: Lars Lochmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na da habe ich ja eine schöne Diskussion ausgelöst. ;-)
Also zunächst hatte ich mich an das Tutorial hier auf der Seite 
gehalten. Da ist das Beispiel bei: "Die Nutzung von printf"

...
uint8_t s[20];

sprintf( s, "Zählerstand: %d", value );
uart_puts( s );
...

Das müsste mit dem C-Compiler funktionieren, mit dem C++ Compiler aber 
nicht.
Ich glaube das Tutorial ist hier an der stelle etwas großzügig, oder?

Das signed char und unsigned char nicht das gleiche ist, ist mir schon 
klar, aber wo ist dann der Unterschied zu char?

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für char nimmt der Compiler entweder den Default-Typ, oder den per 
Option eingestellten.

Was der Default bei gcc ist, weiß ich nicht - da mußt du eben mal 
nachlesen... Bei VC z.B. ist es unsigned char.

C ist bei solchen Kleinigkeiten nicht so pingelig und castet implizit.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist nicht ein char entweder ein signed char oder ein unsigned char?

Nein.

> Welcher Fall zutrifft ist implementierungsabhängig, aber jeweils 2
> Typen sind meiner Meinung nach identisch.

Die interne Wert-Repräsentation ist mit einer von beiden identisch (mit 
welcher, ist tatäschlich implementierungsabhängig, und beide Varianten 
sind verbreitet), aber dennoch ist char immer ein eigener Typ.

> Was der Default bei gcc ist, weiß ich nicht

Das ist wiederum von der Zielplattform abhängig. Bei avr ist es meines 
Wissens vorzeichenbehaftet. Da man aber für Zeichen (und nur dafür) eh 
immer char verwendet, spielt das keine Rolle.  Wie Jörg schon 
geschrieben hat, castet man das dort, wo es zur Hardware geht, einmal 
um. Ob char ein Vorzeichen hat oder nicht, braucht man überhaupt nicht 
zu wissen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit anderen Worten: eine Applikation, die zum C-Standard konform ist,
darf ihr Verhalten nicht ändern, egal ob "char" signed oder unsigned
implementiert ist.  Bei C ist das eine Warnung, bei C++ ist es ein
Fehler, wenn man beides miteinander vermischt.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das führt aber in eine üble Falle:

Angenommen, Modul A ist mit der Option 'char is signed' compiliert und 
Modul B mit 'char is unsigned' und in beiden Modulen werden Zeichen 
verglichen.

Der Linker merkt nicht, daß die in den Modulen definierten Funktionen 
von völlig verschiedenen Voraussetzungen ausgehen und nagelt daraus ein 
Programm zusammen...

Das widerspricht der Grundannahme 'Typsicherheit' von C++ eklatant und 
deckt sich auch nicht mit den täglichen Erfahrungen, die man so mit 
Linkerproblemen macht.

Der Sache mussen wir auf den Grund gehen.

Rolf, kannst du deine Ausführungen belegen?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Angenommen, Modul A ist mit der Option 'char is signed' compiliert und
> Modul B mit 'char is unsigned' und in beiden Modulen werden Zeichen
> verglichen.

Deshalb belässt man das auch auf Default und stellt es nicht per 
Kommandozeile um.

> Das widerspricht der Grundannahme 'Typsicherheit' von C++ eklatant und
> deckt sich auch nicht mit den täglichen Erfahrungen, die man so mit
> Linkerproblemen macht.

Es gibt noch andere Compiler-/Linkeroptionen, die auf das ABI Einfluß 
haben. Wenn man die anfaßt, ist man eben selbst dafür verantwortlich, 
daß das Programm und alle verwendeten Bibliotheken mit denselben 
Einstellungen übersetzt sind bzw. daß man nichts davon übergreifend 
verwendet. Wenn man ein Programm mit -mint8 (int-Größe auf 8 Bit 
verstellen) compiliert, ist ja auch klar, daß man das nicht einfach mit 
anderem Code zusammenlinken kann, bei dem die Option nicht gesetzt ist.

> Rolf, kannst du deine Ausführungen belegen?

Welche meinst du? Ich habe nicht behauptet, man könne Code, der 
verschiedene Einstellungen verwendet, beliebig mischen, sondern nur, daß 
es mir als Programmierer egal sein kann, ob char signed oder unsigned 
ist. Daß es programmweit einheitlich sein muß, ist eigentlich klar.

Autor: Lars Lochmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In meinem Nachschlagewerk: C/C++ Die Referenz, steht zu Datentypen:
unsigned char  0 bis 255       1Byte
signed   char  -128 bis 127    1Byte
Das ist ja denke ich mal auch allen klar und verständlich.
Und was ist jetzt char? Rolf kannst du uns das bitte nochmal genau 
erklären, wenn das keiner der beiden sein sollte?

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lars:
Grundsätzlich (default-Einstellung, ANSI-Standard) gilt: Wenn die 
VOrzeichenangabe bei einem Datentyp weggelassen wird, ist der Typ 
vorzeichenbehaftet. Der Wertebereich von char entspricht also dem von 
signed char. Bei einem int gilt entsprechendes. Man kann dem Compiler 
aber optional mitteilen, dass er den Datentyp (in den mir bekannten 
Fällen geht das afair aber nur für char) ohne Vorzeichenangabe als 
unsigned behandeln soll. Das ist dann aber eine lokale, 
benutzerspezifische Einstellung, die nicht mit dem Standard kompatibel 
ist.

Wenn man char allerdings nur für Textzeichen (ASCII) verwendet (wie es 
ja auch ursprünglich vorgesehen ist, der Datentyp heißt nicht umsonst 
"Character"), ist es völlig wurscht, ob man die Einstellung abweichend 
vom Default gemacht hat, weil die Einstellung ja für alle char im Code 
gilt. Der "Missbrauch" von char als Rechenvariable ist auch auf 
8-Bit-Systemen eigentlich überflüssig, wenn man die stdint.h einbindet 
und die darin befindlichen Datentypen benutzt (und char eben nur für 
ASCII-Zeichen verwendet).

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rolf Magnus

Ich habs mit VC2005 mal näher unter die Lupe genommen:

char ist dort per Voreinstellung signed char.

Die Kommandozeilenoption /J ändert char in unsigned char.

Der Compiler erzeugt für char tatsächlich dieselbe Funktionssignatur, 
gleichgültig, ob mit oder ohne /J compiliert.

Die Fehlermeldung, von der Lars berichtet - die er aber nicht gepostet 
hat - kommt dann wohl davon, daß die gcc Runtimelib kein sprintf für den 
Typ unsigned char enthält.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes M. wrote:
> Wenn man char allerdings nur für Textzeichen (ASCII) verwendet (wie es
> ja auch ursprünglich vorgesehen ist, der Datentyp heißt nicht umsonst
> "Character"), ist es völlig wurscht, ob man die Einstellung abweichend
> vom Default gemacht hat, weil die Einstellung ja für alle char im Code
> gilt.

Das mag für den englischen Zeichensatz gelten - beim deutschen sind 
etliche Zeichen mit gesetztem obersten Bit codiert und dann ist es schon 
nicht mehr 'völlig wurscht', denn das Vergleichsergebnis für < und > ist 
nicht dasselbe.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Uhu:
Da haste natürlich recht. Und das ist vermutlich auch genau der Grund 
für die Compiler-Option "[X] char als unsigned behandeln"...

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf jeden Fall ist es der Grund, warum ich signed char als Standardtyp 
für char nicht mag.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes M. wrote:

> Grundsätzlich (default-Einstellung, ANSI-Standard) gilt: Wenn die
> VOrzeichenangabe bei einem Datentyp weggelassen wird, ist der Typ
> vorzeichenbehaftet.

Bei `int' ja, bei `char' nein.  Die Vorzeichenhaftigkeit von `char'
ist (leider) von den Standards implementierungsabhängig gelassen
worden.

Daher gilt die Annahme (für ein portables Programm), dass `char',
`signed char' und `unsigned char' drei voneinander verschiedene, nicht
zuweisungskompatible Datentypen sind, auch wenn der ersten immer
tatsächlich als einer der beiden letzten implementiert ist.

Unser Waldvogel schrieb:

> Das mag für den englischen Zeichensatz gelten - beim deutschen sind
> etliche Zeichen mit gesetztem obersten Bit codiert und dann ist es
> schon nicht mehr 'völlig wurscht', denn das Vergleichsergebnis für <
> und > ist nicht dasselbe.

Egal, der Vergleich auf kleiner oder größer ist vom Standard sowieso
nur für die Buchstaben a..z, A..Z und die Ziffern 0..9 jeweils
untereinander definiert.  Alles andere kann man nicht auf kleiner oder
größer vergleichen.  Damit ist es auch egal, ob char nun
vorzeichenbehaftet ist oder nicht.

> daß die gcc Runtimelib kein sprintf für den
> Typ unsigned char enthält.

Alle stdio-Operationen gemäß Standard arbeiten auf dem Typ `char'
und sind damit unverträglich mit sowohl `signed char' als auch
`unsigned char'.


Mir ist unklar, was es hier immer noch zu diskutieren gibt...  Der
Standard ist doch so sonnenklar, alle drei sind als verschieden zu
behandeln, punkt.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lars Lochmann

> In meinem Nachschlagewerk: C/C++ Die Referenz, steht zu Datentypen:
> unsigned char  0 bis 255       1Byte
> signed   char  -128 bis 127    1Byte
> Das ist ja denke ich mal auch allen klar und verständlich.

Allerdings nicht ganz allgemeingültig. Die angegebenen Bereiche sind 
nach C-Norm nur Mindestwerte. Es wären auch größere Wertebereiche 
erlaubt. In der Praxis ist es aber in den allermeisten Fällen korrekt.

> Und was ist jetzt char?

Es hat denselben Wertebereich und dieselbe Größe wie eines der beiden, 
wobei es vom Compiler abhängt, welches gewählt wird. Es ist aber dennoch 
nicht derselbe Typ.

> Rolf kannst du uns das bitte nochmal genau erklären, wenn das keiner
> der beiden sein sollte?

Anderes Beispiel: Auf AVR ist int und short gleich groß. Sie haben die 
gleiche Repräsentation und den gleichen Wertebereich. Dennoch sind es 
zwei verschiedene Typen. Und so sind auch signed char, unsigned char und 
char drei eigenständige Typen, obwohl char dieselbe Repräsentation hat 
wie einer der beiden anderen. In C spielt das keine so große Rolle, aber 
in C++ kann man z.B. Funktionen überladen. Da kannst du eine Funktion 
für char, signed char und unsigned char überladen, und der Compiler 
unterscheidet zwischen den dreien abhängig davon, welchen Typ man 
übergibt. Folgendes Beispiel-Programm wird vom Compiler nicht 
akzeptiert, weil er nicht weiß, ob er den Wert nun nach signed char oder 
nach unsigned char konvertieren soll.
void func(unsigned char c) {}
void func(signed char c)   {}

int main()
{
    char c = 'x';
    func(c);
}

Bei den anderen Integertypen ist das nicht so. int und signed int sind 
ein und derselbe Typ, daher ist folgender Code auch zulässig in C++:
void func(unsigned int i) {}
void func(signed int i)   {}

int main()
{
    int i = 42;
    func(i);
}

@Johannes M.

> Grundsätzlich (default-Einstellung, ANSI-Standard) gilt: Wenn die
> VOrzeichenangabe bei einem Datentyp weggelassen wird, ist der Typ
> vorzeichenbehaftet.

Ja, für alle außer char.

> Der Wertebereich von char entspricht also dem von signed char.

Nicht zwangsweise.

@Uhu Uhuhu:

> beim deutschen sind etliche Zeichen mit gesetztem obersten Bit codiert
> und dann ist es schon nicht mehr 'völlig wurscht', denn das
> Vergleichsergebnis für < und > ist nicht dasselbe.

Es macht dann zwar einen Unterschied, aber im Prinzip sind eh beide 
Ergebnisse falsch, weil die Umlaute und anderen Zeichen falsch 
einsortiert werden. Zur Not schreibt man sich eine Funktion oder ein 
Makro, wo der Vergleich gekapselt ist, und wo intern auf den gewünschten 
Typ gecastet wrid.
Letztendlich vergleiche ich auf Ungleichheit meistens nur ganze Strings 
(zum Sortieren), und da ist es die Aufgabe von strcmp, sich darum zu 
kümmern.

> Auf jeden Fall ist es der Grund, warum ich signed char als Standardtyp
> für char nicht mag.

Das Problem ist in dem Fall der Vergleich, nicht der char-Typ. Sobald
du statt mit ASCII z.B. mal mit EBCDIC arbeiten mußt, ist das Ergebnis
von < und > auch für die englische Sprache unsinnig.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Alle stdio-Operationen gemäß Standard arbeiten auf dem Typ `char'
> und sind damit unverträglich mit sowohl `signed char' als auch
> `unsigned char'.

Seufz
Wenn es doch nur so wäre. Die Funktionen, die mit Strings arbeiten, 
benutzen [const] char*, aber die, die mit einzelnen Zeichen arbeiten, 
verwenden zur zusätzlichen Verwirrung int. Beispiel: int putchar(int c);
Aber es kommt noch besser: Diese Funktionen (nicht nur die 
I/O-Funktionen, sondern auch Sachen wie toupper() oder isalpha() - eben 
alles, was einzelne Zeichen verarbeitet) erwarten vorzeichenlose Werte, 
auch dann, wenn char vorzeichenbehaftet ist. Man muß streng nach Norm 
erst nach unsigned char casten! Die korrekte Verwendung von toupper 
sieht also so aus:
char c = 'x';
c = toupper((unsigned char)c);

Ohne den Cast ist das Verhalten formal undefiniert.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg Wunsch
> Unser Waldvogel schrieb:

Der Uhu ein Waldvogel? Na du hast komische Vorstellungen...
http://de.wikipedia.org/wiki/Uhu_%28Vogel%29#Lebensraum

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.