Verständnisfrage ==

[C-Anfaenger (Gast)]

Hallo,

ich bin noch Anfänger und hab ein Verständnisproblem bei der if() 
Funktion mit ==

Ich nutzer den Cosmic Compiler für Freescale HCS12 Mikrocontroller.

Folgende if()-Abfrage funktioniert:

if( ( A & B ) == 0x00)
{
   mach_was();
}

Wenn ich aber schreibe:

if( A & B == 0x00)
{
   mach_was();
}

Wird nie zu "mach_was();" gegangen, es sieht sogar so aus als ob das 
weg-compiliert wird, ich kann da nicht mal einen Breakpunkt setzen in 
der 2. Variante, in der 1. Variante kann ich einen Breakpunkt setzen.

Ich lese zum lernen im Kernighan/Ritchie und da steht auf Seite 41 
eigentlich:

"Vergleiche haben geringeren Vorrang als arithmetische Operatoren. ..."

Ich verstehe das sicher falsch, aber es liest sich so, als wenn 
eigentlich beide Varianten der if()... das gleiche Ergebnis bringen 
sollten.

[Martin N. (emsen)]

Klammern beachten!
Im ersten Beispiel: wenn A UND B den Wert 0 ergibt ...
Im zweiten Beispiel: wenn A=1 ist UND B=0 ist ...

[Peter II (Gast)]

Martin N. schrieb:
> Klammern beachten!
> Im ersten Beispiel: wenn A UND B den Wert 0 ergibt ...
> Im zweiten Beispiel: wenn A=1 ist UND B=0 ist ...

wenn es wirklihc stimmt das

> "Vergleiche haben geringeren Vorrang als arithmetische Operatoren. ..."

dann hätte ich dieses verhalten aucn nicht erwartet.

[Klaus W. (mfgkw)]

C-Anfaenger schrieb:
> ... bei der if() Funktion

es gibt keine if-Funktion.

C-Anfaenger schrieb:
> "Vergleiche haben geringeren Vorrang als arithmetische Operatoren. ..."

Eine korrekte Tabelle hilft mehr als Gerüchte:
http://www.wachtler.de/ck/11_Operatoren_Ausdrucke.html#sec:oper-und-ausdr

> Ich verstehe das sicher falsch, aber es liest sich so, als wenn
> eigentlich beide Varianten der if()... das gleiche Ergebnis bringen
> sollten.

Nein, tun sie nicht.
== steht höher als &.

[Micha S. (ernie)]

C-Anfaenger schrieb:

Moin Moin,

> ich bin noch Anfänger und hab ein Verständnisproblem bei der if()
> Funktion mit ==
>
> Ich nutzer den Cosmic Compiler für Freescale HCS12 Mikrocontroller.
>
> Folgende if()-Abfrage funktioniert:
>
>

> if( ( A & B ) == 0x00)
> {
>    mach_was();
> }
>

>
> Wenn ich aber schreibe:
>
>

> if( A & B == 0x00)
> {
>    mach_was();
> }
>

>
> Wird nie zu "mach_was();" gegangen, es sieht sogar so aus als ob das
> weg-compiliert wird, ich kann da nicht mal einen Breakpunkt setzen in
> der 2. Variante, in der 1. Variante kann ich einen Breakpunkt setzen.
>
> Ich lese zum lernen im Kernighan/Ritchie und da steht auf Seite 41
> eigentlich:
>
> "Vergleiche haben geringeren Vorrang als arithmetische Operatoren. ..."
>
> Ich verstehe das sicher falsch, aber es liest sich so, als wenn
> eigentlich beide Varianten der if()... das gleiche Ergebnis bringen
> sollten.

== bindet staerker als &.
Gruesse,

Michael

[Stefan MM (Gast)]

Liegt an Reihenfolge in der die Operatoren ausgeführt werde.

Oberster Prio haben Klammern. Dann kommen Vergleichsoperatoren, dann 
Bit-Operatoren.

Wenn die Klammern drinn sind wird zuerst A&B ausgeführt, und dann 
geprüft ob das Ergebnis == 0x00.


Lässt du die Klammern weg:
1. B==0x00
2. A & Ergebnis.

Die Auswertung in diesem falls ist also nur wahr wenn: B=0x00 und das 
LSB von a 1 ist.

Schau dir mal eine Präzidenztablle von C an. Da steht die 
auswertreihenfolge drinn.

Beste Grüße,

Stefan

[Michael B. (mb_)]

