Delphi-PRAXiS
Seite 3 von 3     123   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Wann .Free und wann .Destoy benutzen (https://www.delphipraxis.net/95609-wann-free-und-wann-destoy-benutzen.html)

xaromz 11. Jul 2007 08:39

Re: Wann .Free und wann .Destoy benutzen
 
Hallo,
Zitat:

Zitat von sirius
Zitat:

Zitat von xaromz
In einer solchen Sprache möchte ich nicht programmieren.

Programmierst du aber :mrgreen:
Delphi-Quellcode:
var s:string;
begin
  //jetzt ist s nil
  s:='Hallo Welt';
  //und jetzt zeigt s ganz woanders hin
  //ähnliches für dynamische Arrays
end;

nein, tu ich nicht. Wo ist in Deinem Beispiel eine Methode? Was hat eine Zuweisung mit dam Ganzen zu tun?

Zitat:

Zitat von sirius
Generell besteht bei sowas natürlich immer die Frage der Sinnfälligkeit.

Da hast Du Recht.
Zitat:

Zitat von sirius
Aber wann brauch man denn nochmal einen Zeiger auf ein Objekt, dass nicht mehr existiert? Und wieviele Probleme diesbezüglich tauchten schon in der DP auf ("assigned funktoiniert nicht!" --> "Du musst den Zeiger auf nil setzen")?

Natürlich braucht man den Zeiger danach nicht mehr, aber der vorgeschlagene Weg ist nicht geeignet, das Problem zu lösen.

Gruß
xaromz

Hawkeye219 11. Jul 2007 08:57

Re: Wann .Free und wann .Destoy benutzen
 
Hallo sirius,

ich bestreite nicht, daß ein wenig compiler magic in diesem Fall nützlich wäre. Ich wollte - genau wie xaromz - nur aufzeigen, daß es nicht in allen Fällen möglich sein wird, die notwendigen Befehle zum Löschen der Referenz(en) automatisch erzeugen zu lassen. Dies scheitert meiner Meinung nach spätestens dann, wenn die Referenz ein Funktionsergebnis ist. Ob es sinnvoll ist, so etwas zu programmieren, sei dahingestellt. Es kommt vor, deshalb muß ein Compiler auch diese Fälle berücksichtigen. Kann er diese Aufgabe aber nicht vollständig übernehmen, so daß ich als Programmierer gezwungen bin, in "schwierigen" Situation selbst tätig zu werden, dann trifft xaromz' Aussage auch für mich zu: In einer solchen Sprache möchte ich nicht programmieren.

Zitat:

Und wenn du mit mehreren Referenzen auf ein Objekt arbeitest, dann nimm doch lieber ein Interface.
Genau das mache ich (nicht nur in diesem Fall) auch. Die wenigen Probleme (z.B. cyclic references) lassen sich relativ leicht lösen, auf der anderen Seite stehen eine (fast) automatische Speicherverwaltung und -freigabe sowie bessere Möglichkeiten, ein großes Programm zu modularisieren.

Gruß Hawkeye


Alle Zeitangaben in WEZ +1. Es ist jetzt 16:21 Uhr.
Seite 3 von 3     123   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz