ZFX + Developia

CodingCat hat geschrieben:Naja, ich sehe an der flexiblen Lösung nichts schlechtes, und einfach ist sie obendrein.

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.

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.

• Redefinition

• Pattern Matching
  

  eXile hat geschrieben:

  CodingCat hat geschrieben:Naja, ich sehe an der flexiblen Lösung nichts schlechtes, und einfach ist sie obendrein.

  Ja, es ist dann halt duck typing.

  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.

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:

1. Redefinition
2. Pattern Matching

1. die Template-Template-Parameter eines Template-Parameters nimmt, und
2. diese direkt der Template-Parameterliste als Template-Parameter hinzufügt,

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.

eXile hat geschrieben:Hätte ich eine Variante, welche:

1. die Template-Template-Parameter eines Template-Parameters nimmt, und
2. diese direkt der Template-Parameterliste als Template-Parameter hinzufügt,

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.

eXile 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.)

fusedmultiplyadder<adder1<2, 3>, 4>
 : public inherit_base_pattern<adder1<2, 3>, fusedmultiplyadder<adder<2, 3>, 4>>
    : public virtual fusedmultiplyadder<adder<2, 3>, 4>

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>

CodingCat hat geschrieben:Mich würde ja echt interessieren, was du damit eigentlich baust. ;)

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