dummzeuch hat folgendes geschrieben :

Wobei "aeltere Delphis" bedeutet: Delphi 1 bis XE (zu XE2 kann ich noch nichts sagen, aber es wuerde mich nicht wundern, wenn selbst die 64 Bit Version noch compatibel dazu waere).

Ja, genau.

Ich wöllte das gerne gelesen haben als "es ist rückwärtskompatibel, Record-Methoden sind das nicht".

Übrigens: der generierte Code ist exakt der gleiche (Getestet: D7,D10). MethodenRecord ist also nur eine neue Syntax für object. Es würde mich nicht wundern, wenn das von Delphi intern auf eine einheitliche Form abgebildet wird.

Prinzipiell sind Objects von der Speicherverwaltung mit den Klassen in C++ vergleichbar vom Layout. Möchte man Cross Language haben, ist man mit COM/DCOM und anderen Schnittstellen aber oft besser bedient.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Oha, schon lange her, lange nicht reingeschaut... Soweit ich das für mich zusammenfassen kann, ist so etwas schönes wie der Garbage Collector unter Java nicht mit Bordmitteln in Delphi erreichbar. Interfaces sind in dedizierten Situationen eine Alternative, aber klassisches, eigenes Memory Management ist State-of-the-Art, habe ich das soweit richtig verstanden? Damit wird auch die an sich sehr bequeme Vorgehensweise aus einer Funktion eine Instanz zurück zu liefern etwas bedenklich, weil der Rufer ja vielleicht nicht dran denkt die Instanz freizugeben - er hat sie ja nicht angelegt.

Das ist für mich die Essenz, wenn ich falsch liege, dürft ihr mich natürlich gern korrigieren, sonst schließe ich das Thema in den nächsten Tagen.

Danke, Stephan

Vielleicht sind auch Smartpointers passend an dieser Stelle:
members.adug.org.au/...2/05/smart-pointers/

Sieht definitiv interessant aus! Allerdings durchblicke ich es nicht soweit, dass ich - ohne es erstmal anzuwenden - die Grenzen verstehen würde. Nutzt du das? Was sind die Nachteile? Der zusätzliche Implementierungaufwand ist ja nicht so groß, soweit ich das sehen kann, oder? Man muss halt bloß dran denken, beim Anlegen der Instanzen die veränderte Form zu nutzen. Den Beitrag von Stefan Meisner finde ich auch interessant, leider ist da nur ein Teil des Mechanismus abgebildet soweit ich das sehen kann.

vG,
Stephan

Ja, ich nutze das. Ich bevorzuge den ObjectGuard, da ich das andere z.Zt. Overkill finde
Ein Beispiel:

Ich nutz das sogar fast täglich...
Solche Dinge hab ich mir auch für BeginUpdate und EndUpdate gebaut, falls Du daran interessiert bist.

Was ist denn der Sinn von dem Guard? Der funktioniert doch nur innerhalb der gleichen Funktion, dort würde doch auch ein try/finally reichen. Wenn man Guard wie in der Funktion vom Threadersteller als Rückgabewert verwendet (TObjectGuard.Guard(Result, TStringList.Create)), knallt es doch spätestens beim Zugriff der aufrufenden Funktion, da das Objetc wieder freigegeben wurde. Oder hab ich das jetzt falsch verstanden?

Ja. Der Scope geht bis zum "end"

Verwendet man bei der Implementation eines Object ein Interface dann kann das Interface auch als Rückgabeparameter verwendet werden und ist ausserhalb der Funktion verwendbar. Der ObjectGuard löst dieses Problem nicht (da dort die StringList und der Guard als Rueckgabe weitergegeben werden muesste), es ist somit keine Lösung auf die Ausgangsfragestellung von Stephan (Object als Rückgabewert). Zumal sowas dann bei einem "Mischmasch" einfach nur total unübersichtlich wird (muss ich die StringList nun freigeben oder nicht?) was bei einer IInterface Implementierung des Objektes eindeutig zu erkennen ist. Welchen Vorteil hat man also, ausser einer Zeile die man sich beim der Programmierung einspart? (oder 3 mit Try/Finally?)