| Autor |
Beitrag |
zuma
      
Beiträge: 660
Erhaltene Danke: 21
Win XP, Win7, Win 8
D7 Enterprise, Delphi XE, Interbase (5 - XE)
|
Verfasst: So 06.04.08 09:20
Hidden hat folgendes geschrieben: | | Mein Lehrer meinte übrigens, dass das nicht seine Meinung wäre sondern die aller Info-Lehrer. Und, dass Breaks etc. ausschließlich von Schülern benutzt würden. |
Oh, dann bin ich ja nach 20Jahren in der Programmierung immer noch Schüler
ich nutz Break zwar auch eher selten, aber bei suche nach Performance sind die manchmal die einzige Chance,
Exit nutz ich auch gerne am beginn, wenn ich erstmal Parameter checke o.ä. Sehe da auch keine Probleme, allerdings sollte man versuchen, jede Procedure/Function wie ein eigenes Programm zu betrachten. Wenn der Aufbau der Methoden sauber ist, sind alle Befehle gültig/erlaubt/Sauber:
ein exit vor dem init von Var's ist z.b. imho unsauber, danach aber nicht unbedingt.
meine methoden machen immer* erstmal 'ihren eigenen Init',
dann werden evtl. übergebene parameter geprüft,
dann kommt erst die eigentliche Logik.
*(immer heisst natürlich: immer, wenn ich die Zeit dafür bezahlt bekomme  )
_________________ Ich habe nichts gegen Fremde. Aber diese Fremden sind nicht von hier! (Methusalix)
Warum sich Sorgen ums Leben machen? Keiner überlebts!
|
|
Hidden 
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: So 06.04.08 10:34
Hi,
Ich bin mir nicht ganz sicher, was du mit "ihren eigenen init" meinst. a) resultwert festlegen(klar) b) alle Hilfsobjekte, die während der Prozedur erzeugt werden, erzeugen: Kann ich mir nicht vorstellen, das macht doch nur unnötige Arbeit, wenn sie beim exit nicht verwendet werden und dann noch vor dem exit freigegeben werden müssen?
Mein Ansatz beim ignorieren der EAccessViolation war, eine einzelne Validitätsprüfung für jedes zu prüfende Feld zu vermeiden. Ist das falsch?
mfG,
_________________ Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)
|
|
BenBE
      
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: So 06.04.08 11:51
Sorry, aber was hier einige erzählen, konnte ja nicht mal Münchhausen so gut darstellen!
Zu den Exceptions:
Diese sollten vermieden werden, da deren Behandlung zeitaufwendig ist. Außerdem erzeugt die Behandlung von Exceptions overhead im Kernel-Mode, da das System einen Kontext-Snapshot anfertigen muss. Wenn man also allein mit Exceptions "kontrolliert" sein Programm runterfährt, mag man zwar "einen Sicheren" Zustand haben, provoziert aber u.U. genau das Gegenteil.
Nehmen wir an:
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28:
| var X: Integer;
function Foo1: Boolean; begin try Result := Foo2; except Raise Exception.Create('Foo1'); end; end;
function Foo2: Boolean; begin try Result := Foo3; except Raise Exception.Create('Foo2'); end; end;
function Foo3: Boolean; begin try Result := 42 div x = 42; except Raise Exception.Create('Foo3'); end; end; |
Dann frisst die Behandlung nicht nur im Fehlerfalle den Speicher für 3 Exception, Objekte, sondern führt MINDESTENS 2 Kontext-Wechsel aus, bei denen das "Notstandssystem" des Betriebssystem eine Kontext-Sicherung ausführt. Außerdem kommt hinzu, dass jeder dieser Except-Blöcke 2fach angesprungen wird (1. für's Handling, 2. für's Unwinding) und man damit so viel Speicher und Rechenzeit verbrät, dass man den Fehler x=0 hätte 100 mal Abfragen können. Wenn jetzt jemand kommt, Nested Exceptions fängt man ab und reicht sie mit Raise weiter: Ja, ist aber nichts andres, als das Beispiel.
Und ein weiterer Nachteil, den SEH hat, ist die Tatsache, dass selbst, wenn kein Fehler auftritt Zeit verschwendet wird, die man für sinnvolleres verwenden kann ... z.B. um die Fehler-Rahmenbedingungen zu prüfen ...
Wer also ernsthaft der Meinung ist, sein Programm mit SEH vollzupflastern, mag zwar in Software-Technik "Exceptions sind gut" verstanden haben, hat aber im Gegenzug keinen Plan, wie dieses Mittel arbeitet und sollte bitte nicht nur an der Oberfläche kratzen.
P.S.: Die Verwendung globaler Variablen in diesem Beispiel ist Absicht 
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
hansa
      
