[ERLEDIGT] Zugriff auf Klassenfremde Methoden

darkfate

Hallo Leute,

Ich habe eine Klasse (A) in der die Methode implementiert ist:

virtual wxToolBar *GetToolBar() const { return m_frameToolBar; }

Nun leite ich eine Klasse (B) von (A) ab,
diese hat selbstverständlich Zugriff auf diese Methode.

Ich möchte aus einer dritten Klasse (C),
welche nirgendwo aus der Klasse (A) abgeleitet wird
auf die Methode GetToolBar von (B) zugreifen können.

Kann ich es so kapseln dass nur eine Methode
aus der Klasse (C) nur auf diese Methode (GetToolBar)
aus der Klasse (B) zugreifen kann?

Sozusagen: Einer KlassenMethode eine Friend Methode zuordnen.

Die Klasse B ist ein einfaches Fenster während
die Klasse C ein OpenGL-Canvas ist der je nach
Interaktion die Schaltflächen auf der Toolbar
freischalten soll.

SeppJ

Du kannst ganz direkt Memberfunktionen anderer Klassen als friend deklarieren (sofern diese sichtbar sind):

class foo {
public:
   void Func1();

private:
   void Func2();
};

class bar {
private:
   int b;
   friend void foo::Func1( );
};

// Func1 hat Zugriff auf b, Func2 nicht.

darkfate

SeppJ schrieb:

Du kannst ganz direkt Memberfunktionen anderer Klassen als friend deklarieren (sofern diese sichtbar sind):
class foo {
public:
   void Func1();

private:
   void Func2();
};

class bar {
private:
   int b;
   friend void foo::Func1( );
};

// Func1 hat Zugriff auf b, Func2 nicht.

Ich möchte aber:

class foo {
public:
   virtual void funca();
   friend void bar::funcb()
};

class bar {
private:
   int b;
   void funcb( );
};

// Func1 hat Zugriff auf b, Func2 nicht.

Die Funktion: "friend void bar::funcb()" soll nur auf die Funktion funca zugreifen dürfen. funca() erledigt dann den Rest.

Der normale Aufruf aus der Klasse (B) lautet:

GetToolBarGetToolBar()->EnableTool(IDM_TOGGLE_LINE,false);

Kann ich es irgendwie erreichen dass ich es aus der Klasse (C) so aufrufen kann:

B::GetToolBar()->EnableTool(IDM_TOGGLE_LINE,false);

Ich glaube dass ich mich mittlerweile mit Events auseinandersetzen muss...

darkfate

Ich bestehe nicht auf diese Lösung, die auch wahrscheinlich nicht geht. Ich bin für intelligente Ideen offen... Ein schlichtes "Nein, es geht nicht." würde mir im Moment auch helfen.

pumuckl

darkfate schrieb:

Ein schlichtes "Nein, es geht nicht." würde mir im Moment auch helfen.

Es geht nicht

darkfate

pumuckl schrieb:

darkfate schrieb:

Ein schlichtes "Nein, es geht nicht." würde mir im Moment auch helfen.

Es geht nicht

Danke

pumuckl

Außer über sehr skurrile Umwege. Man kann sich zunutze machen, dass alle Member von A Zugriff auf andere private Member von A haben. Man nehme also ein struct, mache es zu einer öffentlichen anonymen Klasse in A, von der A ein einiges statisches Member hat, und gebe ihm einen ebenso privaten operator() mit und deklariere die Funktion in B als friend des structs. Der op() des structs hat nichts zu tun als die fragliche Funktion in A aufzurufen. Damit hat die Funktion in B nur indirekt Zugriff auf die Funktion in A, und zwar nur auf diese, weil sie ja nicht Freund von A selber ist:

class A;
class B
{
public:
  void bar(A const&);
  void bar2(A const&);
};

class A
{
   void foo() const {std::cout << "A::foo()" << std::endl;}
public:
   static struct {
   private:
     void operator()(A const& a) const 
     {a.foo();}
     friend void B::bar(A const&);
   } CallFoo;

};

void B::bar(A const& a)
{
  A::CallFoo(a);
}

//void B::bar2(A const& a)
//{
//  A::CallFoo(a); //Fehler: bar2 ist kein friend des anonymen structs
//}

int main()
{
  A a;
  B b;
  b.bar(a);
}

Kompiliert unter gcc, nicht getestet unter MSVC.

darkfate

pumuckl schrieb:

....

Danke dir

Simon2

pumuckl schrieb:

...

static struct {
   private:

...

Gibt es einen konkreten Grund dafür, dass Du da nicht class nimmst? Gibt es keine anonyme Klassen?
Oder einfach, weil man so "besser sieht, was gemeint ist"?
Aber diese Form der "Verantwortungsverlagerung" finde ich gar nicht so schlecht!
Aber in 99,99% der Fälle tut's wohl auch ein public wrapper.
Gruß,

Simon2.

pumuckl

Simon2 schrieb:

Gibt es keine anonyme Klassen?
Oder einfach, weil man so "besser sieht, was gemeint ist"?

Letzteres, es gibt auch anonyme Klassen. Ursprünglich hatte ich geplant, jedem A ein eigenes anonymes Objekt mitzugeben, das eine Referenz auf das zugehörige A hält.

Aber diese Form der Verantwortungsverlagerung finde ich gar nicht so schlecht!

Ich schon Wenn sowas nötig scheint, läuft meist irgendwas schief. Wenn ich solche Konstrukte sehe denk ich mir meist "muss das so oder will da jmd einen Designfehler ausbügeln?" Ich habs nur aus rein technischem Interesse mal versucht, das gestellte Problem zu lösen...

Andererseits: Eine einfache public-Funktion hätte es auch getan ...

Auf die hätte wiederum jeder Zugriff.

Simon2

pumuckl schrieb:

...

Aber diese Form der Verantwortungsverlagerung finde ich gar nicht so schlecht!

Ich schon ...

Ich hätte mich genauer ausdrücken sollen: "... diese Form der Verantwortungsverlagerung zu kennen, finde ich gar nicht so schlecht!..."
Bei ir geht immer schon eine fette Warnlampe an, wenn ich "friend" irgendwo sehe und habe es (wenn ich mich recht entsinne) bislang immer vermeiden können.
Aber EIN Grund für meine Abneigung war eben genau die Unmöglichkeit, den Zugriff irgendwie einzugreifen - und das kann man wohl umgehen.

pumuckl schrieb:

...

Andererseits: Eine einfache public-Funktion hätte es auch getan ...

Auf die hätte wiederum jeder Zugriff.

Deswegen hatte ich das gleich korrigiert - aber wohl immer noch zu langsam für Dich.

Gruß,

Simon2.