Je te remercie de ta longue réponse, je ne regrette pas d'avoir posé ces question...
Effectivement, l'argument "parce que templates", et recevable.
Ceci dit j'ai tout de même quelques remarques :)
(bon alors ça se voit pas, mais c'est au moins la 4ieme fois que je reprends ce messages, au fur et a mesure que j'avance dans la compréhension du code...)
Bon pour CImg.h, je rends les armes. Effectivement le coté template fait qu'on ne peut pas y faire grand chose. Mais c'est à la fois sa force et son talon d'achile: je ne connaissais pas CImg.h, mais ce que je sais c'est que si un jour je dois choisir une librairie de manipulation d'image, elle viendra en dernier sur ma liste (sauf si je dois gérer des images dont les éléments sont de type ChuckNorris, la on pourra discuter), parce que les pénalités que j'ai déjà décrites ne sont contrebalancés que dans certains cas très particulier...
Pour gmic.cpp, effectivement je ne vois pas de moyen d'accélérer le projet dans son ensemble, MAIS j'en vois une qui allègera le boulot de compilation pour le développeur, en permettant un semblant de compilation incrémentale (oui parce actuellement, si tu touche à un iota de gmic.cpp ou CImg.h, tu recompile tout du début... )
Je propose de faire des classes "wrapper" autour de CImg
(je pense que ces wrappers pourront facilement être généré automatiquement par un script dans la chaine de compilation pour chaque type géré par gmic)
J'en ai fait un bout qui marche, avec juste un constructeur et une méthode, à l'arrache: CImgUC.h :
#include "CImg.h"
Une fois qu'on a ça, on peut tranquillement compiler un cimg_uc.o contenant cette classe, classe qu'on utilisera dans gmic.cpp , mais comme on masque complètement CImg.h, on a un gros gain à la compilation.
Quelques temps: #test.cpp : utilise directement CImg.h
$ time g++ test.cpp -lX11 -lpthread
real 0m5.353s
user 0m5.016s
sys 0m0.320s
#test2.cpp fait la même chose en utilisant la classe CImgUC compilée par CImgC.cpp
$ time g++ -c -o cimgc.o CImgC.cpp
real 0m5.183s
user 0m4.780s
sys 0m0.356s
$ time g++ cimgc.o test2.cpp -lX11 -lpthread
real 0m0.200s
user 0m0.144s
sys 0m0.052s
Voila, en temps que développeur, à a la première compilation ma version est pénalisée... Mais si je change le code de test2.cpp, le temps de compilation du projet total reste à 0.2s au lieu de 5s dans l'autre cas...
J'avais d'autres choses à dire pour soutenir mon argumentaire, mais j'ai plus guère de temps...
[^] # Re: PA-RA-LLELE!
Posté par case42 . En réponse à la dépêche Traitement d'images : Quand G'MIC 1.3.0 s'invite dans GIMP. Évalué à 4.
Effectivement, l'argument "parce que templates", et recevable.
Ceci dit j'ai tout de même quelques remarques :)
(bon alors ça se voit pas, mais c'est au moins la 4ieme fois que je reprends ce messages, au fur et a mesure que j'avance dans la compréhension du code...)
Bon pour CImg.h, je rends les armes. Effectivement le coté template fait qu'on ne peut pas y faire grand chose. Mais c'est à la fois sa force et son talon d'achile: je ne connaissais pas CImg.h, mais ce que je sais c'est que si un jour je dois choisir une librairie de manipulation d'image, elle viendra en dernier sur ma liste (sauf si je dois gérer des images dont les éléments sont de type ChuckNorris, la on pourra discuter), parce que les pénalités que j'ai déjà décrites ne sont contrebalancés que dans certains cas très particulier...
Pour gmic.cpp, effectivement je ne vois pas de moyen d'accélérer le projet dans son ensemble, MAIS j'en vois une qui allègera le boulot de compilation pour le développeur, en permettant un semblant de compilation incrémentale (oui parce actuellement, si tu touche à un iota de gmic.cpp ou CImg.h, tu recompile tout du début... )
Je propose de faire des classes "wrapper" autour de CImg
(je pense que ces wrappers pourront facilement être généré automatiquement par un script dans la chaine de compilation pour chaque type géré par gmic)
J'en ai fait un bout qui marche, avec juste un constructeur et une méthode, à l'arrache:
CImgUC.h :
#include "CImg.h"
class CImgUC
{
protected:
#ifdef _CIMG_UC_
cimg_library::CImg<unsigned char> *img;
#else
void *img;
#endif
public:
CImgUC(const char *const filename);
CImgUC& blur(const float sigma, const bool cond=true);
};
CImgUC.cpp
#define _CIMG_UC_
#include "CImgC.h"
CImgUC::CImgUC(const char *const filename)
{
img = new cimg_library::CImg<unsigned char>(filename);
}
CImgUC& CImgUC::blur(const float sigma, const bool cond)
{
img = &img->blur(sigma, cond);
return(*this);
}
Une fois qu'on a ça, on peut tranquillement compiler un cimg_uc.o contenant cette classe, classe qu'on utilisera dans gmic.cpp , mais comme on masque complètement CImg.h, on a un gros gain à la compilation.
Quelques temps:
#test.cpp : utilise directement CImg.h
$ time g++ test.cpp -lX11 -lpthread
real 0m5.353s
user 0m5.016s
sys 0m0.320s
#test2.cpp fait la même chose en utilisant la classe CImgUC compilée par CImgC.cpp
$ time g++ -c -o cimgc.o CImgC.cpp
real 0m5.183s
user 0m4.780s
sys 0m0.356s
$ time g++ cimgc.o test2.cpp -lX11 -lpthread
real 0m0.200s
user 0m0.144s
sys 0m0.052s
Voila, en temps que développeur, à a la première compilation ma version est pénalisée... Mais si je change le code de test2.cpp, le temps de compilation du projet total reste à 0.2s au lieu de 5s dans l'autre cas...
J'avais d'autres choses à dire pour soutenir mon argumentaire, mais j'ai plus guère de temps...