Beiträge: 3079
Erhaltene Danke: 9
|
Verfasst: So 06.04.08 12:08
Man kann für jeden Fall einen anderen Fall konstruieren, um irgendwelche Vorteile einer Methode zu verdeutlichen. Ungefähr so, wie Alzaimar das gemacht hat.  Ich überlege gerade, ob bei einem Schachspiel nicht tatsächlich ein Exit gut wäre, denn das sind ja immer genau 8x8 Felder, die behandelt werden müssen. Allgemein gilt allerdings folgendes : wer goto benutzt, der wird gesteinigt. Wer Exit benutzt, der kriegt auf die Finger gekloppt ! Bei Break wird ganz besonders gut nachgeguckt. Prinzipiell heißt es also schon : Finger weg von dem Kram. Das wird tatsächlich jeder Lehrer/Prof. sagen. Dass es Ausnahmen von der Regel gibt, das habe ich hier nicht gesagt !  Ne, das merkt man schon irgendwann selber. Anfangs hatte ich auch viele Exits benutzt. Ist ja so schön einfach. Bis dann eine tagelange Fehlersuche begann. Ergebnis : ALLE Exits rausschmeißen und neu testen. Fehler waren weg. Das war wie mit der Herdplatte und den kleinen Kindern. 
_________________ Gruß
Hansa
|
|
Hidden 
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: So 06.04.08 12:17
Hi,
Es geht nicht darum, ein Schachbrett zu durchlaufen. Es soll bestimmt werden, ob ein König im Schach steht. Dazu prüfe ich zunächst die unmittelbare Umgebung auf Springer, Bauern und den 2.König( not Schach(Stellung) ist validationsbedingung für "Zug möglich", daher dies auch, obwohl defakto kein König an den anderen herankommt).
Nachdem ich auf diese Möglichkeiten geprüft habe, gehe ich in alle 8 Richtungen die Reihen vom König ab durch und prüfe auf Schachgeber(Dame, Turm, Läufer). Wenn dir etwas besseres dazu einfällt, kannst du es dir aufheben, da ich die Logik-Unit wahrscheinlich in der entsprechenden Open-Source-Sparte posten werde  .
Edit: Danke, BenBe! ich werde den try-Block durch eine Validitätsprüfung ersetzen. oder ist es besser, das Schachbrett größer zu machen und mit nil zu füllen?
Die Exits lasse ich erstmal. Da dürft ihr dann beim o.e. Posting drauf rumhacken
mfG,
_________________ Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)
|
|
alzaimar
      
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: So 06.04.08 12:45
BenBE hat folgendes geschrieben: | Und ein weiterer Nachteil, den SEH hat, ist die Tatsache, dass selbst, wenn kein Fehler auftritt Zeit verschwendet wird, die man für sinnvolleres verwenden kann ... z.B. um die Fehler-Rahmenbedingungen zu prüfen ...
|
Du meinst also, ich soll prüfen, ob (wie in meinem Beispiel) eine Verbindung zustande kommen kann, anstatt eventuell eine Exception abzufangen? Was soll ich denn dann prüfen? Ich weiss doch gar nicht, was für eine Verbindung das ist? Und die Verbindung selbst macht das ja und meldet sich bei mir über Exceptions. So macht man das nun mal und so ist es auch richtg.
Im 'Kleinen', also bei einfachen Dingen wie z.B. der Prüfung der Arraygrenzen, kommt es auf Performance an und es ist auch sinnvoller, hier direkt zu prüfen, als den Karren blind gegen die Wand fahren zu lassen. Das ist nicht nur hirnrissig, sondern kostet auch gewaltig an Performance, wie Du schon erwähnt hast.
BenBE hat folgendes geschrieben: |
Wer also ernsthaft der Meinung ist, sein Programm mit SEH vollzupflastern, mag zwar in Software-Technik "Exceptions sind gut" verstanden
haben, hat aber im Gegenzug keinen Plan, wie dieses Mittel arbeitet und sollte bitte nicht nur an der Oberfläche kratzen. |
Nun ist es so, das größere Systeme nun mal "à la Softwaretechnik" implementiert werden müssen, um eben überhaupt den Überblick zu erhalten. Da sind Performanceüberlegungen zweitrangig.
Letztendlich muss alles mit Bedacht und Fingerspitzengefühl verwendet werden, nach dem Motto: "So viel wie nötig, aber so wenig wie möglich". Das gilt für Exceptions genauso wie für obskure Programmsprünge, Objekte, eben Alles, was in so einem Programm drinsteckt.
Hier pauschal von 'Exit', 'Exceptions' oder so abzuraten ist genauso falsch, wie zu behaupten, das man die Finger vom Auto lassen soll, weil neulich mal einer umgefahren wurde.
hansa hat folgendes geschrieben: | Man kann für jeden Fall einen anderen Fall konstruieren, um irgendwelche Vorteile einer Methode zu verdeutlichen. Ungefähr so, wie Alzaimar das gemacht hat.  |
Zeig mal ein Beispiel, in dem die Verwendung von Rückgabeparametern übersichtlicher und in der Benutzung auch sicherer ist, als mit Exceptions. Das würde mich interessieren.
hansa hat folgendes geschrieben: | | Allgemein gilt allerdings folgendes : wer goto benutzt, der wird gesteinigt. Wer Exit benutzt, der kriegt auf die Finger gekloppt! |
Das kann man unterschreiben, aber nur weil das 'Allgemein gilt allerdings...' davor steht. Denn im *Einzelfall* ist alles erlaubt.
_________________ Na denn, dann. Bis dann, denn.
|
|
hansa
      
