L'interet par rapport au variant de mat.M est double :
*d'une part en terme d'occupation memoire, mon sVariant occupe 1 int + 1 double, ou plus exactement un enum + le plus gros des types de l'union, alors que la solution initiale occupe la somme de tous les types proposés...
*d'autre part cette solution integre l'aiguilleur du switch.
Cette solution n'est pas une chimere qui sort tout droit de mon esprit tortueux, mais c'est celle retenue par Motif pour les evenements ( a quelque chose près)...
après, faut il un switch ?
Mon esprit de contradiction dirait non... ....pas obligatoirement.
Certes le switch n'est pas une mauvaise solution, mais on peut aussi faire des fonctions pour chaque cas, puis construire un tableau de fonctions (appelons le funcTab) de sorte que funcTab[i] pointe sur la fonction qui traite le cas où type vaut i et le switch devient :
(funcTab[titi.type])(titi);
et on a reconstruit quelque chose qui ressemble ( de loin certes) au polymorphisme...
C'est une solution, qui, si elle est elegante, ne manquera pas de destabiliser nombre de relcteur du code, donc si on la chosit il faudra documenter le code de facon a etre sur d'etre compris...
Partager