Referenzen auf ungültige Objekte

**WM_CLOSE**

@Christian: es gibt theoretisch keine Pointer in .Net. Es gibt nur Referenzen. Auf diese Referenzen kann normalerweise nur das Framework bzw System.Object zugreifen. Wie gesagt: Man könnte eine Klasse x und einen Record y herstellen. Record y wird sich, wenn ihm ein Wert zugewiesen wird bei der entsprechenden Instanz von x melden. Wird nun der Destruktor der Instanz aufgerufen, nilt er allen ys. eigentlich relativ einfach.

**stahli**

Ich versuche mal, auif die genannten Punkte einzugehen:

Grundsätzlich will ich voranstellen, dass ich die Objekte auf Dauer komplett im Speicher halte. Ich erzeuge diese also nicht vorübergehend, um eine Methode auszuführen.
Die Objekte bilden die gesamte Turnierstruktur ab und beinhalten die Daten.
(Alternativ will ich die Daten (Felder) in eine Datenbank auslagern, aber die Struktur und die Geschäftslogik soll in den Objekten abgebildet werden.)

Zitat von alzaimar:

Die Freigabe ist dann ein "gib es dann frei, wenn alle Anforderungen zurückgegeben wurden".
Du müsstest im Code nur dafür sorgen, das die Rückgabe so schnell wie möglich geschieht.
MyObject := ObjectManager.AcquireObjectByHandle(MyHandle);

Dies entspricht ja m.E. in etwa meiner angedeuteten Funktion IsValidObject, es erfolgt eine Prüfung, ob das Objekt noch existiert. Also dafür habe ich schon eine Lösung.

Zitat von Lemmy:

Guten Morgen,

was spräche denn dagegen hier das Observer-Pattern einzusetzen? Der Observer wird vom Subject informiert wenn dieses freigegeben wird. Damit kann der Observer entsprechend reagieren und die Referenz entfernen...

Grüße

Da habe ich ja eigentlich nichts dagegen, nur wollte ich gern eine weniger aufwendige Lösung.
Bernhard bezog sich ja (wie ich jetzt denke) auch auf BEISPIELE in der VCL.
Klar kann man das regeln. Aber man muss den betreffenden Objekten Listen hinzufügen, ggf. Schnittstellen definieren und gegenseitig aufzurufende Methoden implementieren.

Ich hätte eben gern eine mehr oder weniger automatisierte Lösung. Wenn ICH das für meine Objekte kann (es funktioniert ja grundsätzlich sehr gut), kann ich mir vorstellen, dass die Emba-Profis das auch allgemein regeln könnten. Die Programmierer müssten dann eben weniger auf Observer-Pattern setzen und könnten sich eine Menge Arbeit sparen.

Variablen (Pointer) können auf dem Weg ja auch nicht abgesichert werden.

Ein wenig könnte das wie FastMM laufen, das überwacht ja auch Zugriffe auf freigegebene Objekte. Vielleicht ließe sich darauf aufbauend ja eine Lösung finden, dass Referenzen auf solche Objekte genilt werden. So etwa waren meine Überlegungen dazu.

Zitat von Blup:

Das ist ein klassischer Fall für das Observer-Pattern und in der VCL auch so realisiert.
In allen existierenden Objekten nach einer Referenz zu suchen, halte ich für einen Designfehler.

Meine Lösung funktioniert halt diskret und ohne großen Aufwand im Hintergrund.
Eine Observer-Lösung für alle betreffenden Objekte wäre halt sehr viel aufwendiger.
Für alle "echten Datenobjekte" funktioniert meine Lösung ohne Probleme.
Nur wenn ich mal zusätzliche Variablen oder Eigenschaften nutze, unterliegen diese nicht einer "Bereinigung".

Zitat von r2c2:

Zitat:

ein Verein verwaltet eine Liste von Mitgliedern,

Huch. Wieso das? Ich denke doch eher ein Mitglied *ist* eine Person.