Beiträge: 3079
Erhaltene Danke: 9
|
Verfasst: So 06.04.08 12:58
alzaimar hat folgendes geschrieben: | | ..Denn im *Einzelfall* ist alles erlaubt. |
Goto aber nicht.  Das gibts nur, weil den Basic/Cobol-Programmierern die letzte Ausrede für einen Wechsel zu Pascal genommen werden musste. Gerne wurde es allerdings nicht eingebaut. Goto passt zu Pascal, wie die Faust aufs Auge.
P.S.: zu Exceptions habe ich nichts gesagt. Da halte ich mich raus. 
_________________ Gruß
Hansa
|
|
BenBE
      
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: So 06.04.08 14:37
alzaimar hat folgendes geschrieben: | hansa hat folgendes geschrieben: | Man kann für jeden Fall einen anderen Fall konstruieren, um irgendwelche Vorteile einer Methode zu verdeutlichen. Ungefähr so, wie Alzaimar das gemacht hat.  |
Zeig mal ein Beispiel, in dem die Verwendung von Rückgabeparametern übersichtlicher und in der Benutzung auch sicherer ist, als mit Exceptions. Das würde mich interessieren. |
Z.B. die WinAPI (Ich weiß, nicht grad ein Meisterstück in saubrer Programmierung). Was mein ich da speziell: Wenn man von einer API-Funktion einen String haben will, muss man der WinAPI sagen, wo dieser hin soll und wieviel Platz sie dafür hat. Die WinAPI passt dann den übergebenen Puffer an, so dass in diesem der String enthalten ist und gibt als Return-Wert die !BENÖTIGTE! Menge an Speicher aus. Tritt ein Fehler auf, so wird ein definierter Wert zurückgegeben, auf den man Prüfen kann und hat dann die Möglichkeit, die genaue Ursache an andrer Stelle zu erfragen.
Ohne Rückgabe-Parameter würde man hier 20 Funktionen haben, die haufenweise Code-Doppelung hätten und bringen würde es im Endeffekt nicht viel. Nachteilig ist zwar bei dieser Art und Weise, dass man eine API 2-mal aufrufen muss; wenn man aber ausreichende Puffer von Vornherein übergibt, kann in den meisten Fällen der zweite Aufruf durchaus entfallen.
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
dummzeuch
      
