Umgang mit Interfaces

[jaenicke]

Zitat von Whookie:

Die Bereichsüberprüfung (zusammen mit der I/O Prüfung und der Überlaufprüfung) ist absolute Pflicht, wir hatten schon Leute in der Firma, die uns durch abschalten Stress ohne Ende bereitet haben...
Performanz mag ja hin und wieder ein Faktor sein, Sicherheit geht aber vor!

Bei uns gab es in den letzten Jahren in der Hinsicht keinerlei Probleme. Auch in Tests mit aktivierter Prüfung gab es keine entsprechenden Fehler. Die Performance ist ohne die Option jedoch spür- und messbar besser. Deshalb macht es in unserem Fall keinen Sinn die Option zu aktivieren.

Wenn natürlich solche Fehler auch tatsächlich vorkommen, ist das etwas anderes. Da müsste man sich aber schon fragen woran das liegt und ob sich das vermeiden lässt.

[stahli]

Es schweift etwas vom Thema ab aber ich schließe mich da Himi an.
Die Grundeinstellungen sollten für Anfänger optimiert sein.
Wer dann weiß was er tut kann die Bereichsprüfung ausschalten und die Performance erhöhen.

[Whookie]

Zitat von TiGü:

...aber warum das Rad zweimal erfinden?

Code:

fList: TObjectList<TListData>

erfindet ja das Rad nicht neu...

Zitat von TiGü:

Sind denn diese anderen Listen von einen anderen (eigenen) Listentyp ohne Hash?

Es ist eine einfache Liste (in der Interfacelosen-Variante vom Type TObjectList) ohne weitere Daten (der Besitzer durchläuft sie, um z.B. allen Elementen eine Nachricht zu übermitteln).

Zitat von TiGü:

Und der entscheidene Unterschied ist: Ich habe keine Speicherlecks beim Beenden (laut FastMM).

Die habe ich auch nicht, solange es keine Quer-Referenzen gibt. Sobald aber eines der Objekte eine zusätzliche Liste pflegt (siehe Beitrag #39, uImpl.pas, Zeile 130), beginnt der Spaß mit der Referenzzählung. Ich nehme an, dass sich das - unabhängig von der verwendeten Liste - nur durch Manipulation der Referenzzählung (Beitrag 45, himitsu), wirklich lösen lässt.

Zitat von TiGü:

Um wieviel langsamer ist denn die Suche von TDictionary im Verhältnis zu deiner Lösung?

Meine braucht im worst case log2(n) die von Delphi im Durchschnitt n/2, das sind bei 100000 Elementen 17 zu 50000 Vergleiche...


Edit: Was deine Version in #51 angeht, die hat zwar kein Speicherleck, funktioniert aber andererseits auch nicht richtig (du erzeugst zwar 4 Elemente die alle IInteger unterstützen, aber bei der Ausgabe sind es nur mehr 3....)

[Whookie]

Zitat von jaenicke:

Wenn natürlich solche Fehler auch tatsächlich vorkommen, ist das etwas anderes. Da müsste man sich aber schon fragen woran das liegt und ob sich das vermeiden lässt.

Es gibt leider Menschen mit den unterschiedlichsten Charakterzügen...

Zitat von stahli:

...Die Grundeinstellungen sollten für Anfänger optimiert sein.
Wer dann weiß was er tut kann die Bereichsprüfung ausschalten und die Performance erhöhen.

...wobei, das erst die QM-Abteilung nach ausgiebigen Tests erlauben sollten.