Eine Person gibt es nur einmal (mit Namen, Status etc). Diese Person kann Mitglied in einem Verein sein, Spieler in einer Mannschaft, Gastspieler in einer anderen Mannschaft oder sogar Schiedsrichter usw.
Deshalb wird dort die Referenz auf eine Person genutzt.

Zitat:

Eine Funktion ermittelt übergeordnete Komponenten - Z.B. ein Turnier, in dem ein bestimmtes Spiel enthalten ist).

Versteh ich nicht.

Ist ein Spiel beendet, wird das übergeordnete Turnier veranlasst, die Platzierungen neu zu berechnen. Das Spiel kennt sein übergeordnetes Turnier aber nicht direkt. Das wird über eine Funktion ermittelt.

Zitat:

Wird z.B. ein Personenobjekt gelöscht, müssen die anderen Komponenten, die eine Referenz darauf enthalten, diesen ungültigen Zeiger nilen.

Hier solltest du dir genau überlegen, was die Semantik des Löschens ist. Warum wird eine Person überhaupt gelöscht? Und wer tut das? Und was genau soll da passieren? Solche Probleme lösen sich oft durch die Beantwortung der folgenden Fragen:
- Zu wem gehört das Objekt?
- Wer ist dafür zuständig es frei zu geben?
- Wann und warum wird das Objekt freigegeben?

Das Personenobjekt wird gelöscht, wenn z.B. die Turnierveranstaltung gelöscht wird, da das Personenobjekt ein SubMember der Turnierveranstaltung ist.
Das Löschen wird durch den User veranlasst.
(Wann die Person nicht gelöscht werden darf (z.B. wenn sie schon gespielt hat) muss ich noch regeln - das wäre ja aber auch bei anderen Konzepten (SQL-DB) so).)

Zitat:

Im Idealfall hat man die folgenden beiden Fälle:
- Ein Objekt wird nur innerhalb einer Methode benutzt ==> Dann Create und Free mit try..finally in der Methode
- Ein Objekt gehört zu einem anderen Objekt (Komposition) ==> Dann create im Konstruktor und Free im Destruktur.

Das habe ich ja so realisiert. Es geht mir ja aber um die fremden Zugriffe z.B. auf ein Personenobjekt, die nicht dessen Owner sind.

**r2c2**

Zitat von WM_CLOSE:

@Christian: es gibt theoretisch keine Pointer in .Net. Es gibt nur Referenzen.

Ja. Klar.

Zitat:

Auf diese Referenzen kann normalerweise nur das Framework bzw System.Object zugreifen.

Du meinst auf die Adresse, die hinter der Referenz steht. Ja.

Zitat:

Wie gesagt: Man könnte eine Klasse x und einen Record y herstellen. Record y wird sich, wenn ihm ein Wert zugewiesen wird bei der entsprechenden Instanz von x melden. Wird nun der Destruktor der Instanz aufgerufen, nilt er allen ys. eigentlich relativ einfach.

Das wären einfach die genannten Smart Pointer. Das heißt aber nicht, dass Referenzen selbst Objekte wären.

Zitat von stahli:

Zitat von r2c2:

Zitat:

ein Verein verwaltet eine Liste von Mitgliedern,

Huch. Wieso das? Ich denke doch eher ein Mitglied *ist* eine Person.

Eine Person gibt es nur einmal (mit Namen, Status etc). Diese Person kann Mitglied in einem Verein sein, Spieler in einer Mannschaft, Gastspieler in einer anderen Mannschaft oder sogar Schiedsrichter usw.
Deshalb wird dort die Referenz auf eine Person genutzt.

Ja, das ist klar. Aber dann hast du keine zusätzlichen Mitglied-, Spieler- und Schiedsrichter-Klassen. Sondern der Verein hat einfach ne Liste von Personen als Mitglieder. Vielleicht ist das bei dir ja auch schon so und ich hab dich einfach falsch verstanden. Solltest du Rollen brauchen, die im Verhalten von dem normaler Personen abweisen, bietet sich das