Beiträge: 593
Erhaltene Danke: 5
Delphi 5 ent, Delphi 6 bis Delphi XE8 pro
|
Verfasst: So 06.04.08 15:45
Hidden hat folgendes geschrieben: |
Edit2: Mein Lehrer meinte übrigens, dass das nicht seine Meinung wäre sondern die aller Info-Lehrer. Und, dass Breaks etc. ausschließlich von Schülern benutzt würden.
|
Was willst Du eigentlich erreichen? Deinen Lehrer vor der Klasse blossstellen? Das hilft weder Dir noch ihm noch der Klasse.
Er macht seinen Job und dazu gehoert es Euch die Grundlagen der Programmierung beizubringen. Hinterher seid Ihr keine ausgebildeten Programmierer und schon gar keine Experten sondern wisst nur ungefaehr, wie man es macht. Und sein Hinweis, dass man Goto, Exit und Break (in Pascal, denn in C muss man in Case-Statements Break verwenden) vermeiden sollte, ist im Prinzip korrekt. Wer sich darueber im Klaren ist, dass er etwas "verbotenes" tut, ueberlegt es sich mehrmals, ob es nicht einen anderen - besseren Weg gibt.
Wenn der Sinn des Unterrichts waere, Euch zu Programmierern zu machen, die sofort bei der naechsten Softwareklitsche anfangen koennen, dann wuerde auch nicht Delphi gelehrt sondern Java oder C#. Damit will ich definitiv nicht behaupten, dass man mit Delphi keine "richtigen" Programme schreiben kann, schliesslich verdiene ich damit seit Jahren mein Geld. Allerdings sind die Jobs als Delphi-Entwickler relativ duenn gesaeht. Als Anfaengersprache ist Delphi (bzw. das ihm zugrunde liegende Pascal) sehr gut geeignet. Wer die Grundlagen verstanden hat, sollte keine Problem haben, sie auf andere Programmiersprachen zu uebertragen. Wer das nicht schafft, sollte von einer Karriere als Programmierer Abstand nehmen.
Nochmal konkret zu der Aussage Deines Lehrers:
Wenn er das obige wirklich so behauptet hat, so liegt er falsch. Ich bin schon laenger kein Schueler und auch kein Student mehr sondern arbeite seit ueber 10 Jahren als Softwareentwickler. Ich halte mich zwar nicht fuer der Welt besten Programmierer, aber wuerde mich durchaus zum oberen Drittel zaehlen ;-)
Ich habe in dieser Zeit mehrfach Gotos verwendet, allerdings in nur wenigen Ausnahmefaellen, denn in den meisten Faellen machen sie den Quellcode schlechter verstaendlich und sind in Pascal auch umstaendlich zu benutzen, weil man ja die Labels vorher deklarieren muss (und das ist gut so!).
Break und Exit benutze ich haeufiger, naemlich immer dann, wenn sie die Verstaendlichkeit des Sourcecodes verbessern. Ich empfehle uebrigens ein Tool wie Castalia einzusetzen, welches Exits und Breaks im Code hervorhebt, so dass man sie nicht so leicht uebersieht. Ausserdem sollte man sie aus demselben Grund alleine in eine Zeile schreiben.
Es ist aber definitiv kein Fehler, wenn man weiss, wie man diese Konstrukte vermeidet, denn evtl. spaetere Programmaenderungen koennen dazu fuehren, dass man sie durch eine fuer den neuen Zweck besser geeignete Konstruktion ersetzen muss. Das muss uebrigens nicht immer ein weiterer Begin-End Block sein, haeufig ist ein Prozedur- oder Funktionsaufruf sinnvoller, denn im gegensatz zu einem einfachen Begin-End hat dieser einen Namen, den man natuerlich so waehlen sollte, dass man auch zwei Jahre spaeter noch versteht, was sie macht.
Zum Thema Performance von for vs. while: Computerleistung ist billig und wird seit Jahren billiger. Programmiererzeit ist teuer. Schlecht verstaendlicher Sourcecode kostet Programmiererzeit, wenig optimierter Code kostet Computerzeit. Wenn man das beruecksichtigt, wie wichtig ist es dann, ob eine For-Schleife gegenueber einer While-Schleife evtl. 10 Prozessorzyklen einspart?
Nur in wenigen Faellen lohnt es sich, ueber Optimierungen ueberhaupt nachzudenken, naemlich dann, wenn man feststellt, dass das Programm zu langsam ist. Und dann sollte man ueberpruefen, wo denn der Flaschenhals wirklich ist, denn meist sind das Festplattenzugriffe und nicht ineffizienter Code.
twm
|
|
alzaimar
      
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: So 06.04.08 16:36
hansa hat folgendes geschrieben: | alzaimar hat folgendes geschrieben: | | ..Denn im *Einzelfall* ist alles erlaubt. |
Goto aber nicht. |
Doch, wenn es klar verständlich ist.
Delphi-Quelltext 1: 2: 3: 4: 5: 6:
| While SomeCondition Do While AnotherCondition Do While FinalCondition Do If StopAllLoops Then Goto EndLoops;
EndLoops: ... |
Man sieht sofort das Sprungziel und erkennt, das man sich sonst einen abbrechen müsste. Das ist übersichtlich und sauber, aber natürlich durch eine lokale Prozedur mit Exit zu ersetzen...
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12:
| Procedure... Procedure _DoTheLoop; Begin While SomeCondition Do While AnotherCondition Do While FinalCondition Do If StopAllLoops Then Exit; End;
Begin _DoTheLoop; ... |
Ich pflichte Dir aber bei, das man das Goto auch abschaffen könnte.
@BenBE: Wollt' grad noch sagen: Aber nicht die Win-API  ... Dein Beispiel hat aber nix mit Exceptions zu tun, sondern mit Kommunikation. Das ist in Ordnung (für die Win-API), obwohl es wirklich ziemlich umständlich ist. Ein etwas anderes Alloziierungskonzept wäre hier einfacher und robuster. Aber das ist Ansichtssache.
Ich behaupte immer noch, das Exceptions ab zwei aufbauenden Aufrufen IMMER übersichtlicher sind, als Rückgabewerte.
_________________ Na denn, dann. Bis dann, denn.
|
|
Hidden 
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: So 06.04.08 16:37
dummzeuch hat folgendes geschrieben: | Hidden hat folgendes geschrieben: |
Edit2: Mein Lehrer meinte übrigens, dass das nicht seine Meinung wäre sondern die aller Info-Lehrer. Und, dass Breaks etc. ausschließlich von Schülern benutzt würden.
|
Was willst Du eigentlich erreichen? Deinen Lehrer vor der Klasse blossstellen? Das hilft weder Dir noch ihm noch der Klasse.
Er macht seinen Job und dazu gehoert es Euch die Grundlagen der Programmierung beizubringen. Hinterher seid Ihr keine ausgebildeten Programmierer und schon gar keine Experten sondern wisst nur ungefaehr, wie man es macht. Und sein Hinweis, dass man Goto, Exit und Break (in Pascal, denn in C muss man in Case-Statements Break verwenden) vermeiden sollte, ist im Prinzip korrekt. Wer sich darueber im Klaren ist, dass er etwas "verbotenes" tut, ueberlegt es sich mehrmals, ob es nicht einen anderen - besseren Weg gibt.
|
Hi,
Ersteinmal danke für deinen langen Beitrag  . Meinen Lehrer bloßstellen will ich ganz bestimmt nicht. Dass breaks, etc., im Unterricht, zumindest von mir, nichtmehr verwendet werden, steht für mich außer Frage. Nur interessierte mich natürlich, wo denn da ein Sicherheitsfehler liegen könnte, da auch ich der Meinung war, dass diese vom Compiler sowieso verwendet werden...
mfG,
_________________ Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)
|
|
Yogu
      
