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++.
Ce n'est pas ce que je veux dire. L'idée de la programmation objet (quel que soit le langague) est justement de séparer les concepts, d'avoir des classes minimalistes qui représentent un invariant. Il ne me semble pas judicieux, par exemple de mêler dans une même classe gestion des fichiers, des options de ligne de commande, l'interface utilisateur, etc.
J'ai bien vu que tu utilises des traits -- trop peu à mon goût, mais je découvre ta bibliothèque, alors je suis prudent dans mes commentaires :-).
En ce qui concerne les policies, tu pourrais bien, par exemple avoir une classe par algo (blur pour reprendre ton exemple) et t'en servir comme paramètre de template. Il s'agit là de métaprogrammation: la classe n'est jamais instanciée, elle sert de paramètre à une autre classe (cf. Policy-based design sur wikipédia, ou la bibliothèque Loki d'Andrei Alexandrescu). J'insiste, va voir Anti-Grain c'est aussi une bibliothèque graphique, indépendante du type de pixel, couleur, etc., statiquement polymorphe et (à mon avis) lisible.
En ce qui concerne de "faire du C++" je note que tu utilises pas mal de fonctions stdio/stdlib (fopen, sprintf, memcpy, etc.), alors que de meilleurs équivalents C++ sont disponibles (std::fstream, std::ostringstream, std::copy, etc.).
* 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...
Pour les macros, c'est un peu pareil, c'est du C. Je suis sûr qu'il est possible de les réécrire sous forme de templates, elles seraient certainement plus courtes, "type-safe", et le compilateur devrait être capable de produire de meilleures optimisations.
[^] # 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é à 2.
Ce n'est pas ce que je veux dire. L'idée de la programmation objet (quel que soit le langague) est justement de séparer les concepts, d'avoir des classes minimalistes qui représentent un invariant. Il ne me semble pas judicieux, par exemple de mêler dans une même classe gestion des fichiers, des options de ligne de commande, l'interface utilisateur, etc.
J'ai bien vu que tu utilises des traits -- trop peu à mon goût, mais je découvre ta bibliothèque, alors je suis prudent dans mes commentaires :-).
En ce qui concerne les policies, tu pourrais bien, par exemple avoir une classe par algo (blur pour reprendre ton exemple) et t'en servir comme paramètre de template. Il s'agit là de métaprogrammation: la classe n'est jamais instanciée, elle sert de paramètre à une autre classe (cf. Policy-based design sur wikipédia, ou la bibliothèque Loki d'Andrei Alexandrescu). J'insiste, va voir Anti-Grain c'est aussi une bibliothèque graphique, indépendante du type de pixel, couleur, etc., statiquement polymorphe et (à mon avis) lisible.
En ce qui concerne de "faire du C++" je note que tu utilises pas mal de fonctions stdio/stdlib (fopen, sprintf, memcpy, etc.), alors que de meilleurs équivalents C++ sont disponibles (std::fstream, std::ostringstream, std::copy, etc.).
* 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...
Pour les macros, c'est un peu pareil, c'est du C. Je suis sûr qu'il est possible de les réécrire sous forme de templates, elles seraient certainement plus courtes, "type-safe", et le compilateur devrait être capable de produire de meilleures optimisations.