Announcement

**T K** · 15.10.2002, 12:04

Hi,

ich w�rde object keinesfalls verwenden. Leite Deine neuen Objekte von TObject ab. Du MUSST ja keine Konstruktoren schreiben.
Den Punkt Namenskollisionen verstehe ich nicht.
Die Programmierhilfe funktioniert bei TObjekten doch gut?

Und ein sauberes Create/Free in entsprechendem try/except/finally ist doch wesentlich sauberer, denn wenn ich nicht weiss, wie was gerade steht.

Ich denke, Du erlangst nicht wirklich Vorteile durch "object"

Gruss

Tim

**Ulrich Gerhardt** · 15.10.2002, 15:23

Hi Timo, 
h�tte nicht gedacht, dass sich in dem Thread noch mal was tut. :-) 
ich w�rde object keinesfalls verwenden. Leite Deine neuen Objekte von TObject ab.
Du MUSST ja keine Konstruktoren schreiben. 
F�r "objektorientierte" Sachen mit Klassenhierarchie und Polymorphie und so
benutze ich nat�rlich TObject's. Mir gings eben um Sachen wie Punkte/Vektoren.
In "klassischem" Pascal w�rde ich das so machen
<pre>
type
TVector = record
x, y: Double;
end;

function AddVectors(p,q: TVector): TVector;
function SubtractVectors(p,q: TVector): TVector;
// weitere Funktionen auf TVector's

procedure Test;
var
a, b, c, d, e: TVector;
begin
c := AddVectors(a, b);
e := SubtractVectors(AddVectors(a, b), AddVectors(c, d));
end;
</pre>
In "Test" w�rde ich viel lieber sowas schreiben (ich wei�: operator overloading == C++ == b�se :-)):<pre>
c := a + b;
e := ((a + b) - (c + d));
</pre>
... oder wenigstens das:<pre>
c := a.Plus(b);
e := (a.Plus(b)).Minus(c.Plus(d))); // OK, die Zeile ist auch nicht soooo sch�n ;-)
</pre>
Hierf�r fallen record's flach, weil sie keine Methoden haben k�nnen, und TObject's,
weil sich Obiges eben schwer mit der Referenzsemantik und der Pflicht zum
Aufr�umen vereinbaren l�sst.

Den Punkt Namenskollisionen verstehe ich nicht. Die Programmierhilfe
funktioniert bei TObjekten doch gut? 
Den Teil mit Namenskollisionen und Programmierhilfe streich ich mal
nachtr�glich wieder, das l�sst sich ja mit overload bzw. Ctrl-Space einigerma�en
umschiffen.

Und ein sauberes Create/Free in entsprechendem try/except/finally ist doch
wesentlich sauberer, denn wenn ich nicht weiss, wie was gerade steht. 
Siehe oben: schreib mal <code>c := a.Plus(b);</code> mit einem
<code>TVector = class(TObject)</code> - das wird ein Mehrzeiler aus lauter
Create/Free-Verwaltungskram, und bei Wartungsarbeiten wei� keiner mehr,
wer denn jetzt f�r's Erzeugen und/oder T�ten der armen Vektoren zust�ndig ist.

Ich denke, Du erlangst nicht wirklich Vorteile durch "object" 
Na ja. Wenn ich gezwungen w�re, ohne objects zu arbeiten, w�rde ich halt
records nehmen wie im ersten Codefragment; das w�re auch kein Beinbruch.
Aber unter D5 hatte ich (noch?) keine Probleme mit objects, und in zuk�nftigen
Delphi-Versionen k�nnen ja wahrscheinlich -- .NET sei Dank -- records
(nichtvirtuelle) Methoden haben, also habe ich auch in Zukunft keine Probleme.
Das object ist tot -- es lebe der record mit Methoden! ;-)

Ciao, Uli

**Hagen Reddmann** · 15.10.2002, 17:06

Wie w�res es mit Interfaces ? ich habe eine Large Integer Math. Library gecodet, jeweils mit Objects, Klassen und Interfaces. Mit den Interfaces ergab sich die beste Semantik, Potabilit�t und uniform Erweiterbarkeit. Ich nutze die Interfaces aber NUR als Datenobjecte OHNE wesentliche Methoden. Die eigentlichen "Methoden" werden procedural gecodet aber dann mit default Parametern und overloading.
Z.b.:

<pre>

type
IPoint = interface
function X: Double;
function Y: Double;
end; 

procedure PAdd(var A: IPoint; const B: IPoint); overload;
procedure PAdd(var A: IPoint; const B,C: IPoint); overload; 

