Delphi 2011 heißt jetzt Delphi XE

[himitsu]

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

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.

Delphi-Quellcode:

var
    a,b,c: TObject;
begin
    ...
    a := b;

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

Oder

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

[HeikoAdams]

Klingt so, als ob es wirklich das schlauste wäre, den Compiler von Delphi durch den FPC zu ersetzen

[Win32.API]

Bloß keinen anderer Compiler verwenden, der nicht 100% mit den Sprachfeatures von D2010 kompatibel ist. Die Umstellung von Ansi auf Unicode, OHNE dabei abwärts kompatible zu bleiben ({$DEFINE UNICODE}), hat mir gereicht.

[mleyen]

Das war ja schon oft ein Wunschtraum. Delphi IDE + FPC-Compiler + Support und kommerzielle weiterentwicklung.
Jedoch würde sich da wahrscheinlich sowohl Embarcadero als auch die FPC-Entwickler querstellen.
Ich kann mir kaum vorstellen, dass dann noch so viele umsonst am Compiler für Emba weiterentwickeln werden.

Ich bin auch Hansa´s Meinung und man sollte mit neuen Features vorsichtig sein.
Denn nicht alle brauch(t)en unbedingt Unicode, 64bit, Multiplatform, etc.
Für viele Firmen war/ist die Umstellung auf neuere Versionen einfach ein Aufwand (den Code zu portieren) für etwas was sie nicht unbedingt benötigen.

[Bernhard Geyer]

Zitat von mleyen:

Ich bin auch Hansa´s Meinung und man sollte mit neuen Features vorsichtig sein.

Stimmt. Full Ack.

Zitat von mleyen:

Denn nicht alle brauch(t)en unbedingt Unicode, 64bit, Multiplatform, etc.
Für viele Firmen war/ist die Umstellung auf neuere Versionen einfach ein Aufwand (den Code zu portieren) für etwas was sie nicht unbedingt benötigen.

Wenn man sowas nicht braucht, wieso sollte man dann auf neue Version umstellen? Bisher haben wir (Trotz Notwendigkeit von Unicode/Theming/Vista/Win7-Support) noch gut mit D6 leben können. Eine Umstellung haben wir uns bisher gespart (beim letzten mal haben wir aufgrund von Release-Termin eine Umstellung noch verschoben). D2007 ist die erste Version seit D7 die wieder für uns brauchbar war/ist. D2009/2010 würde erst kommen wenn auch die (schon offiziell abgekündigter Win98-Support) nicht mehr nötig ist.

[cookie22]

Zitat von mleyen:

Ich bin auch Hansa´s Meinung und man sollte mit neuen Features vorsichtig sein.
Denn nicht alle brauch(t)en unbedingt Unicode, 64bit, Multiplatform, etc.
Für viele Firmen war/ist die Umstellung auf neuere Versionen einfach ein Aufwand (den Code zu portieren) für etwas was sie nicht unbedingt benötigen.

nicht alle. heisst nicht, dass es nicht ne ganze menge leute gibt, die es brauchen. gerade unicode ist wichtig, wer ohne unicode support neue projekte startet ist selbst schuld.

der delphi compiler ist jahre hinter fpc hinterher. wenn die nicht schnell was machen ist der vorsprung nie wieder einzuholen.

Zitat:

D2009/2010 würde erst kommen wenn auch die (schon offiziell abgekündigter Win98-Support) nicht mehr nötig ist.

habt ihr echt noch kunden, die noch win98 verwenden?