Forum: PC-Programmierung Beispiel: Schleife ohne Wiederholungsprüfung mit Abbruchbedingung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Der Lernende (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hallo,

hat jemand auf die Schnelle ein beispiel für eine Schleife ohne 
Wiederholungsprüfung mit Abbruchbedingung? Danke im Voraus

von Der Lernende (Gast)


Bewertung
0 lesenswert
nicht lesenswert
while (1){
Funktion1();
if (blabla) break;
Funktion2()
}
wäre doch soetwas

von Alexander K. (pucki)


Bewertung
-1 lesenswert
nicht lesenswert
Der Lernende schrieb:
> hat jemand auf die Schnelle ein beispiel für eine Schleife ohne
> Wiederholungsprüfung mit Abbruchbedingung? Danke im Voraus

Das ist logisch unmöglich.

Eine Schleife ist wie der Name schon sagt eine Schleife die sich endlos 
wiederholt.  Um da raus zu kommen, muss man eine Abbruchbedingung haben.

Das andere nennt man Programm.  ;)

Die einzige unsaubere Ausnahme ist eine Schleife mit fehlerhaften 
Start.
Die wird nämlich GAR NICHT ausgeführt.

x = 10

For i = x to 9
 x = x + 1
Next i

Da ist am ende x immer noch 10. wenn du kein Parameter STEP - 1 setzt.

Gruß

  Pucki

: Bearbeitet durch User
von Der Lernende (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Lieber Pucki,

was sagst dazu (siehe Anhang)?

von Alexander K. (pucki)


Bewertung
0 lesenswert
nicht lesenswert
Du sollest das Diagramm darunter lesen.

TRUE
BREAK

Das ist eine Bedingungsprüfung.

Wenn er gefragt hätte ob er eine Schleife verlassen kann, sogar 
mittendrin einfach so, dann hätte ich geantwortet.  Meistens mit EXIT 
[Art der Schleife].  Exit do / Exit for  etc. je nach Syntax.

Was aber absolut kein Sinn macht. Wieso soll ich eine Schleife 
verlassen, ohne eine Bedingung dazu abzufragen. ;) Jede plöde do-while 
Schleife geht so. Da ändere ich halt am Ende die Gültigkeit.

Man sollte lernen Korrekte Fragen zu stellen, ohne Emotion und Gefühl, 
nur eiskalte Logik.

Dann ist das Leben als Programmierer viel einfacher.

Gruß

   Pucki