Decorator-Pattern an.

Zitat:

Ist ein Spiel beendet, wird das übergeordnete Turnier veranlasst, die Platzierungen neu zu berechnen. Das Spiel kennt sein übergeordnetes Turnier aber nicht direkt. Das wird über eine Funktion ermittelt.

Das wäre ein klarer Fall für Events. Für was ne Funktion, die erst suchen muss?

Zitat:

Das Personenobjekt wird gelöscht, wenn z.B. die Turnierveranstaltung gelöscht wird, da das Personenobjekt ein SubMember der Turnierveranstaltung ist.

Dann passiert das einfach im Destruktor.

Zitat:

Das Löschen wird durch den User veranlasst.

Und welches Objekt ist dafür zuständig? Darum geht es.

Zitat:

Das habe ich ja so realisiert. Es geht mir ja aber um die fremden Zugriffe z.B. auf ein Personenobjekt, die nicht dessen Owner sind.

Ja das ist klar. Aber hier stellt sich die Frage, was die fremden Objekte da zu suchen haben. "Don't talk to stragers".

- sind die "Fremden" weiter oben in der Hierarchie, können sie sicher sein, dass das Objekt noch exisiert. ggf. muss es über events benachrichtigt werden, aber oft ist noch nichtmal das erforderlich
- ist es niedriger in der Hierarchie, hat es das Objekt gar nicht zu kennen. Dann solltest du dein Konzept überarbeiten.
- ist es weder höher noch tiefer in der Hierarchie, sollte es entweder gar nix von dem Objekt wissen oder über Events benachrichtigt werden.

Das ist der normale Fall, so wie es alle Welt handhabt. Da etwas zu automatisieren, halte ich für gefährlich. Da werden Referenzen ungültig und ich krieg nix davon mit. Vor allem hat ein Objekt A nix an den Innereien von B zu schaffen. Das ist schon aus Prinzip eklig.

mfg

Christian

**stahli**

Zitat:

Zitat von stahli:

Eine Person gibt es nur einmal (mit Namen, Status etc). Diese Person kann Mitglied in einem Verein sein, Spieler in einer Mannschaft, Gastspieler in einer anderen Mannschaft oder sogar Schiedsrichter usw.
Deshalb wird dort die Referenz auf eine Person genutzt.

Ja, das ist klar. Aber dann hast du keine zusätzlichen Mitglied-, Spieler- und Schiedsrichter-Klassen. Sondern der Verein hat einfach ne Liste von Personen als Mitglieder. Vielleicht ist das bei dir ja auch schon so und ich hab dich einfach falsch verstanden. Solltest du Rollen brauchen, die im Verhalten von dem normaler Personen abweisen, bietet sich das

Decorator-Pattern an.

Nein, ein Spieler und ein Schiedsrichter ist jeweils ein Objekt mit unterschiedlichen Eigenschaften und Methoden, dem jeweils eine Person "zugewiesen" wird (die Person ist dann wiederum eine Eigenschaft des Obektes - eigentlich ja nichts ungewöhnliches).
Die gleichen Zusammenhänge gibt es auch bei anderen Objekten. Egal warum nun ein Objekt freigegeben wird, sollen mögliche Referenzen darauf halt "angepasst" (genilt) werden.

Zitat:

Ist ein Spiel beendet, wird das übergeordnete Turnier veranlasst, die Platzierungen neu zu berechnen. Das Spiel kennt sein übergeordnetes Turnier aber nicht direkt. Das wird über eine Funktion ermittelt.

Das wäre ein klarer Fall für Events. Für was ne Funktion, die erst suchen muss?

Die Funktion durchläuft alle Owner ab dem Spiel und prüft, bis sie auf ein Turnierobjekt trifft.
Wenn ich ein Event verschicke, muss ich doch vorher auch den Adressaten ermitteln!?
Da erkenne ich keinen wirklichen Vorteil. Das ist auch eigentlich nicht mein Problem.

Zitat:

Das Personenobjekt wird gelöscht, wenn z.B. die Turnierveranstaltung gelöscht wird, da das Personenobjekt ein SubMember der Turnierveranstaltung ist.

Dann passiert das einfach im Destruktor.

Ja klar.

Zitat:

Das Löschen wird durch den User veranlasst.

Und welches Objekt ist dafür zuständig? Darum geht es.

Es ist doch rel. egal, wodurch ein Objekt gelöscht wird. WENN es gelöscht wird, will ich mögliche Referenzen darauf nilen.

Zitat:

Das habe ich ja so realisiert. Es geht mir ja aber um die fremden Zugriffe z.B. auf ein Personenobjekt, die nicht dessen Owner sind.

Ja das ist klar. Aber hier stellt sich die Frage, was die fremden Objekte da zu suchen haben. "Don't talk to stragers".

- sind die "Fremden" weiter oben in der Hierarchie, können sie sicher sein, dass das Objekt noch exisiert. ggf. muss es über events benachrichtigt werden, aber oft ist noch nichtmal das erforderlich
- ist es niedriger in der Hierarchie, hat es das Objekt gar nicht zu kennen. Dann solltest du dein Konzept überarbeiten.
- ist es weder höher noch tiefer in der Hierarchie, sollte es entweder gar nix von dem Objekt wissen oder über Events benachrichtigt werden.

Das ist der normale Fall, so wie es alle Welt handhabt. Da etwas zu automatisieren, halte ich für gefährlich. Da werden Referenzen ungültig und ich krieg nix davon mit. Vor allem hat ein Objekt A nix an den Innereien von B zu schaffen. Das ist schon aus Prinzip eklig.

Die Objektreferenzen sind ja nix ungewöhnliches. Macht ja schon DBGrid mit DataSource so. (Ich habe mir heute mal die Freigabeziehungen angesehen.)
Wenn die DataSource freigegeben wird, informiert diese halt (unter Zuhilfenahme komplexer Beziehungen, Listen und Methoden) das DBGrid, das dann seine Eigenschaft DataSource auf nil setzt.
Genau das passiert bei der Nutzung meiner Komponenten automatisch im Hintergrund, ohne dass sich der Programmierer darum kümmern muss.

Eine Lössung für meine Objekte habe ich damit, würde mir das aber auch als Grudsatzlösung wünschen.
Wenn Du das für gefährlich oder eklich hältst, dann muss ich das halt so hinnehmen.

Für lösbar halte ich das. Aber ok, ich gebe schon wieder Ruhe...

Dittsche hätte das aber sicher als Weltidee bezeichnet...

**Bummi**

Wenn Du eine eindeutige Referenz (1 Zeiger) hast kannst Du die Adresse im Konstruktor mit übergeben und im Destructor abräumen (auf nil setzen).
Allerdings kann es ja beliebig viele Kopien der Referenz geben (wie auch immer generiert/kopiert/zugewiesen) wer soll dann wissen was alles "genilt" werden soll.

**stahli**

Ich weiß das

So sehen zwei Objekte von mir aus.
Die zu nutzenden Eigenschaften sind mit einem Attribut gekennzeichnet:

zusammenfalten · markieren

