Discussion :

[samplay]

Bonjour,
j'aimerais un avis sur le probleme suivant:
j'ai écris une petite bibliothéque d'algo geometriques ( splitting, clipping, bsptrees, somme de minkowski,...). Voulant conserver la possibilité d'utiliser des float ou des doubles ( voire pire plus tard ) pour anticiper les problemes de précision je l'ai 'templatisée' avec un type 'scalaire' ( puis Points, Vecteurs..); j' utilise la notion de 'Traits' pour me simplifier la vie et la vaste majorité des données et des algos manipulent des pointeurs ( sur Points,...).
Le probleme est que je me retrouve obligé de templatiser TOUTE la bibliotheque, y compris des algos qui ne traitent que des structures de données ( cad pas de valeurs numeriques), ce qui va recreer TOUT le code a chaque fois, et qui me semble débile.
La solution a laquelle je pense est de deriver mes points/vecteurs templatisés d'une classe virtuelle pure, dont j'utiliserais les pointeurs comme donnees membres de classes utilisatrices de points/vecteur, evitant ainsi d'avoir a templatiser ces dernieres. MAIS cela me rajoute une indirection.
1. cette solution est-elle valable?
2. Cette indirection supplementaire risque-t-elle de me penaliser serieusement en temps de calcul?
3. Autre solution?
Merci a ceux qui prendront le temps de me lire.

[JolyLoic]

1 : Elle est valable, au sens où elle peut marcher, mais je pense qu'elle n'est pas très bonne...
2 : Probablement. Pas uniquement par l'indirection en tant que tel, mais aussi parce que cette indirection va probablement empêcher des possibilités d'inlining.
3 : Si le but du changement de type est d'expérimenter entre plusieurs solutions, pour n'en retenir qu'un à la fin, utiliser un typedef peut éviter les templates. Si le but est que l'utilisateur final ait le choix du type à utiliser, je ne vois pas trop en quoi les templates posent problème (à part en terme de lourdeur d'écriture, et de l'obligation d'avoir le code dans des .h, mais qui ne semblent pas invoqués ici). En effet, le code bloat qui pourrait intervenir me semble limité, puisque l'utilisateur n'utilisera typiquement qu'un seul type d'argument template dans son code (contrairement au code bloat qui pourrait intervenir avec vector, par exemple).

Si le code bloat sur ces algorithmes qui se moquent du type pose réellement problème, tu peux les écrire à base de void*, et ça devrait marcher (éventuellement en effectuant quelques cast dans du code templatisé qui utilise ce code ignorant du type).

[samplay]

Merci pour la réponse!
void* et static_cast me semblent etre la solution.
Pour info, 'double' ( voire MPFR un jour...) est utilisé pour l'elaboration de données ( en principe une fois)
et 'float' pour leur utilisation recurrente ( apres io sur disque), sachant que les algos sont quasi les memes, le tout dans un seul programme actuellement( il est peut etre temps de le scinder en 2!).

[Joel F]

Le bloat template provient souvent d'une implantation bancale. Je conseille la lecture du Papier de Dan Tsafrir sur le code SCARY qui contient un algo de structuration du code template pour limiter le bloat en utilisant a fond le template hoisting.

http://www.cs.huji.ac.il/~dants/pape...es09OOPSLA.pdf

[samplay]

merci encore!

[samplay]

encore moi, apres avoir creusé la question.
1. plutot que void* j'ai codé en utilisant des handles parametrables ( qui sont des void * pour l'instant, mais pourront etre des index plus tard.), mais je ne suis pas tres satisfait.

2.le papier sur le template hoisting est interressant, mais il est difficile d'en tirer des conclusions générales.
De plus, mon probleme est l'inverse de celui traité en exemple; l'exemple est d'eviter d'avoir des classes( iterateurs) nestees dans d'autres classes qui possedent plus d'arguments de templates que les classes nestées au comportement plus generique.
Mon probleme en effet est que j'ai des classes ( points,..) avec quelques arguments en template, qui sont utilisées par des classes ( face, polyhedre, foncteurs,...) qui sont beaucoup plus generiques ; exemple: couper un polyhedre ou une face ne necessite aucun calcul numerique, puisque celui-ci est reporté niveau des segments; je ne devrais donc pas avoir besoin de templatiser mes faces en fonctions du type scalaire, de l'implementation choisie de la classe point, voire de la dimension de l'espace.

3. je n'utilise pas les classes/fonctions nestées, c'est peut etre la solution dans mon cas.

4.j'ai regardé la bibliotheque geometrique CGAL, et ma solution actuelle s'apparente a la leur: bad luck.

5. je vais creuser coté CRTP ( "curiously recurring template pattern")