Beiträge: 2598
Erhaltene Danke: 156
Ubuntu 13.04, Win 7
C# (VS 2013)
|
Verfasst: So 06.04.08 16:57
alzaimar hat folgendes geschrieben: | [...] aber natürlich durch eine lokale Prozedur mit Exit zu ersetzen...
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12:
| Procedure... Procedure _DoTheLoop; Begin While SomeCondition Do While AnotherCondition Do While FinalCondition Do If StopAllLoops Then Exit; End;
Begin _DoTheLoop; ... | |
Warum nicht mit Break? Exit dürfte doch wohl kaum besser sein als Break.
Delphi-Quelltext 1: 2: 3: 4:
| while SomeCondition do while AnotherCondition do while FinalCondition do if StopAllLoops then Break; |
|
|
Hidden 
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: So 06.04.08 17:05
_________________ Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)
|
|
alzaimar
      
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: So 06.04.08 17:24
Preisfrage:
Beim Goto kann ich die Diskussion noch nachvollziehen, beim Break... nun ja, ich finds praktisch, aber das man nun auch das exit verteufelt, also das geht zu weit. Wo iss'n der Unterschied zwischen einem Exit und einem (C#, C, C++, Java) Return? Normalerweise argumentiere ich ja nicht so ("Leute! Fresst sche****! 1 Mio Fliegen können nicht irren"), aber wenn alle modernen Programmiersprachen das 'Break', 'Continue' und 'Exit/Return' unterstützen, wieso soll das dann so schrecklich sein?
Der Lehrer mit dem Sicherheitsrisiko ist ein typischer Vertreter der Lehrkräfte, die den Schülern IT 'beibringen'. Daran hat sich seit 30 Jahren nichts geändert (damals hatte ich das Vergnügen, einem Informatiklehrer erklären zu müssen, wie man richtig kodiert).
_________________ Na denn, dann. Bis dann, denn.
|
|
dummzeuch
      
