Ich hab eine Interface hierarchie, siehe hier:

namespace interface
{
	class A
	{
	public:
	  void irgendwas() = 0;

	};

	class B: public A
	{
	public:
	  void irgendwas() = 0;
	  void mehrirgendwas() = 0;
	  static B * createInstance() { return new BImpl; }
	};
}

namespace logic
{
	class BImpl: public interface:B
	{
	public:
	  void irgendwas() {...}
	  void mehrirgendwas() {...}
          void meinepublicMethode() {...}

	};
}

Alles im ns interface ist Hierarchisch, es gibt mehrere Ebenen, so C von B von A usw.
Das Interface soll völlig frei von anderen Methoden sein (public und protected)
Es sind durchaus weitere Methoden erlaubt, die sollen nur nicht im interface auftauchen.
Daher gibt es von den relevanten Klassen eine KlasseImpl, die davon erbt, so kann createInstance einer Klasse quasi durch Polymorhpie B returnen, dort aber eine Instanz von BImpl packen.

Das funktioniert auch wunderbar, so wie es oben zu sehen ist (Syntax nicht getestet)

Mein Problem ist nun aber, ich würde gerne noch mehr Methoden und Attribute in die Klasse A packen, damit alle anderen Klassen diese automatisch mitvererben.
Diese Sachen sollen aber nicht ins interface, weil der Enduser diese nicht benutzen soll. Was kann ich am besten tun? Ich kann schlecht eine AImpl erzeugen und dort alles reinpacken, weil ich ja an die Sachen garnicht rankomme, da ja meine Klasse B von A und nicht von AImpl erbt. Das soll aber auch so bleiben, ich möchte im Interface keine Implementierungsschicht dazwischen kleben haben.
Mehrfachvererbung will ich auch vermeiden, weil es Diamantstrukturen und bei mehr Base-Klassen sogar mehrfache Diamanten erzeugt.

Ich kann auch BImpl nicht von AImpl erben lassen, weil ich dann keine Polymorphie mehr hätte (außer mit Mehrfachvererbung...)

Was gibt es noch für Lösungen? Das Konzept eines abstrakten Interfaces ist eingentlich recht sinnvoll, wie ich finde. Es hilft uns zumindest die Struktur sauber zu halten und Mehrfachvererbung würd das "sauber halten" tüchtig ruinieren

Mein Problem ist nun aber, ich würde gerne noch mehr Methoden und Attribute in die Klasse A packen, damit alle anderen Klassen diese automatisch mitvererben.
Diese Sachen sollen aber nicht ins interface, weil der Enduser diese nicht benutzen soll.

Welchen Sinn hat es, etwas nach A legen zu wollen, was eh pure virtual werden soll, obwohl ein User das dann gar nicht verwenden können soll?
Das Interface hat ja (u.A.) den Sinn, beliebige Pointer auf abgeleitete Klassen (->BImpl) an FUnktionen zu übergeben, die nur ein interface::A erwarten (Basisklassenzeiger eben).

Ansonsten mach doch die Funktion im Interface private und virtual. Das kannst du dann ruhig im BImpl nach public legen. Es bleibt trotzdem virtual.

Es soll ja eben keine Methode in A rein, weil die für das Interface nicht sichbar ist.
Wenn ich aber intern in der Logik arbeite, also nichts mit dem Interface für den Clienten am Hut habe, möchte ich aber die public Methode der abstrakten Klasse A aufrufen.
Wenn ich 10 Klassen habe, die von A erben, will ich nicht 10 mal die exakt gleiche Methode implementieren müssen. Dann hätt ich mir auch sparen können, diese nach A auszulagern

Also mit Pimpl hatte ich an der Stelle ziemliche Probleme, weil ich zum einen eine Menge Methoden durchreichen musste und zum anderen mit Vererbung-probleme bekommen habe.

Was hat das mit Pimpl zu tun?

Es soll ja eben keine Methode in A rein, weil die für das Interface nicht sichbar ist.
Wenn ich aber intern in der Logik arbeite, also nichts mit dem Interface für den Clienten am Hut habe, möchte ich aber die public Methode der abstrakten Klasse A aufrufen.
Wenn ich 10 Klassen habe, die von A erben, will ich nicht 10 mal die exakt gleiche Methode implementieren müssen. Dann hätt ich mir auch sparen können, diese nach A auszulagern

Entweder hast du ein abstraktes Interface und damit keine implementierten Methoden (eben alles pure virtual) oder du hast eine normale abstrakte Basisklasse mit einigen pure virtual Funktionen.

Wo willst du denn auf diese zusätzlichen Funktionen zugreifen und wie?
Reicht es nicht, wenn du die in a als protected deklarierst? Dann gehören die nicht zur öffentlichen Schnittstelle und clients schauen dumm aus der Wäsche.
Zur Not ist "friend" dein Freund.

Es hilft uns zumindest die Struktur sauber zu halten und Mehrfachvererbung würd das "sauber halten" tüchtig ruinieren

Wie kommst du zu dieser Aussage? Selbst Java lässt Mehrfachvererbung von Interfaces zu!

Konkret musst du die abstrakten Klassen virtuell vererben:

class B : public virtual A ...

class AImpl : public virtual A

class BImpl : public AImpl, public virtual B

Lars