Je dirais juste que c'est quand même bizarre, car je recois de plus en plus de contributions pour CImg qui ne sont pas triviales du tout, donc c'est que ça doit pas être si illisible que çà.
Là, je suis sur le cul. Je croyais que c'était un outil entièrement développé par toi, je ne savais pas que des gens avaient réussi à contribuer ... Bon bah bravo.
Que le code te plaise pas, soit, mais en aucun cas ton avis perso est un critère de qualité objectif de code, excuse moi de te le dire.
Heu, je sais que certains critères sont subjectifs, mais là des fois, tu cumules. Franchement, rien qui si tu pouvais juste le séparer en plusieurs .h, ça aèrerait quand même un peu ... (sans rien changer à la structure, hein)
Boost, je connais. C'est peut-être du grand art de conception C++, mais c'est pas super sympa à *utiliser* (je parle en particulier de GIL, la bibliothèque image de Adobe incluse dans Boost). Franchement *pour l'utilisateur* qui n'est pas un pro du C++, c'est du n'importe quoi. Est-ce que les gens d'Adobe responsables de GIL ont déjà pensé que les traiteurs d'images sont pas tous des programmeurs chevronnés en C++ ? Bah non jamais, je pense, car les mecs derrière GIL ce sont des bons gros programmeurs qui se font plaisir aussi de leur côté, mais franchement...
Je suis d'accord que la lisibilité du code est importante, et qu'il faut qu'il soit accessible au programmeur lambda. Mais déjà, assimiler ton code, je ne pense pas que n'importe quel utilisateur lambda pourrait le faire !
Quant à l'exemple que tu donnes .... bah moi je le trouve super lisible. D'un côté, templeet t'as bouffé la moitié du code donc c'est illisible dans ton commentaire, mais pour ceux qui veulent aller voir sur le lien que tu donnes ...
C'est limite si ça se lit pas comme de l'anglais : on prend une image source immutable, une destination mutable, qui doivent avoir un espace de couleur compatible. Ensuite, on itère sur chaque ligne, puise sur chaque pixel de la ligne, en faisant une simple interpolation ... Je ne vois pas ce qu'il y a de compliqué. Et en plus, comme le tiens, ça marche pour tous les cas et toutes les dimensions.
Bon OK, chacun aura un avis différent la dessus, et effectivement j'ai sûrement un avis biasé. Mais tant mieux si tu as des contributions. J'espère sincèrement que d'autres gens seront motivés pour bosser sur ton projet !
[^] # Re: bon ben c' est simple....
Posté par benoar . En réponse au journal G'MIC : Un nouvel outil libre de manipulation d'images. Évalué à 6.
Là, je suis sur le cul. Je croyais que c'était un outil entièrement développé par toi, je ne savais pas que des gens avaient réussi à contribuer ... Bon bah bravo.
Que le code te plaise pas, soit, mais en aucun cas ton avis perso est un critère de qualité objectif de code, excuse moi de te le dire.
Heu, je sais que certains critères sont subjectifs, mais là des fois, tu cumules. Franchement, rien qui si tu pouvais juste le séparer en plusieurs .h, ça aèrerait quand même un peu ... (sans rien changer à la structure, hein)
Boost, je connais. C'est peut-être du grand art de conception C++, mais c'est pas super sympa à *utiliser* (je parle en particulier de GIL, la bibliothèque image de Adobe incluse dans Boost). Franchement *pour l'utilisateur* qui n'est pas un pro du C++, c'est du n'importe quoi. Est-ce que les gens d'Adobe responsables de GIL ont déjà pensé que les traiteurs d'images sont pas tous des programmeurs chevronnés en C++ ? Bah non jamais, je pense, car les mecs derrière GIL ce sont des bons gros programmeurs qui se font plaisir aussi de leur côté, mais franchement...
Je suis d'accord que la lisibilité du code est importante, et qu'il faut qu'il soit accessible au programmeur lambda. Mais déjà, assimiler ton code, je ne pense pas que n'importe quel utilisateur lambda pourrait le faire !
Quant à l'exemple que tu donnes .... bah moi je le trouve super lisible. D'un côté, templeet t'as bouffé la moitié du code donc c'est illisible dans ton commentaire, mais pour ceux qui veulent aller voir sur le lien que tu donnes ...
C'est limite si ça se lit pas comme de l'anglais : on prend une image source immutable, une destination mutable, qui doivent avoir un espace de couleur compatible. Ensuite, on itère sur chaque ligne, puise sur chaque pixel de la ligne, en faisant une simple interpolation ... Je ne vois pas ce qu'il y a de compliqué. Et en plus, comme le tiens, ça marche pour tous les cas et toutes les dimensions.
Bon OK, chacun aura un avis différent la dessus, et effectivement j'ai sûrement un avis biasé. Mais tant mieux si tu as des contributions. J'espère sincèrement que d'autres gens seront motivés pour bosser sur ton projet !