schon mal festgestellt? A. Due rechnet falsch - Mega ok!

[Klebwax]

Ein char ist halt gut genug, ein character, einen Buchstaben zu speichern. Buchstaben haben nichts ansich, was die Bedeutung eines Vorzeichens hat. Deswegen macht signed oder unsigned bei Buchstaben keinen Sinn und ist für ein char nicht vorgegeben. Überhaupt macht das Rechnen mit Buchstaben keinen Sinn (außer so ein paar Tricks die Groß in Kleinbuchstaben rechnen o.ä.).

Wenn ich eine Ganzzahl, einen Integer, haben möchte, der in 8 Bit passt, dann sollte ich das auch so sagen: int8_t. Da gibts dann keine Zweideutigkeiten oder Compilerabhängigkeiten. Obwohl man bei den heute verfügbaren Speichergrößen das einfach knicken und int nehmen sollte: dann klappts auch mit dem Nachbarn, äh mit jedem anderen Prozessor oder Kompiler

MfG Klebwax

[HaWe]

Mann, du Roboter-Genie... das ist doch jetzt wirklich müßig, das zum hunderttausendsten Mal jetzt noch mal besserwisserisch aufzuwärmen - danke aber für den netten Versuch

(ps, edit: immerhin ist der Code auch viel älter als 2011, und davor gabs noch gar kein int8_t, char war und ist immer noch ein gültiger Datentyp in C, und signed char mit negativen Werten sicher auch nicht als "negative Buchstaben" zu verstehen - aber auch das ist hier inzwischen völlig belanglos, das Problem ist ja auch darüberhinaus längst erkannt und gelöst. Hier mit "Wort-eigentümlichen" semantischen Begrifflichkeiten zu jonglieren, entbehrt auch jeder Grundlage - was, bitte ist dann ein Bissen? oder ein Wort? Oder ein Unversehrtes? oder ein Langes? Dein Post ist also nicht nur sachlich falsch - sondern auch absolut (!) mehr als flüssig... Naja, manche können es halt nicht lassen...)

[Andre_S]

Ein char ist halt gut genug, ein character, einen Buchstaben zu speichern. Buchstaben haben nichts ansich, was die Bedeutung eines Vorzeichens hat. Deswegen macht signed oder unsigned bei Buchstaben keinen Sinn und ist für ein char nicht vorgegeben. Überhaupt macht das Rechnen mit Buchstaben keinen Sinn (außer so ein paar Tricks die Groß in Kleinbuchstaben rechnen o.ä.).
...
MfG Klebwax

Hallo,
wir sollten nicht alles verallgemeinern, es trifft halt nicht überall zu…

Auszug aus meiner Entwicklungsumgebung „mikroC für dsPIC:

Type	Size in bytes	Range
Bit	1–bit	0 or 1
Sbit	1–bit	0 or 1
(unsigned) char	1	0 .. 255
signed char	1	- 128 .. 127
(signed) short (int)	1	- 128 .. 127
unsigned short (int)	1	0 .. 255
(signed) int	2	-32768 .. 32767
unsigned (int)	2	0 .. 65535
(signed) long (int)	4	-2147483648 .. 2147483647
unsigned long (int)	4	0 .. 4294967295

Gruß André

[HaWe]

danke für die Schützenhilfe, aber für Intel x86, Win32, Win64, und AVR von Arduino Micro über Uno und Leonardo bis Mega wird "char" als "signed" behandelt.
Aber wie gesagt, Schnee von gestern. Die tollen Arduino-IDE-Programmierer hätten da in ihr tolles Sketch für gefühlt 10000 verschiedene Boards wenigstens eine Compilerwarnung für den Due einbauen können, wenn sie char jetzt plötzlich anders behandeln als für die 9999 übrigen Boards.

Ich denke, mit deiner Übersicht und diesen abschließenden Worten können wir das Thema schließen und uns jetzt wieder der Zukunft zuwenden. 8-)

(editiert, erst falsch rum gelesen)

[Klebwax]

Hallo,
wir sollten nicht alles verallgemeinern, es trifft halt nicht überall zu…

Auszug aus meiner Entwicklungsumgebung „mikroC für dsPIC:

Type	Size in bytes	Range
Bit	1–bit	0 or 1
Sbit	1–bit	0 or 1
(unsigned) char	1	0 .. 255
signed char	1	- 128 .. 127
(signed) short (int)	1	- 128 .. 127
unsigned short (int)	1	0 .. 255
(signed) int	2	-32768 .. 32767
unsigned (int)	2	0 .. 65535
(signed) long (int)	4	-2147483648 .. 2147483647
unsigned long (int)	4	0 .. 4294967295

Diese Tabelle hat leider einen kleinen Schönheitsfehler, und der beschreibt auch das ganze Problem hier. Sie gilt nur für mikroC. Es gibt in C keine Vorgabe, ob ein char (ohne einen Zusatz) als signed oder unsigned behandelt wird. Warum, habe ich beschrieben. Jeder Compiler kann es also anders halten, und tut es auch, wie dieser Tread zeigt.

Um diesen und ähnlichen Problemen aus dem Wege zu gehen, gibts nun mal stdint.h.

danke für die Schützenhilfe, aber für Intel x86, Win32, Win64, und AVR von Arduino Micro über Uno und Leonardo bis Mega wird "char" als "signed" behandelt.

Das hängt nicht vom Prozessor ab, sondern vom Compiler

Aber wie gesagt, Schnee von gestern. Die tollen Arduino-IDE-Programmierer hätten da in ihr tolles Sketch für gefühlt 10000 verschiedene Boards wenigstens eine Compilerwarnung für den Due einbauen können, wenn sie char jetzt plötzlich anders behandeln als für die 9999 übrigen Boards.

Die IDE ist nur das Frontend für irgendeinen Compiler, den kann man meist sogar tauschen. Die IDE kann also nicht wissen, wie sich der gerade eingestellte Compiler verhält.

Es ist doch ganz einfach: wer sicher sein will, daß sein char signed ist, muß es explizit hinschreiben! Oder, um mich zu wiederholen, stdint.h.

MfG Klebwax

[Andre_S]

Hallo,

belassen wir es doch einfach dabei,.. dann passt es "sogar" für microC

... wer sicher sein will, daß sein char signed ist, muß es explizit hinschreiben!
...
MfG Klebwax

Gruß André

[HaWe]

mein Gott, Klebwax, kleb dir deine Besserwisserei doch irgendwohin.
Für Leute, die erst nichts zur Problemlösung beitragen, und hinterher, wenn alles klar ist, alles nochmal aufwärmen und breittreten, als hätten sie die Weisheit mit Löffeln gefressen, habe ich EINIGE Kategorien zu vergeben.
Klugscheißer und Korinthenkacker sind noch die mildesten.

[RoboHolIC]

@Klebwax:

Diese Tabelle . . . gilt nur für mikroC. . . Jeder Compiler kann es also anders halten

Um diesen und ähnlichen Problemen aus dem Wege zu gehen, gibts nun mal stdint.h.

Danke Dir und den anderen. Ich hab was gelernt, um irgendwann in Zukunft C-Source pflegbar portabel zu schreiben: nämlich das einziehen einer Abstraktionssebene für die Typbezeichner.

Leider ist Abstraktion nicht jedermanns Sache.
Und Selbstbeherrschung bei sozialen Interaktionen auch nicht.

mein Gott, Klebwax, kleb dir deine Besserwisserei doch . . .
Klugscheißer und Korinthenkacker sind noch die mildesten.