+ nämlich mit minimalem Admin-Overhead, +
++ indem er sich auf die VTable des einzubettenden Typs abstützt. +
++ +
++ Die andere Alternative, der OpaqueHolder, verwendet selber nochmal einen zustäzlichen virtuellen Holder, +
++ und Variant paßt auch nicht, da ich ja mit Template-generierten Subklassen arbeite, +
++ und daher nicht a priori die Liste aller einzubettenden Varianten kenne +
+ + ++ nämlich hier der Visitor, der den Aufruf letztlich emfpängt +
+ + ++ ...denn es handelt sich hierbei um einen Konstruktionstrick. +
++ Scott Meyers spricht deshalb auch immer von "unverersal references" und unterscheidet +
++ diese von einer expliziten RValue-Referenz. +
++ +
++ Demnach wäre das Standard-Baumuster, daß alle Glieder in der perfect-forwarding-Kette +
++ per universal-Reference miteinander verbunden sind. Und im Konkreten fall muß man +
++ das so hintricksen, indem man die std::get-Funktion passend bestückt... +
++ +
++ Au weia +
+ + ++ Beispiel: Wenn der Typ selber keinen Support anbietet, +
++ dann nehmen wir immer das volle CopySupport-API, und differenzieren nicht +
++ mehr nach Typen mit reinem clone-support. Was dann tatsächlich dazu führt, +
++ daß der Compiler verucht, den Zuweisungsoperator zu verwernden! +
+ + ++ nämlich diejenige für Typen ohne Support auf dem API. +
+ + ++ ...etwas analog zu meinem TreeMutator. +
++ D.h. man muß alle verwendeten Signaturen auf dem Receiver +
++ erst mal in einem Builder-Konstrukt gewissermaßen "registrieren", um dann den passenden +
++ VerbPack-Typ konstruiert zu bekommen. +
+ + ++ d.h. man erzeugt in einem einzigen Aufruf den VerbPack für eine Zielfunktion +
+ + ++ zwei verschachtelte, delegierende Konstruktoren, +
++ von denen der zweite, innere die eigentliche Typinferenz macht +
+ + ++ sollten z.B. die Konstruktor-Funktionen nicht unmittelbar mit definiert werden? +
+ + ++ ...weil man stets noch einen Layer darübersetzt? +
++ Wie auch im konkreten Fall das TrackProfile, was dann ein vector<VerbPack> werden würde? +
+ + +