Code funktioniert nur manchmal

würde if (taste == ('A' || 'B' || 'C' || 'D' || '*' || '#' || '0' || '1' || '2' || '3' || '4' || '5' || '6' || '7' || '8' || '9')) machen was ich denke?

Natürlich nicht. Wenn ich das richtig sehe, meinst du

if (taste != 0) // wenn irgendeine Taste gedrückt wurde

someuser: if (taste == ('A' || 'B' || 'C' || 'D' || '*' || '#' || '0' || '1' || '2' || '3' || '4' || '5' || '6' || '7' || '8' || '9'))

Das widerspricht den Bedingungsregeln. Andere Tasten hast Du doch überhaupt nicht. Damit ist diese Abfrage sinnlos. Da sollte if (taste) ausreichen, weil das Keypad 0 (==false) liefert, wenn keine Taste gedrückt wurde.

Gruß Tommy

if (taste)

Macht genau was da steht. 0 ist false und alles ungleich 0 ist true. Das geht in dem Fall weil dir egal ist welche Taste gedrückt würde.

Aber bei sowas mit negativen Zahlen aufpassen, welche auch true sind. Es gibt auch mal Libraries die für "nichts" -1 zurück geben. Bei KeyPad ist es aber 0.

Das ist aber wie gesagt nicht dein Hauptproblem :)

Natürlich nicht. Wenn ich das richtig sehe, meinst du if (taste != 0) // wenn irgendeine Taste gedrückt wurde

ich wollte wenn irgendeine taste gedrückt ist, völlig egal welche, das die bedingung erfüllt ist.

ich will vergleichen steht in der variablen "taste" entweder A oder B oder C usw.

Es gibt auch mal Libraries die für "nichts" -1 zurück geben.

wegen solcher eventualitäten mit denen ich mich nicht auskenne wollte ich nicht nur eben genau die Werte nehmen die auch physikalisch exisiteren.

Das ist aber wie gesagt nicht dein Hauptproblem :)

mein hauptproblem ist eigentlich alles - da fang ich lieber mal ganz unten an zu verstehn^^

Gib Dir doch einfach mal im Loop auf den seriellen Monitor aus, was in taste steht. Dann siehst Du doch ganz einfach, was Deine Lib zurück gibt, wenn keine Taste gedrückt wurde.

Gruß Tommy

Gib Dir doch einfach mal im Loop auf den seriellen Monitor aus, was in taste steht. Dann siehst Du doch ganz einfach, was Deine Lib zurück gibt, wenn keine Taste gedrückt wurde.

hab ich hier und da schon mal gemacht, funzt ganz gut. mir ging es eher darum zustände zu vermeiden die ich nicht absehen kann.

im moment funktioniert das Programm - hab einfach den goto sprung eine zeile höher vor die if bedingung gemacht - eigentlich zu einfach. mal sehn wies läuft.

Gewöhne Dir Goto gleich wieder ab. Es gibt << 1% an Problemlösungen, in denen ein Goto sinnvoll sein könnte. In allen anderen Anwendung ist es einfach Murks.

Gruß Tommy

OT: Tommy: Real Programmers aren't afraid to use GOTO's.

bestimmt bekannt, aber das muss jetzt einfach sein ;-)

noiasca: OT: Tommy: Real Programmers aren't afraid to use GOTO's.

bestimmt bekannt, aber das muss jetzt einfach sein ;-)

Kenne ich ;) Aber der Weg vom Neuling zu "Real Programmers" ist sehr weit.

Gruß Tommy

Ich mag die extreme Ablehnung von Gotos auch nicht. Denn bei den wenigen Anwendungen, wo es lohnend ist, macht es keinen Sinn, sich den Blick von Dogmen versperren zu lassen.

Gerade endliche Automaten, wie Parser usw. sind potentiell gute Kandidaten für eine Goto Anwendung.

:o :o :o :o :o

Aber wie immer:

Wer einmal kapiert hat, wie ein Hammer funktioniert, für den sieht jedes Problem, wie ein Nagel aus. Und das wollen wir doch nicht!