Beiträge: 593
Erhaltene Danke: 5
Delphi 5 ent, Delphi 6 bis Delphi XE8 pro
|
Verfasst: So 06.04.08 17:48
alzaimar hat folgendes geschrieben: |
Wo iss'n der Unterschied zwischen einem Exit und einem (C#, C, C++, Java) Return? Normalerweise argumentiere ich ja nicht so ("Leute! Fresst sche****! 1 Mio Fliegen können nicht irren"), aber wenn alle modernen Programmiersprachen das 'Break', 'Continue' und 'Exit/Return' unterstützen, wieso soll das dann so schrecklich sein?
|
Es gibt einen Unterschied zwischen "ist moeglich" und "ist eine gute Idee". Die Aufgabe eines Lehrers ist es, den Schuelern beizubringen, was man machen sollte und was man vermeiden sollte (und moeglichst auch, warum). Mit Exit kann man definitv auch viel Bloedsinn anstellen. Es deswegen komplett zu verteufeln halte ich allerdings auch fuer uebertrieben.
| Zitat: |
Der Lehrer mit dem Sicherheitsrisiko ist ein typischer Vertreter der Lehrkräfte, die den Schülern IT 'beibringen'. Daran hat sich seit 30 Jahren nichts geändert (damals hatte ich das Vergnügen, einem Informatiklehrer erklären zu müssen, wie man richtig kodiert). |
Was, vor 30 Jahren (1978) hattest Du schon Informatikunterricht? In "meiner" Schule wurde der erst eingefuehrt, nachdem ich Abi gemacht hatte (1985). Naja, war vielleicht auch gut so. Vielleicht haette mir sonst ein schlechter Lehrer den Spass daran verdorben und ich haette was anstaendiges gelernt...
twm
|
|
alzaimar
      
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: So 06.04.08 17:52
dummzeuch hat folgendes geschrieben: | Es gibt einen Unterschied zwischen "ist moeglich" und "ist eine gute Idee". Die Aufgabe eines Lehrers ist es, den Schuelern beizubringen, was man machen sollte und was man vermeiden sollte (und moeglichst auch, warum). Mit Exit kann man definitv auch viel Bloedsinn anstellen. Es deswegen komplett zu verteufeln halte ich allerdings auch fuer uebertrieben.
|
Das lassen wir mal als Zusammenfassung so stehen.
_________________ Na denn, dann. Bis dann, denn.
|
|
Hidden 
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: Mo 07.04.08 19:41
_________________ Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)
|
|
BenBE
      
Beiträge: 8721
Erhaltene Danke: 191
Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
|
Verfasst: Mo 07.04.08 19:43
Break breakt nur die letzte (innerste) Schleife.
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
|
|
Yogu
      
Beiträge: 2598
Erhaltene Danke: 156
Ubuntu 13.04, Win 7
C# (VS 2013)
|
Verfasst: Mo 07.04.08 19:53
Hidden hat folgendes geschrieben: | | [quoBreak breakt doch nur die letzte Schleife und nicht alle, oder? |
Ja. War mein Denkfehler, sorry. 
|
|
Strike Eagle
Hält's aus hier
Beiträge: 8
|
Verfasst: Do 10.04.08 16:35
hansa hat folgendes geschrieben: | alzaimar hat folgendes geschrieben: | | ..Denn im *Einzelfall* ist alles erlaubt. |
Goto aber nicht.  |
Wenn ich dir einen Teil eines Codes von mir vorsetzen würde, würdest du das revidieren. Zwei Gotos waren das einzige, das ohne größeren Aufwand und noch viel mehr Unübersichtlichkeit praktikabel funktionierte (Sprache: C#)!
Wobei ich nicht verstehe, wieso ihr da so einen großen Terz drum macht, ist ja fast schon episch hier.  Im PC intern geht es doch sowieso nur so. Und wenn ich manchen Code so sehe, wie gekünstelt es sit mit einer while-Schleife zu arbeiten und zum vorzeitigen Abbruch den Zähler hochzustellen, ne da bekommt man das kalte Grausen. Der Code ging von 170 auf knapp über 100 Zeilen runter, nachdem ich damit fertig war. Übersicht? Jawohl!
Es gibt auch noch Break label, das springt dann aus mehreren raus. (OK, war glaube ich nur in Java so, ist halt der Ersatz fürn goto)
|
|
|