Aufbau ist ungefähr so:

class Widget {
public:
    Widget();
    virtual ~Widget();
private:
    virtual void Create();
};

class Window : public Widget {
public:
    Window();
    virtual ~Window();
private:
    virtual void Create();
}

Jetzt würde ich gerne mehrere Konstuktoren haben, wo ich mit jeweils anderen Werten die virtuelle Create-Methode aufrufe, deshalb ist die da. Soweit kein Problem. In der Create-Methode erstelle ich mir dann mit CreateWindowEx das Fenster, wobei sich aber das Problem ergibt, dass wenn ich ein Objekt vom Typ "Window" erstelle er den Konstruktor das Basisklasse Widget aufruft, was wegen der Vererbung ja auch logisch ist. Jetzt wird aber im Konstruktor von Widget die virtuelle Methode Create (von Widget) aufgerufen, obwohl ich ein Window-Objekt erstelle, die Reihenfolge ist also so:

Window-Objekt erstellen:
1. Window-Konstruktor wird aufgerufen
2. Widget-Konstruktor wird aufgerufen und ausgeführt
3. Widget-Create wird aufgerufen (innerhalb des Widget-Ctors)
4. Window-Konstruktor wird ausgeführt
5. Window-Create wird aufgerufen (innerhalb des Window-Ctors)

Das Problem ist also, dass beide Create-Methode aufgerufen werden, obwohl sie virtual sind. Ich denke, dass es daran liegt, dass der Widget-Ctor für das Window-Objekt ausgeführt wird, an einer Stelle, wo es das Window-Objekt noch nicht gibt, also, dass an der Stelle, wo der Widget-Ctor wegen der Vererbung aufgerufen wird noch nicht klar ist, dass es sich um ein Window-Objekt handelt und deshalb das Create von Widget genommen wird und nicht das von Window.

Die Frage ist jetzt, wie ich das umgehen kann. Eine Möglichkeit wäre, dass ich den Standard-Ctor (ohne Argumente) als protected setze und dort nicht die Create-Methode aufrufe, was meiner Meinung nach aber nicht wirklich eine Lösung sein kann, weil ich auch z.B. ein Fenster mit

Window* win = new Window();

erstellen können möchte.
Eine weitere Möglichkeit wäre im Create von Window das Objekt, welches durch das Create von Widget erstellt wurde wieder zu löschen bevor ein neues durch Window erstellt wird, was sehr unsauber wäre, denke ich.
Als letztes würde mir noch einfallen die Create-Methode public zu machen und explizit aufzurufen, was aber imo ziemlich unhandlich wäre, da man dann immer so etwas hätte:

Window* win = new Window();
win->create();
win->show();
// usw.

Wenn man jetzt viele Fenster oder später auch Buttons, etc. hat, dann ist das create schon sehr lästig, wenn man das noch extra für jedes Objekt aufrufen muss.

Jemand eine Idee, wie man das elegant lösen kann?

Window* win = createWindow();

innerhalb von createWindow kann ja dann allerhand passieren. vor allem new, und result->create().

Jetzt würde ich gerne mehrere Konstuktoren haben, wo ich mit jeweils anderen Werten die virtuelle Create-Methode aufrufe, deshalb ist die da.

dann sollte es keine Create-methode sein, sondern noch ne basisklasse mit nem konstruktor, der verschiedene werte kann.

was ist denn mit

Window* win = createWindow();

innerhalb von createWindow kann ja dann allerhand passieren. vor allem new, und result->create().

Fände ich nicht so schön, weil Extra-Funktion und so, die Klasse sollte das schon selbst erledigen. Eine Möglichkeit wäre hier wohl eine statische Memberfunktion, die mir bei jedem Aufruf ein neues Window-Objekt gibt. Aber auch nicht sehr schön meiner Meinung nach.

volkard schrieb:

Jetzt würde ich gerne mehrere Konstuktoren haben, wo ich mit jeweils anderen Werten die virtuelle Create-Methode aufrufe, deshalb ist die da.

dann sollte es keine Create-methode sein, sondern noch ne basisklasse mit nem konstruktor, der verschiedene werte kann.

Geht ja leider nicht. Ich hätte gerne einen Konstruktur, wo ich alle Werte als Parameter habe und dann andere, die wiederum nur diesen Konstruktor aufrufen. Dafür habe ich ja dann die Create-Methode, die in Wirklichkeit mehrere Parameter hat, z.b. Parent, x, y, width, height, usw., welche dann in jedem Konstruktur aufgerufen wird. Sonst hätte ich den Aufruf von CreateWindowEx (WinAPI) in jedem Ctor drin. Oder gibt es da doch ne Möglichkeit, wäre ich ebenfalls dankbar für.
Ich weiß nur, dass ich das mal ausprobiert hatte und es nicht lief, aber das kann ich ja auch nochmal ausprobieren, so ganz geläufig ist mir nicht mehr, das da genau nicht lief.

Ich hab' mich übrigens vertan, wenn in dem Ctor von Window nicht die Create-Methode aufgerufen wird, dann wird lediglich das Create von Widget ausgeführt. Geht das wirklich nicht?

Im Konstruktor ist die Virtualität von Methoden deaktiviert, da die virtuellen Methodentabellen noch nicht gesetzt sind. Und das aus gutem Grund, da die virtuellen Methoden sonst in noch nicht konstruierte Objekte hineingreifen würden.

Dazu:

http://www.artima.com/cppsource/nevercall.html

In Deinem Fall ist es vielleicht wirklich sinnvoll Konstruktion und Create zu trennen. In der Winapi sind ja die meisten Creates von Windows ziemlich ähnlich, weshalb volkards Vorschlag mit der Basisklasse hier wirklich Sinn macht.
Schau Dir mal die MFC an (bloß nicht als Beispiel für guten Code mißverstehen), aber nicht ohne Grund steckt dort die meiste Functionalität in CWnd. Wie will man schon einen schönen C++ Wrapper um eine häßliche C-Api schreiben :).

In der Winapi sind ja die meisten Creates von Windows ziemlich ähnlich, weshalb volkards Vorschlag mit der Basisklasse hier wirklich Sinn macht.

ich hab die basisklasse wegen RAII vorgeschlagen und weil man im alle von nichttrivialen members die nicht mit nem häßlichen fehleranziehenden default-ctor ausstatten muß. beides gründe, die für mich zwingend zu basisklasse oder layering (aber auf jeden fall einer konstruktorargumentweitergabe in der initialisiererliste) führen würden.

Vielen Dank.

//Edit: Danke auch für den Link, der genau mein Problem erklärt und warum dies so nicht funktionieren kann.

ich finde es aber grundsätzlich etwas seltsam, das du eine methode create() definierst. dafür ist doch der konstruktor da. wenn du das fenster über eine separate methode öffen willst, dann sollte der konstruktor ein "leeres" window-objekt erzeugen (window-handle == 0) und die methode open() erzeugt das eigentliche fenster. damit würde sich dein problem von selbst lösen.

so ein problem, wie du es beschreibst, ist fast immer ein hinweis darauf, daß mit dem programm-konzept etwas nicht stimmt.