ich habe das problem das ein Objekt von verschiedenen Stellen aufgerufen wird und je nach Basisklasse soll es unterschiedliches verhalten haben. Ich versuche das mal mit etwas Quelltext zu veranschaulichen.

interface A{ 
   virtual void Log(LPCTSTR szMessage) = 0;
   virtual void a() = 0;
};
interface B{ 
   virtual void Log(LPCTSTR szMessage) = 0;
   virtual void b() = 0;
};

class C : public A, public B {
public:
  void a();
  void b();
  void A::Log(LPCTSTR szMessage)  {CString sMessage = _T("A") + szMessage; CLogFile.Write(sMessage);}
  void B::Log(LPCTSTR szMessage);
private:
  CLogFile m_LogFile;
}

void C::a(){
}

void C:b(){
}

void C::B::Log(LPCTSTR szMessage){
 CString sMessage = _T("B") + szMessage;
 CLogFile.Write(sMessage);
}

bei Funktion B::Log gibt es vom Compiler folgenden Fehler C2509

Aufgerufen wird das dann im Stile

class D {
   D(A* pIf) {m_pIf = pIf; m_pIf->Log(_T("Test D1"));}
   void FunktionA() {m_pIf->Log(_T("Test D2"));}
   virtual ~D(){m_pIf->Log(_T("Test D3"));}
}

class E {
   E(B* pIf) {m_pIf = pIf; m_pIf->Log(_T("Test E1"));}
   void FunktionA() {m_pIf->Log(_T("Test E2"));}
   virtual ~E(){m_pIf->Log(_T("Test E3"));}
}

Ich denke ich habe dabei strukturell was falsch gemacht. Ich hoffe ich bekomme von Euch Tipps wie ich das auflösen kann.

Vielen Dank schon mal im Voraus.

Klaus

Ganz davon abgesehen, finde ich das, was du vorhast, ziemlich fraglich. Warum sollte sich ein Objekt abhängig davon verhalten, unter welchem Namen ich es anspreche? Das widerspricht dem Konzept von dynamischen Typen. Du könntest das zwar implementieren, indem du das Verhalten über den statischen statt den dynamischen Typen regelst, aber den Sinn sehe ich nicht.

class A1 : public A{
	void Log(LPCTSTR s) { return LogA(s); }
public:
	virtual void LogA(LPCTSTR) = 0;
};

class B1 : public B{
	void Log(LPCTSTR s)  { return LogB(s); }
public:
	virtual void LogB(LPCTSTR) = 0;
};

class C : public A1, public B1{
	void LogA(LPCTSTR s) { /* Implementierung */ }
	void LogB(LPCTSTR s) { /* Implementierung */ }
};

interface scheint auch nur ein anderes Wort für struct zu sein.

wie ist das gemeint über die statischen Typen regeln?

Danke für den Tipp mit der Zwischenklasse.

Ich habe noch nicht verstanden was der Compiler gegen die Implementierung von B::Log hat. A::Log direkt in der Klassendeklaration frisst er doch auch.

wewnn beide Log's in der Klassendeklaration implementiert werden läuft alles durch und auch das Verhalten ist wie gewünscht.

Ich hoffe ich kann noch erleuchtet werden.

Klaus

das ist C++ in der Microsoftschen Ausführung ...

interface scheint auch nur ein anderes Wort für struct zu sein.

Das ist einfach ein #define in den Windows Header Files, der MSVC kennt "interface" nicht selbst als Keyword.

Ich habe noch nicht verstanden was der Compiler gegen die Implementierung von B::Log hat. A::Log direkt in der Klassendeklaration frisst er doch auch.

Die ganze A::Log/B::Log Geschichte ist eine non-Standard Erweiterung im MSVC.

http://msdn.microsoft.com/en-us/library/ksek8777.aspx

wewnn beide Log's in der Klassendeklaration implementiert werden läuft alles durch und auch das Verhalten ist wie gewünscht.

Möglicherweise gibt es hier eine nicht-dokumentierte Einschränkung, dass Funktionen mit gleicher Signatur entweder alle inline Definiert werden müssen, oder alle ausserhalb der Klasse.

Auf jeden Fall bist du mit der Frage hier falsch, da wie gesagt MS-spezifische Extension. Das passende Forum wäre "MFC (Visual C++)".

Auf jeden Fall bist du mit der Frage hier falsch, da wie gesagt MS-spezifische Extension. Das passende Forum wäre "MFC (Visual C++)".

Ich glaube er sollte einfach mal sagen, was er wirklich vor hat, dass bekommt man sicher auch ohne MS-spezifische Extensions hin.

Ich möchte ein Programmweites Logging verschiedener Klassen realisieren, wobei jede Klasse noch noch verschiedene andere globale Funktionen benötigt.

Bei nochmaligem Nachdenken ist der Ansatz den ich verfolgt habe wirklich nicht sinnvoll ist. Es sollen im Logfile auch Instanzen einer Klasse zu unterscheiden sein, was ja auf die Weise auch nicht geht.

Danke für die Unterstützung und die guten Denkanstösse. Ohne die Ich wohl nicht auf die Lösung gekommen wäre.

Klaus