Journal GREYCstoration : Appel à contribution

Posté par  (site web personnel) .
0
31
jan.
2007
Bonjour à tous.
J'ai une info et un appel à contribution à proposer ici.

L'info, c'est que la dernière version 1.1.8 de CImg est sortie vendredi dernier. CImg [1] est une bibliothèque libre C++ pour le traitement d'images génériques, simple à utiliser et multi-plateforme, distribuée sous licence CeCILL.
Le package contient de nombreux exemples d'utilisation (voir [2] pour quelques screenshots et videos en ligne), et en particulier l'algorithme GREYCstoration [3] qui permet de débruiter, inpainter et redimensionner des images. Cet algorithme est basé sur des recherches assez récentes sur les EDP de diffusion [3.5] que j'ai menées au laboratoire GREYC, UMR 6072 du CNRS, implanté à Caen.

Cet algorithme a été porté il y a de cela quelque temps par Victor Stinner dans un plug-in GIMP [4] pour le débruitage d'images. Or depuis ce premier portage (il y a presque 2 ans maintenant), GREYCstoration (l'algorithme) a pas mal évolué, en particulier en terme de vitesse d'exécution (x3!) et de qualité de résultats. Victor m'a confirmé n'avoir plus le temps de s'occuper de ce plug-in, et son développement est donc gelé sur la toute première version de l'algo, ce que je trouve vraiment dommage !
J'ai bien essayé de me plonger un peu dans le code de Victor pour essayer de mettre à jour l'algo, mais j'avoue que la programmation de plug-in et autres GUI n'est absolument pas dans mon domaine de compétences, en plus d'avoir très peu de temps pour cela.
Par contre, j'ai créé une extension pour CImg, qui permet de faciliter l'intégration de GREYCstoration dans des applis tierces. Un exemple d'utilisation minimal [5] permet de se rendre compte de la simplicité d'utilisation.

La situation est donc la suivante :

- Il y a un plug-in GIMP déjà fonctionnel, mais pas très récent, contenant la GUI + le code de l'algorithme de débruitage (l'ancien, ré-organisé dans sa structure par Victor).
- Il y a une extension GREYCstoration de CImg pouvant être appelé simplement de n'importe quel programme C++ externe (un simple include et un appel à une méthode). Cette extension est à priori assurée d'être toujours à jour (c'est moi qui la maintient).

Ma question est donc :
Y-aurait-il quelqu'un(e) interessé(e) pour essayer de recoller ces deux bouts, afin de fournir un plug-in GREYCstoration pour GIMP qui pourrait se mettre facilement à jour en mettant simplement à jour CImg et en recompilant le plug-in ? En gros, il faudrait enlever le code de l'algo dans l'ancien plug-in, et interfacer avec l'extension GREYCstoration de CImg à la place. A noter que l'extension est prévue pour fonctionner de manière multi-threadé et renvoit notamment une indication sur l'état d'avancement du processus. Je ne pense pas que ca soit particulièrement compliqué mais faut mettre les doigts dans le cambouis de GIMP un peu quand même (si j'avais 10 ans de moins... :) ).

Voila, j'espère que ca interessera quelqu'un ! Je pense vraiment qu'avoir une méthode libre de débruitage d'images performante et customisable pour GIMP serait un super truc, avec une bonne visibilité. Si ca vous tente, contactez moi (e-mail boulot) je suis bien sûr prêt à donner un coup de main pour que ca avance au plus vite.

Merci de votre attention.
David.

--------- Références ------------

