Templatespezialisierung und Vererbung

[wxSkip]

Vielleicht ginge es ja, eine Klasse foo_base<T> zu machen und dann foo<T> : foo_base<T> ohne weitere Member und foo<int> : foo_base<int> mit extra-Membern

[typedef wxSkip inchoate;]

wxSkip schrieb:

Vielleicht ginge es ja, eine Klasse foo_base<T> zu machen und dann foo<T> : foo_base<T> ohne weitere Member und foo<int> : foo_base<int> mit extra-Membern

Beizeiten hilft auch ein einfaches typedef weiter.

[wxSkip]

typedef wxSkip inchoate; schrieb:

wxSkip schrieb:

Vielleicht ginge es ja, eine Klasse foo_base<T> zu machen und dann foo<T> : foo_base<T> ohne weitere Member und foo<int> : foo_base<int> mit extra-Membern

Beizeiten hilft auch ein einfaches typedef weiter.

Meinst du so was?

template<typename T> class foo{};

typedef foo<int> FooIntBasic;

template<> class foo<int> : public FooIntBasic{...};

[CStoll]

Das dürfte genauso verkehrt sein wie die ursprüngliche Lösung - auch wenn du der Klasse einen anderen Namen gibst, erst dein foo<int> immer noch von sich selber.

@EOutOfResources: Was hast du mit dem Konstrukt eigentlich vor? Und wie stark unterscheidet sich dein foo<int> von jedem anderen foo<T>?

[wxSkip]

CStoll schrieb:

Das dürfte genauso verkehrt sein wie die ursprüngliche Lösung - auch wenn du der Klasse einen anderen Namen gibst, erst dein foo<int> immer noch von sich selber.

@EOutOfResources: Was hast du mit dem Konstrukt eigentlich vor? Und wie stark unterscheidet sich dein foo<int> von jedem anderen foo<T>?

Das Paradebeispiel wäre hier ja AFAIK std::vector<bool> mit inverse oder so etwas ähnlichem...

[EOutOfResources]

CStoll schrieb:

@EOutOfResources: Was hast du mit dem Konstrukt eigentlich vor? Und wie stark unterscheidet sich dein foo<int> von jedem anderen foo<T>?

foo<int> sollte lediglich ein paar zusätzliche Funktionen anbieten.

[CStoll]

@wxSkip:
vector<bool> hat afaik auch alle anderen vector<>-Methoden auch neudefiniert, um die kompaktere Speicherungsform umzusetzen - Methoden wie flip() sind da nur eine Zugabe.

@EOutOfResources:
Wenn du nichts grundlegendes an der Klassenstruktur ändern willst, kannst du auch eine normale Klasse von foo<int> ableiten, die die zusätzlichen Methoden anbietet. Andernfalls solltest du die gemeinsamen Daten in eine gemeinsame (Template-)Basisklasse zusammenfassen, wie es wxSkip vorgeschlagen hat.

[Dravere]

EOutOfResources schrieb:

CStoll schrieb:

@EOutOfResources: Was hast du mit dem Konstrukt eigentlich vor? Und wie stark unterscheidet sich dein foo<int> von jedem anderen foo<T>?

foo<int> sollte lediglich ein paar zusätzliche Funktionen anbieten.

Kannst du diese zusätzlichen Funktionen nicht auch als freie Funktionen anbieten? Allenfalls kannst du sie auch als friend deklarieren.

Grüssli

[EOutOfResources]

Dravere schrieb:

Kannst du diese zusätzlichen Funktionen nicht auch als freie Funktionen anbieten?

So habe ich es auch implementiert gehabt, aber das Interface gefiel mir nicht.

[Paranominalkritizist]

EOutOfResources schrieb:

So habe ich es auch implementiert gehabt, aber das Interface gefiel mir nicht.

freie Funktionen gehören genauso zum Interface einer Klasse. Und wenn für die Funktion nur das öffentliche Interface notwendig ist, dann sollte die Funktion auch nicht in die Klasse. Die geringst mögliche Bindung an eine Klasse.
Wir sind hier ja nicht bei Java, wo ALLES in eine Klasse gepackt werden muss, selbst die main(). Durch freie Funktionen programmierst du kein schlechteres C++ - eher besseres.

[Nexus]

Paranominalkritizist schrieb:

freie Funktionen gehören genauso zum Interface einer Klasse. Und wenn für die Funktion nur das öffentliche Interface notwendig ist, dann sollte die Funktion auch nicht in die Klasse. Die geringst mögliche Bindung an eine Klasse.
Wir sind hier ja nicht bei Java, wo ALLES in eine Klasse gepackt werden muss, selbst die main(). Durch freie Funktionen programmierst du kein schlechteres C++ - eher besseres.

Sehr gut zusammengefasst!

Artikel von Scott Meyers zum Thema: http://drdobbs.com/cpp/184401197

Die Meinung, dass freie Funktionen "weniger objektorientiert", "schlechteres C++" oder sonst irgendwie prinzipiell minderwertig sind, ist eines der übelsten C++-Irrtümer. Am schlimmsten finde ich Leute, welche in einer Bibliothek den Originalcode verändern, nur um obj.Func() statt Func(obj) schreiben zu können. Man könnte meinen, Syntax allein bestimme über die Qualität einer Schnittstelle.