Template-Parameter kapseln
Code: Alles auswählen
template <int i1, int i2>
struct adder
{
enum
{
result = i1 + i2
};
};
template <adder a, int i3>
struct fusedmultiplyadder1 // Geht natürlich nicht.
{
enum
{
result = a::result * i3;
};
};
template <int i1, int i2, int i3>
struct fusedmultiplyadder2 // Geht; Template-Liste wächst gegen infinity, and beyond!
{
enum
{
result = adder<i1, i2>::result * i3
};
};
Ja, es ist dann halt duck typing.CodingCat hat geschrieben:Naja, ich sehe an der flexiblen Lösung nichts schlechtes, und einfach ist sie obendrein.
Ja, das Beispiel ist zu stark reduziert; es soll hier im Anwendungsfall nur eine bestimmte Klasse an der Stelle verwendet werden dürfen. Wie gesagt: Das sind nur Hilfsklassen, um Schreibarbeit durch Verkürzung der Template-Parameter-Liste zu sparen, und diese Hilfsklassen können von außen gar nicht benutzt werden. Variadic Templates brauche ich hier auch nicht, da war das gegebene Beispiel einfach zu weit von meinem Anwendungsfall entfernt; sorry für das schlechte Beispiel.CodingCat hat geschrieben:Die Frage ist, warum es überhaupt der Einschränkung auf adder bedarf, vermutlich hängt noch irgendetwas komplexeres hinter diesem reduzierten Beispiel.
Hm, ich verstehe nicht, inwiefern du mit der Einschränkung besser auf Template-Parameter zugreifen könntest? Mir fallen eigentlich nur 2 Varianten ein:eXile hat geschrieben:Ich habe es jetzt mal mit typename durchimplementiert, und gerade die angesprochene Flexibilität hat mir in den Hintern gebissen, weil ich doch auf ein paar Template-Parameter der verkapselnden Hilfsklassen zugreifen musste. Also wieder Kommando zurück, zurück zu den riesigen Listen, aber trotzdem danke für die Hilfe.
Fast, aber nicht im Rahmen von Pattern Matching. Hier könntest du sogar ganz einfach eine rekursive Dekomposition mit sehr spezifischen Einschränkungen durchführen.eXile hat geschrieben:Ja, es ist dann halt duck typing.CodingCat hat geschrieben:Naja, ich sehe an der flexiblen Lösung nichts schlechtes, und einfach ist sie obendrein.
Ja, das sind die Lösungen, die sich hier auch herauskristallisieren, und die Beschränkungen von C++ zeigen. Hätte ich eine Variante, welche:CodingCat hat geschrieben:Hm, ich verstehe nicht, inwiefern du mit der Einschränkung besser auf Template-Parameter zugreifen könntest? Mir fallen eigentlich nur 2 Varianten ein:
Das ist korrekt! Wobei bei mir auch noch hinzukommt, dass viele der dekomponierenden Einschränkungsklassen auch noch unterschiedlicher Natur sein können; siehe dafür diese Erweiterung deines Beispiels.CodingCat hat geschrieben:Fast, aber nicht im Rahmen von Pattern Matching. Hier könntest du sogar ganz einfach eine rekursive Dekomposition mit sehr spezifischen Einschränkungen durchführen.
Das musst du genauer erklären. Inwiefern sollen Template-Template-Parameter wie Template-Parameter behandelt werden?eXile hat geschrieben:Hätte ich eine Variante, welche:würden sich ein paar Probleme hier verflüchtigen. Oder kurz: Template-Template-Parameter sollen so wie normale Template-Parameter behandelt werden; was aktuell offensichtlich unmöglich ist.
- die Template-Template-Parameter eines Template-Parameters nimmt, und
- diese direkt der Template-Parameterliste als Template-Parameter hinzufügt,
Ja, einfach implizite Konvertierungen nutzen: http://ideone.com/K0k2beXile hat geschrieben:Wobei bei mir auch noch hinzukommt, dass viele der dekomponierenden Einschränkungsklassen auch noch unterschiedlicher Natur sein können; siehe dafür diese Erweiterung deines Beispiels. Gibt es eine einfache Möglichkeit, das gültig zu machen? (Warum es nicht geht, ist mir klar: Es sind einfach unterschiedliche Typen. Ich brauche also „laxeres“ Pattern Matching.)
Code: Alles auswählen
fusedmultiplyadder<adder1<2, 3>, 4>
: public inherit_base_pattern<adder1<2, 3>, fusedmultiplyadder<adder<2, 3>, 4>>
: public virtual fusedmultiplyadder<adder<2, 3>, 4>Code: Alles auswählen
fusedmultiplyadder1<adder2<2, 3>, 4>
: public virtual fusedmultiplyadder<adder2<2, 3>, 4>
: public inherit_base_pattern<adder2<2, 3>, fusedmultiplyadder<adder<2, 3>, 4>>
: public virtual fusedmultiplyadder<adder<2, 3>, 4>,
public inherit_base_pattern<adder2<2, 3>, fusedmultiplyadder1<adder<2, 3>, 4>>
: public virtual fusedmultiplyadder1<adder<2, 3>, 4>Es hat nichts mit Mathematik zu tun, sondern es sind ein paar Hilfsklassen, die enum traits implementieren; als dass man über enums dann iterieren kann, und der Iterator verschiedene Policies besitzt, mit denen man entweder das enum von Anfang bis Ende einmal durchläuft; oder der Iterator am Ende umwrappt, und man den enum immer wieder in einer Schleife durchläuft. Hintergrund ist, dass ich keine Lust mehr hatte, immer auf so etwas wie if(myEnum == lastEnumElement) myEnum = firstEnumElement; else myEnum++; zu testen; nun muss ich nur myEnumIterator++; aufrufen. Wenn ich das auf obiges inherit_base_pattern umgestellt habe, dabei nicht auf die Nase geflogen bin, und das alles auch im g++ kompiliert (oh Gott mache ich dumme Fehler; aber Visual Studio sagt halt nichts) werfe ich das in die Public Domain, natürlich hier veröffentlicht. Und dann sagt ihr mir, warum das alles Scheiße war. :)CodingCat hat geschrieben:Mich würde ja echt interessieren, was du damit eigentlich baust. ;)
Auweia, dann hoffe ich mal, dass dir virtual- und Mehrfachvererbung nicht sämtliche Optimierung ausschaltet. ;)eXile hat geschrieben:Hintergrund ist, dass ich keine Lust mehr hatte, immer auf so etwas wie if(myEnum == lastEnumElement) myEnum = firstEnumElement; else myEnum++; zu testen; nun muss ich nur myEnumIterator++; aufrufen. Wenn ich das auf obiges inherit_base_pattern umgestellt habe, dabei nicht auf die Nase geflogen bin, und das alles auch im g++ kompiliert (oh Gott mache ich dumme Fehler; aber Visual Studio sagt halt nichts) werfe ich das in die Public Domain, natürlich hier veröffentlicht. Und dann sagt ihr mir, warum das alles Scheiße war. :)