Immer noch arbeite ich an und mit einem DOS-Programm, erstellt mit Turbo-Pascal 7.0. (Leider kenne ich nichts, was eine Umstellung auf Windows (Delphi) halbwegs automatisch ermöglicht.)
Auf meinem neuen Computer (Windows XP Prof.) stelle ich nun fest, dass Sortier-Ergebnisse, Ablauf mit denselben Daten auf demselben Weg, von einander abweichen: Mal sind sie in Ordnung, mal ist die Sortierung fehlerhaft. Kann die Ursache dafür sein, dass der Computer wegen seiner höheren Geschwindigkeit die Ursache dafür ist? Wenn ja: Wie kann ich diese für DOS-Programme drosseln? Oder wo kann die Ursache sonst liegen?
Für Hilfe wäre ich sehr dankbar.
Programmieren - alles kontrollieren 4.934 Themen, 20.613 Beiträge
Hallo Andreas42 und Andere,
das Problem scheint erledigt: Wie so oft, saß es vor dem Bildschirm, zumindest zum Teil. Einiges ist aber dazu noch zu sagen und zu fragen.
Eine Frage zuerst:
Wie kann ich bewirken, dass Zitate wie bei Dir farbig unterlegt auf den Bildschirm kommen? Ich kenne für Übernommenes nur aus meinem E-Mail-Programm Pegasus Mail die Häkchen > vor der Zeile.
>> Diese Funktion ist eine von elf ähnlichen .....
> Das ist C-Programmierstil. ;-)
> Ich hätte dazu eine Objektstruktur erstellt .....
Als Turbo Pascal in irgend einer früheren Version die objektorientierte Programmierung ermöglichte, habe ich diese zunächst in einem Fall angewandt. Dabei ist herausgekommen, dass die TPU der Unit danach wesentlich größer war als vorher. Da mein Programm auf eine 1,4-MByte-Diskette passen sollte, bin ich dann bei der prozeduralen Programmierung geblieben. Objekte finden sich nur in Programmteilen, die ich wie die Baum-Sortierung aus anderen Quellen übernommen habe.
> Ich vermeide einfach Typkonvertierungen und untypisierte Pointer, soweit ich das kann. Diese IMHO C-typischen Operationen waren mir nie ganz geheuer. Ich finde, da verliert man zu schnell bei Änderungen die interne Datenintegrität.
Bisher bin ich eigentlich mit meinem "ohne" gut zurecht gekommen.
> Die Funktion musste ich mir etwas anders Formatieren, damit ich den Ablauf verstehe. Vermutlich fehlen Ungleichs im Quelltext, weil Nickles.de die gefiltert hat. (Kommentare sind von mir.)
.....
> pv : ^t_objekt; {das ist jetzt ein Objekt und nicht pointer? inhalt ist auch so deklariert?}
interface
type p_baum_u = pointer; {die Baumstruktur}
FuncKlein = function (p1, p2: pointer): boolean;
implementation
type t_objekt = array [0 .. maxint] of byte; {Sortier-Objekt}
pKnoten = ^vKnoten;
vKnoten = record
left, right, back : pKnoten;
size : integer;
inhalt : ^t_objekt;
end;
> procedure NewNode (var B_neu: pKnoten; last: p_baum_u); {wieso ist last nicht vom Typ pKnoten? Unten wird da pk2 zugewiesen.}
Wohl weil p_baum_u global verwendet wird, pKnoten aber nur lokal.
> var pk1 : pKnoten;
> begin
> if MaxAvail 1 then Exit;
Die letzte dieser Zeilen muss lauten:
if MaxAvail 1 then Exit;
> .....
> begin {InsVar}
> pk1 := pKnoten (baum5); pk2 := pk1; pv := @v0; okay9 := 0;
> while pk1 nil do {schluckt Nickles.de hier das ungleich?}
Jedenfalls gehört's hinein.
> with pk1^ do begin
> pk2 := pk1; {aktueller Node in pk2 speichern}
> {im aktuellen Element bestimmen, ob der neue Node Links oder Rechts eingefügt werden muss.}
> .....
Ja, so ist's.
> NewNode (pk1, pk2);
> if okay9 > 1 then Exit;
> if pk2 nil then
Auch hier fehlte das Ungleich.
> Baum5 scheint ein Zeiger auf den ersten Node der Baumstruktur zu sein, wird mit einem Wert vom Typ pknoten belegt, ist aber vom Typ p_baum_u.
Siehe oben type.
> Durch die Analyse der Funktion habe ich verstanden, wie dein Sortieren funktioniert. Du baust einen sortierten Baum auf. OK. Grundsätzlich funktioniert das und obwohl ich die ganze Typenbehandlung in deinen Sourcen nicht mag ;-) , kann ich keinen Grund finden, warum die Routine falsch arbeiten sollte.
> Der Baum muss aber noch ausgegeben werden. Vielleicht liegt das Problem an der Stelle. Wie wird die Liste der gespeicherten daten aus dem Baum ausgelesen?
Die hoffentlich nicht nur vorläufige und eingangs erwähnte Lösung:
Das Problem trat auf beim Arbeiten in der Turbo-Pascal-Entwicklungsumgebung. Beim weiteren Untersuchen für diese heutige Antwort stieß ich darauf, dass bei jedem neuen Programmstart nur beim ersten Durchlauf falsch sortiert wurde - jedes Mal gleich falsch -, beim nächsten aber nicht. Damit war die Rekonstruktion möglich und das Finden der Ursache: Die "Urdatei" wurde als ordnungsgemäß alfabetisch nach den Teilnehmerkürzeln geordnet angesehen und behandelt. Ein Teilnehmer war aber anstatt in der Mitte erst am Ende gespeichert. Mit seinem Platzindex 82 wurde dann aus der umsortierten Teilnehmerliste der richtig alfabetisch letzte Teilnehmer in die Mitte eingefügt.
Leider habe ich das erst im Zuge des oben Geschilderten gefunden. Jedenfalls danke ich Dir und allen anderen Ratgebern für die Unterstützung.
Beste Grüße