3. Mein Informatiklehrer sagt, dass

Mein Informatiklehrer sagt, dass

  • F

    Vermutlich will der Informatiklehrer vermeiden, daß Schleifen zwei und mehr Laufbedingungen kriegen. Das wäre schlechter Stil.

    Das sehe ich aber nicht so. In den modernsten Büchern finden sich for-Schleifen, die mit mehreren Bedingungen arbeiten. Warum sollte man unnötig viele Schleifen erstellen wenn man ähnliche Bedingungen auch gleich in den Kopf schreiben kann?

    So weit konnte mein Lehrer gar nicht denken, denn das kam richtig rausgeschossen also ob das wohl das Normalste der Welt sei. Wie als wenn ich geftragt hätte, ob ich void main() oder int main() schreiben soll. Heutzutage bevorzugt jeder das zweite!!!

    lg, freakC++

    0
  • ?

    Habt ihr einmal bedacht, dass der Lehrer es mit Anfängern zu tun hat und diese davon abhalten will unleserlichen Spaghetti-Code zu produzieren? Ein Lehrköper muss eben teilweise pauschal antworten, da er nicht die Zeit hat wie ihr über 100 Seiten einen Flameware zu entfachen, sondern den Stoff durchbringen will.

    0
  • V

    Kenner des Lehrers schrieb:

    Habt ihr einmal bedacht, dass der Lehrer es mit Anfängern zu tun hat und diese davon abhalten will unleserlichen Spaghetti-Code zu produzieren? Ein Lehrköper muss eben teilweise pauschal antworten, da er nicht die Zeit hat wie ihr über 100 Seiten einen Flameware zu entfachen, sondern den Stoff durchbringen will.

    Quatsch!
    Man kann sagen, dass break und continue schlechter Programmierstil sind, und damit lügen.
    Man kann sagen, dass break und continue Signale für schlechten Programmierstil sind und anzeigen, daß man den Code nochmal überdenken sollte, und damit wahr haben.
    Oder man macht's wie ich und sagt anfangs mindestens einmal pro Stunde, daß alle Generalisierungen falsch sind, und später kann ich dann wieder sagen "break und continue sind schlechter Programmierstil!", es wird ja einer widersprechen und sagen "aber es gibt doch bestimmt Fälle, wo es anders ist(?)" und ich sage "Mist, Du hast recht, ja, ich kann mir Fälle vorstellen." und wieder sind zwei aufgewacht; manche warten auch nur darauf, daß ich mich wieder zum Kasper mache.

    0
  • ?

    volkard schrieb:

    und damit wahr haben.

    http://www.google.de/#hl=de&q="und+damit+wahr+haben."&btnG=Google-Suche&meta=&aq=f&fp=eb7d8eb6a2f89501
    http://www.google.de/#hl=de&q="und+damit+recht+haben."&meta=&fp=21aa8cd8ca294c3a

    0
  • V

    wer sagt denn sowas schrieb:

    volkard schrieb:

    und damit wahr haben.

    http://www.google.de/#hl=de&q="und+damit+wahr+haben."&btnG=Google-Suche&meta=&aq=f&fp=eb7d8eb6a2f89501
    http://www.google.de/#hl=de&q="und+damit+recht+haben."&meta=&fp=21aa8cd8ca294c3a

    Mist, Du hast recht.

    0

  • Also bei mir enthält fast jede Schleife ein "break". Man sucht etwas, findet es und bricht die Schleife ab.Natürlich kann man auch die Bedingung in die Schleife reinschreiben, aber ein Break ist auch für fremde Code-Leser ( oder ich nach 4 Wochen 😉 ) manchmal einfach schneller zu verstehen. Man sieht die Bedingung und das break. Für mich eindeutig einfacher.

    Aber andere mögen das anders sehen.

    0
  • S

    It0101 schrieb:

    ...Natürlich kann man auch die Bedingung in die Schleife reinschreiben...

    .. die deswegen auch "Abbruchbedingung" heißt. :p 😉
    Ich persönlich finde die Vielfältigkeit der Ausdrucksmöglichkeiten mit while und for einfach sprechender.
    So assoziiere ich mit "for" gleich das "Abarbeiten einer vorgegebenen Menge" und "while" ein "Wiederholen, solange ein bestimmter Zustand besteht" (bzw. bis ein bestimmter Zustand erreicht ist).

    Das spiegelt bestimmte "Standardschleifen" wider - und diese Standardfälle sind einfacher wiederzuerkennen, wenn man sie entsprechend nennt.
    (Aus demselben Grund bin ich auch für die vernünftige Verwendung der <algorithm>-Funktionen)

    Nicht jede Fachlichkeit kann ausschließlich durch die Struktur

    while(true) {
   a();
   if(irgendwas()) break;
   b();
   if((irgendwas_anderes()) break;
   ...

    beschrieben werden.
    ... ist ein wenig vergleichbar mit dem Einführen der Multiplikation in der Grundschule: Es gibt Schüler, die das für überflüssig halten, weil man sie ja auch durch Addition ausdrücken kann ... aber irgendwann bricht man sich damit die Finger. 😉

    Gruß,

    Simon2.

    0
  • D

    Mein Informatikprofessor in einer der ersten Vorlesungen zu C++

    "Das break ist zu vermeiden, da das Schleifenkonstrukt in einem unbestimmten Zustand verlassen wird, es ist unter Umständen mit unerwünschten Nebeneffekten zu rechnen, viel besser ist es die Abbruchbedingung durch die Schleifenbedingung selbst herbei zuführen." dies sei... so der Prof.: "Guter Programmierstiel!"

    /** schlechter Stil **/
for(int i = 0; i < 4; i++)
{
  /* mach was */ 
  break; // <- ganz böse
}

/** guter Stil **/
for(int i = 0; i < 4; i++)
{
  /* mach was */ 
  i = 4; // <- Gut
}

    Ich gestehe ich halte mich bei meinen Programmen auch nicht daran und verwende break und continue immer dann wenn ich es brauche.

    0
  • C
    Mod

    Hast du mal nachgefragt, was ein "unbestimmter Zustand" sein soll, und unter welchen Umständen diese unerwünschten Nebeneffekte auftreten?

    0
  • V

    camper schrieb:

    Hast du mal nachgefragt, was ein "unbestimmter Zustand" sein soll, und unter welchen Umständen diese unerwünschten Nebeneffekte auftreten?

    Das ist leicht. Wie alle noch existierenden Pascaloiden Krankheiten liegt es an der Absenz von Konstruktoren und hat keine Aussagekraft für C++.

    /** guter Stil **/ 
for(int i = 0; i < 4; i++) 
{ 
  FILE* fi=fopen();
  ...mach was
  i = 4; // <- Gut 
  ...mach nochwas
  fclose(fi);
}
    0
  • D

    camper schrieb:

    Hast du mal nachgefragt, was ein "unbestimmter Zustand" sein soll, und unter welchen Umständen diese unerwünschten Nebeneffekte auftreten?

    Ich könnte Ihm ja mal zum Spass eine Mail mit der Frage senden 🙂

    0
  • D

    volkard schrieb:

    Wie alle noch existierenden Pascaloiden Krankheiten liegt es an der Absenz von Konstruktoren

    Wie bitte..? War das jetzt nur mal schnell Pascal schlecht machen? Was haben den Konstruktoren mit Schleifenbedingungen gemeinsam? Das verstehe ich nicht.

    0
  • N

    DeepCopy schrieb:

    Was haben den Konstruktoren mit Schleifenbedingungen gemeinsam? Das verstehe ich nicht.

    C-Style (keine Konstruktoren, keine Destruktoren, kein RAII)

    while (...)
{
    X* ptr = create_x();
    // ...
    continue;       // böse!
    release_x(ptr);
}

    C++ (kein Problem)

    while (...)
{
    raii_ptr<X> ptr(create_x());
    // ...
    continue;       // alles wird aufgeräumt
    // ...
}

    Aber ob es so sinnvoll war, diesen Thread nochmals auferstehen zu lassen...

    0
  • J

    Und ihr seid euch sicher, dass das wirklich an den Konstrukturen liegt und nicht vielleicht doch an den Destruktoren?

    0
  • N

    Jester schrieb:

    Und ihr seid euch sicher, dass das wirklich an den Konstrukturen liegt und nicht vielleicht doch an den Destruktoren?

    Es liegt nicht nur an den Konstruktoren, da hast du Recht. Diese sind aber ebenfalls Teil der RAII (sogar der eigentliche, wenn mans genau nimmt mit Resource Acquisition is Initialization) - das andere wäre RRID. Naja, es sollte klar sein, was volkard damit aussagen wollte, auch wenn er sich nicht ganz klar ausgedrückt hat.

    0
  • S

    EDIT: Naja - zu spät. ....

    DeepCopy schrieb:

    ...Was haben den Konstruktoren mit Schleifenbedingungen gemeinsam? Das verstehe ich nicht.

    Ich denke mal, dass er meint:
    - Die "Stilprägung" des Profs hat vermutlich vor der Etablierung von RAII (oder las "Pars pro toto": "Destruktoren") stattgefunden.
    - mit "undefiniertem Zustand" meint der Prof im Wesentlichen Situationen, die man prima mittels RAII lösen kann.

    Ich persönlich denke, dass der Prof mit "undefiniertem Zustand" nicht dasselbe meinte wie der C++-Standard, sondern eher "nicht immer den erwarteten Zustand" oder "einen Zustand, der empfindlich von vielen anderen Codestellen abhängt".
    Das ist auch der Teil, den ich bei break schwieriger zu durchschauen finde.

    Gruß,

    Simon2.

    0
  • D

    volkhard schrieb:

    existierenden Pascaloiden Krankheiten

    wenn C++ auf dem gefrickel von C aufbaut, dann ist es wohl eher eine C Destrukor Krankheit.. die man in Pascal nachbauen kann.. und dann hätte ich das auch Anhieb verstanden.

    Merci 🙂

    0
  • V

    vertippt. ich meinte die destruktoren, die fehlen und deshalb zu nicht angenehmen stilregeln führen.

    0
  • S

    Ich sehe jetzt auch nicht, was das mit Schleifen zu tun hat. In Pascal gibt's ja eh kein break -- jedenfalls nicht das Pascal, welches man vor 15 Jahren noch in der Schule lernen konnte. Kann mich aber erinnern, mal eine Schleife so abgebrochen zu haben

    for i:=1 to 10 do begin
    ...
    if ... then begin
      i:=10;  (* vorher abbrechen *)  
    end else begin
      ...
    end;
  end;

    was aber wohl ganz ganz böse ist. 😉

    Dass es im Objekt-Pascal eine Trennung zwischen Initialisieren/Deinitialisieren und Speicher anfordern/freigeben gibt, ist echt schlecht und genau das, was man mit RAII/RRID verhindert. Manuell Konstruktoren und Destruktoren (ja, die gabs auch) aufrufen? Wie öde... :p

    Ich war echt sehr positiv überrascht, als ich das RAII-Prinzip von C++ kennengelernt habe! Davor noch Java gelernt und es anfangs sehr komisch gefunden, dass es keine Destruktoren gibt.

    Gruß,
    SP

    0
  • C
    Mod

    Ich glaube mich zu erinnern, dass es bei Turbo Pascal auch break und continue gab.

    0
Anmelden zum Antworten