Delphi 2011 heißt jetzt Delphi XE

**himitsu**

Es gab keine Enumeratoren in Delphi 7?

Kommt drauf an, was du meinst.

type myEnum = (a, b, c); 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.

Zitat:

AFAIK wird das dort auf Basis von UTF8 gemacht. Handelt man sich aber andere Problem ein als wenn man es wie "üblich" auf UTF16-Basis wie Java/.NET/Windows macht.

Liegt das nicht daran, daß FPC, bzw. viele APIs der VCL und Co. noch "Ansi" waren, aber Lazarus nun Unicode unterstützen wollte?
UTF-8 kann man ja quasi auf Ansi mappen.

**Stevie**

Zitat von xZise:

PS: Operatoren gibt es inzwischen auch für Klassen.

Nö, die Trottel haben den Fehler in der Auflistung der neuen Features seit Delphi7 nur noch nicht gefixt.
Da steht:

Zitat:

Delphi allows certain functions, or operators, to be overloaded within record declarations

aber darunter steht eine Klassen Deklaration... und das geht nicht.

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:

markieren

Delphi-Quellcode:

			type

  IServiceLocator = interface

    function GetInstance<TService>(): TService;

  end;

Möööp! Interfaces unterstützen keine parametrisierten Methoden...

**xZise**

Zitat von Bernhard Geyer:

Zitat von xZise:

Reflection ist doch eine Funktion der IDE,

Nee. Reflection ist die aufgebohrte RTTI damit man halbwegs das machen kann was per Reflection in .NET/Java auch möglich ist.[…]

Ach mist

dachte Reflection wäre Refactoring

MfG
Fabian

**himitsu**

Das kann auch nicht/nie mit Objekten (Klassen) funktionieren, höchstens bei Interfaces wären es noch möglich.

markieren

Delphi-Quellcode:

			var A, B, C: TObject;

A := B + C;

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?
Speicherlecks ohne Ende.
A einfach freizugeben geht auch nicht, da Delphi ja nich wissen kann, ob dieses Objekt noch wo anders in Verwendung ist.

**Stevie**

Zitat von himitsu:

Das kann auch nicht/nie mit Objekten (Klassen) funktionieren, höchstens bei Interfaces wären es noch möglich.

markieren

Delphi-Quellcode:

			var A, B, C: TObject;

A := B + C;

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?
Speicherlecks ohne Ende.
A einfach freizugeben geht auch nicht, da Delphi ja nich wissen kann, ob dieses Objekt noch wo anders in Verwendung ist.

Imo kein großes Problem, ist auch nich viel anders als die Kombination von Copy constructor und Assign/AssignTo

**himitsu**

Nein, da Delphi keine automatische Referenzzählung bei den Objekten besitzt.

markieren

Delphi-Quellcode:

			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);

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.
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.

**Stevie**

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.

**himitsu**

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)

**mkinzler**

Dieses Problem dürften andere Sprache, welche mit Referenzen haben dann auch haben. das Problem besteht ja auch, wei schon gwschrieben auch so.

markieren

Delphi-Quellcode:

			var

    a,b,c: TObject;

begin

    ...

    a := b;

Auch hier existiert das ursprüngliche Objekt, welches a referenziert weiter.

Oder

markieren

Delphi-Quellcode:

			var

   a: TOject;

begin

   ...

   a := Tobject.Create;

   ...

   a := Tobject.Create;

...

**Stevie**

Zitat von himitsu:

Was denkst du denn, warum es nicht für Objekte implementiert wurden ist, sondern eben nur für Records?

Weil sie dort genauso wie bei vielen anderen Sachen nicht zu Ende gedacht haben?

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

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