Ich habe ja gesagt dass ein paar spezielle Anwendung gibt wo es seine Berechtigung hat. Aber hier wird es klar als unnötige Krücke verwendet.

Ja,
Hier wird das Goto, etwas suboptimal, als Schleifenersatz, genutzt.

Wobei:
Das ist eigentlich genau die Stelle, ziemlich auf den Punkt getroffen, wo man Nebenläufigkeit brauchen können würde. Zumindest würde ich so denken.
Und damit ist (computed) Goto dann wieder voll im Rennen.

Viele Möglichkeiten hat man an der Stelle nicht, wenn man einen Automaten bauen will/muss.

  1. irgendwas mit Enum Switch usw.
  2. Functionpointer
  3. Ein geschachteltes if else Gewirre
  4. oder eben Goto

Man nimmt eben das, was schöner und praktischer ist.
!Ein Hoch auf Übersichtlichkeit und Wartungsfreundlichkeit!
Es ist auch eine Geschmacksfrage.

Aber wie immer:

Wer einmal kapiert hat, wie ein Hammer funktioniert, für den sieht jedes Problem, wie ein Nagel aus.

Mal ganz ehrlich, ist hier nicht jedes Problem ideal für einen endlichen Automaten (Nachtwächter) ?

Eine Variante des goto ist übrigens dasreturn;mitten im Code, mit dem man einfach an den Anfang von loop zurückspringt. Das wird eher toleriert und nur von echten Puristen wie ein goto ausgebellt.

Mal ganz ehrlich, ist hier nicht jedes Problem ideal für einen endlichen Automaten (Nachtwächter) ?

Meiner Ansicht nach, sind die meisten, wenn nicht sogar alle, funktionierenden Arduino Programme endliche Automaten. Und dabei ist es völlig egal, ob der Ersteller das wollte, oder nicht.

Hallo,

95% sind Zustandsautomaten würde ich behaupten.

Nur goto halte ich hier für völlig fehl am Platz. Schon weil sich die Lesbarkeit in Größenordnungen verschlechtert. Ein sauberes switch-case mit klaren enum Namen und gut ist. Dann ist der Code auch Jahre später einfach wartbar.

Schon weil sich die Lesbarkeit in Größenordnungen verschlechtert.

Goto verschlechtert die Lesbarkeit? Wie macht es das?

Das sehe ich nicht so.

Mit jedem Sprachmittel kann man Mist bauen, ohne Zweifel! Aber das ist doch dann nicht die Schuld des Sprachmittels...

Und wenn ich mal so ehrlich sein darf: Hier im Forum habe ich schon viel mehr hässliche Switch/Case Konstrukte gesehen, als Goto Einsätze.

Ganz nebenbei: Bei größeren Konstrukten bietet das Goto gar einen Vorteil in Sachen Codegröße und Performance. Bei kleinen Konstrukten wird Switch/Case weitestgehend optimiert. Aber ab einer bestimmten Größe ist Schluss damit.

Das soll alles keine Werbung für den sinnfreien Goto Einsatz sein! Sondern nur mein Beitrag gegen Dogmatismus.

Hallo,

wenn man switch case richtig macht, indem sich die enum Zustandsvariable nur innerhhalb switch-case verändert, dann ist das in Sachen Übersichtlichkeit nicht zu überbieten. Man kann ordentlich lesbare Zustandsnamen verwenden und ordentliche Funktionsnamen die dann aufgerufen werden. Das hilft die Funktionsweise wesentlich schneller zu überblicken.

Mit goto muss man erst das Label im gesamten Code suchen um zu wissen wo es weitergeht und was dort weiter geht. Ich hätte gern ein konkretes Bsp. gewusst wo goto sinnvoll ist. Ich kann es mir derzeit nicht vorstellen.

Performance, da lese ich leider gegenteiliges, Abschnitt unten. http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/008_c_kontrollstrukturen_012.htm

Doc_Arduino:
Ich hätte gern ein konkretes Bsp. gewusst wo goto sinnvoll ist. Ich kann es mir derzeit nicht vorstellen.

