Referenzen auf ungültige Objekte

[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:

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.

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

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

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

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

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...

[Bummi]

@Thom

[stahli]

Nun habe ich auch noch meinen letzten Sympathisanten verloren...

Ok, Ihr geht also davon aus, dass eine solche genaralisierte Verfahrensweise nicht stabil genug implementierbar ist.
Wenn das so zutrifft, dann ist das natürlich schade.
Die Programmentwicklung selbst wäre in einigen Bereichen aber sicher einfacher (wenn man sonst Observer einsetzen müsste).

Das Aufblähen der EXE halte ich für nachrangig. Wenn man selbst entsprechende Lösungen realisiert erzeucgen die ja auch Code und ein paar KB mehr machen letzlich auch nix weiter...


Ok, zumindest weiß ich nun mal, wo Ihr Bedenken seht.
Danke für die Rückmeldungen.

[himitsu]

Zitat:

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

Sowas ist bei Objekten (also Pointern) rein teschnich garnicht möglich, denn

Keiner weiß wo alles Referenzen (Variablen, welche auf das Objekt zeigen) existieren.

Einzige Möglichkeit wäre, wenn der Programmierer irgendwie seine gewünschte Variable "registriert" und somit um das Nil-en bittet.
Solch eine Registrierungsstelle müßtest du aber erstmal implementieren, da es sowas standardmäßig nicht gibt.


Wenn du soein "ähnliches" Verhalten möchtest (nur halt andersrum), dann mußt du Interfaces verwenden.
> Hier wird dann das Objekt (also das hinter dem Interface) erst freigegeben, wenn der Referenzzähler auf 0 steht, also wenn alle Referenzen freigegeben wurden.

[stahli]

Zitat von himitsu:

Einzige Möglichkeit wäre, wenn der Programmierer irgendwie seine gewünschte Variable "registriert" und somit um das Nil-en bittet.
Solch eine Registrierungsstelle müßtest du aber erstmal implementieren, da es sowas standardmäßig nicht gibt.

Ganz genau das meine ich und würde mir eine Implementierung von Emba wünschen...
(Ich habe das zwar für meine eigenen Objekte implementiert, eine generalisierte Lösung kann ich aber natürlich nicht umsetzen.)