Delphi-Quellcode:

			  TodPlayer = class(TodOlympicCustom)

  private

    FPerson: TodPerson;

    function get_StateType: TStateType;

    procedure set_StateType(const Value: TStateType);

  protected

    function get_Person: TodPerson; virtual;

    procedure set_Person(const Value: TodPerson); virtual;  public

    constructor Create(AOwner: TComponent); override;

    destructor Destroy; override;

    function GetClubName: String;

    [AttrOd]

    property Person: TodPerson read get_Person write set_Person;  // EINE REFERENZ AUF EINE PERSON

    property StateType: TStateType read get_StateType write set_StateType;

  published

  end;

  TodMeleePlayer = class(TodPlayer)

  private

    FWin: Integer;

    FLose: Integer;

    FSetsP: Integer;

    FSetsC: Integer;

    FBallsP: Integer;

    FBallsC: Integer;

    FPlaced: Integer;  

    ...

  public

    IsFree: Boolean;

    Pos: Integer;

    constructor Create(AOwner: TComponent); override;

    destructor Destroy; override;

    ...

    [AttrOd]

    property Win: Integer read get_Win write set_Win;

    [AttrOd]

    property Lose: Integer read get_Lose write set_Lose;

    [AttrOd]

    property SetsP: Integer read get_SetsP write set_SetsP;

    [AttrOd]

    property SetsC: Integer read get_SetsC write set_SetsC;

    [AttrOd]

    property BallsP: Integer read get_BallsP write set_BallsP;

    [AttrOd]

    property BallsC: Integer read get_BallsC write set_BallsC;

    [AttrOd]

    property Placed: Integer read get_Placed write set_Placed;

    ...

  published

  end;

Und hier mal ein paar Auszüge, wie ich die Referenz-Nilung erledige.
Ich hoffe, dass das einigermaßen durchschaubar ist.
Der Schwachpunkt ist derzeit sicher der Timer, macht aber praktisch keine Probleme.
Optimieren lässt sich da sicher noch einiges. Aber der Ansatz erscheint mir angenehmer als komplexe Observer-Patterns.

zusammenfalten · markieren

Delphi-Quellcode:

			  odList: TObjectList<Tod>;

constructor Tod.Create(AOwner: TComponent);

begin

  inherited;

  odList.Add(Self); // od-Objekt registrieren

  odClass := ClassName; // Klassendefinitionen für meine RTTI-Funktionen und Datenspeicherung

  if Self is Todl then

    odClass := Copy(odClass, 4 + 1, MaxInt)

  else

    odClass := Copy(odClass, 3 + 1, MaxInt);

  odName := odClass;

  odId := GetNewOdId; // eindeutige ObjektID zuweisen

end;

destructor Tod.Destroy;

begin

  odList.Extract(Self);  // Liste meiner od-Objekte

  odDestroy(Self);

  inherited;

end;

procedure odDestroy(od: Tod);

var

  I: Integer;

begin

  I := 0;

  while I <= odDataSetList.Count - 1 do  // Liste von odControlern

  begin

    if odDataSetList[I].od = od then

      odDataSetList[I].od := nil;

    if odDataSetList[I].use_od = od then

      odDataSetList[I].CalcUse;

    Inc(I);

  end;

  TimerOdDestroy.Enabled := False; // im Anschluss gleich die Refrenzen nilen

  TimerOdDestroy.Enabled := True;

end;

procedure TTimerOdDestroy.DoTimer(Sender: TObject);

begin

  TimerOdDestroy.Enabled := False;

  odCheckPointer;  // Referenzen nilen

end;

procedure odCheckPointer;

var

  iod: Tod;

begin

  for iod in odList do

  begin

    if (iod <> nil) and (not iod.HasNotOdPointer) then

    begin

      odProp.CheckPointer(iod); // Eigenschaften eines Objektes prüfen

    end;

  end;

end;

procedure TodProp.CheckPointer(const od: Tod);

var

  Context: TRttiContext;

  RttiType: TRttiType;

  PropInfo: TRttiProperty;

  F: Boolean;

  Attr: TCustomAttribute;

  Value: TValue;

  O: TObject;

  PropValue: String;

