mikrocontroller.net

Forum: PC-Programmierung C-Programm ohne goto


Autor: Grübler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schönen guten Abend

Ich habe eine kleines C-Programm

for (Schleifenbedingung)
   {
    Befehl;
    Befehl;
    while (Bedingung)
       {
        Befehl;
        if (Abfrage) break; //verlasse beide Schleifen
        Befehl;
       }
   }

Wenn „Abfrage“ erfüllt ist, möchte ich nicht
nur die while-Schleife sondern auch sofort die
for-Schleife verlassen. Mit break wird ja jetzt
nur die while-Schleife verlassen.

Gibt es eine Lösung ohne goto ;-) ?

: Verschoben durch Admin
Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die for schleife hat doch einen Wert z.B. i. Du kannst ja den Wert auf 
dein maximum setzen und bendest dann auch die for-schleife

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry blödsinn :) vergesse es

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ab=false;
for (Schleifenbedingung)
   {
    Befehl;
    Befehl;
    while (Bedingung)
       {
        Befehl;
        if (Abfrage) {
            ab = true;
            break;
        }
        if(ab) break;
        Befehl;
       }
   }

so sollte es gehen

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eher nicht...

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich schrieb:
> eher nicht...

nicht?

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
if(ab) break;
Befehl;

natürlich in die for-schleife nicht in die while!

Autor: Oliver Dippel (unixconf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
for (Schleifenbedingung)
   {
    Befehl;
    Befehl;
    while (Bedingung)
       {
        Befehl;
        if (Abfrage) {
          Schleifenbedingung = FALSE;
          break; //verlasse beide Schleifen
        }
        Befehl;
       }
   }


;-)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grübler schrieb:
> Wenn „Abfrage“ erfüllt ist, möchte ich nicht nur die while-Schleife
> sondern auch sofort die for-Schleife verlassen.
Pack das Ganze in ein Unterprogramm und mach ein return aus dem 
break... ;-)

Autor: Tim T. (tim_taylor)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wärs es in eine Unterfunktion zu packen?
void foo(void) {
 for (Schleifenbedingung) {
  Befehl;
  Befehl;
  while (Bedingung) {
   Befehl;
   if (Abfrage) return; //verlasse beide Schleifen
   Befehl;
  }
 }
 return;
}

Eventuell die Schleifenbedingung, Bedingung und Abfragewert als 
Parameter übergeben falls sie nicht global sind oder lokal gesetzt 
werden.

Autor: kermit der frosch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
warum kein goto? einfache verschachtelte schleifen ohne goto sind in 80% 
der fälle wurstiger code mit redundanzen.

Autor: Grübler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kermit schreibt:
>Warum kein goto?

Goto ist verpönt, da man damit
sehr unübersichtlichen Programmcode
erzeugen kann (Spagetti-Programmierung).
In JAVA gibt es z.B. gar kein goto mehr.

Ich werde aber hier doch ein goto nehmen,
und das Sprungziel direkt unter die Schleifen
setzten. Das scheint mir gut lesbar zu sein.

Danke an alle für die Tipps!

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich seh auch kein Problem mit goto. Ja, man kann viel Blödsinn damit 
anstellen. Das heisst aber nicht, dass man es auch macht, wenn man es 
benutzt.
Ja, man kann es immer vermeiden. Muss man aber nicht:-)

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grübler schrieb:
> Goto ist verpönt, da man damit
> sehr unübersichtlichen Programmcode
> erzeugen kann (Spagetti-Programmierung).

Kreissägen führen bei unsachgemäßer Verwendung regelmäßig zu schweren 
Verletzungen, dennoch sind sie nicht "verpönt".

Du lieferst selbst das beste Beispiel, warum ein pauschales "goto ist 
böse" schwachsinnig ist.

> In JAVA gibt es z.B. gar kein goto mehr.

Da gibt es aber ein break mit Label, eben weil der Abbruch von 
verschachtelten Schleifen sonst unübersichtlich und fehleranfällig wird 
(Pascal lässt grüßen...).

Wenn man es drauf anlegt kann man damit genauso üblen Code produzieren 
wie mit goto in C. Eigentlich sogar noch übler, da das Label bei diesen 
Konstrukten dann nichtmal an der Stelle steht, wo wirklich hingesprungen 
wird. Es steht nur nicht das angeblich böse "goto" da.

Andreas

