Auf "überliegende" Klasse zugreifen ?

[Olli73]

Zitat:

Zitat von stiftII (Beitrag 1270347)

Danke nochmal.
Okay dann versuch ichs mal zu erklären :). Es soll ein Programm werden welches Pokertische verwaltet. Und es arbeitet mit einer Hauptklasse die 3 Threads aufruft.. So in Etwa:

Delphi-Quellcode:

    TMainClass = class
      ID:integer;
      UsefulThreadA:TUsefulThreadA;
      UsefulThreadB:TUsefulThreadB;
      UsefulThreadC:TUsefulThreadC;
      protected
        constructor Create;
    end;

Nun findet UsefulThreadA eine ID heraus und soll sie TMainClass übergeben. Sobald die Information zur Verfügung steht starten UsefulThreadB und UsefulThread C.

Also müssen UsefulThreadB und C wissen, was in TMainClass(.id) steht.

Wenn das ganze auch noch in Threads ablaufen soll, darfst du sowieso nicht einfach aus dem Thread heraus auf MainClass zugreifen. Dann musst du das ganze mittels Synchronize und/oder CriticalSections absichern...

Gruß,
Olli

[stiftII]

Hey danke für den Comment.
Ich benutze dafür CriticalSections. Wobei ich gelesen habe, dass es bei Lesezugriffen eigentlich keine Speicherverletzungen gibt.

Werds wohl jetzt so in etwa machen wie Dejan Vu beschrieben hat.

Allerdings schade, dass ich die andere Möglichkeit (Die ich zugegebenermaßen nicht ganz verstehe) nicht verwenden kann.

Programmcode sieht da so aus:
Falls mal jemand schauen mag warum das eine Zugriffsverletzung gibt.

Delphi-Quellcode:

unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;

type

  { TForm1 }

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    procedure FormCreate(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;

  TMainClass = class;

    TUseFulClass = class
      private
        FMainClass: TMainClass;
      public
        function DoSomething:boolean;
    end;

    TMainClass = class
      usefulinfos:string;
      UsefulClass:TUsefulClass;
      protected
        constructor Create;
    end;



var
  Form1: TForm1;
  MainClass:TMainClass;

implementation

{$R *.lfm}

   { TForm1 }
constructor TMainClass.Create;
begin
    UsefulClass := TUseFulClass.Create;
    //UsefulClass.FMainClass := TMainClass.Create;  // Macht ja nicht so viel Sinn
end;

   procedure TForm1.Button1Click(Sender: TObject);
   begin
     MainClass := TMainClass.Create;
     MainClass.usefulinfos:= 'Very useful Infos';
     Mainclass.usefulClass.DoSomething;
   end;

procedure TForm1.FormCreate(Sender: TObject);
begin

end;

   function Tusefulclass.DoSomething:Boolean;
   begin
      //Access Violation
      Form1.Caption:= fmainClass.usefulinfos;


   end;


end.

[Olli73]

Zitat:

Zitat von stiftII (Beitrag 1270351)

Delphi-Quellcode:

constructor TMainClass.Create;
begin
    UsefulClass := TUseFulClass.Create;
    //UsefulClass.FMainClass := TMainClass.Create;  // Macht ja nicht so viel Sinn
end;

Delphi-Quellcode:

constructor TMainClass.Create;
begin
    UsefulClass := TUseFulClass.Create;
    UsefulClass.FMainClass := self;  // aber das hier Würde zumindest funktionieren, auch wenn es etwas unschön ist, wie du an den anderen Kommentaren siehst
end;

Edit: Etwas besser wäre es, wenn du TUseFullClass einen entsprechenden Constructor mit Parameter "Owner" (bzw. "MainClass") hinzufügst und denn so aufrufst:

Delphi-Quellcode:

UsefulClass := TUseFulClass.Create(self);

[stiftII]

Hey, das funktioniert ja wunderbar :D.

Danke nochmal für die Ausführungen :)

[himitsu]

Zitat:

Zitat von Olli73 (Beitrag 1270338)

Hast du den Code gekürzt oder sieht der wirklich so aus?

Denn darin gibt es keine Konstruktoren und diese werden auch nicht aufgerufen (um die Instanzen/Objekte zu erstellen).

Wenn ihm die Standard-Constructoren vom TObject reichen, weil er im Constructor nichts machen will, dann braucht er natürlich sselber keine zu implementieren.


Da sich die Klassen aber gegenseitig kennen sollen, oder zumindestens die eine Klasse die Andere,
dann sollte man der einen Klasse schon einen Constructor geben, wo man ganz praktisch den Instanzzeiger der anderen Klase mitgeben könnte, welchen sie sich dann in einem privatem Feld speichert.

Also dein FMainClass wäre dann privat und nicht public verfügbar (maximal als ReadOnly-Property).

[Olli73]

Zitat:

Zitat von himitsu (Beitrag 1270382)

Zitat:

Zitat von Olli73 (Beitrag 1270338)

Denn darin gibt es keine Konstruktoren und diese werden auch nicht aufgerufen (um die Instanzen/Objekte zu erstellen).

Wenn ihm die Standard-Constructoren vom TObject reichen, weil er im Constructor nichts machen will, dann braucht er natürlich sselber keine zu implementieren.

Anstatt "und diese werden nicht aufgerufen" meinte ich eigentlich "es werden überhaupt keine Konstruktoren aufgerufen" und deshalb hat er auch die Zugriffsverletzung bekommen; ein "create" hat er erst später ergänzt, wie man am "edit" sieht. Außerdem muss er ja irgendwie/irgendwo die (privaten) Felder füllen für den gegenseitigen Zugriff.

Zitat:

Da sich die Klassen aber gegenseitig kennen sollen, oder zumindestens die eine Klasse die Andere,
dann sollte man der einen Klasse schon einen Constructor geben, wo man ganz praktisch den Instanzzeiger der anderen Klase mitgeben könnte, welchen sie sich dann in einem privatem Feld speichert.

Hatte ich ja in meinem Edit zu #13 geschrieben - OK, ich habe vergessen zu erwähnen, dass er es sich dort im Konstruktor dann in einem privaten Feld speichern soll.

Gruß
Olli

[Blup]

Zitat:

Zitat von stiftII (Beitrag 1270351)

Ich benutze dafür CriticalSections. Wobei ich gelesen habe, dass es bei Lesezugriffen eigentlich keine Speicherverletzungen gibt.

Sobald irgendwer die Variable beschreibt (z.B. der Hauptthread), während irgendein anderer Thread lesend auf die Variable zugreift, kann es krachen.
In einem solchen Fall gibt es keine direkte Zugriffsverletzung ("Speicherverletzungen" ist nicht das richtige Wort). Der gelesene Wert ist aber ungültig.
Ist das z.B. eine Variable die einen bestimmten Speicherbereich adressiert (z.B. ein Objekt), kann als Folge irgendwo eine Zugriffsverletzung auftreten.
Zumindest ist der weitere Programmverlauf dann nicht mehr vorhersehbar.