Hallo, der Compiler meckert zwar nicht, aber kann die folgende Definition auf meiner Hardware zu einem Problem führen? Ist die Länge erlaubt? unsigned char Array[24] = {0x06, 0x00, 0x14, 0x00, 0x01, 0x00, 0x00 ,0x00, 0xD0, 0x08, 0x00, 0x00, 0x00, 0xC2, 0x01, 0x00, 0x07, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00}; Grüße, holger
Wenn du 'Byte' meinst, schreib bitte nicht 'char', sondern 'uint8_t'. Ansonsten dürfte das keine Probleme geben.
Wenn "deine Hardware" nur 23byte Ram hat dann führt das zu Problemen, sonst sollte es gehen.
mach dir keine sorgen....... das läuft also jetzt mal ganz im ernst: vergleiche mal deine frage mit den zur verfügung gestellten informationen. merkste was?
an dieser Zeile ist nichts auszusetzten mir ist keine Hardware bekannt die damit Probleme hat. Aber das Programm hat bestimmt noch mehr Zeilen und dann sollte man darauf achten wieviel Speicherplatz man insgesamt braucht und wieviel die Hardware wirklich hat. Und wie '... ...' sagte die 24 kann man weglassen also ...char Array[]={.... , dann zählt der Compiler und legt die Arraygrösse fest. Aber wenn man sicher sein will das das Array 24 Elemente hat sollte man die Grösse angeben.
>Wenn du 'Byte' meinst, schreib bitte nicht 'char', sondern 'uint8_t'.
Kann mich mal jemand aufklären? Dass check ich nicht. Weil ein char auch
mal nur 7 Bit haben könnte (in extremen Ausnahmefällen auf komischen
Systemen afair)?!
Matthias schrieb: >>Wenn du 'Byte' meinst, schreib bitte nicht 'char', sondern 'uint8_t'. > > Kann mich mal jemand aufklären? Dass check ich nicht. Weil ein char auch > mal nur 7 Bit haben könnte (in extremen Ausnahmefällen auf komischen > Systemen afair)?! Darum gehts nicht. Bei einem char ist nicht festgelegt, ob er signed oder unsigned aufgefasst wird. Das entscheidet der Compilerbauer. Ist dein Compiler so eingestellt, dass er char als signed char ansieht, dann kann das die (auf den ersten Blick) seltsamsten Effekte haben. Edit: Sieh dir mal diesen Thread an. Da ist genau dieses Problem jemandem zum Verhängnis geworden. Beitrag "einfacher If-Vergleich funktioniert einfach nicht :(" Edit 2: Seh gerade, dass der Urposter ohnehin ein unsigned char benutzt hat. Damit hat er dann das Problem natürlich nicht. Trotzdem ist es vernünftig uint8_t anstelle von 'unsigned char' zu benutzen. uint8_t ist kürzer und man muss nicht lange nachdenken, was seine Eigenschaften sind. u wie unsigned. int wie integer. 8 wie 8 Bit uint8_t ist also ein Datentyp, in dem Zahlen ohne Vorzeichen mit 8 Bit gespeichert werden können. Technissch ist ein uint8_t allerdings auch nichts anderes als ein unsigned char. Edit 3: > Weil ein char auch > mal nur 7 Bit haben könnte (in extremen Ausnahmefällen auf komischen > Systemen afair)?! Und so dumm ist das gar nicht. Es ist tatsächlich nicht festgelegt, wieviele Bits ein char aufweisen soll.
Ah ja, danke für deine ausführliche Antwort. Dachte mir schon, dass das "unsigned" doch explizit noch dabei stand. Stehe noch am Anfang meiner Kenntnisse unter C/C++, da fehlt mir teilweise noch ein wenig der Durchblick in den Datentypen. Gibt glaube ich auch Systeme wo char 9 Bit haben soll, aber das führt jetzt zu weit. :D
Also ich programmiere schon über 20Jahre aber Datentypen mit 7 oder 9 Bit hab ich noch nie gesehen, ich weiss auch nicht wie die Hardwarearchitektur damit umgehen soll. Der Typ char war in meinen letzten 20 Jahren immer 8Bit signed. Ich will nicht ausschliessen das es merkwürdige Compiler gibt die was anderes machen. Char int long usw. sind elementare Daten Typen in C und uint_8 usw. sind in einer Header Datei definiert, natürlich kann man selber Datentypen definieren mit 3, 7 oder 13 Bits Hardwaremässig sind sie aber ein vielfaches von 8Bit. Ausserdem entscheidet nicht nur der Compiler sondern auch die Hardware über die Grösse der Datentypen z.b. ist int in einem 8Bit und 16Bit Prozessor 16Bits breit und in einem 32Bit System 32Bit. Und um das zu umgehen das sich die Grösse der Datentypen mit der Hardware ändert ist in einer Headerdatei die Definition wie uint8_t usw. enthalten. Wenn ihr Avr programmiert seht mal in die stdint.h da sind die Typedefs drin.
In "The C Programming Language", K&R Original, wird eine Implementierung auf einer Honeywell 6000 aufgeführt. Die hatte eine Wortbreite von 36 Bits, was bei Maschinen aus den 50ern und 60ern ziemlich häufig vorkam. Da kommt man eher auf 6 oder 9 Bits für ein Zeichen. Also eben 9 Bits in C - und 6 Bits in FORTRAN und anderswo. Warum im ursprünglichen K&R-C externe Namen in den ersten 6 Zeichen eindeutig sein sollten, das erklärt sich damit auch ziemlich zwanglos.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.