AHHHH...
Sowas ist doch Käse. Vor allem, weil es diesen Fehler wohl schon sehr, sehr lange gibt und er immer noch nicht gefixt wurde
Naja, das ganze klagen hilft leider nicht sehr viel, da es am Status im Moment nur sehr wenig bis gar nichts ändern wird. Zum Glück kann ich daher aber meinen Code einfach belassen, man muss ihn halt einfach nur anders nutzen.
Herzlichen Dank für euer Know How! Ich seh schon, ich sollte auch mal grob über das
QC drüber schauen -- aber da steht eben auch nicht gerade wenig, was dann in einem ziemlichen Aufwand ausufern könnte...
-- Edit: Wow... Es wird echt immer besser
Delphi-Quellcode:
type
TApDynamicArray<T> = record
public type
TApArrayToStringFunc = reference to function(Value: T): String;
public
function ToString(const ToStrFunc: TApArrayToStringFunc): String;
end;
function TApDynamicArray<T>.ToString(const ToStrFunc: TApArrayToStringFunc): String;
begin
end;
procedure PrintIntegerArray(A: TApDynamicArray<Integer>);
begin
Writeln( A.ToString(IntToStr) );
end;
var
Tmp : TApDynamicArray<Integer>;
begin
ReportMemoryLeaksOnShutdown := True;
//Writeln( Tmp.ToString(IntToStr) );
PrintIntegerArray(Tmp)
end.
... liefert in der aktuell gezeigten Version
kein Speicherleak. Wenn ihr allerdings PrintIntegerArray() entfernt und das Writeln() aktiviert, dann kommt ein nettes Speicherleak zustande. Da fällt mir nur noch folgendes ein: WTF
Code:
---------------------------
Project1.exe: Memory Leak Detected
---------------------------
This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):
13 - 20 bytes: Project1$1697$ActRec x 1
Entfernt man das
reference to beim Typen TApArrayToStringFunc, dann funktionieren beide Versionen. Ist doch alles echt so super... Jetzt fang ich dann auch noch an, jeden scheiß zu überladen und auszubauen und hoffe, dass der Compiler alles mal in 10 Jahren auf die Reihe bring.
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)