Forum: Mikrocontroller und Digitale Elektronik Frage zu while Schleife


von Peter Schmidt (Gast)


Lesenswert?

Moin !
Kurze Frage zu einer while schleife?

Kann man so einen Vergleich ausführen?

int size, x ;

while(size == x)
{ ... x und size werden hier unterschiedlich erhöht, bis diese gleich 
sind }

und danach soll die Schleife verlassen werden?

Geht so was überhaupt?

von The D. (devil_86)


Lesenswert?

Also theoretisch würd ich ja sagen; er steigt halt nur in die Schleife 
ein, solange size gleich x ist.

von Peter Schmidt (Gast)


Lesenswert?

ahhh, da ist mein Fehler..Ich suche die Lösung, das er in die Schleife 
einsteigt und sie verläßt wenn die beiden Parameter gleich sind!

von The D. (devil_86)


Lesenswert?

Na das mit dem Verlassen ist so ne Sache....du kannst es eben nur so 
programmieren, dass er in die Schleife einsteigt, wenn sie ungleich 
sind, und falls sie irgendwann gleich werden, steigt er eben erst gar 
nicht mehr in die Schleife ein....
Ich weiß nicht, ob das 'Rausspringen' so geht!! Bis jetzt hab ich 
while-Schleifen nur als Endlosschleifen gebraucht [also while(1)].

von Miu (Gast)


Lesenswert?

while(1)
{
if (x == size)
   {
   break;
   }
}

von Dussel (Gast)


Lesenswert?

Wie von Miu geschrieben: 'Break' dannnn verlässt er die Schleife sofort 
oder mit 'continue' springt er wieder zum Schleifenanfang und prüft 
nochmal die Bedingung.

von The D. (devil_86)


Lesenswert?

Na, wieder was gelernt :-)

von T.v.B. (Gast)


Lesenswert?

while( x==size){
   //mach was
}
--> Abbruch bei x!=size


while( x !=size){
   //mach was
}
--> Abbruch bei x==size

Alles klar? ;-)

Gruß T.v.B.

von Gast (Gast)


Lesenswert?

break und continue sind zwar legitime C Anweisungen sollten aber wenn 
möglich nur in Ausnahmefällen benutzt werden. Da es in der 
Programmierung immer mehr als nur einen Lösungsweg gibt, sollte über 
eine Lösung ohne break bzw. continue nachgedacht werden. Es wäre 
"sauberer" und später besser wartbar, da ein plötzlicher 
Schleifenabbruch in einem komplexen System z.T. sehr schwer 
nachvollziehbar ist. Es stellt sich dann meist die Frage : WAS HAT SICH 
DER PROGRAMMIERER NUR DABEI GEDACHT ???? .
Mein genereller RAT : Nur in Ausnahmefällen (kurze Testprogramme!!!) 
Quick and dirty programmieren ansonsten lieber ein wenig Zeit in die 
Programmstruktur investieren. Man wird spätestes beim Debuggen danken.

von Miu (Gast)


Lesenswert?

evtl. auch möglich je nachdem wann du die Überprüfung haben willst:

do
{
//auszuführender Code
}
while(rest != x);

von Miu (Gast)


Lesenswert?

Break und Continue erachte ich als sehr "Sauber"!!!

von Gast (Gast)


Lesenswert?

Tja, da unterscheiden sich unsere Erfahrungen. Bei Schleifen mit 3 
Anweisungen im Schleifenkörper ist das sicher nicht der Rede wert. Aber 
bei größeren, komplexeren Bedingungen schon.

von Gast (Gast)


Lesenswert?

Dann schau Dir mal eine komplexe Software an, bei der aufgrund von 
Timing und anderer Dinge Prozesse aufgesplittet wurden und dieses 
mittels break und continue realisiert wurde. Dann wirst Du schnell 
feststellen das dies als Mittel zum Zweck geschah aber aber sehr 
schlecht wartbar/erweiterbar ist. Daher kommt kommt für mich nur das 
break in einer Switch/Case Struktur in Frage, alles andere ist erstmal 
Tabu, es gibt immer einen anderen Weg.

von Michael W. (wiebel42)


Lesenswert?

Ich würde mich Miu's Vorschlag anschliessen. Eine Fussgesteuerte 
Schleife ist genau, dass was gefragt ist, es wird in jedem fall einmal 
ausgeführt und danach getestet.
Von wengen Break <-> While, ich will da nichts bewerten, beides hat 
seine Vor- und Nachteile aber wenn man schon mit Breaks arbeitet könnte 
man evtl. gleich ganz auf goto umsatteln, das hätte auch den grossen 
Vorteil das mit Sicherheit jeder Comiler aus einem goto ohne grosses 
Federlesen ein rjmp erzeugt, was natürlich schon performanter ist als 
denkbare Konstrukte die für ein while nötig sein dürften. Wobei ich auch 
nicht genau weiss was gcc aus while(1) macht. Nur so ein Gedanke. 
-wiebel

