Im Grunde will ich so etwas wie
"Komponente"
haben. Eine Komponente muss nichts können, sondern einfach nur den Typ haben, nur wie schaffe ich es, dass keine leeren Komponenten erzeugt werden?
Der Weg, den ich kenne, ist es irgendeine Methode wie foo()=0; einzubauen. Aber meine Komponente hat keine Methoden.

Zum zweiten:
Eine Klasse soll aus solchen Komponenten bestehen, ich möchte aber, dass bestimmte Typen von Komponenten (sozusagen die Grundkomponenten) auf jeden Fall vorkommen, wie macht man das halbwegs elegant?

Und nochwas:
Jeder Komponententyp darf nur einmal vorkommen, um Probleme zu vermeiden.

Aber meine Komponente hat keine Methoden.

Und wie, was und wann tut denn eine solche Komponente irgendwas?

Falls es Dir nur darum geht, eine abstrakte Klasse ohne Methoden zu machen:
Mach einfach den Destruktor rein virtuell und implementiere ihn trotzdem.

Eine Komponente muss nichts können, sondern einfach nur den Typ haben

Design-Kritik: Es klingt so, als wolltest Du eine dynamic_cast-Orgie starten. Igitt!

Also was ich haben möchte ist so etwas wie

Toolkit
{
 Grundkomponente A
 Grundkomponente B
 Grundkomponente C
 Andere Komponenten
}

Wobei es bei andere Komponenten jede Menge Möglichkeiten geben kann. Und nur weil ich eine Komponente mehr haben möcht, will ich nicht vom Toolkit erben müssen inder Art:

erweitertes Toolkit: Toolkit
{
 Zusätzliche Komponente D
}

Gibts da irgendwas eleganteres?

Toolkit
{
Komponenten
}

Komponente
{
//einfach damit das Toolkit sie annehmen kann
}

KomponentenTypA
{
  tuWas()  -> müssen alle von Typ A haben
}

KomponentenTypAImplementierung
{
//zusätzlich
  meine Variablen
  tuWasAnderes()
}

Das riecht sowieso schon nach Design-Fehler

Vererbung niemals, um sich TippArbeit zu sparen.
"Ist implementiert mit" ist eine Composition, kein Inheritance !

class erweitertes_Toolkit
{
    Zusätzliche_Komponente D;
    Toolkit                Base;
};

Ist eh sauberer im Design ...

Es sei denn, Toolkit und erweitertes_Toolkit sollen gleichbehandelt werden, also Codeanteile machen keinen unterschied zwischen den Beiden.
Dann ist vererbung natuerlich angebracht und auch notwendig!
Dann haben wir aber auch eine "Ist ein" Beziehung !

Ciao ...

class ComponentA;
class ComponentB;
...

class Toolkit
{
public:
  virtual ComponentA* GetComponentA() = 0;
  virtual ComponentB* GetComponentB() = 0;
  ...
};

Ich denke mal, in C++ wird so was eher über Type Traits gelöst?

Bei uns im Java-Projekt gibt es auch solche leeren Interfaces. Dann wird einfach abgefragt, ob das Objekt eine Instanz vom Interface-Typ ist, und es wird dann darauf entsprechend reagiert. Ziemlich Un-OO.

Ich denke mal, in C++ wird so was eher über Type Traits gelöst?

Wenn der dynamische Typ zur Compile-Zeit nicht bekannt ist, helfen Type Traits nicht weiter. Type Traits sind auch eher dazu da, Eigenschaften von bereits bekannten Typen zu erfragen.

Thingy t = ....;
if (t instanceof SuchAndSuch) {
  SuchAndSuch s = (SuchAndSuch) t;
  s.transmogrify();
  ....
}

-->

Thingy* t = ....; // Thingy is a polymorphic class type
if (auto s = dynamic_cast<SuchAndSuch*>(t)) {
  s->transmogrify();
}

K*cke sieht das aber in beiden Fällen aus, ob Java, ob C++.