./34621 Ben c'est quand même assez limite comme exemple, la metaprogrammation c'est jamais très beau.
Je voulais pouvoir accéder à un élément d'un tuple au runtime, mais j'en ai marre, j'ai abandonné. C'est trop pénible, pour un
tuple<Ts> chaque élément doit être projeté dans un
variant<Ts...>. Et après faut retourner le bon type, et la t'es coincé parce que tu dois donner le type attendu à la compilation, ce que je voulais éviter - j'ai même écrit une super classe de variant qui expose un opérateur de cast implicite vers le type assigné (puisque mes variant changent jamais de type). Mais même avec ça le type est perdu puisque pour rester efficace je peux faire ça qu'une fois (sinon le compilateur va juste crash), donc je stocke ça dans un array de
tagged_variant(*)(tuple). Let soucis évident c'est que chaque type
tagged_variant est unique, puisque chacun expose un différent T qui est équivalent à
nth_element<I, Ts...>. I est unique aussi (il correspond, pour un variant donne, à la position originale du type wrappé dans le parameter pack). En somme je peux récupérer un variant de
Ts... mais l'info de type est inaccessible. Il faudrait à la limite que je stocke un
tuple<variant<Ts...>>, et là ça m'a vraiment gonflé et je suis resté vers mes accesseurs statiques. En plus de ça ça rend le mapping vers un type strict classique encore plus infernal
Édit: rappelez moi de ne plus jamais écrire de pavé comme ça depuis mon téléphone...
Edit2: autre solution: ce genre de trucs:
inline operator parameter_pack...() const {
// ...
}En gros, on définit d'un coup autant de conversions implicites qu'il y a de types dans le pack. Ça n'est "malheureusement" pas géré par le standard.