von Peter (Gast)


Lesenswert?

Ein guter Compiler erzeugt bei gleicher Semantik den gleichen Code. Da 
ist es egal, ob man while, do, oder break/continue/goto benutzt hat.
Obwohl, beim GCC hätte ich da auch meine Zweifel.

von Simon K. (simon) Benutzerseite


Lesenswert?

Michael Waiblinger wrote:
> Wobei ich auch
> nicht genau weiss was gcc aus while(1) macht. Nur so ein Gedanke.

Ernst gemeint? ;)

-O0 (keine Optimierung):
1
  while(1)
2
    ;
3
  aa:  ff cf         rjmp  .-2        ; 0xaa <main+0x1c>

von Michael W. (wiebel42)


Lesenswert?

Nagut, war ich wohl zu pessimistisch. ;)

von Netbird (Gast)


Lesenswert?

Hallo,
Gast hat Recht, das Stichwort heißt "Strukturiertes Programmieren".

Wichtig ist, dass ein Algorithmus mit einigen wenigen vernünftigen 
Kontrollstukturen auskommt, dazu gehören auch WHILE "Bedingung wahr" ... 
End While und REPEAT ... UNTIL Bedingung wahr (hier 
programmiersprachen-unabhängig formuliert, wie es bei der Entwicklung 
von Programmabläufen auch zunächst selbstverständlich ist.)
Mehrfach geschachtelte Konstrukte werden durch Benutzung strukturierter 
Elemente vernünftig lesbar, GOTOs, Breaks u.ä. sind dagegen mehr oder 
weniger strikt verboten, da sie NICHT-strukturiert sind.
In der Programm- Dokumentation gibt es für die Strukturen 
"Nassi-Shneiderman- Diagramme".
Was ein Compiler macht, ist unerheblich, denn für Entwicklung und 
Wartung von Algorithmen ist die Struktur wichtig!. Googelt mal unter den 
obigen Stichworten, dann stoßt Ihr allenhalben auf Informatik-Links, die 
diese Sachverhalte behandeln.

Fußnote: Es war schon zu Zeiten des Commodore C64 mit seinem unsäglichen 
(weil unstrukturiertem) BASIC möglich und dringend empfohlen, einen 
Algorithmus strukturiert zu entwerfen und beim Kodieren diese Elemente 
ersatzweise mit IF und GOTO- Konstruktionen zu  realisieren. Der Vorteil 
liegt darin, dass bei einem Wechsel der Programmiersprache der 
Algorithmus praktisch keine Veränderungen erforderte, nur die 
Übersetzung in die Sprachelemente der neuen Sprache war notwendig! Ein 
vernünftig entwickelter Algorithmus ist und bleibt verstehbar und 
überdauert einige "Sprachmoden" ...
MfG

von Peter (Gast)


Lesenswert?

> Mehrfach geschachtelte Konstrukte werden durch Benutzung strukturierter
> Elemente vernünftig lesbar, GOTOs, Breaks u.ä. sind dagegen mehr oder
> weniger strikt verboten, da sie NICHT-strukturiert sind.

http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf

von nico26plus1 (Gast)


Lesenswert?

man kann breaks durch returns ersetzen, wenn man die Abbruchbedingung 
bzw. die Schleife in ein Unterprogramm packt. Wenn man es geschickt 
macht, bleibt der Code dadurch auch gut lesbar.

und bei verschachtelten schleifen dient goto und co sogar der sauberen 
programmierung, da ansonsten der code durch Merker und deren Abfragen 
aufgebläht wird und so unübersichtlich wird.

dass man nicht wild im code hin- und herspringt sollte klar sein. aber 
daraus abzuleiten, sprünge generell zu verbieten, ist lachhaft...

von Miu (Gast)


Lesenswert?

Jup, die Merker Setzerei find ich auch sehr sehr schwierig zum 
Nachvollziehen!!!
Und stimme dir voll zu, dass gegen einen sinnvollen Einsatz von Sprüngen 
nichts spricht...

von Michael W. (wiebel42)


Lesenswert?

Netbird wrote:
> ... GOTOs, Breaks u.ä. sind dagegen mehr oder
> weniger strikt verboten, da sie NICHT-strukturiert sind.

Diese Aussage geht meines Wissens nach auf einen sehr alten Artikel der 
Probleme mit Pascal behandelt zurück und hat dem armen unschuldigen GOTO 
einen echten Imageschaden zugefügt. Ich schliesse mich nico26plus1 und 
Miu an. Man sollte alle Möglichkeiten die einem eine Programmiersprache 
gibt auch nutzen, sicher sollte man mit einigen Dingen aufpassen und ja 
mit GOTO kann man grosse Verheerungen anrichten, aber mit Verstand 
eingestzt ist das alles was Gutes. -wiebel

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.