Speicherverbrauch bei langer if...then-Liste

[Sel2012]

Ich habe keine Ahnung, wie rechnerintern Speicherplatz für if...then verwendet wird.
Bei ca. 60 if...then-Zeilen habe ich keine Probleme. Bei längeren "Listen" kommt die
Zuordnung außer Tritt. Wahrscheinlich müsste der Speicherbedarf vorstrukturiert werden, oder?

Siehe Beispiel.

Delphi-Quellcode:

// Zufallswort wird ausgesucht   

wortwahl[w]:= random (maxLine)+1;
   wort[w]:= Memo1.Lines.Strings[wortwahl[w]];

// 4x das gleiche...

   wort_1.text:= wort[1];
   wort_2.text:= wort[2];
   wort_3.text:= wort[3];
   wort_4.text:= wort[4];

// davon wird ein Wort vertont

   tonwahl:=random (4) + 1;  
   suchwort:= wort[tonwahl];
   mediaPlayer1.FileName := TPath.Combine(TPath.GetDocumentsPath, (suchwort+'.mp3'));
   mediaPlayer1.Play;

{ so klappt das gut. Bei Wörtern mit Umlauten muss ich aber wegen .mp3 die Tondatei
  umbenennen. Dazu fällt mir leider nur die if..then-Variante ein. 
  Die funktioniert auch gut und stabil bis zu ca. 60 Zeilen. }

  if suchwort = 'am' then  ton2:='am';
  if suchwort = 'im' then  ton2:='im';
  if suchwort = 'Bär' then  ton2:='Baer'; 

  mediaPlayer1.FileName := TPath.Combine(TPath.GetDocumentsPath, (ton2+'.mp3'));
  mediaPlayer1.Play;

// Bei längeren if...then-Listen kommt ton2 bei einer Neuwahl von suchwort "aus dem Tritt" und der letzte ton2
// wird 1- oder 2-mal wiederholt.

[haentschman]

Moin...:P

Als erstes schreibst du uns bitte mal deine Delphi Version. :zwinker: Da können wir genauer helfen.

Das Problem hat imho nichts mit der if then Orgie zu tun. Durch die vielen Zeilen, und der damit verbundenen Unübersichtlichkeit, können sich andere Fehler einschleichen.

Tipp / eine Möglichkeit:
Die Daten z.B. Bär = Baer extern in einer INI oder Textdatei vorhalten. Diese in das Programm einlesen und in einer Liste oder Dictionary verwalten. Das erspart bei Ergänzungen das Ändern des Programmes... :zwinker:

[Daniel]

Zitat:

Zitat von Sel2012 (Beitrag 1311548)

Ich habe keine Ahnung, wie rechnerintern Speicherplatz für if...then verwendet wird.
Bei ca. 60 if...then-Zeilen habe ich keine Probleme. Bei längeren "Listen" kommt die
Zuordnung außer Tritt. Wahrscheinlich müsste der Speicherbedarf vorstrukturiert werden, oder?

Nein - es ist das menschliche Hirn, das aus dem Tritt kommt und den Code nicht mehr überblickt.
Du möchtest eine eindeutige Zuordnung schaffen zwischen Suchbegriff und Dateiname. Klassisch könnte man hier ein Dictionary verwenden. Etwas - billiger - aber auch nicht schlecht: TStringList. Auch diese bietet eine Zuordnung zwischen Name und Wert an und der kannst Du sogar sagen, was bei Duplikaten passieren soll.

Davon abgesehen, dass das IF absolut zuverlässig funktioniert, ist es die falsche Herangehensweise bei diesem Problem - weil der Code ein unwartbares Monstrum wird. Das siehst Du ja jetzt schon.

[Sel2012]

Zitat:

Zitat von haentschman (Beitrag 1311549)

Moin...:P

Als erstes schreibst du uns bitte mal deine Delphi Version. :zwinker: Da können wir genauer helfen.

