typedef uint8_t boolean; typedef uint8_t byte; In mehreren Include (Arduino) fand ich dies. Ist das korrekr, da es meiner meinung ,welche natürlich falsch sein kann, eine doppelte Defination ist?
> Ist das korrekr [..] Klar. > [..] eine doppelte Defination ist? Nein. Semantik des typedef beachten. Und vielleicht öfters mal einen Spellchecker anwerfen. HTH
typedef uint8_t boolean; typedef uint8_t byte; Sollte ich das so verstehen das hier ein Byte deklariert wird obwohl doch nur ein Bit für boolean ausreichen würde?
UINT8_t == unsigned char U -> unsigned ohne Vorzeichen INT -> Integer 8 -> Bit länge _t -> Kennung das ein Typ ist Und wie passt das in die Definition?
Destination != Definition :) Ja - es werden dort in der Definition 8bit für ein Boolean "verballert". Who kers?
teacher schrieb: > Axel R. schrieb: >> Who kers? > > Autsch! Ich finte es Auch unmöglich, wie hir mit der rechtschreipung Umgesprungen wird und als tietscher könte man wenigstens einen Perichtiskunk einfließen laßen.
Danny schrieb: > typedef uint8_t boolean; > typedef uint8_t byte; > > In mehreren Include (Arduino) fand ich dies. > Ist das korrekr, da es meiner meinung ,welche natürlich falsch sein > kann, > eine doppelte Defination ist? Es ist korrekt, weil es gerade keine doppelte Definition ist. Einmal wird der Typ "byte" definiert und einmal der Typ "boolean". Ja, das Kranke an der Sache ist die perverse C-Syntax, wo's mal von rechts nach links geht und mal in die Gegenrichtung, wie's der Macroassembler halt gerade braucht, der C im Kern auch nach 25 Jahren immer noch ist. Aber wenn man C will, muß man mit dieser sogar mehrfach standardardisierten(!!) Perversion des gesunden Menschenverstands einfach leben können. Und du wolltest offensichtlich C (wahrscheinlich waren dir die Konsequenzen bei der Wahl einfach noch nicht hinreichend klar). Also lebe entweder damit oder wähle unter Berücksichtigung dieser neuen Erkenntnisse einfach die Sprache nochmal neu...
c-hater schrieb: > Ja, das > Kranke an der Sache ist die perverse C-Syntax, wo's mal von rechts nach > links geht und mal in die Gegenrichtung In C++ gibts daher jetzt
1 | using boolean = uint8_t; |
2 | using byte = uint8_t; |
Welches genau wie typedef einen Typ-Alias definiert, aber die "bekannte" Reihenfolge beibehält (links neu, rechts alt).
Danny schrieb: > typedef uint8_t boolean; > typedef uint8_t byte; > > Sollte ich das so verstehen das hier ein Byte deklariert wird obwohl > doch nur ein Bit für boolean ausreichen würde? Ja. Und was würdest du als sparsamer Programmierer mit den übrigen 7 bits machen ? Normalerweise ist nur false mit wert 0 definiert. True ist NOT false, demzufolge ist jeder Wert ungleich Null true. Das ist (mMn) gar nicht mal so schlecht, denn auf diese Weise kann man sich auch ein bisschen Arbeit sparen und Programme in C, die ja sowieso schon unverständlich genug sind, wenigstens etwas verständlicher machen. Mal angenommen, du hast einen Schalter mit 7 Positionen und OFF.
1 | #define OFF false
|
Wenn (schalter == OFF) brauchst du gar nicht weiter zu prufen, ansonsten gehst du mit switch weiter:
1 | switch(schalter){ |
2 | case 1: |
3 | case 2: |
4 | ...
|
5 | case 7: |
6 | }
|
Somit hast du diese variable sowohl als Boolean als auch eine normale variable benutzt. Es steht nirgendwo geschrieben, dass Boolean nur zwei Werte haben darf, sondern dass es nur zwei Zustände annehmen kann, nämlich true und false . Mit uint8_t hast du genau einen Wert fur false, aber 255 Werte für true.
Eigentlich will ich nicht in C eindringen. Wollte nur mit den Arduino bissel Blinki Blanki und sonstige Kleinigkeiten machen. Bin auf diesen Umstand gestoßen als ich eine PS2 Tastatur anschließen wollte. Da stelle ich fest das genau bei diesen Definitionen ein Kompilerfehler ausgeworfen wurde. Auch bei anderen Include Dateien wie DMX Simpel war dies so.
Danny schrieb: > typedef uint8_t boolean; > typedef uint8_t byte; Naja, im Grunde ist das auch nur eine weitere Stufe der Herumdefiniererei. Im ersten Schritt wird aus byte ein uint8_t und im zweiten Schritt dann aus uint8_t_ ein unsigned char - und letzteres ist das, was der Compiler schlußendlich abkriegt. Also nochmal zum Einprägen: uint8_t ist für den Compiler nichts anderes als unsigned char. Das ist ja das Bescheuerte an diesem Mumpitz, daß es sich niemals um echte Datentypen handelt, sondern immer nur um Umbenennungen. Auch heutzutage kennt ein jeder C-Compiler nix anderes als char und int, bei Bedarf gewürzt mit unsigned und long, wobei man int per default auch weglassen kann, weshalb ein long für den Compiler ein long int ist. Alles Andere (bool, byte, uintXXX_t und so) ist nur oben drauf gesetzt und wird entweder - wenn per #define - vom Präprozessor oder bei Verwendung von typedef vom compilerinternen Typ-Präprozessor in die Grundtypen zurückübersetzt. Merke: mit typedef definiert man keinen neuen Typ, sondern nur einen neuen Namen für einen bereits vorhandenen Typ. W.S.
W.S. schrieb: > Also nochmal zum Einprägen: uint8_t ist für den Compiler nichts anderes > als unsigned char Nö. uint8_t ist ein unsigned 8-Bit Integer. unsigned char könnte zB auch ein 16bit-Integer sein. In diesem Falle existiert der uint8_t Typ nicht. W.S. schrieb: > Das ist ja das Bescheuerte an diesem Mumpitz, daß es > sich niemals um echte Datentypen handelt, sondern immer nur um > Umbenennungen. Das ist nicht bescheuert, das ist äußerst sinnvoll. So kann man plattformunabhängig korrekte Integer-Typen verwenden. Braucht man zB einen 16bit-Integer, schreibt man int16_t. Auf AVR wird der dann zu "int", auf x86 zu "short", je nachdem welcher Typ 16bit ist. Das ist wesentlich sinnvoller als einfach immer "int" zu verwenden und zu hoffen dass der immer 16bit ist! W.S. schrieb: > Auch heutzutage kennt ein jeder C-Compiler nix anderes als char und > int Und short, long, float, double. W.S. schrieb: > und wird entweder - wenn per #define - vom Präprozessor Zum Glück nicht per #define, sondern per typedef W.S. schrieb: > Verwendung von typedef vom compilerinternen Typ-Präprozessor in die > Grundtypen zurückübersetzt. Das ist kein Präprozessor, das nennt sich Typsystem. Und für Typ-Aliase natürlich immer schön typedef (oder "using" in C++) und nicht #define verwenden, da letzteres nur eine Dumme kontext-insensitive Textersetzung ist.
teacher schrieb: > Axel R. schrieb: >> Who kers? > > Autsch! Hehe, ich bin zwar erst seit 14:44Uhr angemeldet, aber darüber hinaus lang genug hier dabei. Wenn Du mich kennen würdest, dann wüsstest Du...
Axel R. schrieb: > Hehe, > > ich bin zwar erst seit 14:44Uhr angemeldet, aber darüber hinaus lang > genug hier dabei. Wenn Du mich kennen würdest, dann wüsstest Du... Sollte es nicht richtig heissen: Hoo kers ?
Richtig heißt das "hu kehrs" und bedeutet "wer fegt" (die Werkstatt beispielsweise, weil er nicht genuch programmiert) :D
Programmierer schrieb: > Nö. uint8_t ist ein unsigned 8-Bit Integer. unsigned char könnte zB auch > ein 16bit-Integer sein. In diesem Falle existiert der uint8_t Typ nicht. Ein "char" ist per Definition in C 8 Bit breit. Alle anderen Integertypen können irgendwelche Bitbreiten haben. >> Das ist ja das Bescheuerte an diesem Mumpitz, daß es >> sich niemals um echte Datentypen handelt, sondern immer nur um >> Umbenennungen. > Das ist nicht bescheuert, das ist äußerst sinnvoll. So kann man > plattformunabhängig korrekte Integer-Typen verwenden. Nein. Sinnvoll wäre ein Basistyp "16-Bit unsigned Integer", den man dann - je nach Anwendung - auf "int" oder "short" mappen kann. Aber die C-Basistypen sind schlicht unbrauchbar, weil es genau umgekehrt ist. Also müssen diese Typen erstmal plattform- und compilerspezifisch umbenannt werden, was unportabel ist und stinkt. > Und short, long, float, double. "short" und "long" sind Abkürzungen für "short int" und "long int". Ob C ursprünglich mal float/double kannte, weiß ich nicht. Gibt aber genug Compiler, die double zwar anerkennen, aber nicht implementieren.
S. R. schrieb: > Ein "char" ist per Definition in C 8 Bit breit. Alle anderen > Integertypen können irgendwelche Bitbreiten haben. Das ist falsch! Ein char ist mindestens 8-Bit breit. Kann aber auch größer sein. Z.B auch 9 oder 24 Bit oder ... Die anderen Datentypen sind dann Vielfache davon.
S. R. schrieb: > Ein "char" ist per Definition in C 8 Bit breit. Bitte lies nach in K&R, Seite 34. Ein "char" soll ein Zeichen des verwendeten Zeichensatzes halten können. Als C definiert wurde, war char auch mal 9 Bit breit. Auch die Breite von "int" schwankte damals schon erheblich. Int ist per Definition "das natürliche Datenformat" für die verwendete Architektur.
Wenn ein int immer 16 Bit hätte, dann könnte man es nicht plattformübergreifend benutzen, denn dann wäre dieser Basis-Typ einer Ganzzahl auf vielen "modernen" Maschinen nicht zu gebrauchen. Deshalb gibt es <inttypes.h>. Bräuche ich eine Anzahl Bits, oder auch eine Mindestanzahl, dann die Typen mit der Zahl im Namen. Brauch ich einfach nur eine Laufvariable, dann ist int das, was die konkrete Maschine am besten verdaut. Ausnahme sind 8-Biter, da wäre int als nur 8 Bit zwar konsequent, aber C definiert int zu "mindestens 16Bit". Wer mal auf den AVR mit der Option "8-Bit int" experimentiert hat, der ahnt warum. Aber man muß C nicht mögen. Es gibt so viele besser Programmiersprache. Z.B. B*COM. Da ist die Welt klein und übersichtlich.
Okay, ich korrigiere mich. POSIX (nicht C) erzwingt uint8_t und int8_t, daraus folgt zwingend CHAR_BIT==8. Das ist in normalem C tatsächlich nicht so.
Seit wieviel Jahren gibt es Mikroprozessoren und -controller? Und seit wieviel Jahren sind Datenbreiten zu 8 Bit und dessen Vielfachem aus technologischen Gründen festgelegt? Mal abgesehen von ganz speziellen Video-Speichern zu 18 Bit, die aber sowas von exotisch sind.. Und seit wieviel Jahren gibt es ASCII? Und hier kommt mir jemand mit 9 Bit Char's. Nochmal Mumpitz, denn so etwas kommt bestenfalls in extrem exotischen Gefilden vor. Äh.. 'kam' - denn von Rechnerarchitekturen, die mit 9 Bit Datenbreite arbeiten, sieht man heutzutage weit und breit nix. Aber nochmal: typedef dient einzig zu dem Zwecke, einem bestehenden Datentyp einen zweiten Namen zu geben. Es definiert KEINE neuen Datentypen. Auch dann nicht, wenn ganz besonders eifrige C-Programmierer die Realität nicht akzeptieren wollen. Aber diese unfruchtbare Diskussion hatten wir schon x mal. W.S.
W.S. schrieb: > Es definiert KEINE neuen Datentypen Du musst (solltest) noch etwas dazu lernen. typedef struct murks {char name[10], int (*func)(), int parm} MURKS; definiert schon einen neuen Datentyp. Die Honeywell 6000 mit ihren 9 Bit breiten Char war durchaus weit verbreitet. Nur, weil es heutzutage kaum jemand mehr kennt, ist es kein Mumpitz.
Georg G. schrieb: > Du musst (solltest) noch etwas dazu lernen. > > typedef struct murks {char name[10], int (*func)(), int parm} MURKS; Dann lerne du zuvor was dazu: struct murks {char name[10], int (*func)(), int parm}; typedef struct murks MURKS; So geht das eigentlich. Du hast es bloß nicht kapiert, daß du mit dem ersten Term eine eigentliche Typdefinition vorgenommen hast und selbige mit dem typedef-Wrapper anschließend in MURKS umbenannt hast. Also hast du anschließend zwei Möglichkeiten, dein Elaborat zu benutzen: struct murks Ottokar; und MURKS KarlHeinz; und beide sind gleichwertig benutzbar. Du mußt bei murks bloß immer das struct davorschreiben. W.S.
W.S. schrieb: > Und seit wieviel Jahren gibt es ASCII? Und hier kommt mir jemand mit 9 > Bit Char's. Na und. ASCII hat nur 7-Bit. Und trotzdem muss ein char mindestens 8-Bit haben. Es können auch 16-Bit sein. Und denke daran: ein char ist die kleinste adressierbare Einheit.
Ein echtes Boolean (also ein Bit) hast Du nur bei Prozessoren mit bitadressierbaren Speicherzellen. Alle anderen Systeme kennen keine Einzelbits. Die Bitadressierung ist sonst immer eine Maskierung mit oder ohne Schiebeoperation. Ich weiß nicht, ob man dies vor dem Programmierer unbedingt verstecken muss. Wer Platz sparen muss, maskiert sowieso lieber selber, als es einem Compiler zu überlassen. Für alle anderen ist es nicht wirklich von Betracht, ob ein oder zwei Speicherzellen "verschwendet" werden. Grüße, XXX
Thread beobachten
Seitenaufteilung abschaltenBitte 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.