Not Operator in C(++)/Arduino: Ergebnis vom Datentyp abhängig?

[Roth (Gast)]

So ich hoffe, dass ich mit meinen spärlichen C-Kenntnissen jetzt keine 
all zu dumme Frage stelle. ;-)

Ich hatte eben ein Thema aufgemacht, wo es darum geht, wie die CPU (oder 
Compiler, wie auch immer ... ) organisiert bzw. in welcher Form das im 
Speicher abgelegt wird.

Der Frage voraus ging eine andere Frage, die ich mir, wenn ich ehrlich 
bin, in keiner anderen Sprache je gestellt habe...gar nicht stellen 
musst. In C/C++ bin ich aber am schwimmen.

Die Frage: was ergibt "not true" ?

Die Antw. ist natürlich klar: "false"

Jetzt stehe ich aber vor folgender Überlegung. Wenn ein Bit invertiert 
wird, wird eine 1 zu 0.

Wenn aber ein Byte vom Wert 1 invertiert wird, wird daraus 254. So 
habe ich das jedenfalls gelernt und bei vielen Sprachen ist das auch so. 
Un deswegen habe ich immer ein komisches Gefühl, wenn ich in C solche 
Trivialitäten wie "not" (bzw !) einsetze. Wird das ergebnis von !1 0 
sein, oder 255? Oder hängt das vom Datentyp ab? Wäre nett, wenn man das 
nicht an der Frage, sondern allgemeinbezogen beschreiben könnte. Ich 
komme mir ja schon behindert vor, dass ich damit Unklarheiten habe ...

[Roth (Gast)]

Schnellschuss

Roth schrieb:
> Ich hatte eben ein Thema aufgemacht, wo es darum geht, wie die CPU (oder
> Compiler, wie auch immer ... ) organisiert bzw. in welcher Form das im
> Speicher abgelegt wird.


Ich hatte eben ein Thema aufgemacht, wo es darum geht, wie die CPU (oder
Compiler, wie auch immer ... ) booleans organisiert bzw. in welcher 
Form das im Speicher abgelegt wird.

[(prx) A. K. (prx)]

Komplement (~) und logisches invertieren (!) sind zwei paar Stiefel.

[Jim M. (turboj)]

Roth schrieb:
> Wenn aber ein Byte vom Wert 1 invertiert wird, wird daraus 254. So
> habe ich das jedenfalls gelernt und bei vielen Sprachen ist das auch so.

Falscher Operator.

Bitweises Not

  ~(uint8_t)1 == 0xFE;

Boolsches not:

  !1 == 0;

Die meisten anderen Sprachen haben ähnliche Unterscheidungen zwischen 
boolschen und bitweisen Operatoren.

[Jemand (Gast)]

C11 6.5.3.3:
"4 The result of the ~ operator is the bitwise complement of its 
(promoted) operand (that is,
each bit in the result is set if and only if the corresponding bit in 
the converted operand is
not set). The integer promotions are performed on the operand, and the 
result has the
promoted type. If the promoted type is an unsigned type, the expression 
~E is equivalent
to the maximum value representable in that type minus E.


5 The result of the logical negation operator ! is 0 if the value of its 
operand compares
unequal to 0, 1 if the value of its operand compares equal to 0. The 
result has type int.
The expression !E is equivalent to (0==E)."

[Roth (Gast)]

A. K. schrieb:
> Komplement (~) und logisches invertieren (!) sind zwei paar Stiefel.

Verlass dich drauf.
Oder gib (Beispiel) im VBA-Direktbereich ein :

print not 1
-2

Ist ganz easy, nicht wahr. Wenn 1 = true ist, muss immer 0 rauskommen. 
Tuts aber leider nicht. Wenn da sin C so ist...ok. aber das war ja meine 
Frage

Jim M. schrieb:
> Boolsches not:
>
>

>   !1 == 0;
>

>
> Die meisten anderen Sprachen haben ähnliche Unterscheidungen zwischen
> boolschen und bitweisen Operatoren.

Habe das schon ausprobiert :) Auch !12345 in C ergibt in 0. Der Arduino 
kann auch "not" . Ergibt das dann auch false bzw. 0 ? Nochmal VBA:

print not 12345
-12346

Und -12346 ergibt in VBA TRUE. Somit ergibt, wenn man (bei VBA) nicht 
aufpasst, not trut = TRUE !! ;)

VBA war aber nur ein Beispiel.

[(prx) A. K. (prx)]

Mit Beispielen in VBA kommst du bei mir nicht weit.

