Bereich in if anweisung bestimmen

[Nina (Gast)]

hallo,
ich habe ein kleines Programm in C geschrieden.Das Programm soll nur 
der Bereich einer Variable überprüfen.Wenn der Bereich stimmt, wird eine 
andere Funktion aufgerufen.
Wenn Zahl auch die Werte 32 hat ist auch die transmitt Funktion 
aufgerufen.
Wo mache ich Fehler.
Danke

[Johannes M. (johnny-m)]

Nina wrote:
> Wo mache ich Fehler.
> Danke
Z. B. da:

if(0<= zahl<=15)

Wenn überhaupt, dann

if((0 <= zahl) && (zahl <= 15))

Es sind zwei Bedingungen zu erfüllen, und die kann man in C nicht in 
einer Abfrage überprüfen.

[Jörg W. (dl8dtl) (Moderator)]

Compilerwarnungen auch mit angucken:

foo.c:20: warning: comparison is always true due to limited range of data type
foo.c:20: warning: comparisons like X<=Y<=Z do not have their mathematical meaning

[Stefan E. (sternst)]

Die Bedingung (0<= zahl<=15) ist immer wahr.
Warum? Siehe hier:
Beitrag "Re: RC5-Auswertung Problem"

[Nina (Gast)]

hallo,
danke für die Anweisung, es funktionniert jetz.

[Nina (Gast)]

Hallo,
ich habe mich sehr schnell gefreut. Die transmitt Funktion wird nur 
aufgerufen für zahl=0; für andere Werte klappt nicht.

Nina

[Johannes M. (johnny-m)]

Das kann so überhaupt nicht funktionieren und dürfte zu einer ganzen 
Reihe Fehlermeldungen beim Compilieren führen! Zuweisungen an Variablen 
dürfen in C nur innerhalb von Funktionen stehen. In main() fehlt 
nebenbei noch eine Endlosschleife (was allerdings kein Fehler i.e.S. 
ist, aber den Compiler zumindest zu einer Warnung veranlassen dürfte, da 
eine Funktion vom Typ int einen Rückgabewert braucht, ein return 
hier aber fehlt...). Weitere Fehlermeldungen dürften dadurch 
hervorgerufen werden, dass die aufgerufenen Funktionen zum Zeitpunkt 
ihres Aufrufs nicht bekannt sind. Also bitte compilierbaren Code posten!

[Johannes M. (johnny-m)]

> if(((0>=(zahl))&& ((zahl)<= 14)))
Und nochmal: Zahl ist unsigned und kann nie kleiner als Null werden! 
Dementsprechend ist die Abfrage "0 >= zahl" völlig sinnfrei! Das müsste 
auch eine Compilerwarnung geben (wie oben schon mal erwähnt), die aber 
angesichts der anderen schon kaum noch eine nennenswerte Rolle spielt!

[Karl H. (kbuchegg)]

Nina wrote:
> Hallo,
> ich habe mich sehr schnell gefreut. Die transmitt Funktion wird nur
> aufgerufen für zahl=0; für andere Werte klappt nicht.
>

Du musst anfangen dir selbst zu helfen.
Setze doch einfach mal für zahl ein paar Werte ein.
ZB. 1