Das Problem hat imho nichts mit der if then Orgie zu tun. Durch die vielen Zeilen, und der damit verbundenen Unübersichtlichkeit, können sich andere Fehler einschleichen.

Tipp / eine Möglichkeit:
Die Daten z.B. Bär = Baer extern in einer INI oder Textdatei vorhalten. Diese in das Programm einlesen und in einer Liste oder Dictionary verwalten. Das erspart bei Ergänzungen das Ändern des Programmes... :zwinker:

Ich arbeite mit XE5. Bei allen dummen Fehlern, die mir schon unterlaufen sind, kann ich hier ganz unbescheiden behaupten, dass die 100 Zeilen lange Wiederholung der immer gleichen if...then-Zeilen ausgesprochen übersichtlich ist. Die falsche Zuordnung tritt ja auch nicht regelmäßig und reproduzierbar auf, sondern mehr zufällig. Bei 3 Durchläufen passiert nix falsches, dann mal hier, mal da eine falsche (die vorherige) Zuordnung. Beim nächsten Durchlauf ist wieder alles ok. Gerade diese Unregelmäßigkeit lässt mich vermuten, dass prinzipiell kein Programmierfehler vorliegt (sonst würde sich ja ein Fehler reproduzierbar einfressen), sondern dass sich ein Speicherproblem auswirkt.
Ich kann nicht generell "Bär" zu "Baer" machen, da als Text im Label "Bär" angezeigt werden soll.

[Sel2012]

Zitat:

Zitat von Daniel (Beitrag 1311552)

Davon abgesehen, dass das IF absolut zuverlässig funktioniert, ist es die falsche Herangehensweise bei diesem Problem - weil der Code ein unwartbares Monstrum wird. Das siehst Du ja jetzt schon.

Es ist ja gerade das Rätsel, dass ich ganz einfach deine These vom "zuverlässigen IF...THEN" widerlagen kann. Die Erklärung dafür würde mich schon (theoretisch) interessieren.
Jetzt werde ich mich mal auf TStringList konzentrieren (für 2000 Suchbegriffe).

[Daniel]

Zitat:

Zitat von Sel2012 (Beitrag 1311555)

Es ist ja gerade das Rätsel, dass ich ganz einfach deine These vom "zuverlässigen IF...THEN" widerlagen kann

Ganz so einfach ist es nicht.
Stand jetzt hast Du ein fehlerhaftes Projekt - den Nachweis hast Du erst dann erbracht, wenn Deine Situation reproduzierbar wird. Und genau das ist ja nach Deiner Aussage nicht gegeben.

[haentschman]

:P

Zitat:

...kann ich hier ganz unbescheiden behaupten, dass die 100 Zeilen lange Wiederholung der immer gleichen if...then-Zeilen ausgesprochen übersichtlich ist.

...dem widerspreche ich mal spontan. :P Es liegt im Auge des Betrachters. Unbestritten ist aber das der Code bescheiden wartbar ist. :roll:

Zitat:

Ich kann nicht generell "Bär" zu "Baer" machen, da als Text im Label "Bär" angezeigt werden soll.

Sollst du ja auch nicht. Du greifst dann nur auf das Dictionary zu wenn du das Äquivalent benötigst.

Zitat:

...dass prinzipiell kein Programmierfehler vorliegt (sonst würde sich ja ein Fehler reproduzierbar einfressen), sondern dass sich ein Speicherproblem auswirkt.

Setze doch mal an alle 100 - 2000 Zuweisungen einen Breakpoint. :stupid: Da kannst du dann sehen wann und warum welcher Wert zugewiesen wird. :zwinker:

Hänge das fehlerhafte Projekt mal komplett an.

[Sel2012]

Zitat:

Zitat von Daniel (Beitrag 1311556)

Zitat:

Zitat von Sel2012 (Beitrag 1311555)

Es ist ja gerade das Rätsel, dass ich ganz einfach deine These vom "zuverlässigen IF...THEN" widerlagen kann