In C muss man erst einmal wissen, was man eigentlich will. Bits 
umkippen, oder einen logischen true/false Status umdrehen. Das hat 
nichts miteinander zu tun.

Richtig ist aber, dass ein Wert in Abfragen auch dann als "true" gelten 
kann, wenn er nicht den Wert "true" hat:
   if (2)          // trifft zu
   if (2 == true)  // trifft nicht zu, Programmierfehler
   if (2 != false) // so klappts besser
Deshalb ist es - wenn's denn unbedingt sein muss - sinnvoller, mit false 
zu vergleichen, als mit true.

Sowas kommt raus, wenn eine Programmiersprache Booleans als Integers 
betrachtet, statt diese Datentypen unvereinbar zu machen.

[Roth (Gast)]

A. K. schrieb:
> Mit Beispielen in VBA kommst du bei mir nicht weit.
Es war ja klar, dass sowas kommen muss.

A. K. schrieb:
> Deshalb ist es - wenn's denn unbedingt sein muss - sinnvoller, mit false
> zu vergleichen, als mit true.

Das hilft nicht weiter, wenn man in C boolsche Werte invertiert. '!' und 
'^' ist mir bekannt. Und wie verhält sich 'not' ?

Wieso gibts überhaupt ein 'not', wenn beiden Operatoren (boolsche und 
bitweise) schon da sind ? Das ist kein Feature, sondern ein Manko.

Wenn man 'not' verstanden hat, taucht dann vielleicht ein 'Not' aus der 
Versenkung auf (mit großem 'N' )?

Wieso gibts boolean, wenn es bool gibt? Sorry, aber das ist einfach nur 
inkonsistent. Sage bitte niemand, dass es so vernünftig ist.

Klar. Wenn ich 20 J. in C programiere, kenne ich das alles. Aber wie 
soll man klar kommen (Zitat: "schau mal in der C-Doku") wenn es x 
Ableitungen von ein und derselben Sache gibt. Von der man nicht weiß 
(ich jedenfalls nicht), WOVON sie abgeleitet ist ...

Es gibt bool.
Es gibt boolean.
Gibt es auch Boolean mit großem 'B' ?

Denn es gibt ja auch sowas:

#define bool _Bool

Als ich in den 80ern das erste Mal mit C zu tun hatte, hatte ich ein 
mulmiges Gefühl im Bauch. Dass die Unterscheidung zwischen Groß- und 
Kleinschreiben zu einem Wirrwarr führen muss.

Heute, 30 J. und tausende Libs später, sehe ich es leider bestätigt. 
Wohl dem, der in den Gewäddern zu Hause ist, aber LERNEN kann man das 
eher nicht. auswendig lernen vielleicht, aber mit Lernen hat das ncihts 
mehr zu tun. Die "Vielfalt" identischer Befehle und Operatoren unter 
unterschiedlichsten Namen hat mit Sinnhaftigkeit nichts mehr zu tun.

[(prx) A. K. (prx)]

Roth schrieb:
> Das hilft nicht weiter, wenn man in C boolsche Werte invertiert. '!' und
> '^' ist mir bekannt. Und wie verhält sich 'not' ?

Was C oder C++ Standards angeht kenne ich "not" nur als Identifier mit 3 
Buchstaben ohne festgelegte Bedeutung.

> Wieso gibts boolean, wenn es bool gibt?

Weder in C noch in C++ gibt es "boolean".

> inkonsistent. Sage bitte niemand, dass es so vernünftig ist.

Offenbar ist diese Erkenntnis auch bei Arduinos durchgedrungen, sonst 
stünde zu "boolean" nicht "It’s recommended to instead use the standard 
type bool, which is identical."

[Roth (Gast)]

A. K. schrieb:
> Weder in C noch in C++ gibt es "boolean".

Sage das bitte meinem (Arduino) Compiler . Er - compiliert - es.

Aber ich habe die booleans in byte ausgetauscht und verwende von nun an 
nur noch 0 und 1. Das gefällt mir besser.

[avr (Gast)]

Roth schrieb:
> Sage das bitte meinem (Arduino) Compiler .

Es gibt keinen Arduino-Compiler. Das ist der ganz normale GCC.

> Er - compiliert - es.

Was du in der Arduino IDE siehst und mit was der Compiler von der IDE 
gefüttert wird sind verschiedene Dinge. Der GCC kennt boolean nur, weil 
die IDE den Code ergänzt.

[Roth (Gast)]

avr schrieb:
Der GCC kennt boolean nur, weil die IDE den Code ergänzt.

