entgegen aller Warnungen hab ich in einem aktuellen Projekt ziemlich viel mehrfach vererbt. Das ganze ist der Tatsache geschuldet, das Design und Implementierung komplett getrennt sein sollten (Header komplett Plattformunabhängig, Implementierung DAO und Windows) und die einzelnen Abstraktionebenen unabhängig voneinander in verschiedenen Projekten genutzt werden. Wenn ich zu Projektbeginn schon ein bisschen mehr Erfahrung mit Templates gehabt hätte, wäre die Lösung sicher eleganter geworden - egal:

template<class TDbReadWrapper>
class DbObserver : public IDbReadObserver
{
	DbOpener* GetOpener(void){return m_pDbWrapper;}
        bool EqualsPtr( const void* pPtr )const//tests for equality to the given Ptr
		{ 
			return ( (pPtr >= m_pDbWrapper) && (pPtr < ( m_pDbWrapper + sizeof(TDbReadWrapper) ) ) );//liegt der Ptr im Speicherbereich des m_pDbWrapper???
		}
        TDbReadWrapper* m_pDbWrapper;
}

Ich muß zu bestimmten Gegebenheiten checken, ob ein bestimmter DbOpener dem gewrapptem m_pDbWrapper entspricht. Einen vernünftigen op== kann ich dafür nicht schreiben. Also vergleiche ich die Ptr. Der von GetOpener zurückgelieferte Ptr zeigt aber schon auf einen anderen Speicherbereich als der zugehörige m_pDbWrapper. Also vergleiche ich in EqualsPtr, ob der gegebene Ptr in dem Bereich liegt, den die Instanz, auf die m_pDbWrapper zeigt belegt. Es scheint auch zu funktionieren. Giebt es dafür eine schönere Lösung, ohne RTTI?

Danke für Eure Hilfe

Ich bin dieser Sache dahingehend aus dem Weg gegangen, dass ich eine virutelle Funktion definiert habe:

virtual ETYPE GetType () { return ETYPE::E_MYSPECIALCLASS; }

und diese in Abhängigkeit von der Implementierungs-Klasse ändere. Auf diese Weise kann ich immer abfragen was für ein Typ sich tatsächlich hinter der Schnittstelle verbirgt.

DbOpener* GetOpener(void){return m_pDbWrapper;}

Diese Funktion liefert dir doch den Pointer zurueck.. was hindert dich daran diesen mit einem anderen Pointer zu ueberpruefen?

struct BaseA
{
	virtual void DoSomeThingA(void) = 0;
	bool bMemberA_;
};
struct BaseB
{
	virtual void DoSomeThingB(void) = 0;
	bool bMemberB_;
};
struct MultiDerived : public BaseA, public BaseB
{
	void DoSomeThingA(void){ cout << "I'm an A" << endl; }
	void DoSomeThingB(void){ cout << "I'm an B" << endl; }
	bool bSomeOther_;
};
template < class TWrapped >
struct Wrapper
{
	Wrapper( TWrapped* pWrap ) : pWrapped_(pWrap){}
	BaseB* GetMyB(void){ return pWrapped_; }
	TWrapped* pWrapped_;
};

Wrapper<MultiDerived>* pWrapper = new Wrapper<MultiDerived>( new MultiDerived );
	BaseB* pBaseB = pWrapper->GetMyB();
	assert( (pBaseB >= (void*)pWrapper->pWrapped_ ) && (pBaseB < ((void*)(pWrapper->pWrapped_ + sizeof(MultiDerived)))) );//OK
	assert( ((void*)pWrapper->pWrapped_) == pBaseB );//failure

Hab der Einfachheit halber mal alles public in structs gesteckt. Den Wrapper könnte ich mir für das Beispiel eigentlich sparen. Jedenfalls Zeigt pWrapper->pWrapped_ auf was anderes als der return von GetMyB (auch irgendwie logisch). Ich sehe hal keinen anderen weg als so festzustellen, ob ein Pointer dazugehört oder nicht.
Frage war eigentlich eher, ob das in irgendeinem Fall Fehlschlagen kann.

Danke schonmal für Deine Hilfe, das hat mich zumindest mal animiert das ganze in ein kleines Beispiel zu packen.

Wäre schon sauberer, ich müßte dann aber jedes Objekt, mit jedem beliebigen anderen im Projekt vergleichen können, d.h. nur für diesen einen Test jedem Objekt einen op== spendieren. Wie gesagt, das sind größtenteils Datenbank Verbindungen (Wrapper und sonstiges DB-Zeug ), und theoretisch wäre es möglich das zwei Instanzen die gleichen Verbindungsdaten haben und trotzdem unterschiedliche Zwecke erfüllen (Reader, Writer).
Im Prinzip alles nur Ausreden, um nicht den Aufwand mit dem op== zu haben ...

Der Compiler ist in der Lage jedes Objekt über die Schnittstelle der Oberklasse anzusprechen (und auch automatisch).
Das funktioniert solange, wie man nicht auf die Idee kommt an dieser Stelle mit Void-Pointern zu arbeiten.

Wenn du einen void-Pointer übergibst nimmt der Compiler einfach den Pointer den er hat. Wenn du aber DbOpener* übergibst wandelt er Compiler die Adresse automatisch um.

Böse (und ohne Nutzen, da m_pDbWrapper immer DbOpener als Basisklasse haben muss):

bool      EqualTo  (const void * pPtr )const;

Richtig:

bool      EqualTo  (const DbOpener* pPtr )const;

, da m_pDbWrapper immer DbOpener als Basisklasse haben muss):

Wer sagt das?

bool EqualTo (const DbOpener* pPtr )const;

Auch richtig, setzt aber voraus, das deine 1. Annahme stimmt und legt mich auf DbOpener fest. Das ist für den Zweck, den die Funktion erfüllen soll nicht unbedingt zwingend.

Ich gebe Dir recht, das die Variante mit dem void* dort sicher nicht die schönste ist. Ich werd nochmal darüber nachdenken, ob die Einschränkung, das ich nur mit DbOpener vergleichen kann irgendwie hinnehmbar ist.
Zumindest habe ich jetzt gelernt, warum eine abstract class keine Datenmember haben sollte .

Wenn das Objekt das du vergleich willst nicht über die Schnittstelle von DbOpener verfügt, dann kann es nicht identisch mit m_pDbWrapper sein.
(Einzige Ausnahme: Du hast das Objekt ueber die Schnittstelle der zweiten
Basisklasse vorliegen und du willst es damit vergleichen. Ist nicht schön
aber kommt vor.
An der Stelle könntest du allerdings einen C-Cast verwenden, um die richtige
Adresse heraus zu finden. Der ist zwar nicht sicher aber da es dir bei dem
Pointer nur um einen Adressvergleich geht fände ich dies besser.)