Ganz so einfach ist es nicht.
Stand jetzt hast Du ein fehlerhaftes Projekt - den Nachweis hast Du erst dann erbracht, wenn Deine Situation reproduzierbar wird. Und genau das ist ja nach Deiner Aussage nicht gegeben.

Ich muss nur die "Liste" der if...then-Zeilen auf 30 reduzieren und schon läuft alles tausendfach stabil. Also muss der "Fehler" in der nicht mehr ständig, sondern nur gelegentlich funktionierenden Zuordnung zum THEN liegen. Darin sehe ich kein Programmierfehler, sondern ein internes Programm-Problem.
Aber, wie schon festgestellt, wäre diese Abfrage für 2000 Wörter nicht praktikabel. Nur theoretisch wäre eine Erklärung des Phänomens interessant.

[DeddyH]

Wenn ein Programm nicht tut, was es soll, liegt das in den allermeisten Fällen an Denkfehlern des Programmierers, gefolgt von Fehlern in den verwendeten Klassen/Komponenten und nur in ganz ganz seltenen Fällen (ich schätze, weit unter 1%) an Fehlern im Compiler.

[Uwe Raabe]

Zitat:

Zitat von Sel2012 (Beitrag 1311562)

Also muss der "Fehler" in der nicht mehr ständig, sondern nur gelegentlich funktionierenden Zuordnung zum THEN liegen. Darin sehe ich kein Programmierfehler, sondern ein internes Programm-Problem.

Dann siehst du das falsch. Ein IF-THEN funktioniert unter denselben Voraussetungen entweder immer oder nie. Die Tatsache, daß es bei allen anderen immer funktioniert und nur bei dir manchmal, ist ein starkes Indiz, daß die Ursache eben nicht in Delphi liegt, sondern in dem, was du programmiert hast. Offenbar stellst du eben nicht immer dieselben Voraussetzungen sicher. Das Problem ist also mit Sicherheit kein Fehler in Delphi - und das wird dir jeder hier, der mit Delphi arbeitet, bestätigen können.

Wenn ich hier mal aus dem The Pragmatic Programmer zitieren darf:

Zitat:

Zitat von Pragmatic Software Development Tips

“select” Isn’t Broken
It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.

Leider können wir ohne den vollständigen Quelltext bzw. eine vollständige Testumgebung auch nicht sagen, was die eigentliche Ursache ist. Damit könnten wir auch noch eine weitere, wenn auch sehr unwahrscheinliche Fehlerquelle (eine defekte Hardware) ausschließen.

[hoika]

Hallo,
also beim Code sagt mir doch der Compiler "value not assigned", weil ton2 nicht initialisiert ist.

Lieber TE , du hast einen Bug produziert, sieh es einfach ein.

Also bitte mehr Code.

Wie steht es eigentlich mit einem Unit-Test?


Heiko

[Aviator]

Das liegt wohl an der Zeile:

Delphi-Quellcode:

mediaPlayer1.FileName := TPath.Combine(TPath.GetDocumentsPath, (ton2+'.mp3'));

Hier könnte es passieren, dass keine der IF-Statements greift und somit die Ausgabe ".mp3" wäre, da in ton2 nichts drin steht.

Edit: Um die Warnung zu entfernen, solltest du beim Aufruf der Procedure(?) den Wert von ton2 auf '' initialisieren.

[Helmi]

Drehen wir doch den "Delphi-"Spieß doch einfach mal um:
Zeig uns doch mal deinen kompletten Code bei dem es zu Problemen kommt und auch das Suchwort
bei dem es vermeintlich zu Differenzen in der Verarbeitung von IF..THEN kommt.

[haentschman]

@hoika:

Zitat:

Wie steht es eigentlich mit einem Unit-Test?

...da mußte ich schmunzeln. :P Offensichtlich hat der TE, ohne es abwertend zu meinen, nur Basiswissen. Meinst du nicht das das ihn überfordert?

[Helmi]

Zitat:

Zitat von Aviator (Beitrag 1311569)