Dann muss doch 'boolean' zumindest bekannt sein. Oder wie soll das 
gehen? Alle Fehler, unbekannte Schlüsselworte oder nicht definierte 
Bezeichner, werden ordnungsgemäß als Fehler ausgeworfen, 'boolean' aber 
nicht.

[A. S. (Gast)]

Roth schrieb:
> Sage das bitte meinem (Arduino) Compiler . Er - compiliert - es.

Du solltest Dein Handbuch lesen oder Deine includierten Dateien kennen. 
Wenn "not" zu "!" wird, dann wirst Du sowas wie

#define not !

in einer Header-Datei finden. Da es soviele .h-Dateien nicht gibt, lass 
Deinen Editor (Deine IDE) nach "not" in allen .h suchen, notfalls auch 
*.*.

Und dann nochmals im Handbuch.


Der C-Standard ist relativ klein (ja, sogar sehr klein) und alles andere 
findest Du normalerweise in Headern.

[chris (Gast)]

Roth schrieb:
>Wieso gibts boolean, wenn es bool gibt? Sorry, aber das ist einfach nur
>inkonsistent. Sage bitte niemand, dass es so vernünftig ist.

Es gibt schon einen Grund dafür:
Beitrag "Re: Arduino: Ist boolean intern als Bit oder byte (char) organisiert?"

[Walter S. (avatar)]

Roth schrieb:
> So ich hoffe, dass ich mit meinen spärlichen C-Kenntnissen jetzt keine
> all zu dumme Frage stelle. ;-)

kennst du diese Seite, da steht einiges zu Arduino:
https://www.arduino.cc/reference/en/

[Rolf M. (rmagnus)]

Roth schrieb:
> A. K. schrieb:
>> Mit Beispielen in VBA kommst du bei mir nicht weit.
> Es war ja klar, dass sowas kommen muss.

Was? Dass Leute, die zum Thema C in einem Forum für µCs posten, nicht 
zwingend VBA-Kenntnisse haben? Ja, das musste so kommen.

Roth schrieb:
> Das hilft nicht weiter, wenn man in C boolsche Werte invertiert. '!' und
> '^' ist mir bekannt. Und wie verhält sich 'not' ?

not ist ein anderer Name für !. Es verhält sich exakt gleich.

> Wieso gibts überhaupt ein 'not', wenn beiden Operatoren (boolsche und
> bitweise) schon da sind ? Das ist kein Feature, sondern ein Manko.

Man wollte wohl auch die Möglichkeit bieten, boolesche Ausdrücke konform 
zu ISO-646 schreiben zu können. In der Praxis benutzt das aber kein 
Mensch.

> Wenn man 'not' verstanden hat, taucht dann vielleicht ein 'Not' aus der
> Versenkung auf (mit großem 'N' )?

C++-Standard-Identifier fangen nie mit einem Großbuchstaben an. Ob 
Arduino auf die Idee kommt, sowas zu machen, kann man aber schlecht 
vorhersehen. Das ist wie bei Microsoft: Da gibt's für jeden Typ nochmal 
ein Alias mit dem selben Namen, nur komplett groß geschrieben. 
Hauptgrund scheint zu sein, es möglichst inkompatibel zum Rest der Welt 
zu machen.

> Wieso gibts boolean, wenn es bool gibt? Sorry, aber das ist einfach nur
> inkonsistent. Sage bitte niemand, dass es so vernünftig ist.

Frag das die Arduino-Entwickler. Vielleicht haben die erst später 
gelernt, dass es bool schon gibt.

> Denn es gibt ja auch sowas:
> #define bool _Bool

Das hat aber andere Gründe. _Bool ist auch nicht für die direkte 
Verwendung gedacht. Abgesehen davon ist das auch nur für C gedacht und 
nicht für C++, wo bool schon ein Schlüsselwort ist.

A. K. schrieb:
> Was C oder C++ Standards angeht kenne ich "not" nur als Identifier mit 3
> Buchstaben ohne festgelegte Bedeutung.

Tja, dann kennst du C und C++ nicht vollständig. ;-)
Schau dir mal an, welche Schlüsselwörter es in C++ gibt und staune: 
https://en.cppreference.com/w/cpp/keyword
In C ist es kein Schlüsselwort, kann aber über den Standard-Header 
<iso646.h> eingebunden werden.

[my2ct (Gast)]

Roth schrieb:
> avr schrieb:
> Der GCC kennt boolean nur, weil die IDE den Code ergänzt.

Aber er kennt bool und der Rest steht in Arduino.h

typedef bool boolean;

in stdbool.h

#ifndef __cplusplus