von Der Lernende (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
mhh erklär mir mal bitte, woran du dich so reibst...

von sid (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ich versteh auch grad nicht wieso da geschimpft wird.

ich nutze häufig Abbruchbedingungen innerhalb von lange-laufendenn 
Schleifen die eben nicht Teil der Schleifenbedingung ist
zB um via ISR ausgelösten Stopp-befehl in die Schleife zu bringen

in eta so:
while (x < 1000 && d > 100)
{
   if(global_stopp==true) break;
   x++;
   d--;
}

Nun bin ich kein Freund der unbedingten Schleifenkonstruktion,
gestehe aber ein, dass besonders in Arduino-IDE man so am einfachstem
seinem Ziel näher kommt die loop an der weiteren Ausführung zu hindern
loop()
{
  ....
  if(somecondition==true)
  {
    while(true){}; // force loop into endless sub-loop to stop execution
  }
  ....
}

nun könnte ich mir in der Tat vorstellen,
dass es eventuell eine Situation gibt in der jemand sich daraus dann 
dann doch wieder ohne reset befreien will.
(es wär mMn zwar unsauberer Code.. und es wird eine elegantere Lösung 
geben die zu bevorzugen wäre... aaaber nichts desto trotz)
kann auch diese Schleife ebenfalls gebrochen werden mit einem 
if(x)break;

wie gesagt while(!x){} find ich schöner als while(true){if(x) break;}
denke aber dass das beides sogar ähnlichen assembler erzeugt.

Also bedingungslose Schleifen halte ich zwar generell eher für 
vermeidenswert
 while(true)
{}

for(;;)
{}

do
{} while(true)
aaber eine abbruchbedingung kann jederzeit innerhalb gesetzt werden
if(x) break; wenn Du aus der schleife raus willst, return wenn Du aus 
der umgebenden funktion raus willst oder oder oder..

Also ja exakt so wie Du es im zweiten Beitrag schriebst zB

'sid

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> aaber eine abbruchbedingung kann jederzeit innerhalb gesetzt werden
> if(x) break

Es gibt Firmen in denen das wegen der Verständlichkeit von Software 
verboten ist. Es ist schlechter Programmierstil in einer Schleife 2 
verschiedene Ausgänge zu haben. Das fängt schon beim Debuggen an.

Exit ist kaum besser als Goto (das ginge ja auch).

Georg

von sid (Gast)


Bewertung
0 lesenswert
nicht lesenswert
georg schrieb:
> Es gibt Firmen in denen das wegen der Verständlichkeit von Software
> verboten ist.

Liegt hauptsächlich daran dass in vielen Firmen in Teams programmiert 
wird,
und Progammierer B ist zu faul um die schleife zu lesen die 
Programmierer A geschrieben hat

schlechter stil.. ich würde widersprchen wollen:

sid schrieb:
> wie gesagt while(!x){} find ich schöner als while(true){if(x) break;}
> denke aber dass das beides sogar ähnlichen assembler erzeugt.

also ja, im Grunde gehört jede Abbruchbedingung in die 
Schleifenkondition.

Aaaber Du wirst sicherlich die Situation kennen in denen
die Schleifenkondition so ausartend lang ist,
dass schon dies unleserlich werden.
(verschachtelte AND und OR usw.. hab da schon zehn Zeiler gesehen die 
mir Kopfschmerzen vom gucken machten)
und ab dem Punkt finde ich (-persönlicher Geschmack-)
dass eine selten auftretende Bedingung auch innerhalb der Schleife 
liegen darf und eben dort überwacht werden
insbesondere solche die programmatisch unabhängige Dinge überwachen
(Notaus-taster usw)
Da geht mir leserlichkeit vor;
immerhin muss software mbMn auch 'wartbar' bleiben
und da ist lesbarkeit unabdingbar.

Firmen wie jene die das generell untersagen, haben schlechtes Personal
(nur schlechtes personal profitiert von solcher Regelung)
oder schlechte Führung (dumme Chefs machen dumme Regeln)
oder wurden schlicht schlecht beraten (siehe schlechtes personal)
Egal.. glücklicherweise nicht mein Problem :D

georg schrieb:
> Es ist schlechter Programmierstil in einer Schleife 2
> verschiedene Ausgänge zu haben. Das fängt schon beim Debuggen an.

Ehrlich gesagt hab ich noch nie ein Problem beim debuggen gehabt was das 
angeht, erklär mir mal in welchem Zusammenhang Du meist das könnte 
Problematisch werden.

'sid

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> Liegt hauptsächlich daran dass in vielen Firmen in Teams programmiert
> wird

Du gehörst wohl in die Kategorie "ich muss so unverständlich wie möglich 
programmieren, damit niemand meine Programme versteht (besonders nicht 
mein Chef) und ich unentbehrlich werde".

So haben das manche in der Gründerzeit der IT gemacht, aber heute sind 
diese Unentbehrlichen alle längst entbehrlich und Teamarbeit ist 
angesagt. Auch wenn du das doof findest und Regeln zur Verständlichkeit 
für dich nur was für Nichtskönner sind. Da bekenne ich mich gerne zum 
Nichtskönnertum, auch wenn ich allein programmiere. Mir hat ein sauber 
strukturiertes, verständliches und gut dokumentiertes Programm noch nie 
geschadet.

Georg

von Josef G. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mögliche Alternativen zur while(1)-Schleife mit einem bedingtem break
Beitrag "Re: Gibt es eine Programmiersprache mit diesem Schleifentyp?"

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> Mögliche Alternativen zur while(1)-Schleife mit einem bedingtem break
> Beitrag "Re: Gibt es eine Programmiersprache mit diesem Schleifentyp?"

Klassisch. Der Josef. Immer für einen Scherz gut.

von Josef G. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Immer für einen Scherz gut.

Kein Scherz.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> Kein Scherz.

Ja. Leider.

von dis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
sid schrieb:
> gestehe aber ein, dass besonders in Arduino-IDE man so am einfachstem
> seinem Ziel näher kommt die loop an der weiteren Ausführung zu hindern

Noch nie was von Statusmaschinen gehört, aber erzählt was von sauberem 
Stil? Oh, und Protothreads gibts auch noch. Und...

Die Arduino-loop() zu blockieren ist eine ganz blöde Idee, weil dann je 
nach Plattform plötzlich auch jede Menge anderer Späße nicht mehr 
funktionieren...

von sid (Gast)


Bewertung
0 lesenswert
nicht lesenswert
georg schrieb:
> Du gehörst wohl in die Kategorie "ich muss so unverständlich wie möglich
> programmieren, damit niemand meine Programme versteht (besonders nicht
> mein Chef) und ich unentbehrlich werde".
Mein Chef kann das lesen.. hauptsächlich weil er das getippt hat ;)

Ne, wie gesagt, ich lege wert auf Leserbarkeit;
ich erwarte allerdings,
dass jemand mindestens in der Lage ist auch den Code und nichtnur die 
Kommentare zu lesen;
und das beinhaltet eben auch den Inhalt einer Schleife im Zweifel ;)