begin

  if not Assigned(od) then

    Exit;

  od.HasNotOdPointer := True;

  Context := TRttiContext.Create;

  RttiType := Context.GetType(od.ClassType);

  if Assigned(RttiType) then

  begin

    for PropInfo in RttiType.GetProperties do

    begin

      F := False;

      for Attr in PropInfo.GetAttributes do

      begin

        if Attr is AttrOd then

          F := True;

      end;

      if F then

      begin

        PropValue := '';

        Value := TValue.Empty;

        case PropInfo.PropertyType.TypeKind of

          tkClass:

            begin

              if PropInfo.IsWritable then // betrifft die Eigenschaft eine Objektreferenz?

              begin

                od.HasNotOdPointer := False;

                Value := PropInfo.GetValue(od);

                if (not Value.IsEmpty) then

                begin

                  O := Value.AsObject;

                  try  // wenn das refenzierte Objekt nicht mehr existiert oder ein Zugriff fehl schlägt, dann nilen

                    if (O <> nil) and (O is Tod) and (not odExist(O as Tod)) then

                    begin

                      Value := nil;

                      PropInfo.SetValue(od, Value);

                    end;

                  except

                    Value := nil;

                    PropInfo.SetValue(od, Value);

                  end;

                end;

              end;

            end;

        end;

      end;

    end;

  end;

  Context.Free;

end;

function odExist(od: Tod): Boolean;

begin

  Result := odList.IndexOf(od) >= 0;

end;

**stahli**

Ein prominentes Mitglied der Comunity hat mir zwischenzeitlich im Vertrauen tröstend erklärt, dass ich (zumindest aus seiner Sicht) nicht völlig meschugge bin, sondern lediglich etwas andere Ansätze und Ansprüche habe, als normale Programnmierer...

Daher mal noch allgemein gefragt:

Wenn "Delphi YE" z.B. eine Möglichkeit böte (rein hypothetisch), Objektreferenzen automatisch auf nil zu setzen, wenn das Zielobjekt aufgelöst wird, würdet Ihr dann diese Neuerung

a) freudig erregt nutzen (und künftig auf ObserverPatterns verzichten)
b) interessiert zur Kenntnis nehmen
c) regungslos zur Kentnis nehmen
d) absichtlich übersehen (und weiter ObserverPatterns schreiben)
e) aufhören, zu programmieren
f) Emba verklagen?

Es wäre doch nett, wenn man eine Objekteigenschaft MyObject.AutoObserver hätte, die man auf True setzen könnte. Alle künftigen Zuweisungen dieses Objektes an Variablen oder Eigenschaften würden "vom Compiler überwacht" (besser gesagt entsprechende automatische Funktionen implementiert), die bei der Auflösung dieses Objektes angestoßen würden und registrierte Referenzen auflösen.

Es wäre letztlich auch eine Observer-Regelung, allerdings nicht im einzelnen Objekt implementiert sondern zentral im Projekt. Das sollte dann sogar auf Variablen anwendbar sein.

Der Compiler müsste dann eine Regestrierung der Beziehung bei der Zuweisung von O1 := O; einbinden.

Variablenreferenzen auf O würden dann direkt in einer Liste verwaltet:

Zitat:

@MyVar1=O
@MyVar2=O
@MyVar3=O

Wird O freigegeben, wird den 3 Variablen nil zugewiesen und sie werden aus der Liste gestrichen.
Wird eine Variable ungültig (Prozeduraussprung), wird sie aus der Liste entfernt.

Eigenschaftsreferenzen wären etwas umfangreicher zu verwalten:

Zitat:

@MyObject1.Ref1=O
@MyObject1.Ref2=O

Die Unterscheidung nach Feldern und Eigenschaften wäre sicher schon aufwendig, aber für Profis doch bestimmt realisierbar.

Ich halte das GRUNDSÄTZLICH für denkbar und möglich (bzw. ich halte es für denkbar, dass das möglich ist).

Jeder Anfänger geht doch erst mal davon aus, dass nach

markieren

Delphi-Quellcode:

			O := TObject.Create;

O1 := O;

O.Free;

O1 = nil ist.
Man lernt natürlich, dass es nicht so ist, aber vielleicht wäre es Zeit dafür...

Nicht nur die Quellen von DBGrid und DataSource könnten bezüglich der DataSource-Freigabe deutlich schlanker werden...

**DeddyH**

Ich war bislang noch nicht in der Verlegenheit, so etwas zu brauchen, aber es wäre sicherlich in meinen Augen ein nettes Feature, solange es zuverlässig funktioniert.

P.S.:

Zitat von stahli:

