Wieso keine Polymorphie in ctor?

Eisflamme

Ach Mist, jetzt hab ich erst kapiert, was Du da sagst.

Ja, das würde nicht funktionieren... na ja, zurzeit sehe ich keinen Fall, in dem ich zukünftig nochmals ableiten müsste, aber es ist nicht so ganz schön, ja... Solange es kein UB erzeugt, werde ich die Optimierung dieses Teils aber erstmal niedriger priorisieren... läuft ja gerade gut und ist erweiterbar genug (in den Richtungen, wie ich es vorhabe :))

hustbaer schrieb:

Gugelmoser schrieb:

hustbaer schrieb:

Gugelmoser schrieb:

Ich sage mal, Gott sei Danke, dass es nicht funktioniert. Es ist doch einfach unlogisch, wenn ein Elternteil auf die Gene des Kindes zugreifen könnte. Das widerspricht der Natur.

Was hat C++ mit Natur zu tun?

Ich verbinde Objektorientierung mit der Natur. Es heißt bestimmt auch nicht zum Spaß Vererbung.

Ganz schwerer Fehler, das führt bloss zu komischen Vorstellungen aus denen schlechter Code erwächst.

Das passiert halt, wenn man Gott und Familienplanung in die Programmierung bringt.

pyhax

Vielleicht kannst du es ja so machen?

#include <iostream>
#include <type_traits>

#define DEF_HAS_MEMBER_FUNC(member)                                                     \
  template <class T>                                                                    \
  class has_##member {                                                                  \
    private:                                                                            \
      class Fail {};                                                                       \
      template <class T2>                                                               \
      static constexpr auto check(double) -> decltype(&T2::member);                     \
      template <class T2>                                                               \
      static constexpr Fail check(int);                                                 \
    public:                                                                             \
      static const bool value = !std::is_same<decltype(check<T>(1.2) ), Fail>::value;   \
  };

DEF_HAS_MEMBER_FUNC(constructorHook1)

class BaseInterface { 
  public:
    virtual void doSomething() = 0;
};

template <class Child>
class Base: public BaseInterface {
  public:
    Base() {
      static_assert(has_constructorHook1<Child>::value, "Need constructHook1 member.");
      std::cout << "-------------------------" << std::endl;
      std::cout << "Start init\n";
      std::cout << "Calling some specialized algorithm" << std::endl;
      Child::constructorHook1(this);
      std::cout << "Finish init.\n";
      std::cout << "-------------------------" << std::endl;
    }
};

class Child: public Base<Child> {
  protected:
    static void constructorHook1(Base<Child>*) { std::cout << "Constructor in child.\n"; }
  public:
    virtual void doSomething() { std::cout << "Doing something.\n"; }
    friend class Base<Child>;
    friend class has_constructorHook1<Child>;
};

int main() {
  Child c;
  BaseInterface * base_ptr = &c;
  base_ptr -> doSomething();
}

templates + moc ist so ein Problem...
http://developer.qt.nokia.com/doc/qt-4.8/moc.html#limitations

Ich frag mich:
Wie sind die Widgets angeordnet? Willst du ein Widget an einer Position durch ein anderes austauschen (immer nur eine Instanz aus dem gesamten Child-Class-komplex), oder hast du irgendwie Tabs oder eine andere Anordnung, so dass immer mehrere Instanzen unterschiedlicher Child-Klassen gleichzeitig existieren? Evtl. sogar eine statische Anordnung, die VOR dem kompilieren fest steht?

Eisflamme

pyhax:
Ich schaue mir das später nochmal an, bin gerade zu fertig, war eben laufen. Danke in jedem Fall schon Mal für die Mühe!

arghonaut:
Also genau, ich habe einige Tabs. Innerhalb dieser Tabs findet sich jeweils ein Kopfteil (unterscheidet sich je Tab) und eine Tabelle (unterscheidet sich hauptsächlich von der 2. Spalte vom Tab, aber es gibt auch geringere, andere Unterschiede). Neben Kopf und Tabelle unterscheiden sich die Tabs grundsätzlich noch weiter durch Buttons, die ich noch nicht eingebaut habe... Weiß auch noch nicht, wo ich die genau hinstellen möchte.

Auch die Tabellen werden sich später vermutlich noch weiter in ihrer Struktur ändern als nur durch den Inhalt der zweiten Spalte.

Weiters ändert sich die Anzahl der Zeilen pro Tabelle zwischendurch, weswegen ich diese hin und wieder neu erstelle. Man kann (später) dynamisch Zeilen hinzufügen oder abziehen, was die zu Grunde liegende Datenstruktur ändert. Das UI nach der Datenstruktur auszurichten, indem ich dort auch Zeilen lösche und hinzufüge, löse ich gerade dadurch, dass ich die Tabelle einfach neu erstelle. Es macht nämlich als Benutzer keinen optischen Unterschied und war fürs Erste jetzt natürlich auch einfacher zu implementieren.

Da geht wohl noch einiges eleganter, aber es lässt sich gerade recht einfach und zentral ändern und in die Richtung, die ich möchte, auch gut weiterentwickeln. Wenn ich kein UB erzeuge, sehe ich daher nicht viel Anlass dazu es zu ändern.

Natürlich freue ich mich trotzdem auf Anregungen, falls man jetzt schon welche geben kann.

Zwei Fragen:
* Ist für dich "Tabelle"=="QTableView"?
* Was heißt "grafische Rafinessen", die du noch einbauen willst?

Generell würde ich sagen:
GUI komplett mit dem Designer gestalten. TabWidget ins Fenster ziehen, anpassen (Anzahl Tabs, Beschriftungen, usw.), dann in einem Tab das allgemeine Layout einrichten, alle Elemente markieren, kopieren, ins nächste Tab einfügen und so ändern, wie du es dort brauchst.
Wenn Tabelle tatsächlich ein QTableView ist, kannst du die Daten eh schon ganz abstrakt per Model liefern.