Wenn "gewachsene" Teams zusammenarbeiten ist minimale Regelung nötig;
wenn aber alle paar Wochen/Monate neue Mitglieder eingearbeitet werden 
müssen,
braucht man meist doppelt so lange für den fertigen Code und schlimmer
mehr Einschränkungen um Chaos zu verhindern.
Gruppiert man ähnlich gesinnte regeln die das unbürokratisch 
untereinander in sehr sinnvollen Massen

Son Einschränkungs-Kokolores macht gradenoch auf github Sinn, oder in 
Firmen in denen die Mitarbeitert regelmässig stiften gehen, (meist weil 
der Chef ein Idiot ist)
und man regelmässig Leute umlernen muss damit deren 'woanders' 
angelernter Codingstil passt.

Nene, so frei wie möglich tippen ist immer schneller,
lesbar ja, kommentiert auch,
aber der Lesende sollte schon auch in der Lage sein mitzudenken oder er 
hat nix in der Materie verloren.

Man gewöhnt sich schnell an die Quirks der Mittipper (coding monkeys)
und versteht diese zu lesen..
NUR wenn der Auftraggeber den Quelltext überantwortet bekommt
(passiert eher selten)
werden verbindliche Stil-Vorgaben gemacht (dauert länger, kostet extra)
Dennoch kann ich noch immer einige meiner Äffchen an ihren Zeilen 
erkennen.. anderes Thema!

dis schrieb:
> Die Arduino-loop() zu blockieren ist eine ganz blöde Idee, weil dann je
> nach Plattform plötzlich auch jede Menge anderer Späße nicht mehr
> funktionieren...
Hoffentlich ALLE anderen Spässe,
das ist ja der Sinn eines Fullstop;
die ISR bleibt zwangsläufig und der Reset bleibt ja auch noch

Und nein, nur um es nochmal zu sagen:

sid schrieb:
> Also bedingungslose Schleifen halte ich zwar generell eher für
> vermeidenswert

Aber für Kinkerlitzchen und Arduino-geschiss, sind sie eben nicht 
schlimm genug alsdass ich sie direkt verteufeln wollte.
Man muss auch mal seinen vernagelten Kopp ausm Arsch ziehen können um zu 
verstehen,
dass der gemeine Hobbyist eben andere Anforderungen hat als eine 
gelernte Fachkraft.

wenn ich für mich alleine Arduino schiselameng am Wochenende 
zusammenprokrastiniere,
dann mach ich auch keine Doku dazu, schreib auch keine Kommentare rein,
halte mich nichtmal immer an meine eigenen naming conventions und mir 
ist es vollkommen Hupe ob sich mir nächstes Jahr der Magen umdreht wenn 
ich das lesen muss oder nicht.
ich kopier sogar ganze Blöcke aus alten Projekten wenn sie einigermassen 
passen
(was ich beruflich in der Tat verteufel! libraries ja, copy&paste nie!!)

Weil es total egal ist solange es tut was es soll!
Unreachable code, auskommentierte alternativzeilen,
alte dummy funktionen.. bleibt alles drin (sofern ich die entfernteste 
chance eines revivals sehe),
was der Compiler nicht wegoptimiert und dennoch keine Probleme macht 
stört auch nicht.

Wie gesagt Jungs, lasst dem Laien seine laienhafte Freude am Probieren;
es macht doch keinen Sinn irgendwelche hauptsächlich fiktiven Regeln 
aufzustellen die defacto nicht existent sind ausserhalb der geldwerten 
Tätigkeit.

Im Gegenteil: Ich schalmeie Euch folgendes zu:
Ran an die Tasten, schreibt möglichst absurden blinky-piepse code für 
den Arduino, dreckig und wild, als Fingerübung;
versucht jede Stil-Regel zu brechen
alles in 1337 wo möglich, kilometerlange Einzeiler;
mischt Assembler mit Arduino librarie Funktionen etc.
das fördert die Kreativität!
Besonders wenn ihr das in ein paar Monaten erneut öffnet und versucht es 
zu lesen :D
Im schlimmsten Fall bildet sich ne neue Synapse,
im Besten habt ihr Spass daran herauszufinden ab wann der Compiler Euch 
ins Gesicht spucken will ;)

shalömmchen juchee

'sid

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.