|
Anzeige
|
Welchen Sinn hat der Datentyp "bool"?Hallo,
verwende den freien Compiler XC32 von Microchip.
Habe jetzt festgestellt, das ein "bool" die gleich Größe an Ram Speicher wie ein "char" verbraucht. Warum bekommt es ein moderner Compiler nicht hin, in ein Byte 8 bools zu packen ?????
Warum sollte man das wollen? Den allermeisten sind die 8bits egal, die wollen Geschwindigkeit. Nur ein paar exotische Mikrocontroller-Nerds fahren auf solche Bitfrickeleien ab. Oliver Ineffizient. Ein Byte oder ein Wort lesen, dann die anderen Bits ausmaskieren kostet Zeit und Code. Beim Schreiben genauso. Ausnahme: Der Prozessor hat entsprechende Bit-Befehle, etwa MSC-51 oder bei ARM Bitbanding. Letzteres wird aber nur stiefmütterlich unterstützt und ist (deshalb?) bei neueren Typen gar nicht mehr vorhanden.
Ja klar, was denn sonst? Speicherzellen sind numal mindestens 8 bit groß.
Warum sollte ich mich mit CHAR mit 255 Zuständen herumschlagen, wenn bool schon vom Compiler aus nur zwei Zustände kennt?
Wieviel Speicher denkst Du denn, kostet es, sich zu merken, wo und an welcher Stelle der Bool ist?
Das dachten sich Kernigham&Ritchi auch.
Sie bekommen es hin, alles eine Frage wie gut der Compilerschreiberling war. Entscheidend ist, pointer auf Bits zu verbieten, damit
kein Problem wird.
Jo! Einfach sich mal eine Makro bastel was sowas nachbildet und sich dann den Assembler output anschauen. Um 7-Bit Datenspeicher einzusparen, hat man dafür dann mehrere Byte an zusätzlichem Code bei jedem Zugriff darauf. Im Prizip kann man sich sowas auch mit "bit field" nachbasteln, da erzeugt der Compiler dann den ganzen zusätzlichen Programmcode im Hintergrund: OK, Danke. Verstanden.
Nicht unbedingt, wie uC haben Bitadressierungszugriffsarten, da ist das 1 Befehl. Ob der Compiler sie effizient nutzt, wie ein Assemblerprogrammierer, sei dahingestellt, viele Compiler sind strohfoof.
Tut er doch! ... Wenn möglich und GEWÜNSCHT. Also auf die Optimierungsstufe achten! (Standard für lau tut/tat!) (Zuletzt mit V5.x verwendet und geprüft. Nich weils nötig war, nur haben wollen, mus so sein etc. :)
Ubs, völlig verplant... Das war die IDE Version. :} XC8 2,36 Ja, andere Baustelle aber ich könnt mein linken Schuh drauf verwetten... Wenn ich mich recht erinnere, hab ich die alle als Global anlegen müssen(?) und das Progrämmchen war wirklich mehr überschaubar.
Gast
#7552671
Ist das Chinesisch? Lau tut tat? Bitte uebersetze doch Mal.
"für lau" == umsonst (aber nicht vergebens), "für umme", kostenfrei, gratis tut = macht etwas /jetzt/, Gegenwart tat = machte etwass /früher mal/, Vergangenheit
Tat = Schreibfehler -> Dat = Das/Dieses :DDD
Klingt in diesem Kontext dann aber komplett bizarr:
Ich hatte mir das so ins Hochdeutsche übersetzt: Also auf die Optimierungsstufe achten, die [im XC8] kostenlose Standardoptimierung genügt bzw. genügte früher, als ich [Teo] das mit V5.x [des XC8] nutzte. Oh, meine Fehlschreibung "etwass" ist peinlich, da muss die Tastatur geprelllllllllt und ich Blindfisch das nicht gesehen haben. Also:
Wobei der fehlende Ptr viele weitere Dinge impliziert, z.b. Ansicht im Debugger, Arraxs, memcpy, sizeof...
Gast
#7552713
Damit man quasi "natursprachlichen" Code niederschreiben kann. OK, für einen englisch-sprecher ist der Verständnisvorteil offensichtlicher:
mit dem Schlüsselwort "then" wäre es noch "natürlicher" Auf deutsch und auf "magic numbers" verzichtet:
aber wer lässt sich schon c-code "vorlesen" oder legt Wert darauf, das auch C-Unkundige verstehen könnten was das Programmieräffchen da zusammengekritzelt hat hat...
Dafür braucht man keine Bools, if(motorenabled) würde auch mit einem int o.dgl. funktionieren.
Der obige Griff ins Klo macht diese Äusserung noch peinlicher.
Klar, damit geht dann auch motorenabled ++ Wer weiß, vielleicht möchte man ja mal mitteilen, der Motor sei "doppelt plus an". Schönen Gruß an Herrn Blair!
Es geht natürlich beides. Mit bool kann man in C nicht mehr machen als auch mit int oder char möglich ist. Aber mit bool drückt man klar aus, daß man nicht mit einer von vielen möglichen Zahlen hantieren will, sondern mit "ja" oder "nein". (Es soll Leute geben, die lesbare Programme bevorzugen.) In C++ wird es dann interessanter, weil da mehr auf Typen geachtet wird. Bspw. beim Überladen von Funktionen kann ein Aufruf mit einer bool etwas anderes sein als ein Aufruf mit einer Zahl. Man könnte eine Funktion, die Werte ausgibt, z.B. für bool anders überladen als für char oder int:
Oder streams (vulgo files, wie std::cout als Standardausgabe, oder eine echte Datei): Wenn man so einen stream an etwas übergibt, was einen stream erwartet, wird er halt als stream behandelt. f.write(...) würde also etwas in die Datei f schreiben, und wieder f zurückliefern. Benutzt man einen stream aber in einem logischen Ausdruck, wird er in bool konvertiert. Diese Konvertierung ist für streams aber so überladen, daß sie true ergibt, wenn der stream noch funktioniert, oder false, wenn nicht (z.B. Fehler aufgetreten). Das ermöglicht eine Konstruktion wie:
, weil while einen logischen Ausdruck braucht und die Konvertierung von f nach bool den Status des streams liefert. Wer also meint, bool ist überflüssig, der hat eigentlich recht und darf gerne ohne bool weiter herumstümpern :-) Ich denke, dass bool beim C99 Standard extra für die Pascal und Basic - Koryphäen eingeführt wurde, weil die damals auch mal C probieren wollten! Auch Nichtkoryphäen, haben da gerne mit Defines, ihre Programme aufgehübscht. Wurde grad von XC8 (2.36) enttäuscht. Hab mal auf die schnelle, einer Funktion mit Booleschen Rückgabewert, ne Zahl >1 zugewiesen. Nich mal ne Warnung (-9) gibts. :´(
Ich meine beim XC8 Compiler gibt es doch den Datentyp "bit" Den vermisse ich beim XC32.....
Gast
#7552831
Maddonix iddonetlimm! (Macht fast gar nichts, ist wirklich nicht so schlimm)
Ist ja eigentlich auch nicht schlimm:
Auf die Schnauze fällt man dann, wenn man es einem bitfeld-bool zuweist. (Seit einiger Zeit nutze ich 0/1 statt false/true. Keine Ahnung, warum ich das geringfügig besser lesbar finde, trotz verwechselungsgefahr mit integerwert)
Aber ne Warnung wärs wert, denke ich. Ich glaub, ein paar Synapsen tuns grad wieder... Wenn ich mich recht erinnere, ist beim XC8 bool, auch nur ein Makro mit _bit. Das in ein Byte stopfen, geht denke ich, da auch nur mit statischen.
Gast
#7552983
bool in Basic ? Hatte der 9kbyte grosse Interpreter des C64 überhaupt Platz für solchen Zuckerguß? https://www.c64-wiki.de/wiki/C64-Befehle Und klar, das "boolean" als Hochsprachenkonstrukt von Embedded Hackern die C eher als eine Art "Assembler für Warmduscher" verwenden, weitgehend ignoriert wird. Dabei kann man mit passender Typisierung viele Fehler vermeiden bzw. schon im Compiler abfangen. Es sind schon Raketen abgestürzt wegen dem falschen typ.
1999 ist für den C64 etwas spät. Das war 5 Jahre nach EOL. Es war eher so die Zeit, als sie alle mit Visual Basic hantiert haben, das es da schon seit 8 Jahren gab.
Gast
#7553055
Naja, wenn man "Visual Basic" meint sollte man auch "visual Basic" schreiben und nicht "BASIC". Und bei den amüsanten Vergleich zwischen C99 und "dem Rest der welt" geht es wohl eher um die Unterscheidung in "stark" und "Schwach" typisierte Sprachen. https://de.wikipedia.org/wiki/Typisierung_(Informatik)#Beispiele Und das alle mit Visual Basic hantiert hätten ... IMHO gab es da mehr als das sprichwörtliche Gallische Dorf die ihren eigenen Zaubertrabk köchelten und damit in die Schlacht zogen: (Borland-) Pascal, ADA, Modula-2, Lisp, Forth, Erlang, .... Wobei ohne Betrachtung des Anwendungsgebietes ist diese Einteilung IMHO allein zweckfrei. Esy geht halt darum, ob man in konkreten Anwendung Vorteile durch die Verwendung von "passenden Typen" hat. Der Prozessor selbt hat hat nur die Typen Datenbusbreite (char, int) und pointer auf Speicherzelle an Datenbus. Damit kommt dann auch der Embedded Coder besten aus. Und dann gibt es Applikationen, die abstrakt weit weg vom Prozessor sind, beispielsweise GUI oder natursprachlich formulierte Ablaufsteuerungen, Datenbanken, ... die sind dann eher für "Hochsprachen und ihre Concepte" geeignet, da möchte man nicht die Programmlogik durch Maschinendetails "verbogen" sehen.
Da stand "Basic", nicht "BASIC", und da das BASIC vom C64 zu der Zeit keine Rolle mehr gespielt hat und wie du richtig angemerkt hast, auch keinen bool-Typ hat, war das offensichtlich nicht gemeint.
Es ging um die Frage, warum C99 einen Typ bool eingeführt hat. Das hat erst mal nicht soviel damit zu tun, dass C schwach typisiert ist. Es ist eher so, dass es deswegen nicht zwingend ein bool gebraucht hat und daher anfangs keins hatte. Schließlich funktioniert ja z.B. in einem if auch ein beliebiger numerischer oder Zeiger-Typ als Bedingung.
Mit "alle" meinte ich alle, die irgendwas mit Basic am Hut haben, nicht alle Programmierer weltweit. C64-BASIC war 1999 nicht mehr so gefragt.
Ja, deshalb hat man ja Hochsprachen.
Wobei es natürlich trotzdem meist gewisse Randbedingungen gibt.
Damit man Hochsprachencode mit "true" und "false". schreiben kann. Mir fällt es aber trotzdem leichter, logische Operationen z.B. in Bitfeldern zu verarbeiten. Von Flags, logischen Operationen mit Registern, um diese zu setzen, und lustigem Hin- und Herspringen willst du lieber nichts wissen.. ;) Abfragen wie or ax,ax gleich an den Anfang einer (bestimmten) Schleife zu setzen, hatte mir mal ein professioneller Programmierer beigebracht. Der Code von dem sah im Debugger auch super aus. Aber der konnte auch gut coden. Von der Performance her sind auch Algorithmen sehr beliebt, wie auch effektiv.
Beitrag #7555481 wurde von einem Moderator gelöscht.
Irgendwie übersehen hier alle, dass ein C99 bool die tolle Eigenschaft hat, dass er immer 0 oder 1 ist. Man braucht auch beim Casten von größeren Datentypen keine Angst zu haben, dass nur die unteren Bits beachtet werden. 0x40000 in einen bool mit sizeof(bool) == 1 zu casten, liefert 1. Das gleiche in einen uint8_t zu casten, liefert 0.
Gast
#7555509
Tja, wer zu doof zum casten ist, sollte es lassen.
Der übliche kurze Hack ist !! (Bei einem Argument, sonst && oder ||) Es ist aber super, wenn man gar keinen Hack braucht.
Hast Du mal ein Beispiel? Oder geht es nur um Assembler-Hacks
Gast
#7555637
Ein boolean wird nie gecastet, ein boolean wird nur in Bedingungsoperatoren wie if () etc verarbeitet. Siehe auch Beitrag "Re: Welchen Sinn hat der Datentyp "bool"?" und Matthäus 5,37 .
Wobei es in C++98 ulkigerweise noch void* statt bool war. Und dieser war dann je nach Stream-Status ein Nullpointer oder nicht.
Beitrag #7556325 wurde von einem Moderator gelöscht.
Es geht nur um eine Bedingungsprüfung. Du könntest auch IF(ax) schreiben. In Asm geht aber die Schleifenkonstruktion etwas anders als in C, und Asm-Schleifen sind auch nicht so stark standardisiert. Beim Intel gibt es aber Befehlserleichterungen wie loop oder repz und auch die Register wie SI und DI z.B. für Richtungsabarbeitungen. Mit "Hacks" hat das nichts zu tun. Mit in logischen Operationen gut sein, aber schon.
M.E. doch Assembler-Hacks. Z.B. XOR zum löschen eines Registers oder swap Zweier. Also was als Pattern für seinen Assembler lernt und der C-Compiler auch kennt.
Jo, genau - hilft zur Vermeidung von Seiteneffekten bei z.B. Rückgabewerten. Angenommen musst nen Test schreiben, und musst potentiell alle Restklassen eines chars durchklappern, weil jemand auf Platz optimiert hat. Kann zwar auch sinnvoll sein, kommt aber drauf an. Pauschal da nur 2 Zustände brauchen zu müssen, könnte man halt irgendwie dezent als etwas sauberer erachten. ich hätte ja nichts dagegen, wenn ein bool auch tatsächlich ein bool wäre. Ich habe aber noch keinen (C-) Compiler gesehen, der bei
einen Fehler oder auch nur eine Warnung ausgespuckt hätte. So ist das keine Spur besser als
Selbst bei den C++ Compilern warnt nur MSVC, die anderen nur bei
Oliver
Ein bool ist ein bool ist ein bool.
Das liegt aber nicht daran, dass es kein bool wäre, sondern daran, dass ein int implizit nach bool konvertiert werden kann. In b steht nachher nämlich trotzdem keine 12 drin.
Doch, denn da stünde nachher 12 drin. Codevision AVR kann mit bool umgehen und macht die auch wirklich nur ein bit breit in einem Register.
Nö, da ist ein großer Unterschied. C macht eine automatische Konvertierung auf den Zieltyp ohne Warnung. Aus 12 wird also b = true d.h. b = 1.
Das ist missverständlich: Alles != 0 (also auch 12) wird zu true gewandelt, wenn eine boolsche Entscheidung gebraucht wird (z.B. bei if, while, ...). if(b==true) ist hingegen nur erfüllt, wenn b ein bool ist, nicht wenn es ein int ist. Bei if & Co behilft man sich, indem man niemals auf true vergleicht (was den code oft besser macht). Bei Zuweisungen erfordert es jedoch Klimmzüge:
b=12 geht aber eben nicht, weil b ein bool ist, der den Wert 12 nicht annehmen kann.
Wie ist das vorgegeben? Meckert der compiler dann, oder macht er einfach still ein TRUE (1) aus der 12? Der eigentliche Grund für die Bools ist, dass man einen richtigen, boolschen statt binären, postfix toggle Operator haben wollte: https://godbolt.org/z/GGrsrEoYP
Gast
#7582695
Er macht ein TRUE (1) aus der 12. Der Vorteil von bool (oder BOOL) ist, dass die Absicht des Programmierers klar ist, unabhängig ob der darunterliegende Datentyp ein INT oder ein BYTE ist. // Hier weiss ich dass die Funktion TRUE liefert, wenn alles passt. // Im Fehlerfall wird FALSE zurückgeliefert. BOOL doSomething() // Hier liefert die Funktion üblicherweise 0, wenn alles passt. // Im Fehlerfall wird ein Fehlercode zurückgeliefert. INT doSomething()
Eine Konvertierung von int nach bool macht wie oben angegeben aus 0 ein false, aus allem anderen ein true. Umgekehrt macht eine Konvertierung von bool nach int aus false eine 0 und aus true eine 1. Dabei können solche Konvertierungen implizit durchgeführt werden, also "still". Folgendes C-Programm gibt daher 1 aus:
Oder bei getchar(): 0 .. 0xFF = gültiges Datenbyte EOF (-1) = end of file
Die Konvertierungen können nicht nur implizit, also "still" durchgeführt werden, die werden grundsätzlich implizit, also "still" durchgeführt. Was dann zu der oben angemoserten Eigenschaft führt, das der Compiler nicht warnt. Oliver Danke für die geduldigen Erläuterungen, auch wenn ich das aus den voran gegangenen Posts hätte heraus lesen können.
Man kann sie per Cast durchaus auch explizit machen, wenn man das will:
Aber es ist in dem Fall nicht nötig, weil die implizite Konvertierung genauso geht.
Was überaus ungeschickt gemacht ist, denn char kann auch signed sein, also einen Wertebereich von -0x80 bis 0x7F haben.
Der Return-Wert von getchar() ist int. Schon der erste Kernighan-Ritchie benutzte
Ein char ist hier überhaupt nicht im Spiel. Das K&R-Kopierprogramm
funktioniert auch anstandslos auf Systemen, wo char signed sein kann. Die Verwendung von char in der Zuweisung wäre aber hier ein Fehler - nämlich des Programmierers, nicht der Bibliotheksfunktion.
Gast
#7583432
Was aber nicht funktioniert:
Doch, das mit dem Wertebereich von Char ist tatsächlich ein Problem, egal, ob ich die jetzt in ein int oder ein char packe. Ich konvertiere die dann immer erstmal nach unsigned char, bevor ich die weiter auswerte. Mir ist es schon passiert, dass ich ein Case in einem Switch hatte, und dann war das Zeichen negativ! Der Wert von EOF ist aber auch Implementationsspezifisch, der wird fast überall auf was ausserhalb vom char Bereich gesetzt, egal ob char nun in der Implementation signed oder unsigned ist. Der Wert von EOF ist also in der Regel kein Problem. Blöd ist nur, wenn man im selben Switch EOF und 0x80 prüfen will. Dann kann man nicht einfach nach "unsigned char" casten. Ok, '\x80' müsste dann eigentlich gehen. Aber so einen Fehler muss man erst mal finden!
Bei ISO8859 funktioniert das durchaus. c hat dann nämlich einen positiven Wert, nämlich 0xE4 - auch wenn auf dem System char signed wäre. Beachte, dass Du "int c" geschrieben hast, nicht "char c". getchar() liefert folgenden Wertebereich: 0 bis 255, -1 bei EOF - auch auf Systemen, wo char signed ist. Ich wiederhole: bei getchar() ist überhaupt kein char im Spiel!
Natürlich kann das passieren, wenn Du char als Type verwendest. Das hat aber nichts mit getchar() zu tun. Ich antwortete auf folgenden Satz:
Dieser bezog sich auf getchar(). Und darauf habe ich geantwortet. Dass Du jetzt darauf ansprichst, weil Du mal den Fehler gemacht hast, einen signed char buffer zu verwenden, hat mit getchar() überhaupt nichts zu tun. Wenn Du Zeichen speichern(!) willst, dann natürlich unsigned char:
Aber zum Auswerten des Rückgabewertes von getchar() brauchst Du weiterhin ein int! Ich hab gerade nochmal nachgesehen, was der Standard sagt. Die Zeichen die getchar zurückgibt sind tatsächlich als ob sie vorher nach unsigned char konvertiert wurden.
Eben. Wenn Du eine int-Variable nimmst, um den Rückgabewert von getchar() zu testen, bist Du immer im grünen Bereich. Von daher ist gar nichts "ungeschicktes" an der Funktion getchar(). Diese hat 1970 schon anstandslos mit Binärdateien funktioniert und funktioniert auch heute noch mit 8-Bit-Zeichensätzen wie ISO8859 oder UTF-8. Was mir aber gerade aufgefallen ist, bei Zeichenkonstanten ist das nicht festgelegt, ob wohl die auch vom typ int sind. Hier ein Beispiel, wo es negativ raus kommt: https://godbolt.org/z/z8xG7G4Wv Vermutlich ist es das, was ich in der Regel verwechsle. Da nimmt man extra '' für Zeichen im Switch, und dann sind die negativ!
Das war was anderes. Den Fehler mache ich definitiv nie. War wohl das Zeichen positiv, aber die Zeichenkonstante negativ.
Ja, Du hast 0x80 durch die Hochkommas in einen (negativen) char gewandelt. Hier sieht man das ganz gut:
'\x80' ist aber vom type int: https://godbolt.org/z/Y5rj6Pq3G
Ausgabe:
Gast
#7583690
Mein Verständnis ist: Char 'ä' ist signed ((char)0xE4 < 0), und wird implizit auf int gewandelt, damit habe ich eine negative Zahl. Der Rückgabewert von getchar ist aber immer positiv oder -1. Der Vergleich wird also schiefgehen. Aber für ASCII Zeichen, die ja alle positiv sind, passt die Funktion. Negative Zeichenkonstanten muss man auf (unsigned char)'ä' wandeln. Das kommt aber in der Praxis selten vor.
"Hällo" ist ein char Array. Und dort kann das zweite Element negativ oder positiv sein (halt wie char implementiert ist, als signed oder unsigned) 'ä' ist ein integer. Und positiv, wenn es "im erweiterten ASCII" liegt. Wenn ich 'a' nun einem char zuweise, dann wird es in diesem char halt als signed oder unsigned interpretiert, aber erst dort.
Ja, das ist auch der korrekte Weg.
Wie "natürlich"? Der Typ für Text ist char. Alle Stringfunktionen wie printf() oder strcmp() arbeiten mit Arrays aus char, nicht aus unsigned char. Explizit sollte man die signedness nur angeben, wenn man damit rechnen oder Bitgefummel machen will, denn Text hat eigentlich keine Signedness.
Ja. Das Problem ist: char ist eigentlich der Texttyp. Wenn der signed ist, dann muss getchar() den Wert erst in einen unsigned char wandeln, was auch im Standard so steht. Spannender wird es z.B. bei toupper(). Sagen wir mal, ich möchte mit fgets() (das auch mit einem char* arbeitet) einen String einlesen und diesen dann per toupper() zeichenweise in Großbuchstaben wandeln:
An toupper() dürfen nämlich außer EOF keine negativen Werte übergeben werden. Man muss erst nach unsigned char casten.
Und genau das ist es, was ich meinte.
In C ist 'ä' bereits vom Typ int. In C++ ist es vom Typ char, muss aber so wie du sagst für den Vergleich erst nach int konvertiert werden (Integer-Promotion).
Das ist richtig.
Oder halt umgekehrt den Rückgabewert von getchar() nach char wandeln.
Heutzutage mit UTF-8 gibt's kein 'ä' mehr.
Nein, eben nicht. Wenn char signed ist, ist 'ä' ein int mit negativem Wert! Was haltet ihr von -funsigned-char?
Nicht allzuviel, ich hab gern "selbst" (=direkt im Code) in der Hand, was ich mit einer Variablen mache, bzw wie diese interpretiert wird. Vielleicht habe ich den Sinn dieses Parameters aber auch nicht ganz verstanden, keine Ahnung... Der C-Standard sagt, dass es alle Integer-Typen in einer signed- und einer unsigned-Variante gibt. Dabei gilt, dass der Default, wenn man nichts explizit angibt, immer signed ist - außer für char. Da ist es implementation-defined, also der Compiler darf das entscheiden. Aus Gründen der Konsistenz mit den anderen Integer-Typen ist char deshalb zumindest bei gcc meist signed. Da es aber eben compilerabhängig ist, sollte an sich die Verwendung am besten so sein: signed char - für einen kleinen Integer mit Vorzeichen unsigned char - für einen kleinen Integer ohne Vorzeichen char - für Text Allerdings scheinen manche ein Problem damit zu haben, wenn Textzeichen in einem signed-Typ gespeichert werden, obwohl das streng genommen egal sein sollte. Text braucht nur genug Bits, um ein Zeichen zu speichern. Wie diese Bits verwendet würden, wenn man damit rechnen würde, spielt ja keine Rolle. Auf der anderen Seite sind dann noch die oben genannten Funktionen, die wie schon gesagt eher ungeschickt definiert sind und nicht sonderlich gut zu einem signed-char passen. Daher wird der eine oder andere mit dieser Option char auf unsigned zwingen. Am Ende schreibe ich aber meine Programme lieber so, dass es keine Rolle spielt, ob char signed oder unsigned ist und damit auch dieser Kommandozeilenparameter überflüssig ist.
Ja. Es geht nicht um char als Variable (da kann ich ja vorschreiben, was ich will) sondern um Stringkonstanten und library-funktionen mit char. Da würden ja genug Beispiele genannt.
Sinnigerweise sollten beide das gleiche verwenden.
C167 hatte auch Bitbefehle, da hätte das Sinn gemacht. Ist schon so lange her...ich weiß nicht mehr, ob der C-Compiler diese Befehle genutzt hat. Ansonsten ist die kleinste Zugriffseinheit bei den Prozessoren 1 Byte, 1 Wort, 1 Doppelwort usw...., abhängig von der Breite des Datenbus. Wie Andreas schrieb, würde es Code und Zeit kosten die Bits innerhalb eines Bytes zu maskieren. bool macht trotzdem Sinn in C: FALSE = 0; TRUE = !FALSE (also alles außer 0)
Wenn es als Scherz gemeint ist, dann bitte Smiley ;-) TRUE ist hier 1. '!' bedeutet nicht "alles außer" sondern "0-->1, sonst -->0"
Ja, den Fehler sieht man erstaunlich häufig. x != 0 ist aber eben nicht das gleiche wie x == !0. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