[1] CImg : http://cimg.sourceforge.net
[2] CImg Screenshots : http://cimg.sourceforge.net/screenshots.shtml
[3] GREYCstoration : http://www.greyc.ensicaen.fr/~dtschump/greycstoration/demons(...)
[3.5] GREYCstoration, le principe :
http://www.greyc.ensicaen.fr/~dtschump/data/ijcv2006.pdf
[4] Port de GREYCstoration pour GIMP : http://linuxfr.org/~haypo/17437.html
[5] Code source pour utiliser l'extension GREYCstoration de CImg : http://cimg.cvs.sourceforge.net/cimg/CImg/examples/greycstor(...)
  • # Hum..

    Posté par  (site web personnel) . Évalué à 10.

    C'est où pour plusser les journaux ?
    • [^] # Re: Hum..

      Posté par  . Évalué à 7.

      La première impression que j'ai eu en essayant le plugin d'Haypo il y a presque 2 ans était bien : Whaoo on tient vraiment quelque chose de bon... !
      La comparaison d'ailleurs avec de bons logiciels propriétaires tenait largement la route.
      Si l'algo a fait du chemin, il serait réellement dommage qu'il reste dans les cartons (ou dans les publications) de David. C'est un outil adapté et utilisable facilement pour de nombreuses tâches (et même en "production"...)
      Jetez un oeil sur les videos et copies d'écran de l'ensemble de la bibliothèque CImg, c'est assez bluffant.

      La recherche fondamentale publique en France est capable de choses magnifiques... qui resteront inconnues si personne ne s'en sert !

      Merci à David et merci à ceux qui feront de son travail un outil utilisable pour tous.
  • # S'adresser aux devs de GIMP ?

    Posté par  . Évalué à 3.

    Il doit y avoir une ML de développement pour GIMP non ? si ça se trouve les devs seraient intéressés par ton algo, et pourraient l'intégrer directement dans le logiciel, avec les avantages de maintien, d'intégration, que ça comporte, sans compter la pub potentielle ;)
    • [^] # Re: S'adresser aux devs de GIMP ?

      Posté par  (site web personnel) . Évalué à 2.

      Apparemment, Victor avait déjà essayé de voir avec eux, mais ils ne veulent pas de plug-in basés sur du C++.
      Peut-être peut-il confirmer.. Mais effectivement, c'est dommage.

      David.
      • [^] # Re: S'adresser aux devs de GIMP ?

        Posté par  (site web personnel) . Évalué à 2.

        Pour info le lien où il en parlait à l'époque: http://linuxfr.org/comments/546001.html#546001

        J'imagine que la position des dév. de GIMP n'a pas évolué depuis.
        • [^] # Re: S'adresser aux devs de GIMP ?

          Posté par  . Évalué à 6.

          "J'imagine que la position des dév. de GIMP n'a pas évolué depuis."

          GIMP non plus.



          Pour moi, GIMP est LA déception des logiciels libres: en 2000, il pouvait concurrencer partiellement Photoshop 5.5 avec sa version 1.17. aujourd'hui, Gimp est quasiment le même.

          Quelques bug corrigés, une gestion des images lourdes un peu meilleures mais aucune révolution. Pas de gestion du CMJK, des images 16bits, des méta-données IPTC.


          David, as-tu contacté les développeurs de Krita qui peut-être sauront reconnaitre la qualité de ton algorithme.
          • [^] # Re: S'adresser aux devs de GIMP ?

            Posté par  . Évalué à 1.

            As-tu déjà entendu parler de GEGL ? Sinon, un quelconque moteur de recherche te donnera quelques informations...
            • [^] # Re: S'adresser aux devs de GIMP ?

              Posté par  (Mastodon) . Évalué à 3.

              Pour ceux qui, comme moi, ne savent pas ce que c'est :

              GEGL (Generic Graphics Library) is a graph based image processing framework.

              GEGLs original design was made to scratch GIMPs itches for a new compositing and processing core. This core is being designed to have minimal dependencies. and a simple well defined API.


              Ce qui n'enlève rien aux propos du commentaire précédent le précédent (vous suivez ? ;) ;) ), Gimp a très peu évolué depuis, en gros, Gimp 2 ....
      • [^] # Re: S'adresser aux devs de GIMP ?

        Posté par  (site web personnel) . Évalué à 2.

        Oui le C++ n'est pas une langage admis dans GIMP.

        Par contre, ce qui peut être fait, c'est de coder une glue C->C++ sur laquelle se baserait le plugin. Dans ce cas, le projet Gimp+plugin greycstoration serait 100% C, il aurait une chance d'etre revu et accepté. Par contre il faudrait, j'imagine, que cette glue C->C++ soit maintenue Upstream (David quoi :-)) sinon on se retrouve dans le cas où Gimp dépend de C++.

        Un autre projet fait ce genre de chose. Il s'agit de libopenraw, Hugue Figuiere n'est pas pour un retour au C, il lui prefere le C++ pour ce projet. Par contre conscient que le C++ pose trop souvent des problemes d'ABI, il a codé une API C qui fait le pont entre le C++ et le C.
  • # Krita

    Posté par  . Évalué à 2.

    Je sais que ca a été aussi implémenté à l'époque dans Krita.
    http://dot.kde.org/1112424719/1112455063/1112456663/
    http://docs.kde.org/stable/en/koffice/krita/commands-dialogs(...)

    Est-ce que qqun sait si la situation est mieux suivie ?
    Sinon, comme il y a une conférence sur krita au fosdem, j'en soufflerai 2 mots à cette occasion :-)
    • [^] # Re: Krita

      Posté par  (site web personnel) . Évalué à 3.

      Pour Krita et Digikam, j'ai mis au courant les développeurs des projets sur la mise à jour de GREYCstoration. Mais je crois savoir qu'ils se sont basés sur les sources du plug-in GIMP pour leur intégration, donc je ne sais pas si ils ont pu mettre à jour l'algorithme de leur coté.

      En faisant l'extension à GREYCstoration ,j'avais justement dans l'idée de centraliser l'utilisation de l'algo GREYCstoration pour pouvoir proposer des mises à jours simples aux développeurs sans qu'ils aient besoin de répercuter beaucoup de modifs sur leur propre code.

      David.
  • # Krita et digikam

    Posté par  (Mastodon) . Évalué à 2.

    Il me semblait qu'il existait des plugins pour Krita et digikam aussi : qu'en est il de la mise à jour de ceux-ci ?
    Concernant Krita, j'ai vu qu'il était toujours dans l'arborescence svn, mais pas moyen de trouver une info sur sa mise à jour (je ne risque pas d'y comprendre grand chose !), d'où ma question.

    Merci.
  • # Une vraie bibliothèque.....

    Posté par  (site web personnel) . Évalué à 0.

    Je ne veux pas passer pour le donneur de leçons, mais il semble quand même que ton gros fichier .h de plusieurs milliers de lignes, avec en vrac des trucs pour le fenêtrage/affichage, des fonts en dur etc.... embête plus qu'autre chose. Tu avais l'air de penser que c'est le plus simple, et pourtant regarde :
    - personne au monde ne fait comme ça (parmi les personnes qui codent bien en tout cas...) ; c'est quand même un indice.
    - si le packager pour le plug-in gimp l'a dit, que les dev krita préfèrent partir du code du plug-in Gimp, c'est peut-être un autre indice.
    - les dev ne sont pas des imbéciles ; s'ils n'arrivent pas à gérer 3 .cpp qui se courent après, ils peuvent arrêter de coder....

    Si ton code était bien séparé entre .h et .cpp, qu'on puisse obtenir une vraie bibliothèque, ça changerait surement des choses (et si comble du bonheur, il y avait en plus une interface en pur C, ça ouvrirait encore d'autres horizons -- même si SWIG gère aussi le C++) : un vrai paquet dans les distribs, des bindings vers d'autres langages (python etc...), un développement pour des plug-in facilité...

    Enfin bon, je m'emporte, et je ne t'ai même pas félicité pour ton algo excellent ; mais je trouve dommage qu'il soit si mal mis en valeur.
    • [^] # Re: Une vraie bibliothèque.....

      Posté par  (site web personnel) . Évalué à 7.

      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 :

      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.
      • [^] # Re: Une vraie bibliothèque.....

        Posté par  (site web personnel) . Évalué à 2.

        Et je m'excuse auprès des développeurs de GIL d'Adobe, leur travail est très intéressant et instructif par ailleurs (j'ai regardé en détail leur présentation), même si je ne suis pas d'accord sur tout leurs concepts.
      • [^] # Re: Une vraie bibliothèque.....

        Posté par  . Évalué à 0.

        Je confirme : effectivement en C++, quand on utilise les templates, il faut le faire dans le .h... voir par exemple la lib boost... qui est un gros .h !

        En résumé : C++ c'est de la daube.
        • [^] # Re: Une vraie bibliothèque.....

          Posté par  . Évalué à 6.

          - Ton '.h' tu l'appeler '.c' ou même .bidule si ya que ça qui te gênes.
          - Je ne vois pas en quoi mettre du code dans le '.h' te gênes, c'est d'ailleurs ce que font beaucoup de langages, qui ne font pas de distinction entre déclaration et définition (au hasard sh,eiffel,perl,java,list,ocaml,python,C#,etc.)
          - Enfin c'est sur qu'en C, on va pas déclarer des templates dans un '.h' puisque ce langage n'implémente pas les templates (et passer par le préprocesseur pour faire du template-like ou caster du void*, c'est au moins aussi pourri).
          En résumé: ton résumé est naze.
          • [^] # Re: Une vraie bibliothèque.....

            Posté par  . Évalué à 3.

            Si, ocaml fait une différence entre définition et déclaration... c'est la différence entre un .mli et un .ml -- ou un .cmi et un .cmo.

            Et non, renommer un .h en .c (ou .cpp, .cxx, .cc, etc) ne change rien : c'est toujours un fichier qu'il faut #includer pour l'utiliser plutôt que linker avec.

            Techniquement, le problème est que le C++ n'est pas un pur langage à part, il est construit sur le C. Or un fichier objet C ne peut contenir que des implémentations. Un foo n'est pas implémenté, donc ne peut trouver sa place dans un .o. Voir la faq C++ pour les détails.

            En résumé, mon résumé est correct : une lib avec template doit venir en .h, c'est normal.

            Que certains ne soient pas d'accord avec mon opinion ferme sur le C++ est une autre histoire.
        • [^] # Re: Une vraie bibliothèque.....

          Posté par  (site web personnel) . Évalué à 3.

          Quelle argumentation, quel sens critique. On sent la longue expérience qui a permis de se forger un avis construit.

          Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: Une vraie bibliothèque.....

        Posté par  (site web personnel) . Évalué à 0.

        Merci de ta longue réponse.

        Alors non je n'ai pas ton expérience en C++ c'est bien certain. Mais l'argument 'ça existe depuis des années' désolé mais bof bof. Le VB aussi ça existe depuis des années....

        Ensuite oui je connais la STL et le principe des templates ; et bien elle n'est pas constituée d'un seul fichier tu m'excuseras. Donc non je n'ai pas la prétention de connaître la meilleure façon de faire , sinon je ne me remettrais pas en question tous les 3 jours. Et si je suis peut-être prétentieux (on est mauvais juge de soi-même), permets moi de te retourner le compliment.

        Alors tu fais ce que tu veux, je n'ai droit de regard sur ton travail (je précise que toutes les remarques que j'ai faites je les ai faites sur des souvenirs de précédents journaux ; c'est parce l'air de rien je me suis intéressé à ton travail). Mes critiques se voulaient constructives c'est tout, mais ta 1ère liberté, c'est de ne pas les écouter.

        Je ne peux que souhaiter qu'une bonne âme face le plug-in gimp. Voilà.
        • [^] # Re: Une vraie bibliothèque.....

          Posté par  (site web personnel) . Évalué à 0.

          Je n'ai fait que répondre point par point à ton argumentaire, si tu trouves ca prétentieux, c'est bien dommage, j'essayais d'être constructif.
          Après, le style employé à chaud est peut-être un peu aggressif, mais étant donné le ton de ton premier message, tu m'excuseras je pense d'avoir répondu de la sorte.

          David.
          • [^] # Re: Une vraie bibliothèque.....

            Posté par  (site web personnel) . Évalué à 1.

            Je n'ai jamais prétendu être une brute du C++ ; je faisais référence à des gens comme ceux de boost par exemple. Tu sais, ces gros guignols qui s'y connaissent un tout petit peu en templates et méta programmation ; et bien eux non plus ne foutent pas tout dans un seul fichier (pourtant on pourrait certainement trouver des points perfectibles dans leur code, malgré leur maîtrise - parce que c'est de ça dont il s'agit). Alors que toi tu sembles être sûr de toi, parce que ta lib existe depuis 7 ans, donc tu ne peux pas avoir commis une seule erreur (j'entends par là que ce n'est pas un argument technique ça).

            [ argument technique oublié dans la précipitation : sinon découper en plusieurs fichiers, ça pourrait aussi apporter en temps de compilation (mais si tu codes en C++ comme un bourrin, tu dois le savoir) ]

            Sans rancune.
            • [^] # Re: Une vraie bibliothèque.....

              Posté par  . Évalué à 3.

              oui enfin tu n'aimes peut etre pas son style de programmation mais ca c'est ton probleme. Il a fait un librairie de traitement d'image rivalisant avec ce qui se fait dans le commerce, l'a mise en acces libre et il se trouve des gens pour cracher dessus parceque ne correspondant pas a leur style de programmation.

              Je sais pas si c'est possible, je ne connais pas bien la licence mais bon si c'st libre fait un fork et decoupe en petit morceau le fichier.

              Ce genre de reaction (surtout la precedente) a de quoi degouter la moindre personne de faire un logiciel libre.

              Moi je lui dis merci et c'est vrai que j'aimerai que ce soit inclu dans krita, digikam et gimp.
              • [^] # Re: Une vraie bibliothèque.....

                Posté par  (site web personnel) . Évalué à 1.

                J'avoue avoir été méchant. Je ne l'ai félicité qu'une seule fois ; et j'ai osé émettre un avis sur ce qui me semble être une légère erreur.

                Je ne le referai plus, c'est promis ; je n'émettrai à l'avenir plus que des commentaires dithyrambiques. C'est comme ça que les logiciels s'améliorent, en émettant _que_ des encouragements.

                <mode sincèrement gentil>
                Continue David, c'est du bon boulot.
                </mode sincèrement gentil>

                [et si David s'est senti agressé, j'en suis vraiment désolé, c'était vraiment pas mon intention. Il faut croire qu'écrire des commentaires quand on a passé une journée de merde c'est pas mon fort]
            • [^] # Re: Une vraie bibliothèque.....

              Posté par  . Évalué à 0.

              Je ne voudrais pas passer pour un donneur de leçons, mais il semblerait que cette petite plaquette http://www.hybird.org/plaquette_hybird.pdf de quelques lignes à peine, pour certaines d'entre elles colorées, pose quelques problèmes.

              Si son français était correct, de manière à ce que l'on puisse la déchiffrer convenablement, cela ferait certainement plus professionnel et t'ouvrirait d'autres horizons.

              Enfin bon, je dis ça, je dis rien.
              • [^] # Re: Une vraie bibliothèque.....

                Posté par  (site web personnel) . Évalué à 0.

                C'est bien possible, c'est pas moi qui m'en occupons (et pour l'instant on ne compte pas trop sur le web pour attirer les clients - et pourtant ça marche).

                Mais MERCI de ta critique.
              • [^] # Re: Une vraie bibliothèque.....

                Posté par  . Évalué à 1.

                d'abord merci, c'est "grâce" à toi que je viens voir ce magnifique journal.

                Parce que c'est moi qui est en grande partie cette plaquette dont le français ne te semble pas correct.

                Alors je dois dire il est vrai, que je ne comprend pas vraiment l'intêret de ton argument sur les fautes de français de cette plaquette dans une discussion sur le fait qu'une librairie en un seul fichier, c'est hautement perfectible et la pire des décisions possible.

                Mais soit, après tout, je n'ai pas la science infuse et peut-être que ton argument a sa place dans la discussion. (bien entendu je ne considère pas que le fait de me ridiculiser par pure mesquinerie , comme quand on était môme dans la cour de récré fasse qu'il est sa place ici, nous sommes au dessus de ces basses pratiques n'est ce pas ?)

                Mais donc, j'aimerais bien, que par message privé, tu me fasse la liste des mes erreurs de français, que je me couche moins couillon et que je puisse les corriger.

                Comme ça la prochaine fois que moi ou quelqu'un d'autre ayant un lien avec cette plaquette discutera technique, il n'aura pas comme argument le fait que je fasses des fautes de français.

                Merci d'avance pour ton message privé.
      • [^] # Re: Une vraie bibliothèque.....

        Posté par  . Évalué à 1.

        Bonjour,

        Quelques petites remarques. Et comme je suis fatigué, je vais parler franchement.

        Tout mettre en un seul fichier, c'est clairement une erreur de développement de débutant.

        Un fichier de 10 000 lignes c'est illisible. Il n'y a pas besoin de plonger son nez 5 minutes, 3h ou 30 secondes. Je serais malpoli , je dirais que un seul fichier c'est pourri ou autre chose.

        Puisqu'on parle de template, qui a dit qu'on devait découper obligatoirement découper les fichier en .h et .cpp ?

        C'est donc interdit de découper en plusieurs .h ? un par classe par exemple
        ou de faire des .h et des .hxx ( ou hpp ou inc ) les h ne faisant que déclarer les autres définir ?

        Les gens sont suffisant indigents dans leur compréhension d'une librairie pour ne vouloir qu'un seul enorme include. bah un fichier include_all.h qui fait tout les include des petits fichiers et que les gens qui le veulent pourront inclure.

        Bon après pour le reste des arguments, du style la tentative de dénigrement par le machin sur l'école d'ingé .. c'est risible.

        A et pour que tout soit clair, on sait jamais hein, je bosse dans le même bureau que le monsieur à qui tu réponds.

        Et pour que ca soit clair aussi de la programmation template C++ on en mange depuis quelques années, on en mange professionnellement depuis plus d'un an et c'est bien la première que je vois ça ...

        et pourtant des trucs bizarres, j'en ai vu...
      • [^] # Re: Une vraie bibliothèque.....

        Posté par  (site web personnel) . Évalué à 1.

        C'est très tendant de replonger dans le troll "un fichier de 13000 ça pue des fesses", mais je vais juste corriger une erreur qui m'a fait tomber de me chaise.

        La STL c'est loin d'être *un* fichier ! Pour commencer, chaque "composant" a son fichier :

        $ ls /usr/include/c++/4.1.2
        algorithm
        deque
        iostream
        ...

        Ensuite, quand on ouvre ces fichiers, on ne trouve que d'autres includes vers des fichiers (a) "bits/(...).h" et "bits/stl_(...).h" (ex: bits/basic_string.h) et des (b) "bits/(...).tcc".

        Les fichiers (a) ne contiennent que les prototypes, et bien documenté comme il faut. Fichiers courts, synthétiques, facile à lire.

        Les fichiers (b) contiennent l'implémentation, le code gruiiik que seuls les gourous arrivent à lire :-)

        Il y a donc 4 profondeurs de découpage :
        - par composant
        - include global pour simplifier la vie
        - prototype
        - implémentation

        ----

        Pourquoi découper prototype et implémentation ? Ben le fichier prototype sert de documentation.

        Pourquoi découper par composant ? Ben parce que les fichiers de 13.000 lignes ça pue de fesses (*plouf*, désolé).

        Victor
        • [^] # Re: Une vraie bibliothèque.....

          Posté par  (site web personnel) . Évalué à 2.

          Mais qui a dit que la STL c'était un seul fichier ? C'est du grand n'importe quoi !
          J'ai juste dis que c'était des .h, la dessus tu as l'air d'accord non ?
          Après, si vous voulez séparer la lib en plusieurs .h, pas de problèmes, mais
          comme les classes s'utilisent les unes dans les autres (ce qui n'est pas le cas de la STL), j'imagine aisément que la conséquence va être la suivante : tout les codes utilisant CImg vont commencer par :

          #include "CImg_namespace.h"
          #include "CImg_display.h"
          #include "CImg_toto.h"
          ...
          #include "CImg_globals.h"
          #include "CImg_tutu.h"

          à la place de #include "CImg.h".
          Alors dis moi, dans ce cas, où est le gain sur la vitesse de compilation ? sur la performance ? Bah oui tiens en fait, non ca sert à rien !
          Un grand merci pour ces conseils avisés !

          Quand je vois le toto du dessus qui parle d'erreur de débutant, j'imagine qu'il ne se classe donc pas dans cette catégorie.. quelle blague !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.