Erbt hier die Spezialisierung von der Basisklasse mit dem Templateparameter int oder von sich selbst (was ja nicht geht)?

MfG, EOutOfResources

Was du möchtest, lässt sich nur mit Copy-Paste erreichen. Was du solltest, ist eine explizite Spezialisierung von einzelnen Funktionen.

Eine eigene Klasse lohnt sich eigentlich nur, wenn man die Daten anders anordnen will.

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 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{...};

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

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: 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.

@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.

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

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.

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.

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.