Martin N. schrieb:
> Klammern beachten!
> Im ersten Beispiel: wenn A UND B den Wert 0 ergibt ...
> Im zweiten Beispiel: wenn A=1 ist UND B=0 ist ...

Halb richtig. Das zweite Beispiel wird implizit so geklammert:

if( A & (B == 0x00))
{
   mach_was();
}

Der if-Körper wird also ausgeführt, wenn B gleich 0 ist und das erste 
Bit (bit 0) in A gesetzt ist.

[C-Anfaenger (Gast)]

Aha ... vielen Dank für die tollen Erklärungen ! Ich denke das ich das 
Problem jetzt verstehe. Vielen, vielen Dank.

[Jan M. (mueschel)]

Noch zur Ergänzung:

> "Vergleiche haben geringeren Vorrang als arithmetische Operatoren. ..."

Dein Buch hat durchaus Recht, allerdings handelt es sich bei & nicht um 
einen arithmetischen Operator sondern um einen logischen.

+ und - haben Vorrang vor ==
und
== hat Vorrang vor & und |

[Yalu X. (yalu) (Moderator)]

Jan M. schrieb:
> Dein Buch hat durchaus Recht, allerdings handelt es sich bei & nicht um
> einen arithmetischen Operator sondern um einen logischen.

Doch, & und | sind arithmetische Operatoren, denn sie rechnen mit
Zahlenwerten. Die logischen Operatoren in C heißen && und ||.

Die nicht ganz nachvollziehbaren Präzedenzregeln für & und | haben
historische Gründe. Dennis Ritchie beschreibt hier die Zwickmühle, in
der er sich damals befand:

  http://www.lysator.liu.se/c/dmr-on-or.html

[Rolf Magnus (Gast)]

Yalu X. schrieb:
> Jan M. schrieb:
>> Dein Buch hat durchaus Recht, allerdings handelt es sich bei & nicht um
>> einen arithmetischen Operator sondern um einen logischen.
>
> Doch, & und | sind arithmetische Operatoren, denn sie rechnen mit
> Zahlenwerten.

C spricht hier nicht von arithmetischen, sondern von bitweisen 
Operatoren. Sie arbeiten ja auch nicht mit den Zahlenwerten, sondern nur 
mit den einzelnen Bits.
Ich würde & und | nicht als arithmetische Operatoren betrachten.

[Yalu X. (yalu) (Moderator)]

Rolf Magnus schrieb:
> Ich würde & und | nicht als arithmetische Operatoren betrachten.

Das ist Geschmackssache. Ich würde die bitweisen Operationen als eine
Teilmenge der arithmetischen betrachten.

Auf jeden Fall sind & und | für mich (und auch für den C-Standard) keine
logischen Operatoren, denn logische Operationen liefern immer "wahr"
order "falsch" (bzw. 1 oder 0), aber niemals eine Zahl wie 27583.

[ernst (Gast)]

...das es immer noch Leute gibt, welche sich freiwillig diesen 
unübersichtlichen und unvorhersehbare Resultate erzeugenden "C"-Unfug 
antun... Dieser Treppenwitz der EDV-Geschichte sollte doch langsam ins 
Kuriositätenkabinett verbracht werden und zukünftigen Generationen von 
"Compilerbauern" und "Sprachkonstrukteuren" als abschreckendes Beispiel 
dienen, wie man's nicht machen sollte!

(duck und wech ;-)

[Karl H. (kbuchegg)]

ernst schrieb:
> ...das es immer noch Leute gibt, welche sich freiwillig diesen
> unübersichtlichen und unvorhersehbare Resultate erzeugenden "C"-Unfug
> antun... Dieser Treppenwitz der EDV-Geschichte sollte doch langsam ins
> Kuriositätenkabinett verbracht werden und zukünftigen Generationen von
> "Compilerbauern" und "Sprachkonstrukteuren" als abschreckendes Beispiel
> dienen, wie man's nicht machen sollte!
>
> (duck und wech ;-)

Wird auch gut sein.
Nichts von alledem, was du da dahergebrabbelt hast, ist korrekt.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Klaus Wachtler schrieb:
> C-Anfaenger schrieb:
>> ... bei der if() Funktion
> es gibt keine if-Funktion.
Na gut, dann eben bei der if-Schleife... ;-)

[Klaus W. (mfgkw)]

sowas etwa?

#include <stdio.h>

#define if while

