-
Je suis d'accord que tu peux utiliser les templates comme maniere de factoriser du code dans tes implementations. Mais cela releve du detail d'implementation a mon avis, et ne devrait pas etre expose publiquement.
Le cas typique du renderer qui est implemente de differentes manieres (OpenGL/DirectX) est de passer par une classe abstraite Renderer et une factory qui instancie l'une ou l'autre implementation. Ces implementations peuvent alors reposer sur un template interne, prive.
Concernant les dlls, si j'ai bien compris, tu exportes une instanciation explicite de template (dis moi si je me trompe). C'est super pas portable / limité / risqué. Les template ne sont pas faits pour traverser les frontieres d'un module compilé, telle une dll. Ils ne devraient pas faire partie de leur interface.
-
Qu'est ce qui pourrait poser problème, dis-moi ? Il y a déjà eu un sujet la dessus : http://www.developpez.net/forums/sho...d.php?t=507420
-
En ce qui me concerne, il y a plusieurs points "conceptuels" qui me genent sur cette utilisation des templates. J'ai tendance a me demander si on ne devie pas de leur sens premier et si on ne pourrait pas faire au moins aussi bien avec une approche non template.
Je veux bien admettre qu'il existe des cas astucieux, mais je n'arrive pas a les trouver par moi meme. Je ne vois pas l'interret de cette approche par rapport a une approche classique a base de classe abstraite de base.
Ce que je vois c'est que si l'utilisateur est un novice du C++, et qu'il instancie ton template avec un mauvais type, il va se payer une erreur de link au lieu d'une erreur de compilation. C'est le premier point qui me gene.
Ensuite, de mon experience personnelle, au travail, ce genre de pratique remplace les erreurs de compilation par des erreurs de link totalement incomprehensibles par beaucoup de monde.
Parce que dans l'etat actuel des choses, en C++, il n'est pas possible de facilement restreindre de type donne au template, il est facile d'ecrire Renderer<float> et n'avoir aucune erreur, de compilation j'entends. Aussi je ne comprends pas l'interret de:
- exporter un template Renderer<> avec un type DirectX et OpenGL
- face a exporter 2 classes RendererOpenGL et RendererDirectX, qui en interne eventuellement sont implementees via un heritage de template.
Dans mon dernier job, il y avait ainsi une quarantaine de classes declarees comme des typedefs de templates, et dans un gros fichier .cpp, on avait le body des templates et la liste des instanciations explicites, et la liste des specialisations de fonctions membres pour quelques unes de ces classes, parce que bien sur les templates de base ne pouvaient pas etre assez generalistes pour toutes les classes en question. Quand on ajoutait une nouvelle classe, il fallait l'instancier explicitement dans ce gros cpp, puis eventuellement specialiser pour son type certaines fonctions membres. :?
En bref, je trouve que c'est de la magouille, de la magouille qui n'apporte - d'apres ma courte experience - rien par rapport a une approche "conventionnelle" avec classe de base et redefinition de fonction virtuelles dans les classes derivees.
Ensuite, toujours d'apres mon experience, et pour en revenir sur le point initial de mon message comme quoi les templates se marrient mal avec les interfaces exportees d'une, c'est que le risque de violer la "One Definition Rule" est eleve, surtout si tu utilises la STL ou autre.
Dans mon cas, j'exportais une classe non template qui, au sein de ses membres private, contenait un std::vector. Entre la dll contenant l'implementation et le code client compile (chacun instanciant son propre std::vector => violation de l'ODR), il y avait une difference dans les flags du proprocesseur afin de desactiver les warning de depreciation de VC++ dans un cas, a savoir _SECURE_SCL je crois. Ce que je ne savais pas, c'est que ce flag en interne de std::vector modifie la structure du template et de ses iterator. Et j'avais droit a une jolie corruption memoire en release, un truc tordu que j'avais mis 2 jours a trouver :aie:
Plus d'infos:
http://www.unknownroad.com/rtfm/Visu...ningC4251.html
