* Dans la classe CImg, il n'y a aucun code plateforme-dependent. C'est une grosse classe, car effectivement, les algos agissant sur les images sont des fonctions membres. Est-ce une erreur de conception ? Je ne crois pas. C'est différent de la STL ou de boost, mais ca permet un style de programmation assez naturel et lisible ('img.blur(3);' on comprend tout de suite ce que ca fait). Si on ne veut vraiment pas de fonctions membres dans les classes, alors on fait des structures C et c'etait pas la peine de faire du C++. Le fait que le compilo ait du mal n'est pas une raison valable pour décrier la conception, je pourrais te répondre que c'est la faute au compilo qui est mal fichu... (mais évidemment, c'est un raccourci que je ne me permettrais pas de faire).
* CImg utilise pas mal de traits, tu peux aller voir dans le code. En particulier pour determiner les types de retours des images quand c'est nécessaire. Mais le problème des traits c'est que quand ça devient systématique, ca devient souvent illisible au niveau du code les utilisant (oui, oui je trouve l'utilisation un peu poussée de boost rapidement illisible, et je crois pas être le seul..)
* Certaines données sont en dur, c'est vrai pour un souci pratique. C'est discutable, mais je ne crois pas que les 10 Ko de données qu'elle représentent au final sont la cause du temps de compilation. D'ailleurs, la plupart des exemples fournis avec CImg compilent relativement rapidement, et possèdent aussi ces données là. Donc, c'est définitivement pas la cause du problème.
* Les macros peuvent faire peur, mais elles sont très peu utilisées dans CImg, et je pense qu'elles le sont à bon escient. Ca fait peur parce que elles se trouvent en début de fichier, et que c'est vrai que ca prend de la place... Mais bon, c'est des macros, je vais pas les mettre à la fin du fichier...
G'MIC est un exemple assez extrême : Il nécéssite la compilation d'énormément de fonctions différentes, et évidemment cela se ressent avec une machine 'limite' (faut voir comment ca peut bouffer, un g++ en pleine action..). Mais l'utilisation de CImg dans un cadre plus 'normal' n'a pas ce genre de problème, fort heureusement.
[^] # Re: bon ben c' est simple....
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. Évalué à 2.
* Dans la classe CImg, il n'y a aucun code plateforme-dependent. C'est une grosse classe, car effectivement, les algos agissant sur les images sont des fonctions membres. Est-ce une erreur de conception ? Je ne crois pas. C'est différent de la STL ou de boost, mais ca permet un style de programmation assez naturel et lisible ('img.blur(3);' on comprend tout de suite ce que ca fait). Si on ne veut vraiment pas de fonctions membres dans les classes, alors on fait des structures C et c'etait pas la peine de faire du C++. Le fait que le compilo ait du mal n'est pas une raison valable pour décrier la conception, je pourrais te répondre que c'est la faute au compilo qui est mal fichu... (mais évidemment, c'est un raccourci que je ne me permettrais pas de faire).
* CImg utilise pas mal de traits, tu peux aller voir dans le code. En particulier pour determiner les types de retours des images quand c'est nécessaire. Mais le problème des traits c'est que quand ça devient systématique, ca devient souvent illisible au niveau du code les utilisant (oui, oui je trouve l'utilisation un peu poussée de boost rapidement illisible, et je crois pas être le seul..)
* Certaines données sont en dur, c'est vrai pour un souci pratique. C'est discutable, mais je ne crois pas que les 10 Ko de données qu'elle représentent au final sont la cause du temps de compilation. D'ailleurs, la plupart des exemples fournis avec CImg compilent relativement rapidement, et possèdent aussi ces données là. Donc, c'est définitivement pas la cause du problème.
* Les macros peuvent faire peur, mais elles sont très peu utilisées dans CImg, et je pense qu'elles le sont à bon escient. Ca fait peur parce que elles se trouvent en début de fichier, et que c'est vrai que ca prend de la place... Mais bon, c'est des macros, je vais pas les mettre à la fin du fichier...
G'MIC est un exemple assez extrême : Il nécéssite la compilation d'énormément de fonctions différentes, et évidemment cela se ressent avec une machine 'limite' (faut voir comment ca peut bouffer, un g++ en pleine action..). Mais l'utilisation de CImg dans un cadre plus 'normal' n'a pas ce genre de problème, fort heureusement.