Voilà, ton commentaire est intéressant, parce qu'il illustre parfaitement ce que je disais précédemment, à savoir que tu donnes un avis assez tranché, mais "général", sur la façon de structurer un code (avis d'ailleurs que je peux partager pour du code "classique"), alors même que tu ne connais pas suffisamment les spécificités techniques des projets G'MIC (et CImg surtout) pour comprendre pourquoi j'ai fait comme ça (et c'est parfaitement normal également). Et dans le cas du projet G'MIC en particulier, il s'avère que cette structuration classique ne serait pas forcément la meilleure. Note qu'elle ne serait pas tellement plus mauvaise non plus, mais qu'à mon avis, elle propose légèrement moins d'avantages (et mon point de vue a quand même un poid important sur le résultat final). Ca se joue pas à grand chose, mais c'est comme ça. Et comme ça se joue quand même vraiment sur des détails (purement techniques en plus), ça m'étonne toujours que ça fasse tant parler. Surtout que la plupart des gens qui émettent un avis n'en savent probablement pas suffisamment pour que leur avis soit constructif.
Mais de fait, je maintiens qu'avoir plusieurs fichiers plutôt qu'un seul est un point purement technique, au fond assez anecdotique. La quantité de donnée stockée est quasiment la même dans les deux cas (avec même moins de redondance dans le cas d'un gros fichier). Le point qui te dérange sans doute, c'est de te dire que le compilateur est plus efficace à compiler plusieurs fichiers qu'un seul gros. Et que séparer en plusieurs fichiers, c'est l'assurance de ne pas recompiler des bouts de code déjà compilés.
Tu as raison "en général", mais d'une part, je dirais que ça pourrait presque être vu comme une limitation du compilo. On peut très bien imaginer dans le futur qu'un compilateur puisse déterminer quelles parties d'un gros fichier il doit recompiler, sans recompiler le reste du fichier. Mais bon, Ok c'est pas encore le cas. Par contre, ceci est vrai en général, sauf quand on utilise des bibliothèques de fonctions templates où le type des paramètres template est inconnu à la compilation. Est c'est exactement le cas de CImg, la bibliothèque d'opérateurs de traitement d'images que j'utilise (et que je distribue à part). Ici de toute façon, le compilo va devoir "tout" recompiler (en fait, non pas tout, il est assez malin pour recompiler juste les méthodes utilisées dans le code, avantage No 1 : tu auras pas dans ton code final des blobs binaires de code que tu n'utilises pas) pour les types template instanciés dans par l'utilisateur. C'est du template, c'est le principe.
Dans le cas de G'MIC, le gros du travail de compilation, c'est de compiler les méthodes de CImg qui sont utilisées, donc une fois que ça c'est fait, quasiment tout est fait. Après, dire que CImg est pas modulaire, c'est archi-faux, tout est bien structuré, dans des beaux namespaces, des belles classes, c'est juste que tout ça est défini dans un seul fichier. Pourquoi par plusieurs ? Parce que comme toutes ces belles classes dépendent fortement les une des autres, il faudrait de toute façon inclure tous ces beaux fichiers séparés en même temps, donc d'un point de vue performance de compilation, ça reviendrait exactement au même. A noter que de toute façon, la phase de parsing des fichiers par le compilo dans le temps global de compilation est réellement négligeable par rapport au reste (phase d'optimisation en particulier) donc que le fichier soit gros ou pas, le compilo s'en tape un peu.
Revenons en au temps de compilation. Hé bien non, ça prend pas longtemps, désolé (avec un compilo décent). Peut-être un peu plus longtemps que si j'avais utilisé des fonctions non-template (mais j'aurais perdu en généricité, ce qui serait perdre beaucoup pour gagner peu), mais ça reste très acceptable pour développeur. Actuellement, sans les optimisations, G'MIC complet, avec toutes les dépendances se compile en 1 minute (sur mon portable, avec g++ 4.8). C'est long 1 minute pour un projet comme G'MIC ? Non, carrément pas !
(avec clang++ c'est kif-kif). Alors OK, avec les optims c'est plus long, mais ça c'est quelque chose qu'on fait seulement de temps en temps, pas pour le développement de tous les jours (et au boulot, pareil ça prend 15mn avec make -j... oulala j'ai à peine le temps d'aller prendre un chocolat chaud à la machine avant que ma release soit prête. Pourquoi penses-tu que je peux proposer des pre-releases quasiment journalières sans que ça soit une torture ?).
Après, tu sous-entends que ça favorise pas les contributions extérieures. Mais c'est là encore archi-faux ! Des contributions j'en recois raisonablement, autant pour CImg que pour G'MIC. Et quelle facilité pour maintenir le code ! Une contribution sur un tel code, ça sera forçément très local dans un fichier, ça sera pas du code nouveaux disséminé dans 4 ou 5 fichiers différents, et bien ça c'est très appréciable pour la relecture des patchs, et la mise en adéquation au style de codage du projet. Je conseille à tout le monde d'essayer au moins une fois dans sa vie de maintenir un projet avec 3-4 fichiers maxi. Vous allez voir comme c'est simple !
Découper un projet en pleins de fichiers, c'est pas juste une question de mode ou pas de mode. Il faut le faire quand c'est nécessaire, mais il faut surtout ne pas se forcer à le faire quand ça sert à rien. Dans le cas de G'MIC / CImg, ça sert à rien. Que quelqu'un me prouve le contraire (mais pas juste avec des arguments bateaux), comme je le dis je suis pas fermé. Mais depuis 1999 (année ou j'ai commencé CImg), jamais personne ne m'a convaincu. Je commence quand même à me dire que c'est parce que j'ai choisi une façon de faire qui se défend carrément.
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 9.
Voilà, ton commentaire est intéressant, parce qu'il illustre parfaitement ce que je disais précédemment, à savoir que tu donnes un avis assez tranché, mais "général", sur la façon de structurer un code (avis d'ailleurs que je peux partager pour du code "classique"), alors même que tu ne connais pas suffisamment les spécificités techniques des projets G'MIC (et CImg surtout) pour comprendre pourquoi j'ai fait comme ça (et c'est parfaitement normal également). Et dans le cas du projet G'MIC en particulier, il s'avère que cette structuration classique ne serait pas forcément la meilleure. Note qu'elle ne serait pas tellement plus mauvaise non plus, mais qu'à mon avis, elle propose légèrement moins d'avantages (et mon point de vue a quand même un poid important sur le résultat final). Ca se joue pas à grand chose, mais c'est comme ça. Et comme ça se joue quand même vraiment sur des détails (purement techniques en plus), ça m'étonne toujours que ça fasse tant parler. Surtout que la plupart des gens qui émettent un avis n'en savent probablement pas suffisamment pour que leur avis soit constructif.
Mais de fait, je maintiens qu'avoir plusieurs fichiers plutôt qu'un seul est un point purement technique, au fond assez anecdotique. La quantité de donnée stockée est quasiment la même dans les deux cas (avec même moins de redondance dans le cas d'un gros fichier). Le point qui te dérange sans doute, c'est de te dire que le compilateur est plus efficace à compiler plusieurs fichiers qu'un seul gros. Et que séparer en plusieurs fichiers, c'est l'assurance de ne pas recompiler des bouts de code déjà compilés.
Tu as raison "en général", mais d'une part, je dirais que ça pourrait presque être vu comme une limitation du compilo. On peut très bien imaginer dans le futur qu'un compilateur puisse déterminer quelles parties d'un gros fichier il doit recompiler, sans recompiler le reste du fichier. Mais bon, Ok c'est pas encore le cas. Par contre, ceci est vrai en général, sauf quand on utilise des bibliothèques de fonctions templates où le type des paramètres template est inconnu à la compilation. Est c'est exactement le cas de CImg, la bibliothèque d'opérateurs de traitement d'images que j'utilise (et que je distribue à part). Ici de toute façon, le compilo va devoir "tout" recompiler (en fait, non pas tout, il est assez malin pour recompiler juste les méthodes utilisées dans le code, avantage No 1 : tu auras pas dans ton code final des blobs binaires de code que tu n'utilises pas) pour les types template instanciés dans par l'utilisateur. C'est du template, c'est le principe.
Dans le cas de G'MIC, le gros du travail de compilation, c'est de compiler les méthodes de CImg qui sont utilisées, donc une fois que ça c'est fait, quasiment tout est fait. Après, dire que CImg est pas modulaire, c'est archi-faux, tout est bien structuré, dans des beaux namespaces, des belles classes, c'est juste que tout ça est défini dans un seul fichier. Pourquoi par plusieurs ? Parce que comme toutes ces belles classes dépendent fortement les une des autres, il faudrait de toute façon inclure tous ces beaux fichiers séparés en même temps, donc d'un point de vue performance de compilation, ça reviendrait exactement au même. A noter que de toute façon, la phase de parsing des fichiers par le compilo dans le temps global de compilation est réellement négligeable par rapport au reste (phase d'optimisation en particulier) donc que le fichier soit gros ou pas, le compilo s'en tape un peu.
Revenons en au temps de compilation. Hé bien non, ça prend pas longtemps, désolé (avec un compilo décent). Peut-être un peu plus longtemps que si j'avais utilisé des fonctions non-template (mais j'aurais perdu en généricité, ce qui serait perdre beaucoup pour gagner peu), mais ça reste très acceptable pour développeur. Actuellement, sans les optimisations, G'MIC complet, avec toutes les dépendances se compile en 1 minute (sur mon portable, avec g++ 4.8). C'est long 1 minute pour un projet comme G'MIC ? Non, carrément pas !
(avec clang++ c'est kif-kif). Alors OK, avec les optims c'est plus long, mais ça c'est quelque chose qu'on fait seulement de temps en temps, pas pour le développement de tous les jours (et au boulot, pareil ça prend 15mn avec make -j... oulala j'ai à peine le temps d'aller prendre un chocolat chaud à la machine avant que ma release soit prête. Pourquoi penses-tu que je peux proposer des pre-releases quasiment journalières sans que ça soit une torture ?).
Après, tu sous-entends que ça favorise pas les contributions extérieures. Mais c'est là encore archi-faux ! Des contributions j'en recois raisonablement, autant pour CImg que pour G'MIC. Et quelle facilité pour maintenir le code ! Une contribution sur un tel code, ça sera forçément très local dans un fichier, ça sera pas du code nouveaux disséminé dans 4 ou 5 fichiers différents, et bien ça c'est très appréciable pour la relecture des patchs, et la mise en adéquation au style de codage du projet. Je conseille à tout le monde d'essayer au moins une fois dans sa vie de maintenir un projet avec 3-4 fichiers maxi. Vous allez voir comme c'est simple !
Découper un projet en pleins de fichiers, c'est pas juste une question de mode ou pas de mode. Il faut le faire quand c'est nécessaire, mais il faut surtout ne pas se forcer à le faire quand ça sert à rien. Dans le cas de G'MIC / CImg, ça sert à rien. Que quelqu'un me prouve le contraire (mais pas juste avec des arguments bateaux), comme je le dis je suis pas fermé. Mais depuis 1999 (année ou j'ai commencé CImg), jamais personne ne m'a convaincu. Je commence quand même à me dire que c'est parce que j'ai choisi une façon de faire qui se défend carrément.