Fehlerbehandlung und Resourcenfreigabe am Ende einer Funktion:
https://blog.regehr.org/archives/894

Wird z.B. im Linux Kernel sehr oft verwendet

Doc_Arduino: Performance, da lese ich leider gegenteiliges, Abschnitt unten. http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/008_c_kontrollstrukturen_012.htm

Es tut mir leid, das sagen zu müssen:

Erstens: Das ist ein C Buch, keine C++ OK, das hat wenig Auswirkungen an der Stelle... aber computed Goto kann altes C nicht.

Zweitens: Das mit der Performance ist in dem Buch gelogen. Oder, zumindest nicht belegt. Du darfst diese Unwahrheit glauben. Aber weitererzählen, tue es bitte nicht. Denn sonst bezichtige ich dich der bewussten Lüge. Des bewussten weitererzählens dieser Unwahrheit .

Ok ok, vielleicht ist es ja keine bewusste Lüge von dem Autor, sondern nur ein Irrtum. Aber eigentlich gehören auch Irrtümer aus Dogmatismus auf den Haufen der Geschichte. Irrtümer und Lügen unterscheiden sich nur durch die dahinter stehende Absicht. Die Folgen sind nahezu identisch.

Drittens: Das sich der Autor vom Dogmatismus gefangen fühlt hört man schon an dem Satz:

Ich habe mir lange überlegt, ob ich Goto überhaupt in diesem Buch erwähnen soll, ....

Ein Fachbuchautor, welcher wegen solcher Gedanken mit sich hadert, ist an der falschen Stelle unterwegs. Unterdrückung und Zensur von Sprachmitteln in Sprachfachbüchern, ist so ziemlich das schlimmste, was man lernenden antun kann. Meiner Meinung nach.


Mache dir doch bitte bewusst, dass dieser anti Goto Dogmatismus aus einer Zeit stammt, als Subroutinen und Funktionen noch ein Fremdwort waren. Oder gerade eingeführt wurden. Der anti Goto Dogmatismus stammt nicht aus C, oder gar aus C++, sondern ist ein Basic stämmiger anti Goto Dogmatismus. Goto war eine unabwendbare, absolute Notwendigkeit, alter Basic Dialekte. Das hat mit uns hier doch gar nichts zu tun

Vergleichbares Argument: Schokolade ist für Menschen giftig, weil ein Hund an einer Tafel Zartbitter stirbt, sterben kann. Das mit dem Hund ist richtig. Aber die Übertragung auf den Menschen ist falsch. Denn, anderer Stoffwechsel. Ein Informaltionsübertragungsfehler im Kopf.

Liebster Doc_Arduino, wärest du nicht selber diesem Dogma unreflektiert erlegen, dann würdest du das Performance Argument selber prüfen. Dass du nicht mal auf die Idee kommst, belegt deine Gläubigkeit.


Weiterhin: Ja, mit Goto kann man Mist bauen. Aber ein verantwortungsvoller Umgang damit ist möglich. Das gilt für jedes Sprachmittel.

Hallo,

das gezeigte Bsp. von Serenifly macht Sinn, sehe ich ein, in dem Fall kürzerer und besser lesbarer Code mit goto.

Ich verweigere mich nicht grundsätzlich Neuen, ich habe nur immer erstmal eine klare Meinung zu einem Thema. Kennt ihr ja. :slight_smile: Wenn dann irgend jemand um die Ecke kommt und was anderes behauptet und ich verstehe es nicht oder kann es erstmal nicht nachvollziehen, dann frage ich nach und bohre nach. Genau das kann manchmal unbequem sein. Manchmal filtert das Unwissende von Wissenden heraus. :slight_smile: Auch ich bin in der Lage meine Meinung zu ändern, man glaubt es kaum, nur ändere ich diese nicht auf Grund von dahin gewurfenen weiteren Behauptungen. Ansonsten fördert es oder sollte es das tiefere Verständnis fördern um das um was es geht. Gleichzeitig werden die Erklärungen immer besser und verständlicher.

ruhiges WE euch allen …