implementation 

type
TPoint = class(TInterfacedObject, IPoint)
X,Y: Double;
end; 

function AllocPoint(var A: IPoint): TPoint;
begin
if A = nil then A := TPoint.Create;
end; 

procedure PSwp(var A,B: IPoint);
var
T: Pointer;
begin
T := Pointer(A);
Pointer(A) := Pointer(B);
Pointer(B) := T;
end;

procedure PAdd(var A: IPoint; const B: IPoint);
begin
PAdd(A, A, B);
end; 

procedure PAdd(var A: IPoint; const B,C: IPoint);
var
R: IPoint;
begin
with AllocPoint(R) do
begin
X := B.X + C.X;
Y := B.Y + C.Y;
end;
PSwp(R, A);
end;

// vorteil zur Nutzung 

procedure Test;
var
A,B,C: IPoint;
begin
PSet(A, 1, 1);
PAdd(C, A, PGet(1, 1));
PAdd(B, C);
usw.
end; 

</pre>

D.h. keinerlei Initialisierungen/Finalisierungen sind n�tig, totzdem k�nnen dynamische Speicherbereiche benutzt werden. Zudem gibts die M�glichkeit des "Copy on write demand" also so wie LongStrings oder dynam. Arrays. Dies geht mit objecten nicht. Dadurch werden enorm unn�tige Kopieroperationen vermieden. 
Das Nutzerinterface = mathematischen proceduren l�sst sich jeder Zeit erweitern OHNE das am Object/Klasse rumgepuscht werden mu�. Normalerweise entstehen in expensiven math. Libraries Object mit sovielen Methoden das sie als Monsterklassen bezeichnet werden m�ssen.
Desweiteren klappt das overloading + default Paramter + open array Parameters mit proceduren/function einwandfrei, mit Methoden gibts extreme Probleme.

Gru� Hage

**Ulrich Gerhardt** · 15.10.2002, 17:45

Hallo, Hagen! 
Wie w�res es mit Interfaces ? 
Finde ich eigentlich prinzipiell eine faszinierende Sache, aber
irgendwie bin ich bisher immer wegen der "zwangsweisen" Referenzz�hlung auf die Nase gefallen. F�r viele Zwecke w�ren mir Java-m��ige Interfaces ohne compiler magic erstmal lieber. F�r den konkreten Einsatz hier oder diese SafeGuard-Geschichten ist's nat�rlich praktisch, wie's jetzt ist.

Die eigentlichen "Methoden" werden procedural gecodet aber dann mit default Parametern und overloading. Z.b.:
Wo ist denn dann noch der Unterschied gegen�ber<pre>
type
TVector = record
x, y: Double;
end;
 
function AddVectors(p,q: TVector): TVector;
// oder:
procedure AddVectors(var Result: TVector; const p,q: TVector);
</pre>

Von der Performanz her merkst du wohl keine Nachteile, von wegen viele kleine Allokationen und so? Wie ich dich einsch�tze, wird deine
Bibliothek schon eher unter "stressigen" Bedingungen laufen, wo sowas z�hlt.
 Ich hab so einen Vergleich mal (mehr spa�eshalber) unter VB gemacht -- Type versus *.cls -- und der Unterschied war beachtlich, Faktor 200 oder so. War nat�rlich keine todsichere, wissenschaftlich fundierte Aktion, aber die Gr��enordnung wird schon passen. :-) Lag wahrscheinlich an dem ganzen nicht zu umschiffenden COM-Overhead.

Ciao, Uli

**Hagen Reddmann** · 15.10.2002, 21:09

Hi Uli

Deine obige Annahme ist in sofern richtig wenn wir mit ordinalen Datentypen als Unter-Typen arbeiten. Dann w�re es tats�chlich am besten/effizientesten mit Recordtypen und proceduralem Interface. 
Allerdings ging es mir um dynamische Datentypen wie super gro�e Integer/Rationale oder Floating Points. Solche "Typen" sind sehr "empfindlich" in deren Speichermanagement. In meiner Library habe ich solche "forged" Interfaces mit einem eigenen FILO Stack zur Speicherverwaltung kombiniert. Alleine dieser FILO Stack erh�hte die Performance um 10-20%. Z.b. bei der Berechnung der Zahl PI mit 1 Million exakten Dezimalstellen machen 20% sehr viel aus. Ab einer gewissen Gr��e entscheiden sogar diese 20% �ber Machbarkeit oder Unl�sbar. 

Gru� Hage

Announcement

objects und Delphi?

objects und Delphi?

Comment

Comment

Comment

Comment

Comment