5 Programmteile, Erklärung gesucht, bitte.

[p80286]

@nahpets
:thumb: Textverständnis gut.
Wobei trotzdem interessant wäre in welcher Sprache

Delphi-Quellcode:

For ik:= 1 to i+3 do
begin
 writeln("abc"); i:=i+1;
end;

realisiert werden soll.

a) Der Endpunkt der Schleife i+3 wird vor dem Eintritt in die Schleife festgelegt, dann läuft sie von 1 bis i+3
b) Das erreichen des Endpunktes wird nach jedem Schleifendurchlauf überprüft, dann hast Du einen Käfer er läuft und läuft und läuft und ....

Gruß
K-H

[a.def]

Oder der Delphi-Fan ("Lehrer") denkt sich, der Code funktioniert schon so wie er da steht und weiß von dem gecache nichts.

[p80286]

Es kommt darauf an wie die Schleife im Assembler umgesetzt wird

Code:

i:=5;               mov ebx,$0005
for ik:=0 to i+3 do lea eax,[ebx+$03]
                    test eax,eax
                    jl +$05
                    inc eax
inc(i,1);           inc ebx 
                    dec eax
                    jnz -$04

Da wird nichts gecached.

Gruß
K-H

[a.def]

Nachdem was hier alles besprochen wurde und auch gesagt wurde, dass das alles nur ein Gedankenexperiment ist finde ich, dass die von diesem Delphi-Fan-Lehrer gestellte Aufgabe weder für ein Gedankenexperiment noch zum Lernen gut ist.
Allein schon diese Schleife bietet zu viele Interpreationsmöglichkeiten weil eben noch zu viele Frage offen sind.
Das würde alles nicht passieren, wenn die Schleife klarer und praxisnaher formuliert wäre.

Nur meine Meinung.

[nahpets]

Zitat:

Zitat von a.def (Beitrag 1359578)

Oder der Delphi-Fan ("Lehrer") denkt sich, der Code funktioniert schon so wie er da steht und weiß von dem gecache nichts.

Ich formuliere es mal etwas dreist:

So doof, wie Du das Lehrpersonal hinstellst, ist es nun wirklich nicht. Habe mich im Laufe meines Lebens öfter mal damit rumschlagen müssen.

Es geht immer um das abstrakte Lernen und nicht um die konkrete Umsetzung.

Für 'ne Klausur könnte der Prof. / Lehrer auch 'ne eigene Phantasiesprache wählen. Wesentlich ist nur, dass abstrakte Gedanken und Formalitäten klar abgebildet werden.

Wenn das oft wie Pascal/Delphi aussieht ist das ein Nebeneffekt, aber für die Lösung der Aufgabe nicht wesentlich.

Klar ist es hilfreich, wenn man das Programmieren mit 'ner Entwicklungsumgebung lernt, aber es geht auch ohne. Und in Klausuren muss man die Aufgaben auch ohne Entwicklungsumgebung lösen können, da hat man nur Papier und Bleistift/Kugelschreiber/Füller.

@p80286
a) wird von Delphi genommen
Pascal-Script von RemObjekt, dass man gut in Delphiprogramme einbinden kann, nutzt Variante b). Hab's eben extra ausprobiert.

@a.def:
Die Aufgabenstellungen sind alle so, dass man da nachdenken muss, um zu verstehen, was da passiert. Es geht nicht darum, dass man das irgendwie mit Delphi kompilieren oder gar sinnvoll nutzen kann.

Und einige der Aufgaben enthalten gravierende Fehler. Und Aufgabe ist es, diese gravierenden Fehler zu erkennen und zu benennen.

Hier

Delphi-Quellcode:

For ik:= 1 to i+3 do
begin
 writeln("abc"); i:=i+1;
end;

heißt die Antwort also sinngemäß.

Da i im Laufe der Schleife permanent erhöht wird, wird das Ende der Schleife nie erreicht.

[a.def]

Brauchst mir das nicht erklären, keine Sorge. Papier und Kugelschreiber während mehrstündiger Klausuren waren vor vielen Jahren meine besten Freunde. Da hat man nicht selten viele seiten lange Algorithmen auf Papier gezeichnet.

Klar, es geht darum, dass man um die Ecke denkt absolut keine Frage. Aber ich finde, ein Lehrpersonal sollte dennoch realistisch bleiben und sich nicht irgendetwas aus den Fingern saugen.

Zitat:

Und Aufgabe ist es, diese gravierenden Fehler zu erkennen und zu benennen.

Das steht doch nirgendwo als Aufgabenstellung.

Das ist das Problem mit vielen Lehrern. Wenn man bei manchen Dingen schreibt, dass Fehler XY auftritt und das Programm nie beendet wird, fühlen sich viele verletzt und geben aus trotz keine Punkte.
Ist mir schon mal passiert bei einer staatlichen Schule. Danach habe ich solche Vereine abgeschrieben und nur noch private IT-Schulen besucht.

[nahpets]

Eigentlich finde ich die Aufgaben garnicht so schlecht. Zeigt doch die Diskussion hier (und auch in dem anderen Thread zu diesen Aufgaben), dass es garnicht so einfach ist, da mal eben zu 'ner Lösung zu kommen.

Wer bei diesen Aufgaben zu richtigen Lösungen kommt, hat damit gezeigt, dass er auch Dummfug noch logisch analysieren kann und daraus sinnvolle Schlüsse ziehen und die Konsequenzen ableiten kann.

Eigentlich ist es nix anderes, als das komprimierte reale Leben für 'nen Entwickler ;-)

Wer hat nicht schon ähnlich konfuse, fachliche Vorgaben bekommen und sollte dann daraus was logisches und richtig funktionierendes programmieren? ;-)

[linomail]

:thumb: hat mir aber ne menge gebracht, diese Diskussion:)

[Delphi-Laie]

Zitat:

Zitat von a.def (Beitrag 1359555)

[..] Prof [..]

Der scheint mir wirklich nur ein "Fan" zu sein und kein "Kenner" oder ähnliches.

Er muß auch kein Kenner sein. Informatiker sind i.d.R. keine Programmierer!

Zitat:

Zitat von a.def (Beitrag 1359555)

Vielleicht ließt er das hier ja mit?

Jo, der hat ja auch nichts anderes zu tun.

Ein Professor ist oft genug auch nach Feierabend und am Wochenende beschäftigt, und sei es nur geistig-intellektuell. Für den gibt es keine schönere Entspannung, keinen schöneren Zeitvertreib, nachdem er Sonnabendabend mit seiner Arbeitswoche endlich abgeschlossen hat (oder auch nicht), in einem Programmierforum zu "leßen" / schmökern / stöbern, was seine Schützlinge so treiben. Wer glaubt so etwas ernsthaft?

Ergänzung: Schließt man die Zeit ein, in der ein Professor sich mit seiner Materie auch nur mental beschäftigt, kommt er - grob über den Daumen gepeilt - auf das Doppelte einer normalen Arbeitswoche. Diese Belastung ist hoch, aber sog. "positiver Streß", denn sein Gebiet ist normalerweise sein Interesse, sein Steckenpferd, und deshalb macht das ein Professor gern.