Bonjour,
Tu sais, j'ai pas mal discuté de çà avec Victor, et effectivement nous n'étions pas d'accord sur certains points. Je ne vais pas recommencer la discussion avec toi en profondeur, car ca risquerait d'être trop long.
Cela dit, tu t'emportes mais tu me parais bien prétentieux ! Pourquoi tu aurais toi la connaissance absolue de la façon de bien programmer ? Tu parles ici d'un sujet qu'apparemment tu ne maitrises pas : le C++ et ses spécificités, notamment la programmation générique à base de templates.
- Tu parles de séparation en .h et .cpp, c'est effectivement une technique assez classique mais dès lors que l'on parle de bibliothèque C++ générique utilisant à fond les templates, cette règle est généralement moins évidente, notamment quand le type des classes n'est connu qu'à la compilation (exactement comme quand on utilise la STL, qui est comme chacun sait, une bibliothèque faite avec les pieds par des débutants en programmation). Je peux te citer d'autres exemples. C'est un fait, la programmation générique utilisant des templates est un concept fort du C++ qui est assez particulier et qu'il faut prendre en compte.
- La plupart des classes du .h de CImg sont extrêmement bien séparées, et on peut tout à fait compiler la bibliothèque sans utiliser de display ou autres bibliothèques optionnelles. Ne t'arrête pas aux 50 premières lignes qui effectivement contiennent des tableaux de données dont j'ai besoin pour certaines fonctions. Si tu as le temps essayer de regarder un peu plus loin, tu verras que c'est bien structuré et très facile à lire (ce n'est pas le nombre importants de contributions et de corrections de bugs que je recois régulièrement qui va me dire le contraire, comme si bizarrement les gens avaient moins peur d'aller débugger un code de fonction plus court et bien localisé qu'un code étalé sur 50 fichiers différents...)
- Pour finir, je vais peut-être t'étonner, mais il y a un bon paquet de gens qui utilise CImg justement parce que c'est simplissime au niveau des dépendances et ca leur rappelle un peu la STL. Va voir dans les forums, je peux te trouver des messages absolument contraires au tiens qui encense cette structure. Alors bien sûr il y a des défauts je ne le cache pas (notamment le temps de compilation quand on active l'optimisation), mais beaucoup de qualités aussi, notamment le fait de pouvoir écrire des codes très courts (va voir la longueur des codes sources exemples fournis dans le package).
Bref je ne cache pas que CImg est un peu original, et a été clairement élaboré pour la programmation C++ générique. Alors oui ca s'interface pas très bien avec le python, et la structure ne ressemble pas à la façon typique qu'on enseigne en école d'ingénieur mais si c'est ton seul critère pour juger la valeur d'une bibliothèque, permets moi de te dire que c'est un peu léger.
Pour finir, CImg a maintenant 7 ans d'existence, et crois moi, si cette structure avait posé problème, je pense que ca aurait été modifié depuis bien longtemps.
Je pense qu'au contraire, elle a pu évoluer relativement rapidement grâce à cette simplicité d'écriture et d'utilisation.
Alors moi aussi je m'emporte, mais faudrais arrêter de vouloir donner des leçons comme tu le fais quand manifestement tu n'as pas plongé ton nez plus de 5 minutes dans cette bibliothèque. A l'inverse quand je vois que des gens "reconnus" (adobe) proposent aujourd'hui des bibliothèques de traitement d'images soit disant C++ qui s'utilisent avec des structures comme ca :
[^] # Re: Une vraie bibliothèque.....
Posté par David Tschumperlé (site web personnel) . En réponse au journal GREYCstoration : Appel à contribution. Évalué à 7.
Tu sais, j'ai pas mal discuté de çà avec Victor, et effectivement nous n'étions pas d'accord sur certains points. Je ne vais pas recommencer la discussion avec toi en profondeur, car ca risquerait d'être trop long.
Cela dit, tu t'emportes mais tu me parais bien prétentieux ! Pourquoi tu aurais toi la connaissance absolue de la façon de bien programmer ? Tu parles ici d'un sujet qu'apparemment tu ne maitrises pas : le C++ et ses spécificités, notamment la programmation générique à base de templates.
- Tu parles de séparation en .h et .cpp, c'est effectivement une technique assez classique mais dès lors que l'on parle de bibliothèque C++ générique utilisant à fond les templates, cette règle est généralement moins évidente, notamment quand le type des classes n'est connu qu'à la compilation (exactement comme quand on utilise la STL, qui est comme chacun sait, une bibliothèque faite avec les pieds par des débutants en programmation). Je peux te citer d'autres exemples. C'est un fait, la programmation générique utilisant des templates est un concept fort du C++ qui est assez particulier et qu'il faut prendre en compte.
- La plupart des classes du .h de CImg sont extrêmement bien séparées, et on peut tout à fait compiler la bibliothèque sans utiliser de display ou autres bibliothèques optionnelles. Ne t'arrête pas aux 50 premières lignes qui effectivement contiennent des tableaux de données dont j'ai besoin pour certaines fonctions. Si tu as le temps essayer de regarder un peu plus loin, tu verras que c'est bien structuré et très facile à lire (ce n'est pas le nombre importants de contributions et de corrections de bugs que je recois régulièrement qui va me dire le contraire, comme si bizarrement les gens avaient moins peur d'aller débugger un code de fonction plus court et bien localisé qu'un code étalé sur 50 fichiers différents...)
- Pour finir, je vais peut-être t'étonner, mais il y a un bon paquet de gens qui utilise CImg justement parce que c'est simplissime au niveau des dépendances et ca leur rappelle un peu la STL. Va voir dans les forums, je peux te trouver des messages absolument contraires au tiens qui encense cette structure. Alors bien sûr il y a des défauts je ne le cache pas (notamment le temps de compilation quand on active l'optimisation), mais beaucoup de qualités aussi, notamment le fait de pouvoir écrire des codes très courts (va voir la longueur des codes sources exemples fournis dans le package).
Bref je ne cache pas que CImg est un peu original, et a été clairement élaboré pour la programmation C++ générique. Alors oui ca s'interface pas très bien avec le python, et la structure ne ressemble pas à la façon typique qu'on enseigne en école d'ingénieur mais si c'est ton seul critère pour juger la valeur d'une bibliothèque, permets moi de te dire que c'est un peu léger.
Pour finir, CImg a maintenant 7 ans d'existence, et crois moi, si cette structure avait posé problème, je pense que ca aurait été modifié depuis bien longtemps.
Je pense qu'au contraire, elle a pu évoluer relativement rapidement grâce à cette simplicité d'écriture et d'utilisation.
Alors moi aussi je m'emporte, mais faudrais arrêter de vouloir donner des leçons comme tu le fais quand manifestement tu n'as pas plongé ton nez plus de 5 minutes dans cette bibliothèque. A l'inverse quand je vois que des gens "reconnus" (adobe) proposent aujourd'hui des bibliothèques de traitement d'images soit disant C++ qui s'utilisent avec des structures comme ca :
http://opensource.adobe.com/gil/html/giltutorial.html#Images(...)
Des fois je me dis que c'est pas la peine de faire du C++.
David.