Jeder Anfänger geht doch erst mal davon aus, dass nach

markieren

Delphi-Quellcode:

			O := TObject.Create;

O1 := O;

O.Free;

O1 = nil ist.

Wieso sollte O1 nil sein, wenn noch nicht einmal O nil ist?

**stahli**

Zitat von DeddyH:

Ich war bislang noch nicht in der Verlegenheit, so etwas zu brauchen, aber es wäre sicherlich in meinen Augen ein nettes Feature, solange es zuverlässig funktioniert.

P.S.:

Zitat von stahli:

Jeder Anfänger geht doch erst mal davon aus, dass nach

markieren

Delphi-Quellcode:

			O := TObject.Create;

O1 := O;

O.Free;

O1 = nil ist.

Wieso sollte O1 nil sein, wenn noch nicht einmal O nil ist?

Ich meinte nur, dass ein Anfänger das im ersten Moment vermuten würde.
Wobei, wenn dieses potentielle Feature O1 nilen würde und O einen ungültigen Zeiger hält, wäre das auch komisch.
Also würde zu dem Wunsch noch dazu gehören, dass O.Free auch automatisch O nilt.

Sofern es zuverlässig funktioniert (das natürlich immer vorausgesetzt) sollte eigentlich niemand Nachteile dadurch haben...

**Thom**

Zitat von stahli:

a) freudig erregt nutzen (und künftig auf ObserverPatterns verzichten)
b) interessiert zur Kenntnis nehmen
c) regungslos zur Kentnis nehmen
d) absichtlich übersehen (und weiter ObserverPatterns schreiben)
e) aufhören, zu programmieren
f) Emba verklagen?

Ganz eindeutig f und mit dem Schadensersatz daraus zu e übergehen!
Nein - mal im Ernst: Automatismen sind bequem, beherbergen aber auch viele Risiken und Nebenwirkungen.
Keine "Compilermagie" ist immer und überall fehlerfrei. Dafür gibt es viele Beispiele. Um nur mal zwei zu nennen: Zugriff auf COM-Objekte und überladene Methoden/Konstruktoren - davon könnte ich nach der Programmierung des Google Maps Frameworks ein oder besser gleich mehrere Lieder singen...

Dazu kommt, daß Automatismen die Exe zwangläufig aufblähen, da zusätzlicher Code generiert werden muß. Wenn ich zum Beispiel eine Demo des Frameworks mit Delphi 2010/XE compiliere, ist das Resultat etwa 2 MB groß. Das Ganze zur Kontrolle (ohne irgendwelche Veränderungen!) noch einmal durch den Compiler von Delphi 5 gejagt: Dann bleiben nur noch ca. 400-500kB übrig! Ohne jetzt über Optimierungen diskutieren zu wollen: Der Preis, der für Komfort zu zahlen ist, ist unübersehbar.

Zitat von stahli:

Jeder Anfänger geht doch erst mal davon aus, dass nach

markieren

Delphi-Quellcode:

			O := TObject.Create;

O1 := O;

O.Free;

O1 = nil ist.

Na dann sollte er eben Hilfetexte lesen (auch wenn das anstrengend ist, wie viele Hausaufgabenfrager hier im Forum beweisen) und lernen, FreeAndNil() einzusetzen.

Es gibt viele Lösungsmöglichkeiten, das von Dir beschriebene Problem anzugehen (viele davon wurden schon diskutiert).
Aber mich ausschließlich auf den Compiler verlassen!? Nicht wirklich.

Mal ein Gegenbeispiel für den Aufwand, der entstehen würde:
Eine Objektreferenz wird in einer TObjectList gespeichert. Diese wird aufgelöst, bevor das Objekt freigegeben wird. Und nun!? Jetzt müßte Code generiert werden, wie und ob auf die Objektreferenz überhaupt noch zugegriffen werden kann.

Ich denke, der einfachste und sicherste Weg ist eine saubere Programmierung im Einzelfall - auf für weniger anspruchsvolle Programmierer wie mich...