Autor: Markus ---- (mrmccrash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre es nicht einfacher, die Schleifenbedingung für das For zu erfüllen?

z.B.
int i;
bool abbruch = false;

for (i=0; (i<4)&&(!abbruch); i++)
{
  Befehl();
  Befehl();
  while (Bedingung)
  {
    Befehl();
    if(Bedingung)
    {
      abbruch = true;
      break;
    }
   }
}

_.-=: MFG :=-._

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grübler schrieb:
> Gibt es eine Lösung ohne goto ;-) ?

Nein, es gibt keine Lösung, die gleich effektiv ist.

Die mit Return kostet etwas Stack, ist aber gleich gut leserlich, wie 
das Goto. Und dann kommen aber die Nörgler, die sagen, daß jede Funktion 
nur ein Return haben soll.

Die mit ner Variable macht den Code deutlich unleserlicher und kann 
sogar richtig teuer werden, wenn extra für diese zusätzliche Variable 
ein Stackframe angelegt werden muß.


Man sollte Goto nicht unnütz nehmen. Wenn es aber paßt, wie die Faust 
aufs Auge, dann nimmt man es einfach.

Irgendwelche Dogmen auszusprechen und sich sklavisch daran 
festzukrallen, halte ich für Schwachsinn. Der gesunde Menschenverstand 
sollte Vorrang haben.


Ein ähnliches Problem hat man auch bei Switch-Anweisungen in einer 
Schleife.
Sehr oft gibt es einen oder mehrere Case, die die Schleife verlassen. 
Durch die Doppelfunktion des Break ist das aber nicht möglich
Daher findet man Goto auch sehr oft in Switch-Anweisungen.
Sehr sinnvoll wäre daher ein extra Schlüsselwort zum Beenden eines Case 
gewesen.


Peter

Autor: klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gibt es eine Lösung ohne goto ;-)


void f()
{
for (Schleifenbedingung)
   {
    Befehl;
    Befehl;
    while (Bedingung)
       {
        Befehl;
        if (Abfrage) return; //verlasse beide Schleifen
        Befehl;
       }
   }

}

?

Autor: benjamin tülpchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich wette, dass 10k mal öfter gesagt wird goto ist scheiße, als 
verkackter code mit goto gelesen wird.

oder:

ich wette, dass 99% der leute, die sagen goto ist verpönt, noch nie 
verkackten goto-code gesehen haben.

Autor: z.b. so (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#define gehezu goto
und schon ist das goto weg ;-)

wenn es passt und den code leserlicher gestaltet, verwende es.
weenn es dein code ist - mach was du willst, wenn dir dein arbeitgeber 
ein goto verbieten möchte/verbietet hast du zwei möglichkeiten:
- gut argumentieren und eine rebellion veranstalten
- akzeptieren und hässliche/schlecht lesbare/sonstige workarounds 
einbauen...

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Die mit Return kostet etwas Stack, ist aber gleich gut leserlich, wie
> das Goto. Und dann kommen aber die Nörgler, die sagen, daß jede Funktion
> nur ein Return haben soll.

Jepp, und die Nörgler haben oft recht. Wie toll ist es wenn Du am Ende 
einer Funktion einen Breakpoint setzen willst und musst dann 2 oder 3 
oder 7 setzen, weil entsprechend viele returns da sind.
Wie toll ist es wenn du am Ende der Funktion schnell einen Trace 
rausschreiben willst und kannst auch das dann 3 oder gar 7 mal machen.

Peter Dannegger schrieb:
> Die mit ner Variable macht den Code deutlich unleserlicher und kann
> sogar richtig teuer werden, wenn extra für diese zusätzliche Variable
> ein Stackframe angelegt werden muß.

Der Code von Markus war keinen Deut schlechter. In Sachen Effizienz gabe 
ich dir 100% recht, wobei das auf µCs manchmal eine Rolle spielt, auf 
PCs nur in absoluten Ausnahmefällen.

Peter Dannegger schrieb:
> Man sollte Goto nicht unnütz nehmen. Wenn es aber paßt, wie die Faust
> aufs Auge, dann nimmt man es einfach.
>
> Irgendwelche Dogmen auszusprechen und sich sklavisch daran
> festzukrallen, halte ich für Schwachsinn. Der gesunde Menschenverstand
> sollte Vorrang haben.

100% agree, deshalb habe ich oben auch nur oft gesagt :-)