Edit: Um die Warnung zu entfernen, solltest du beim Aufruf der Procedure(?) den Wert von ton2 auf '' initialisieren.

Oder mal folgendes:

Delphi-Quellcode:

ton2 := '';

  if suchwort = 'am' then ton2:='am';
   if suchwort = 'im' then ton2:='im';
   if suchwort = 'Bär' then ton2:='Baer'; 

//...jede Menge if...then´s

   If ton2 <> '' then
     begin
       mediaPlayer1.FileName := TPath.Combine(TPath.GetDocumentsPath, (ton2+'.mp3'));
       mediaPlayer1.Play;
     end;

Jetzt müssten ja "Aussetzer" zu hören sein, wenn das Suchwort nicht vorhanden ist

[Sel2012]

[QUOTE=Uwe Raabe;1311566]

Zitat:

Zitat von Sel2012 (Beitrag 1311562)

Also muss der "Fehler" in der nicht mehr ständig, sondern nur gelegentlich funktionierenden Zuordnung zum THEN liegen. Darin sehe ich kein Programmierfehler, sondern ein internes Programm-Problem.

Entwarnung?! Ich habe aus anderen Gründen den Rechner ganz neu gestartet und siehe da, das Problem ist weg.
Ich konnte mir ja auch nicht erklären, warum simple und überschaubare IF..THEN-Anweisungen zu einem nicht konstanten "Zufallsergebnis" führen sollte. Also war es doch wohl ein außerhalb von Delphi liegendes temporäres Speicherproblem des Rechners.

[stahli]

Kennst Du CodesiteLogging? XE5 hat das dabei (denke ich).

CodesiteLogging in den Uses einbinden und dann

Delphi-Quellcode:

   if suchwort = 'am' then ton2:='am';
   if suchwort = 'im' then ton2:='im';
   if suchwort = 'Bär' then ton2:='Baer'; 

   Codesite.Send(Suchwort + '->' + ton2);

   mediaPlayer1.FileName := TPath.Combine(TPath.GetDocumentsPath, (ton2+'.mp3'));
   mediaPlayer1.Play;

So kannst Du zumindest mal die Ergebnisse verfolgen.

Oder hast Du einfach einen Bereichsüberlauf. Sind Deine Arrays mit 1 initialisiert?

Die Übersetzung würde ich aber wirklich über ein Dictionary, Stringlist oder Ini lösen.
Letzteres hätte den Vorteil, dass Du sie auch mal ohne Neukompilierung ändern und erweitern kannst.

[idefix2]

Dass eine Kette von if-then Zuweisungen nicht funktionieren, wenn es "zu viele" werden, das wäre in der 20jährigen Geschichte von Delphi ein Unikum, das man wohl ausschliessen kann.
Da läuft mit Sicherheit etwas anderes schief, und bei endlosen Codeschlangen ist das auch nicht zu verwundern. Ohne das ganze Projekt zu sehen, werden wir wohl nicht viel helfen können.

Unabhängig davon, dass es sicher funktioniert, deuten aber soclche Unmengen von Abfragen auf krasse Designfehler hin. Hinweise auf TDictionary und TStringList sind schon gefallen, du solltest das Programm unbedingt in so einer Richtung umbauen.

[Daniel]

Zitat:

Zitat von Sel2012 (Beitrag 1311573)

[Ich habe aus anderen Gründen den Rechner ganz neu gestartet und siehe da, das Problem ist weg.
Ich konnte mir ja auch nicht erklären, warum simple und überschaubare IF..THEN-Anweisungen zu einem nicht konstanten "Zufallsergebnis" führen sollte. Also war es doch wohl ein außerhalb von Delphi liegendes temporäres Speicherproblem des Rechners.

Solang es keine reine Beschäftigungstherapie für die DP-Benutezr war ... :roll:
Nachdem das Problem gelöst ist, wie die Ursache vermutlich nie finden werden mache ich hier mal zu. Auf Basis dieser dünnen Informationslage erübrigen sich weitere Beiträge.