Optimierung oder Compilerfehler oder was?

[MichaelT]

Mir kommt das result:=FFilteredStanzprogramm; ein wenig seltsam vor.

Vor dem Addieren wird die Value vom FFilteredStandprogramm gezogen und zumal ein Clear im Code steht liegt die Vermutung nahe, dass die Liste dieselbe ist.

Aus der Sicht des Compilers ist .Value call an sich identisch.

D.h. würde man die beiden Aufrufe vertauschen müsste 6 rauskommen.

Zitat von himitsu:

Wenn es wirklich an der Optimierung liegt, dann den Code anpassen
oder notfalls ein http://docwiki.embarcadero.com/RADSt...erung_(Delphi) drumrum, bzw. an den Anfang der Unit.

[Rainer Wolff]

Zitat von MichaelT:

Mir kommt das result:=FFilteredStanzprogramm; ein wenig seltsam vor.

Vor dem Addieren wird die Value vom FFilteredStandprogramm gezogen und zumal ein Clear im Code steht liegt die Vermutung nahe, dass die Liste dieselbe ist.

Aus der Sicht des Compilers ist .Value call an sich identisch.

D.h. würde man die beiden Aufrufe vertauschen müsste 6 rauskommen.

Zitat von himitsu:

Wenn es wirklich an der Optimierung liegt, dann den Code anpassen
oder notfalls ein http://docwiki.embarcadero.com/RADSt...erung_(Delphi) drumrum, bzw. an den Anfang der Unit.

Beim Vertauschen der Anweisungen kommt tatsächlich auch 6 als Ergebnis heraus.

Für die Liste war es ja auch so gedacht, dass diese immer die selbe ist, dann brauche ich die nicht immer erzeugen und freigeben, nur der Listeninhalt soll sich ändern. Die Liste wird im constructor von TTyp einmalig erzeugt:

Code:

  FFilteredStanzprogramm:=TEinzelSchrittlist.Create;
  FFilteredStanzprogramm.OwnsObjects:=False;

und bei Programmende wieder freigegeben.

Optimierung war für das ganze Testprojekt eigentlich sowieso schon deaktiviert, auch die Compiler-Direktiven ändern nix am Ergebnis.

[Rainer Wolff]

und gerade explizit noch einmal ausprobiert:

unter Berlin läuft der selbe Test durch.

[Fritzew]

Der Compiler erzeugt ungefähr:

Delphi-Quellcode:

// Ursprung   
count:=FTypList[0].FilteredEinzelschritte[gWkz.Werkzeug['Zurr_240']].Count+
         FTypList[0].FilteredEinzelschritte[gWkz.Werkzeug['Zurr_840']].Count;
         
//Nur Schema:  Also macht der Compiler ungefähr das:
   lTemp1 : TFilteredStanzprogramm = FTypList[0].FilteredEinzelschritte[gWkz.Werkzeug['Zurr_240']];
   lTemp2 : TFilteredStanzprogramm FilteredEinzelschritte[gWkz.Werkzeug['Zurr_840']];
   Count :=  lTemp1.Count + lTemp2.Count;
//   Und da beide Ltemps auf das gleich Object zeigen.....

Sieht aus wie ein Compilerfehler, wobei ich jetzt schon weiss was dabei rauskommt: 'Works as designed'
Es ist soweit ich es kenne nicht dokumentiert was der Compiler da macht, oder machen darf...

[MichaelT]

Ist auch kein Vorwurf. Die Idee ist schon ok. Mit wundert eher, dass das jemals funktioniert hat.

Stellt sich die Frage ob sich was im Fall der Zuweisung.

Delphi-Quellcode:

FTypList[0].FilteredEinzelschritte[gWkz.Werkzeug['Zurr_240']].Value + FTypList[1].FilteredEinzelschritte[gWkz.Werkzeug['Zurr_840']].Value;

sofern genug Platz vorhanden ist etwas ändert.

Dann ist es der 'Iterator' und der Compiler durchaus 'intelligent'. Wobei ich nicht vermute dass sich viel ändert. Es könnte aber genügen wenn sich die Adresse der Referenz mit deren Hilfe .Value wird aufgerufen ändert.

Du hast zwei Iteratorobjekte auf einer Liste laufen. Du willst die Summe über beide.

Ansonsten macht das Programm genau was du geschrieben hast. Du hast geschrieben. Hole das Erste Ergebnis, lösche die Liste, hole das zweite Ergebnis aus der selben Liste und addiere.

Das Ergebnis kommt als Referenz zurück und wird nicht auf einen Stack geknallt. Aktueller Objektzustand und davon Value und das addieren.

Ich habe immer separate Objekte gehalten und die Value war immer aktuell ermittelte Summe (abklappern).