int main( int nargs, char **args )
{
  char *p = "Hallo\n";

  if( *p )
  {
    putchar( *p++ );
  }

  return 0;
}

[Rolf Magnus (Gast)]

Yalu X. schrieb:
> Rolf Magnus schrieb:
>> Ich würde & und | nicht als arithmetische Operatoren betrachten.
>
> Das ist Geschmackssache. Ich würde die bitweisen Operationen als eine
> Teilmenge der arithmetischen betrachten.

Viele Assembler-Dokumentationen sehen das anders. Da sind die 
entsprechenden Instruktionen i.d.R. unter den logischen Instruktionen 
einsortiert, oder sie sind - wie beim AVR - zusammen mit den Additionen 
u.s.w. unter einer gemeinsamen Kategorie "arithmetische und logische 
Instruktionen" zu finden.

> Auf jeden Fall sind & und | für mich (und auch für den C-Standard) keine
> logischen Operatoren,

Für C sind sie auch keine arithmetischen.

> denn logische Operationen liefern immer "wahr" order "falsch" (bzw. 1
> oder 0), aber niemals eine Zahl wie 27583.

Die arithmetischen Operationen dagegen interpretieren immer eine 
Kombination mehrerer Bits als eine zusammenhängende Zahl. & und | tun 
das nicht. Sie betrachten jedes Bit einzeln, unabhängig von den anderen. 
Daß man den "bithaufen", der hinten rauskommt, dann wieder als Zahl 
interpretieren kann, ändert daran nichts.

Klaus Wachtler schrieb:
> #define if while

Das ist ja getürkt. So sieht eine richtige if-Schleife aus:

#include <stdio.h>

int main( int nargs, char **args )
{
  char *p = "Hallo\n";

Loop:
  if( *p )
  {
    putchar( *p++ );
    goto Loop;
  } 

  return 0;
}

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

Rolf Magnus schrieb:

> Das ist ja getürkt. So sieht eine richtige if-Schleife aus:

Das war eine goto-Schleife. Eine if-Schleife geht so:

int f( char *p )
{
  fputchar( *p++ );
  if( *p ) f( p );
}

Wenn du nicht glaubst, dass sei eine Schleife, dass zieh es mal durch 
GCC.

[Klaus W. (mfgkw)]

ja, zumindest mit f( -1 ) geht das echt ab!

[Klaus W. (mfgkw)]

Außerdem ist die "Schleife" ja eigentlich nicht recht im if drin, nur im 
Block daran.

Wie wäre es damit:

   int f( int n )
   {
      if( !f( --n ) ) return n;
      else return 0;
   }

?

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

Klaus Wachtler schrieb:

> Wie wäre es damit:

Bös Ressourcen fressend. Meine Version ist effizienter. Kommt (via GCC 
-O) exakt der gleiche Code raus wie bei do..while.

[Rolf Magnus (Gast)]

A. K. schrieb:
> Das war eine goto-Schleife.

Eine if-Schleife mit goto. ;-)

> Wenn du nicht glaubst, dass sei eine Schleife, dass zieh es mal durch
> GCC.

Das ist keine Schleife, sondern Rekursion.

[Peter II (Gast)]

Rolf Magnus schrieb:
> Das ist keine Schleife, sondern Rekursion.

ich vermute mal das es genau das nicht ist, dann es gibt keine lokalen 
variablen der compiler macht daraus eine entlosschleife ohne calls

[Rolf Magnus (Gast)]

Es bleibt eine Rekursion, auch wenn es einen Compiler gibt, der das im 
Zuge seiner Optimierung durch eine Schleife ersetzt.

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

Peter II schrieb:

> ich vermute mal das es genau das nicht ist, dann es gibt keine lokalen
> variablen der compiler macht daraus eine entlosschleife ohne calls

In Prinzip korrekt, aber dank des if ist es keine Endlosschleife, 
sondern do..while. Der Compiler ersetzt die Endrekursion. In der anderen 
Variante ist es keine Endrekursion und daher ist auch der erzeugte Code 
rekursiv.

[Sam .. (sam1994)]

Lothar Miller schrieb:
> Klaus Wachtler schrieb:
>> C-Anfaenger schrieb:
>>> ... bei der if() Funktion
>> es gibt keine if-Funktion.
> Na gut, dann eben bei der if-Schleife... ;-)

http://www.if-schleife.de/

[Klaus W. (mfgkw)]

Danke, man lernt nie aus!
Jetzt weiß Lothar es auch... :-)