5 Programmteile, Erklärung gesucht, bitte.

[nahpets]

Zitat:

Zitat von linomail (Beitrag 1359550)

-die Schleifen FOR/Repeat/While und die If Statements
-fehlerhafte Programmteile erkennen

Mir scheinen diese beiden Punkte in den Aufgabenstellungen wohl wesentlich zu sein.

[linomail]

Ja gut, ich sagte ja nicht das ich das 100% beherrsche das Fehlersuchen :D

Ja programmieren ist nicht so meine Stärke obwohl mich das ziemlich interessiert naja ich denke wenn ich weiter am ball bleibe wird das schon was :thumb:

[a.def]

Lern am besten privat und sauge das von deinem Prof nur so nebenbei auf.
Der scheint mir wirklich nur ein "Fan" zu sein und kein "Kenner" oder ähnliches.

Vielleicht ließt er das hier ja mit?

[linomail]

@nahpets ja denke ich auch. Danke dass du soviel geduld mit mir hattest bei den AUfgaben :D:-D

[linomail]

Haha ja vill :D

[himitsu]

Zitat:

Zitat von Luckie (Beitrag 1359511)

Zitat:

Soweit ich weiß ist das sogar eine Totsünde die Iterations-Variable einer For-Schleife selber hochzuzählen.

Geht das überhaupt so einfach? Ich meine nämlich das geht nur mit erheblichen Klimmzügen.

Und selbstmordgefährdet, denn wenn dabei das Schleifenende übersprungen wird, dann stoppt es da nicht. (kein >= im Abbruch, sondern ein =)

Eigentlich nur einmal böse rumpointern (referenzieren und dereferenzieren) und damit die Codeprüfung umgehen.

[nahpets]

Ihr solltet bei solchen Aufgaben bitte bedenken:

Es geht nicht um die mögliche Programmierung mit einer konkreten Entwicklungsumgebung, sondern ausschließlich um das Verständnis dessen, was dort als Quelltextfragment vorgegeben ist.

Keines der Beispiele muss auch nur ansatzweise kompilierbar sein.
Es handelt sich ausschließlich um Gedankenexperimente und die Prüfung, ob die Lernenden in der Lage sind, das Geschriebene zu verstehen.

Statt

Delphi-Quellcode:

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

könnte da auch sowas stehen:

Delphi-Quellcode:

für ik von 1 bis i + 3 
wiederhole
  Schreibe("abc"); 
  i := i + 1;

Die Frage lautet nun: Was passiert im folgenden Programmteil?

Welche Antwort gebt ihr nun in der ersten Version und welche in der Zweiten?

[himitsu]

Oder anders gesagt "es soll nicht kompilieren, sonst könnten die es einfach ausführen, ohne nachzudenken" :lol:

[nahpets]

Zitat:

Zitat von himitsu (Beitrag 1359574)

Oder anders gesagt "es soll nicht kompilieren, sonst könnten die es einfach ausführen, ohne nachzudenken" :lol:

Ja, durchaus.

Die Leute sollen sich ganz konkrete Gedanken machen. Nur kompilieren und geht, reicht nicht zum Lernen.

[himitsu]

Zitat:

Zitat von nahpets (Beitrag 1359575)

Die Leute sollen sich ganz konkrete Gedanken machen. Nur kompilieren und geht, reicht nicht zum Lernen.

Wobei das ja schon ein bissl gemein ist.

Zitat:

Delphi-Quellcode:

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

Erstmal ist i nicht initialisiert, oder jemand hat nur die Hälfte gezeigt.
Und dann macht die Schleife nicht das, was Viele vielleicht denken würden, denn Pascal/Delphi berechnet den Endwert zu Beginn, cached das und "irgnoriert" somit Änderungen.
In den For-Schleifen von C-Sprachen ist das anders.

[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.