AW: Delphi 2011 heißt jetzt Delphi XE
Zitat:
Delphi-Quellcode:
gab's schon, aber die Enumerator-Klassen, welche z.B. für das For-In genutzt werden, wurden zusammen mit dem For-In eingeführt.
type myEnum = (a, b, c);
Zitat:
UTF-8 kann man ja quasi auf Ansi mappen. |
AW: Delphi 2011 heißt jetzt Delphi XE
Zitat:
Da steht: Zitat:
Anstatt ihrer Sch**** SVN Integration, UML Designern (vor allen sie zeigen nur Reverse Engeneering, oder? Wen interessiert das? Das und viel mehr konnte Modelmaker schon vor Jahren) und sonstigem Fluff sollten sie mal die QC abarbeiten und derbe Fehler in der RTL/VCL fixen und die Generics endlich komplett benutzbar machen. Ich stoß dauernd an Stellen wo ich mir nur denke, toll in C# würd das gehen... Beispiel? Hab versucht, den CommonServiceLocator auf Delphi zu portieren:
Delphi-Quellcode:
Möööp! Interfaces unterstützen keine parametrisierten Methoden... :wall:
type
IServiceLocator = interface function GetInstance<TService>(): TService; end; |
AW: Delphi 2011 heißt jetzt Delphi XE
Zitat:
MfG Fabian |
AW: Delphi 2011 heißt jetzt Delphi XE
Das kann auch nicht/nie mit Objekten (Klassen) funktionieren, höchstens bei Interfaces wären es noch möglich.
Delphi-Quellcode:
Denn wer soll jetzt dafür sorgen, daß eine Klasse in A auch ordnungsgemäß freigegeben wird, wenn da nun eine neue Klaee als Rechenergebnis reinwöllte?
var A, B, C: TObject;
A := B + C; Speicherlecks ohne Ende. A einfach freizugeben geht auch nicht, da Delphi ja nich wissen kann, ob dieses Objekt noch wo anders in Verwendung ist. |
AW: Delphi 2011 heißt jetzt Delphi XE
Zitat:
|
AW: Delphi 2011 heißt jetzt Delphi XE
Nein, da Delphi keine automatische Referenzzählung bei den Objekten besitzt.
Delphi-Quellcode:
Wenn man jetzt einfach so die alte Zahl in C freigeben würde, dann wäre der Objektzeiger in D nun fehlerhaft, da man ihm das Objekt unterm Arsch geklaut hat.
C := TZahl.Create(789);
D := C; A := TZahl.Create(123); B := TZahl.Create(456); C := A + B; // function TZahl.Add(x, y: TZahl); // begin Result := TZahl.Create(x.num + y.num); end; WriteLn(C.num); Macht man mit dem alten Objekt in C nichts und dieses Objekt wäre sonst nirgendwo referenziert, dann entstünde ein Speicherleck. Mit Interfaces ist es also möglich, da man dort weiß wieviele Referenzen es auf die enthaltenen Objekte/Interfaces gibt und kann es somit freigeben. Bei Records ist garnichts nötig, da dort die Speicherbereiche direkt vorliegen (quasi ein RefCount von 1). Darum hab ich bei meinen MatheLibs auch in dem Record ein Interface gekapselt, da ich so die Vorteile eines Interfaces (Referenzzählung), mit den Operatoren der Records kombinieren konnte. |
AW: Delphi 2011 heißt jetzt Delphi XE
Dir ist schon klar, dass das nicht das Problem von operatoren auf Klassen ist sondern das des Programmierers, der hier lustig Objekte gegenseitig zuweist? Wenn per Definition ein Operator ein neues Objekt erzeugt ist allen klar, dass sie bei einer Zuweisung von a := b + c vorher a sichern oder freigeben müssten, wenn da was drin steht. Was hat das bitte mit Operatoren zu tun, das wäre bei jeder normalen Methode die ein Objekt zurück gibt genauso.
|
AW: Delphi 2011 heißt jetzt Delphi XE
Weil Delphi/Emba bei einem Versuch die Operatoren, Aufgrund der Natur der Objekte, bei den Objeten zu implementieren, nur scheitern kann, da man hier eben nichts "sicher" abfragen kann.
(ungültige Objektzeiger und unbekannte Mehrfachreferenzen) Was denkst du denn, warum es nicht für Objekte implementiert wurden ist, sondern eben nur für Records? (die Interfaces hatten die wohl einfach nur vergessen) |
AW: Delphi 2011 heißt jetzt Delphi XE
Dieses Problem dürften andere Sprache, welche mit Referenzen haben dann auch haben. das Problem besteht ja auch, wei schon gwschrieben auch so.
Delphi-Quellcode:
Auch hier existiert das ursprüngliche Objekt, welches a referenziert weiter.
var
a,b,c: TObject; begin ... a := b; Oder
Delphi-Quellcode:
...
var
a: TOject; begin ... a := Tobject.Create; ... a := Tobject.Create; |
AW: Delphi 2011 heißt jetzt Delphi XE
Zitat:
Nee, ernsthaft, wahrscheinlich würde es theoretisch gehen, nur würds wohl mehr Verwirrung stiften und Fehler hervorrufen es nützen würde. überschreibt mal fix den Zuweisungsoperator für einige Klassen, muhaha :twisted: P.S.: Da fällt mir gerade ein... würden die operator Überladungen dann vererbt? Japp, das könnt wohl richtig derb nach hinten losgehen, wenn man da was falsch macht :D |
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:06 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz