En résumé, la modularité n'a rien à voir la dedans, G'MIC utilise un tas de fonctions différentes avec des types d'images différents (et de la généricité statique) et donc de toute façon, le compilo doit les compiler pour tous les types que l'on a prévu.
Mais c'est bien ce qu'il dit, il y a à mon avis aussi un gros problème de conception. Il ne s'agit pas de saucissonner le code en fichiers .h, bien sûr que ça ne règlerait pas le problème.
* Pourquoi tout mettre dans une seule classe (CImg)? À la fois du code dépendant de la plateforme, du code de traitement d'image, de tracé de formes. Tout cela pourrait avantageusement séparé.
* As-tu considéré les traits/policies? Tu conserves ainsi le polymorphisme statique (lorsqu'il est vraiment nécessaire). Il faudrait des benchmarks pour arbitrer avec le polymorphisme dynamique.
* Pourquoi toutes ces données codées en dur (polices, chemins, tableaux de constantes, etc.)?
* Des fonctions/macros qui prennent une dizaine de paramètres?!
Comme le post parent le suggère, jette un coup d'oeil à Boost, la STL, etc. Tu verras qu'il est possible de conserver de la généricité tout en gardant des tailles de fichier et des temps de compilation raisonnables.
Ne le prends pas mal, c'est du bon et gros boulot, les algos de traitement d'image sont certainement bons et ta bibliothèque utile, mais elle gagnerait à une conception utilisant mieux le langage C++.
Vois également la bibliothèque AGG (antigrain). Elle est très polymorphe (y compris statiquement), les headers et classes sont clairement décomposés.
[^] # Re: bon ben c' est simple....
Posté par Achille Fouilleul . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. Évalué à 3.
Mais c'est bien ce qu'il dit, il y a à mon avis aussi un gros problème de conception. Il ne s'agit pas de saucissonner le code en fichiers .h, bien sûr que ça ne règlerait pas le problème.
* Pourquoi tout mettre dans une seule classe (CImg)? À la fois du code dépendant de la plateforme, du code de traitement d'image, de tracé de formes. Tout cela pourrait avantageusement séparé.
* As-tu considéré les traits/policies? Tu conserves ainsi le polymorphisme statique (lorsqu'il est vraiment nécessaire). Il faudrait des benchmarks pour arbitrer avec le polymorphisme dynamique.
* Pourquoi toutes ces données codées en dur (polices, chemins, tableaux de constantes, etc.)?
* Des fonctions/macros qui prennent une dizaine de paramètres?!
Comme le post parent le suggère, jette un coup d'oeil à Boost, la STL, etc. Tu verras qu'il est possible de conserver de la généricité tout en gardant des tailles de fichier et des temps de compilation raisonnables.
Ne le prends pas mal, c'est du bon et gros boulot, les algos de traitement d'image sont certainement bons et ta bibliothèque utile, mais elle gagnerait à une conception utilisant mieux le langage C++.
Vois également la bibliothèque AGG (antigrain). Elle est très polymorphe (y compris statiquement), les headers et classes sont clairement décomposés.