- LiFePO4 Speicher Test         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 17

Thema: C Klammerung

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076

    C Klammerung

    Anzeige

    Powerstation Test
    Hallo zusammen, noch eine kurze Frage zum Wochenende

    Ich bin mal wieder auf die Nase gefallen und habe lange nach einem Fehler gesucht.
    Ich verstehe nicht wo der Unterschied zwischen diesen beiden Abfragen liegt, dass es mal geht und mal nicht.


    Code:
    int main(void)
    { int a,b,result;
    
      a = 0x01;
      b = 0x80;
      
      if (a & b == 0)   /* Bitweises UND, es müste 0 rauskommen */
      {
         result = TRUE;  
      } else
      {
        result = FALSE;    /* Ergebis ist aber FALSE */
      }
    
    
      a = -3;
      b = +3;
      if (a + b == 0)
      {
         result = TRUE;   /* Ergebnis ist TRUE, hier stimmt es */
      } else
      {
        result = FALSE;  
      }
    
    }
    Ich weis, (falsch: man hat mir gesagt) ich muss hier nochmal Klammern.
    if ((a & b) == 0)

    als alter Pascal Freak, ist das für mich natürlich überhaupt nicht einleuchtend, weil da brauche ich garkeine Klammern bei diesem simplen Gebilde

    Aber ich möchte einfach nur verstehen warum ich hier nochmals Klammern setzen muss.
    Eine if Abfrage muss generell in Klammern, okay ist halt so festgelegt, aber wozu die anderen Klammern.
    Bei der Addition funktioniert es ja auch ohne, bei dem Bitweisen UND nicht mehr.

    Dank Euch für Infos.
    Siro

  2. #2
    Neuer Benutzer Öfters hier
    Registriert seit
    28.09.2013
    Ort
    D
    Beiträge
    7
    Das hängt alles von der Abarbeitungsrichtung und der Rangordnung der Operatoren ab. Guck mal hier: http://manderc.manderby.com/operator...ator/index.php

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Danke Dir erstmal für den Link:

    Verstanden hab ich es nicht wirklich.
    Die Abarbeitungsrichtung ist demnach von links nach rechts bei einem Bitweisen AND
    == hat den Rang 10
    & hat den Rang 4

    aber was sagt mir das jetzt ?

    wie dem auch sei:
    Laut Assembler Code hat mein Compiler result = FALSE daraus gemacht.
    Er hat die AND Funktion also garnicht erst ausgeführt.
    wie kommt er darauf, er weis dorch garnicht was rauskommt.

    es sei denn, er hat es wie folgt aufgelöst ?
    if (a & (b==0))

    wenn also b==0 ist, muss a zwangsläufig nach dem AND auch 0 sein und damit ist das Ergebnis des Vergleichs immer 0
    und deshalb erzeugt er nur den Code für result = FALSE

    Liege ich da ungefähr richtg ?

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    11.08.2008
    Ort
    Hallein
    Alter
    32
    Beiträge
    802
    Siehe Operator Precedence. == hat eine höhere Wertung als & und wird somit als erster evaluiert. Generell, weiß man es nicht, oder will sich nicht darauf verlassen, immer Klammern setzen. Schadet nie und schützt vor überraschenden Änderungen in der Zukunft, oder komischen Compilern.
    Kultuverein Metal Resurrection, für mehr Bands und Konzerte in Österreich (:

  5. #5
    Erfahrener Benutzer Roboter Genie Avatar von malthy
    Registriert seit
    19.04.2004
    Ort
    Oldenburg
    Beiträge
    1.379
    und "+" bindet seinerseits stärker als "==", deswegen das Ergebnis deiner zweiten Abfrage. Hätte ich jetzt auch nicht gewusst, insofern war's lehrreich .

  6. #6
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    61
    Beiträge
    5.799
    Blog-Einträge
    8
    Hallo

    Obwohl man die Bindung oder Rangfolge der Operatoren bei Unsicherheit ja schnell mal nachschlagen kann setze ich trotzdem immer ein paar Klammern mehr, weil es die Lesbarkeit des Codes erhöht. Der Kompiler ignoriert überflüssige Klammern sowieso...

    Gruß

    mic
    Bild hier  
    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Okay, Danke Euch, dann hab ich es jetzt doch verstanden. Hätte nie gedacht, daß eine Zuweisung VOR einer Operation stehen könnte.
    Ich dachte immer, erstmal rechnen und dann zuweisen. Naja man lernt halt nie aus. Ich denke auch, es ist "einfacher" ein paar Klammern mehr zu setzen,
    nicht das erste Mal, daß ich mir dadurch das Leben schwer mache. Dann habt noch ein Bugfreies Wochenende

  8. #8
    Erfahrener Benutzer Roboter Genie Avatar von malthy
    Registriert seit
    19.04.2004
    Ort
    Oldenburg
    Beiträge
    1.379
    Zitat Zitat von Siro Beitrag anzeigen
    Hätte nie gedacht, daß eine Zuweisung VOR einer Operation stehen könnte.
    Hm, versteh dich jetzt nicht so ganz. Eigentlich werden ja nur die Wahrheitswerte von (a & b == 0) und (a + b == 0) berechnet. Und weil die Operatoren & und + eben einmal stärker und einmal schwächer als == binden, fällt das Ergebnis eben so aus, wie es es ausfällt.

  9. #9
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    sorry, das war ja jetzt auch falsch ausgedrückt. Das ist natürlich keine Zuweisung, sondern eine Abfrage.
    das mit dem Binden ist schon merkwürdig (verwirrend) für mich, weil das gab es in der Form nicht bei Pascal/Delphi.
    Geändert von Siro (19.10.2013 um 00:28 Uhr)

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Siro Beitrag anzeigen
    sorry, das war ja jetzt auch falsch ausgedrückt. Das ist natürlich keine Zuweisung, sondern eine Abfrage.
    Eigentlich nicht. == ist ein genau so ein Operator wie &. So etwas wie einen Abfrageoperator gibt es in C nicht. == ist der Vergleichsoperator und liefert TRUE, wenn die Werte auf beiden Seiten gleich sind.
    das mit dem Binden ist schon merkwürdig (verwirrend) für mich, weil das gab es in der Form nicht bei Pascal/Delphi.
    Aber natürlich gibt es das, wie überall, wo mehrere Operationen in einem Ausdruck zulässig sind. Ein einfacher, bekannter Fall ist: Punktrechnung geht vor Strichrechnung (d.h. ein * bindet stärker als ein +. Es gibt aber noch weitere Regeln für Brüche. Da es aber in C (und eigentlich allen Programmiersprachen) viel mehr Operatoren als nur die rein mathematischen gibt, sind die Bindungsregeln auch komplexer. Daher ist
    Obwohl man die Bindung oder Rangfolge der Operatoren bei Unsicherheit ja schnell mal nachschlagen kann setze ich trotzdem immer ein paar Klammern mehr, weil es die Lesbarkeit des Codes erhöht. Der Kompiler ignoriert überflüssige Klammern sowieso...
    eine gute Strategie.

    Ich denke, das Problem liegt an einer anderen Stelle. Ein if in C funktioniert etwas anders, als in manchen anderen Sprachen. Ist der Wert der Klammer hinter einem if TRUE, wird der nächste Befehl ausgeführt. Ob sich der Wert in der Klammer durch einen Vergleichsoperator, durch einen anderen Operator oder durch eine beliebig komplexe Aufreihung von Operatoren ergibt (oder ob da einfach der Wert 1 steht) ist egal. Deswegen ist ein gängiger Fehler in C, daß man statt if ( a == 3) die Zuweisung if ( a = 3) schreibt. Das zweite ist in C sytaktisch korrekt, aber meist nicht das, was man will.

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test