benjamin tülpchen schrieb:
> ich wette, dass 99% der leute, die sagen goto ist verpönt, noch nie
> verkackten goto-code gesehen haben.

Ich habe mal ein paar Jahre Code warten müssen, der von einem 
selbstgeschriebenen Cross-Compiler (nicht von mir) aus IBM-Host 
Assembler C für Unixsysteme und Windows und OS/2 erzeugt hat. So grausam 
kann kein Mensch C Spagetticode programmieren, nicht mal einer der sonst 
nur Basic programmiert hat :-).

Gruß

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
benjamin tülpchen schrieb:
> ich wette, dass 10k mal öfter gesagt wird goto ist scheiße, als
> verkackter code mit goto gelesen wird.

Wohl wahr.

Aber die Regel ist so leicht, daß jeder sie nachplappern kann.
Ähnlich wie "Makros sind verboten".

Denken statt Abklappern von Regel-Checklisten ist halt aufwendiger.
Das Ganze auf die Spitze getrieben heisst dann MISRA-C.

Autor: skorpionx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein "goto" ist wie Gift, genauso wie vieles gute in Medizin. Es gibt
Programme die dankt dem Befehl gut strukturiert und gut lesbar sind.
Z.B. am Anfang prüft man die Plausibilität von sehr vielen Angaben. Wenn 
etwas nicht passt dann lädt man Puffer für Anzeige eine Meldung und mit 
einem Sprung „goto Ergebnis“ verlässt man egal wie tief verschaltete 
Schleife. Im Ergebnis prüft man dann ob etwas zum Schlissen (geöffnete 
Files) oder zum Freigeben (Speicher).

Autor: Nico22 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U.R. Schmitt schrieb:
> Peter Dannegger schrieb:
>> Die mit Return kostet etwas Stack, ist aber gleich gut leserlich, wie
>> das Goto. Und dann kommen aber die Nörgler, die sagen, daß jede Funktion
>> nur ein Return haben soll.
>
> Jepp, und die Nörgler haben oft recht. Wie toll ist es wenn Du am Ende
> einer Funktion einen Breakpoint setzen willst und musst dann 2 oder 3
> oder 7 setzen, weil entsprechend viele returns da sind.
> Wie toll ist es wenn du am Ende der Funktion schnell einen Trace
> rausschreiben willst und kannst auch das dann 3 oder gar 7 mal machen.

Da lässt sich aber drüber streiten. Man kann eine Funktion auch ganz 
schön unübersichtlich machen, wenn man aus Krampf nur ein return haben 
möchte. Das gibt dann auch gerne Spaghetticode. Der Königsweg wäre 
natürlich, per goto zu einem Return zu springen ;-)

Nico

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Qunitessenz ist wie so oft:

Diese Daumenregeln sind grundsätzlich nicht schlecht. Sie geben einem 
Anfänger Richtlinien, wie er die gröbsten Source-Code Fehler vermeiden 
kann. Beachtet man sie, dann läuft man nicht so leicht in Gefahr den zu 
Recht gefürchteten 'Spaghetti-Code' zu produzieren.

Aber wie so oft sind derartige Regeln nicht als Dogma zu sehen, von dem 
man nicht im Einzelfall abweichen kann, solange man weiß was man tut und 
einen guten Grund dafür hat.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hasse generell Schleifen, die mittendrin verlassen werden. Das 
ist immer schwer zu verstehen. Das obige Beispiel würde ich selbst daher 
so schreiben:
for (Schleifenbedingung)
   {
    short running = 1;

    while(running)
      {
        Befehl;
        Befehl;
         while (Bedingung && running)
          {
            Befehl;
            if (running = !Abfrage))
             {
               Befehl;
             }
          }
   }

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nico22 schrieb:
> Da lässt sich aber drüber streiten. Man kann eine Funktion auch ganz
> schön unübersichtlich machen, wenn man aus Krampf nur ein return haben
> möchte. Das gibt dann auch gerne Spaghetticode.

Jepp, ganz klar, wie Peter gesagt hat:
> Irgendwelche Dogmen auszusprechen und sich sklavisch daran
> festzukrallen, halte ich für Schwachsinn. Der gesunde Menschenverstand
> sollte Vorrang haben.

> Königsweg wäre natürlich, per goto zu einem Return zu springen ;-)
***ROFL***