Deine Abfrage lautet (mal um etliche Klammern befreit)

  if( ( 0 >= zahl ) && ( zahl <= 14 )

Jetzt mal für zahl gleich 1 eingesetzt.

  if( ( 0 >= 1 ) && ( 1 <= 14 )

Der erste Ausdruck lautet    0 >= 1
Ist das wahr oder falsch? Ist 0 tatsächlich größer oder gleich 1?

Offensichtlich nicht. Und da damit der erste Ausdruck bereits
falsch ist, brauchst du den 2.ten erst gar nicht berücksichtigen.
Wenn bei einem UND ein Teilausdruck falsch ist, dann ist der
ganze Ausdruck falsch.

Abgesehen davon. Wie bereits gesagt: zahl ist ein unsigned Wert.
Der kann per Definition nicht kleiner als 0 sein.

[Nina (Gast)]

hallo Johannes,
mein compiler zeigt keinen Fehler, deswegen möchte ich die aufgabe 
weiter machen.

[Johannes M. (johnny-m)]

Nina wrote:
> mein compiler zeigt keinen Fehler, [...]
Das kann mit dem Code nicht sein! Der wimmelt nur so von 
Syntaxfehlern!

uint8_t zahl1=4;
uint8_t zahl2=6;
uint8_t zahl3=8;

So weit i.O. ...

zahl=4;

Hier wird einer Variable, die gar nicht existiert, außerhalb einer 
Funktion ein Wert zugewiesen --> Schon mal mindestens 2 Fehler!

uint8_t buffer;
int l=0;
int k=0;
int counter=0;

Das ist zumindest syntaktisch OK...

int main(void)
{
    chek();
    fehler(); 
}

Sowohl chek() als auch fehler() sind dem Compiler zu diesem Zeitpunkt 
unbekannt --> Wahrscheinlich Warnmeldungen à la "implicit declaration 
of..."

void chek(void)
{

    if(((zahl1)<= 14))
    {
        counter++;
    }
    else 
        return;

    if(((zahl2)<= 10)
    {
        counter++;  
    }
    else 
        return;
    if(((zahl3)<= 8))
    {
        counter++;
    }
    else 
        return;

Naja, zumindest keine Syntaxfehler...

    if (counter==3)
    {
        transmitt();
    }    
}

Und wieder: transmitt() kennt der Compiler gar nicht, weil erst weiter 
unten definiert!

void transmitt(void)
{
    buffer=2*zahl;
}

void fehler(void)
{
    printf("Wert ausser dem Bereich:%s");
}

printf ist dem Compiler auch nicht bekannt, weil die entsprechende 
Bibliothek gar nicht eingebunden ist!

Der Code war im Original übrigens grauenvoll formatiert. Exzessive 
Verwendung von Leerzeilen und relativ unmotiviertes Einrücken tragen 
sicher nicht positiv zur Lesbarkeit bei...

Und wie schon im anderen Thread gesagt: C-Buch kaufen und lesen. Ohne 
Grundlagen geht gar nichts und das Forum ist dafür nicht da!

(Amnmerkung: Der Code stammt aus dem zweiten Thread von Nina, der 
mittlerweile wegen Doppelposting geschlossen wurde...)

[DEtlfe (Gast)]

Ich habe da nur einen Rat an euch beide:

"Gebt es auf! Es macht keinen Sinn!"

DEtlef

[Nina (Gast)]

Hallo Johannes,
bitte sei nicht aufgeregt, ich brauche nur Hilfe.Wir können noch einmal 
versuchen.
Hier ist eine saubere Code

[Johannes M. (johnny-m)]

Nina wrote:
> Hier ist eine saubere Code
...und immer noch mit den selben Fehlern! Und "sauber" ist auch was 
Anderes...

[Karl H. (kbuchegg)]

Johannes M. wrote:
> Nina wrote:
>> Hier ist eine saubere Code
> ...und immer noch mit den selben Fehlern! Und "sauber" ist auch was
> Anderes...

@Nina

Allerdings. Sauber ist wirklich was anderes.

Jetzt gehst du erst mal her und schmeisst alle überflüssigen
Klammern raus. Du hast jede Menge Klammern die den Blick
aufs wesentliche verschleieren und nichts, aber auch gar nichts
zur Klarheit beitragen.

Aus

 if(((zahl1)<= 14))

  {
  counter++;
  }
  else 
    return;

wird so

  if( zahl1 <= 14 )
    counter++;
  else 
    return;

Sieht doch gleich viel besser aus. Alternativ kann man auch die
{ } Klammern drinnen lassen

  if( zahl1 <= 14 )
  {
    counter++;
  }
  else 
  {
    return;
  }

oder so

  if( zahl1 <= 14 ) {
    counter++;
  }
  else {
    return;
  }

ist in dem Fall (bei nur einer abhängigen Anweisung) Geschmackssache.
Ich persönlich mag es nicht, weil es den Code zu m.M. zu sehr in die
Länge zieht.

Danach gehst du her und stellst erst mal deine Einrückungen richtig.
Nach jeder { wird zb. 2 Leerzeichen eingerückt und nach jeder }
wird die nachfolgende Zeile wieder 2 Leerzeichen ausgerückt.
(Statt 2 kann man auch 4 nehmen. Mehr ist meist unpraktisch, weil
man zu schnell an den rechten Rand kommt)

So was

 int main(void)
{
  chek();
fehler();
  
}

geht zum Beispiel gar nicht. Das int bei /int main()/ muss am linken
Rand stehen. Der Aufruf der Funktion chek ist zwar sauber eingerückt
aber schon in der nächsten Zeile stimmt die Einrückung schon wieder
nicht. Und die Leerzeile vor der schließenden } trägt nichts, aber auch
gar nichts zur Lesbarkeit bei.
Generell: Wenn dir etwas wichtig genug ist, dass du Leerzeilen davor
oder dahinter einfügen willst, dann kannst du als bessere Alternative
auch gleich überflüssigen Leerzeilen durch einen Kommentar ersetzen,
der die Situation erklärt. Ansonsten sind auch mehrere Leerzeilen
hintereinander genausowichtig wie mehrere Rufzeichen beim Posten in
einem Forum: völlig unsinnig.

Sieh dir mal den Abschnitt an

  if(((zahl1)<= 14))

  {
  counter++;
  }
  else 
    return;

  if(((zahl2)<= 10))

  {
  counter++;  
  }
  else 
    return;
  if(((zahl3)<= 8))

Warum ist da nach dem ersten if eine Leerzeile? Will uns die irgendetwas
sagen? gehört das nachfolgende { counter++; ... etwas nicht mehr
zu diesem if?
Warum ist allerdings vor dem if(((zahl3)<= 8)) keine Leerzeile?
Da wäre sie doch sinnvoll! Denn schliesslich gehört dieser Teil
nicht mehr zum vorhergehenden if.

Baue deinen Code so auf, dass er leicht lesbar ist. Dann hast
du und jeder andere der ihn lesen muß sehr viel mehr davon.

Und nein. Eine ordentliche Codeformatierung ist nicht Selbstzweck
sondern ist eine deiner Waffen um Fehler im Code zu finden.

PS: chek schreibt sich übrigens mit ck - check.
Auch solche offensichtliche Tippfehler tragen beileibe nicht
zum einfachen Codeverständnis bei.

[Johannes M. (johnny-m)]

Karl heinz Buchegger wrote:
> PS: chek schreibt sich übrigens mit ck - check.
> Auch solche offensichtliche Tippfehler tragen beileibe nicht
> zum einfachen Codeverständnis bei.
...und transmit mir nur einem t am Ende. Aber das ist eher 
Fliegendreck im Vergleich mit dem Rest. Ich finde es eher sehr 
verdächtig, dass Nina behauptet, ihr Compiler würde das da ohne 
irgendwelche Fehler- und Warnmeldungen übersetzen. Das hat fast 
Troll-Format.

[Karl H. (kbuchegg)]

Johannes M. wrote:
> Karl heinz Buchegger wrote:
>> PS: chek schreibt sich übrigens mit ck - check.
>> Auch solche offensichtliche Tippfehler tragen beileibe nicht
>> zum einfachen Codeverständnis bei.
> ...und transmit mir nur einem t am Ende. Aber das ist eher
> Fliegendreck im Vergleich mit dem Rest.

Allerdings.
Ich finde es nur immer wieder bezeichnend, dass die Leute mit
dem grauslichsten Code immer die meisten (läppischen) Fehler
drin haben. Hundertausend Leerzeilen zwischen 2 Anweisungen
aber dort wo Leerzeichen den Lesefluß unterstützen könnten sind
keine.

> Ich finde es eher sehr
> verdächtig, dass Nina behauptet, ihr Compiler würde das da ohne
> irgendwelche Fehler- und Warnmeldungen übersetzen. Das hat fast
> Troll-Format.

Full ACK. Das bringt sie so nie und nimmer durch den Compiler.

@Nina:
Ich würde es so schreiben

#include <stdio.h>
#include <stdint.h>

uint8_t zahl1 = 4;
uint8_t zahl2 = 6;
uint8_t zahl3 = 8;
uint8_t zahl  = 4;
uint8_t buffer;

void fehler( void )
{
  printf( "Wert ausser dem Bereich:" );
}

void transmit( void )
{
  buffer = 2 * zahl;
}

void check( void )
{
  if( zahl1 <= 14 &&
      zahl2 <= 10 &&
      zahl3 <=  8 )
    transmit();
}

int main( void )
{
  check();
  fehler();
}

PS: Ich weiß, daß es hier noch viel zu tun gäbe aber ich will ihr
auch nicht zuviel auf einmal ändern. Sie muß die Änderung ja auch
noch überschauen und mit ihrem eigenen Code vergleichen können.

[DEtlef (Gast)]

Danke! Ich wette darauf hat Nina jetzt etwa 24h gewartet. Endlich hat 
ihr jemand das Programm geschrieben. Obwohl ich glaube jetzt kommen wir 
erst zum eigentlichen Problem. Das war doch nur vorgeplänkel.

DEtlef

[Karl H. (kbuchegg)]

DEtlef wrote:

> erst zum eigentlichen Problem. Das war doch nur vorgeplänkel.

:-)
Allerdings.
Sieh dir das Program an. Damit kann man im Grunde nichts anfangen.
Aber ist mal ein Anfang um die Syntax zu zeigen.

[Nina (Gast)]

hallo,
ich danke euch für die Hinweisen und werde auch auf die Schreibfehler 
achten.
Danke

[Unbekannter (Gast)]

> Sieh dir das Program an. Damit kann man im Grunde nichts anfangen.

Och, das würde ich nicht sagen... Ein Compiler mit eingeschalteter 
Optimierung hat hier ein richtiges Erfolgserlebnis... Schade das 
Compiler keine Jubel-Gefühle zeigen...