Ich steht abundzu vor diesem Problem:

ich hätte gerne eine Basisklasse wie diese (sehr vereinfacht):

class Form
{
 int a;
};

und folgende subklassen:

class Kreis : public Form
{
 int b;
};

class Rechteck : public Form
{
 int c;
};

wenn ich jetzt einfach ausgedrückt das hier machen will:

...
void addForm(Form *form);
...
Rechteck *re = ne Rechteck();
addForm(re);
...

Dann geht das zwar irgendwie, aber wie finde ich in addForm herraus was da jetzt eigentlich für eine Basisklasse reinkommt?
ich hab dann ein Form und muss auf "gut glück" casten, was natürlich nur geht, wenn ich genau weiss was reinkommt.

meiner meinung ist die lösung irgendwas mit "dynamischen casts", aber ich habe da noch nicht 100%ig durchgeblickt.

Wäre nett wenn mir jemand helfen könnte! Danke!

Gruß
Marcel

zB

enum Formen { Kreis,Rechteck };

class Kreis {

   Formen meineForm;
 public:
   Kreis():meineForm(Kreis) {};

   Formen whoamI() { return meineForm; }

};

So wäre mein Lösungsansatz

also willste lauter konkrete funktionen bauen, die einen typen speziell behandel?

void addRechteck(Rechteck* re);
void addKreis(Kreis* kr);
...

ok, mach das. nu bleibt noch die frage, was bei Form* passieren soll.

void addForm(Form* f){
   f->dispatchAddForm();
}

//virtual Form::dispatchAddForm()=0;

Kreis::dispatchAddForm(){
   addKreis(this);
}
Rechteck::dispatchAddForm(){
   addRechteck(this);
}

um dynamic-cast oder switch bei sowas zu nehmen, mußt du erst bei mar++us einen antrag stellen. weil das ist fast immer schlecht.

adsci schrieb:

meiner meinung ist die lösung irgendwas mit "dynamischen casts", aber ich habe da noch nicht 100%ig durchgeblickt.

So denken nicht gerade wenige Leute, idR ist das aber keine gute Idee und macht wirklich nur in wenigen Fällen Sinn. Besser ist es, du lagerst die Sachen, die du spezifisch für die abgeleiteten Klassen behandeln musst, in virtuelle Funktionen aus. Du musst dir so zwar etwas mehr Gedanken über dein Design machen, im Endeffekt lohnt sich das aber, da dir auch schneller Schwächen auffallen. Zudem ist es nicht nur strukturell sauberer, sondern bedeutet praktisch auch keinen Overhead. Den indirekten Funktionsaufruf kannst du dir schenken, im Gegensatz zu dynamic_cast und RTTI.