Das ist in java toll. Du klammerst das mit einem try finally und kannst 
dort dann alles sauber beenden, egal wie verschachtelt das Ganze ist.
Das ist nämlich das nächste Problem mit mehreren returns. Du hast eine 
komplexere Aktion, z.B: liest Du aus einer Datei/Dateien und/oder 
MQ-Queues Daten und speicherst Sie (abhängig von dem was Du gelesen 
hast, also komplexe Bedingungen und ggf. Schleifen) in eine Datenbank 
und oder andere Queues. Am Ende musst Du alles aufräumen und je nachdem 
ob es geklappt hat in MQ und Datenbank commit oder rollback absetzen. 
Dann noch mehrere Returns und deine Funktion/Methode wird nie richtig 
funktionieren.
Mit try finally problemlos in den Griiff zu kriegen.

Aber Java in µCs ist auch nicht meine Präferenz :-)

Autor: Nico22 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh ja, finally fehlt mir in C++.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U.R. Schmitt schrieb:
>> Königsweg wäre natürlich, per goto zu einem Return zu springen ;-)
> ***ROFL***
>
> Das ist in java toll. Du klammerst das mit einem try finally und kannst
> dort dann alles sauber beenden, egal wie verschachtelt das Ganze ist.

Solange dich nicht interessiert, wo innerhalb des Blocks die Exception 
aufgetreten ist. Sonst mußt du halt um jede Funkton ein eigenes try 
setzen.

> Das ist nämlich das nächste Problem mit mehreren returns. Du hast eine
> komplexere Aktion, z.B: liest Du aus einer Datei/Dateien und/oder
> MQ-Queues Daten und speicherst Sie (abhängig von dem was Du gelesen
> hast, also komplexe Bedingungen und ggf. Schleifen) in eine Datenbank
> und oder andere Queues. Am Ende musst Du alles aufräumen und je nachdem
> ob es geklappt hat in MQ und Datenbank commit oder rollback absetzen.
> Dann noch mehrere Returns und deine Funktion/Methode wird nie richtig
> funktionieren.
> Mit try finally problemlos in den Griiff zu kriegen.

Mit goto auch.

> Oh ja, finally fehlt mir in C++.

Warum? Dank vernünfig funktionierender Destruktoren braucht man das doch 
gar nicht.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nico22 schrieb:
> Oh ja, finally fehlt mir in C++.


Brauchen wir auch nicht.
Wir haben einen Destruktor, der auch so funktioniert wie er soll.
RAII und du brauchst kein finally mehr

http://www.research.att.com/~bs/bs_faq2.html#finally

damit verlieren dann auch mehrere return in einer Funktion ihren 
"Schrecken".

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja, manchmal wäre es schon nett.
Wenigstens das finally kann man Java als Vorteil zugestehen.

Autor: qt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur nicht-Informatiker können über so eine Lapallie so lange Diskutieren 
:D

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du bist Informatiker? Denen sagt man Rechtschreibschwächen nach... :-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> naja, manchmal wäre es schon nett.

z.B. ?

> Wenigstens das finally kann man Java als Vorteil zugestehen.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
z.B. schlichte Debugausgaben nach dem Motto "ich komme gerade hier 
vorbei und springe zurück..." oder halt alles, was mit Aufräumen zu tun 
hat.

Letzteres kann man natürlich immer in einem dtor verpacken, aber
das lohnt nicht in jedem Fall.

Also hat man dann doch manchmal in mehreren catch-Zweigen mehr
oder weniger Codewiederholung, die in einem finally-Block besser
aussehen würden.

Nachtrag: am ehesten vermisse ich es dann, wenn ich etwas machen
will, was nicht direkt mit der eigentlichen Programmlogik verwebt
ist, z.B. Laufzeitmessung eines Algos.

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
qt schrieb:
> Nur nicht-Informatiker können über so eine Lapallie so lange Diskutieren

Stimmt, Informatiker schreiben darüber eine Doktorarbeit :-P

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> naja, manchmal wäre es schon nett.
> Wenigstens das finally kann man Java als Vorteil zugestehen.

Ich sehe es eher als Krücke, die man eingebaut hat, weil die 
Destruktoren fehlen.