#define bool  _Bool
#define true  1
#define false  0

#else /* __cplusplus */

/* Supporting <stdbool.h> in C++ is a GCC extension.  */
#define _Bool  bool
#define bool  bool
#define false  false
#define true  true

#endif /* __cplusplus */

[chris (Gast)]

>> Wieso gibts boolean, wenn es bool gibt? Sorry, aber das ist einfach nur
>> inkonsistent. Sage bitte niemand, dass es so vernünftig ist.
>Frag das die Arduino-Entwickler. Vielleicht haben die erst später
>gelernt, dass es bool schon gibt.

Ich hatte es bereits geschrieben: "boolean" kommt vom Wunsch nach 
Kompatibiltät zu Java.

Beitrag "Re: Arduino: Ist boolean intern als Bit oder byte (char) organisiert?"

[Markus L. (rollerblade)]

Rolf M. schrieb:
> C++-Standard-Identifier fangen nie mit einem Großbuchstaben an.
Du meinst Type Specifier. Identifier sind was anderes.

[Peter D. (peda)]

Roth schrieb:
> Oder gib (Beispiel) im VBA-Direktbereich ein :print not 1
> -2

Bin ich im falschen Film oder wie.
Seit wann ist denn VBA ein C-Compiler?

[mh (Gast)]

Was C bzw C++ zu "not" zu sagen haben steht in den Kapiteln:
C++17 Draft (n4687):

5.5 Alternative tokens [lex.digraph]

C11 Draft (n1570):

7.9 Alternative spellings <iso646.h>

https://en.cppreference.com/w/cpp/language/operator_alternative liefert 
eine kurze Erklärung, warum es not und co, sowie di- und trigraphen 
gibt/gab.

[Carl D. (jcw2)]

Für die Freunde prosaischer Ausdrücke hier eine Liste der Alternativen 
Operatorbezeichnungen in C++:

&&  and
&=  and_eq
&   bitand
|   bitor
~   compl
!   not
!=  not_eq
||  or
|=  or_eq
^   xor
^=  xor_eq

laut http://cppreference.com

[Rolf M. (rmagnus)]

Markus L. schrieb:
> Rolf M. schrieb:
>> C++-Standard-Identifier fangen nie mit einem Großbuchstaben an.
> Du meinst Type Specifier. Identifier sind was anderes.

Type Specifier sind Identifier. Aber mir ist eingefallen, dass es nicht 
ganz stimmt. FILE passt nicht zu dieser Regel.

[Roth (Gast)]

Peter D. schrieb:
> Roth schrieb:
>> Oder gib (Beispiel) im VBA-Direktbereich ein :print not 1
>> -2
>
> Bin ich im falschen Film oder wie.
> Seit wann ist denn VBA ein C-Compiler?

Das war doch nur ein Beispiel dafür, dass "not true" NICHT unbedingt 
"false" ergeben muss. Sprachbedingt eben.

_______


Eine Frage habe ich noch:
Was haben solche Konstruktionen für einen geistigen Nährwert?

#define bool  bool
#define false  false
#define true  true

in stdbool.h

Ansonsten Danke für die interessante Diskussion :-)

[Ralf D. (doeblitz)]

Roth schrieb:
> Eine Frage habe ich noch:
> Was haben solche Konstruktionen für einen geistigen Nährwert?#define
> bool  bool
> #define false  false
> #define true  true
> in stdbool.h

Diese Preprocessor Macros ändern nichts am Text, sind damit aber 
definiert und somit mittels #ifdef/#ifndef prüfbar.

[Carl D. (jcw2)]

Roth schrieb:
> Peter D. schrieb:
>> Roth schrieb:
>>> Oder gib (Beispiel) im VBA-Direktbereich ein :print not 1
>>> -2
>>
>> Bin ich im falschen Film oder wie.
>> Seit wann ist denn VBA ein C-Compiler?
>
> Das war doch nur ein Beispiel dafür, dass "not true" NICHT unbedingt
> "false" ergeben muss. Sprachbedingt eben.
>
> _________
>
>
> Eine Frage habe ich noch:
> Was haben solche Konstruktionen für einen geistigen Nährwert?
>

> #define bool  bool
> #define false  false
> #define true  true
>

> in stdbool.h
>
> Ansonsten Danke für die interessante Diskussion :-)

Weil in stdbool.h am Ende noch
 #define __bool_true_false_are_defined 1
steht
und damit diese Makros vom restlichen Programm erwartet werden können. 
Und zwar unabhängig davon, ob es sie als Schlüsselwort oder als "Alias" 
gibt.