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.

class foo {
public:
   void Func1();

private:
   void Func2();
};

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

// Func1 hat Zugriff auf b, Func2 nicht.

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

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

Es geht nicht

darkfate schrieb:

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

Es geht nicht

Danke

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.

....

Danke dir

...

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.

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.

...

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.