Autor: Stefanie B. (sbs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grübler schrieb:
for (Schleifenbedingung && Bedingung)
    {
     Befehl;
     Befehl;
     while (Bedingung)
        {
         Befehl;
         if (Abfrage) break; //verlasse beide Schleifen
         Befehl;
        }
    }

Variation nur in Zeile 1 mit && Bedingung

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rolf Magnus:
ok, daß der Grund für finally in Java ein übler ist, macht
den Mechanismus ja nicht per se schlecht.

Autor: Nico22 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> ok, daß der Grund für finally in Java ein übler ist, macht
> den Mechanismus ja nicht per se schlecht.

Genau darum ging es mir. Wenn man nicht Lust hat, jedes 
C-init()-und-end() in eine eigene Klasse zu kapseln (was natürlich sehr 
elegant ist), dann vermisst man das finally manchmal schon. Es geht 
natürlich auch ohne.

Gruß,
Nico

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> @Rolf Magnus:
> ok, daß der Grund für finally in Java ein übler ist, macht
> den Mechanismus ja nicht per se schlecht.

Ganz sicher nicht.

Aber wenn man erst mal auf RAII aufgesprungen ist und das konsequent 
macht, will man es nicht mehr missen. Und dann lösen sich 99% aller 
finally Probleme, genauso wie 99% aller Memory Leaks in Luft auf und man 
vermisst einen GC plötzlich überhaupt nicht mehr :-) Und eigentlich ist 
es ja der GC, im Zusammenspiel mit einem unbrauchbaren Destruktor, der 
einem Dinge wie finally aufzwingt.

Autor: Nico22 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, einen GC vermisse ich auch überhaupt nicht. Ist aber immer 
schon, wenn einem valgrind zeigt, dass man doch lieber RAII hätte 
benutzen sollen, weil man irgendwo ein *_end() vergessen hat.

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Ich sehe es eher als Krücke, die man eingebaut hat, weil die
> Destruktoren fehlen.

Sorry aber das ist ziemlicher Blödsinn.
Mit finally kann man auch innerhalb einer Methode viel feiner granuliert 
Dinge 'zum lokalen' Schluß beenden.
Und komm mir nicht mit OO-Designtheorien daß dann das Design falsch ist 
und man einzelne Klassen mit jeweils einem Destruktor machen müsste.
Man kann den Spiess auch umdrehen und sagen, C++ hat die Destruktor 
Krücke weil ...
Ausserdem wollte ich hier keine "die Programmiersprache ist besser 
weil..." Diskussion lostreten.
Aber es fühlen sich manche immer wieder ans Bein gepinkelt, wenn man 
"Ihr" System, Sprache, Tool angeblich schlecht macht, nur weil man wagt 
darauf hinzuweisen, daß es bei einem anderen Tool, System, Sprache, ... 
andere Konzepte gibt.
Viel Spass

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U.R. Schmitt schrieb:

> Aber es fühlen sich manche immer wieder ans Bein gepinkelt, wenn man
> "Ihr" System, Sprache, Tool angeblich schlecht macht, nur weil man wagt
> darauf hinzuweisen, daß es bei einem anderen Tool, System, Sprache, ...
> andere Konzepte gibt.

Genau darum gehst letztenendes.
In C++ gibt es kein finally, weil man in C++ anders programmiert.

Das hat doch nichts mit 'ans Bein pinkeln zu tun'.
Das muss man den Leuten einfach nur vermitteln, die zb von Java zu C++ 
kommen. Manche Idiome funktionieren in C++ nun mal anders. Und ehe man 
nach Möglichkeiten einer 1:1 Übersetzung sucht, sollte man besser auf 
die in der Zielsprache üblichen und bewährten Idiome umschwenken. In C++ 
ist es nun mal der Destruktor, der Aufräumarbeiten erledigt. Das hat den 
Vorteil, dass man als Verwender einer Klasse nicht darauf vergessen kann 
die entsprechende Funktion aufzurufen und man sich daher auch nicht 
darauf konzentrieren muss.

Um einen deutschen Text ins englische zu übertragen, reicht es auch 
nicht aus einfach nur Grammatik und Vokabeln zu beherrschen.

Autor: High Performer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Detlev T.:

ja, so ähnliche mache ich das auch. Wenn man gute Bezeichner wählt, ist 
es übersichtlich und logisch. Evtl. ein klein wenig ineffizienter als 
andere Lösungen, aber schön.


@Markus:

>for (i=0; (i<4)&&(!abbruch); i++)

Hmmm, gefällt mir nicht sooo gut. for-Schleifen verwende ich nur, wenn 
die Abbruchbedingung feststeht (z.B. Anzahl der Elemente eines Arrays 
etc.)
Sonst verwende ich lieber eine while- oder do-while-Schleife.

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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