C++ interdit de noyau.

• [^]Re: C++ interdit de noyau.

  Posté par Raphaël Maurel-Segala () le 28/10/2004 à 16:45. (lien). Évalué à 3.

  Puisque le sujet "à quoi ça sert" vient d'être évoqué, le non-informaticien raplique pour s'enquérir des détails.
  Bon, ce serait quoi, l'intérêt de supporter le C++ dans le noyau ?

  • [^]Re: C++ interdit de noyau.

    Posté par Erwan (page perso, ) le 28/10/2004 à 17:26. (lien). Évalué à 7.

    Ca servira a ceux qui preferent le C++ au C d'ecrire des modules dans un langage qu'ils preferent. C'est tout. C'est comme les bindings C++ de Gtk/Gnome, ca ne permet pas d'ajouter des "killer features" mais juste d'apporter du confort a certains developpeurs.

    [+] [^]Re: C++ interdit de noyau.

    Posté par 007 () le 28/10/2004 à 17:41. (lien). Évalué à -10.

    > Bon, ce serait quoi, l'intérêt de supporter le C++ dans le noyau ?
    
    Excellente question.
    Fesons une analogie.
    KDE => C++
    Gnome => C
    
    Voilà, tu as ta réponse.

    • [^]Re: C++ interdit de noyau.

      Posté par Raphaël Maurel-Segala () le 28/10/2004 à 18:17. (lien). Évalué à 9.

      Magnifique. Du grand art, je suis sincèrement admiratif.
      
      Dois-je comprendre que ça servira à doter Linux d'une gestion avancée du troll directement au niveau noyau ? C'est clairement une fonctionnalité cruciale pour le power-user.
      
      Si c'est le cas, il faudra penser à en causer sur fr.comp.os.linux.debats. Luc2 sera certainement intéressé.
      
      Mais je suis pas sûr de très bien comprendre. Tu pourrais préciser avec d'autres analogies ? Quest-ce que ça donne avec Vi/Emacs ? Avec Gentoo/Debian ? etc.

      • [+] [^]Re: C++ interdit de noyau.

        Posté par 007 () le 28/10/2004 à 18:39. (lien). Évalué à -10.

        > Mais je suis pas sûr de très bien comprendre.
        
        Si t'as toujours pas compris quel est le meilleur des deux languages, j'y suis pour rien.
        Compte pas sur moi pour nourrir le troll.

        • [^]Re: C++ interdit de noyau.

          Posté par KaZeKaMi (page perso, ) le 28/10/2004 à 19:40. (lien). Évalué à 1.

          >Si t'as toujours pas compris quel est le meilleur des deux languages
          
          la réponse est bien sûr le Java

          [^]Re: C++ interdit de noyau.

          Posté par Larry Cow () le 28/10/2004 à 23:09. (lien). Évalué à 7.

          Si tu n'as toujours pas compris qu'un langage ne pouvait être le meilleur que pour un (ou plusieurs, certes) domaine donné... si tu n'as toujours pas compris ce qui dérange certaines personnes dans le C++... c'est peut-être que tu n'en as pas fait suffisament.
          
          C++ est un bon langage pour certaines choses. Pour de la simulation, par exemple.
          
          C++ est un langage quelconque, voire médiocre, pour d'autres choses, comme le développement de GUIs. Typiquement, les meilleurs APIs graphiques basées sur du C++ ajoutent toutes une bidouille à leur sauce pour dépasser les limites du langage. Genre QT avec le moc. Sans parler de cette vision si particulière (d'autres diraient "psycho-rigide") de l'objet.
          
          C++ est un (très) mauvais langages pour d'autres tâches, et la programmation système en fait partie.

          • [^]Re: C++ interdit de noyau.

            Posté par LupusMic (page perso, ) le 29/10/2004 à 07:31. (lien). Évalué à 5.

            > Typiquement, les meilleurs APIs graphiques basées sur du C++ ajoutent toutes une bidouille à leur sauce pour dépasser les limites du langage. Genre QT avec le moc.
            
            Je crois que tu place la médiocrité au mauvais endroit. En effet, les rustines made in QT ont été écrites pour pallier à des manques initiaux du C++. Depuis, le C++ a évolué... QT est resté dans ses rustines...

            • [^]Re: C++ interdit de noyau.

              Posté par Pinaraf (Jabber id, ) le 30/10/2004 à 10:25. (lien). Évalué à 1.

              Et il me semble qu'avec QT4 on verra une certaine évolution de ce point de vue là (utilisation des templates, des namespace...)

              • [^]Re: C++ interdit de noyau.

                Posté par zeSixty4Douille () le 31/10/2004 à 13:47. (lien). Évalué à 1.

                c'est vraiment dommage ... J'espere pas qu'il considere cela comme la killer feature de Qt4. Cependant je suis persuade que les gars qui ont fait Qt s'y connaissent vraiment en compilateur.
                
                Qq1 sait ou l'on peut trouver les C++ coding rules de KDE ? Celle de mozilla sont tres bonnes en tout cas.

                • [^]Re: C++ interdit de noyau.

                  Posté par Pinaraf (Jabber id, ) le 31/10/2004 à 14:02. (lien). Évalué à 1.

                  Les killer features de Qt4 sont trop nombreuses (enfin par rapport à Qt3 je suppose que d'autres libs concurrentes de Qt ont déjà certaines de ces features).
                  J'attend beaucoup de QT4 + KDE4... Vitesse, conso mémoire...
                  Cependant je suis persuade que les gars qui ont fait Qt s'y connaissent vraiment en compilateur.
                  J'avais lu une interview d'un dév de Qt, et je confirme, ils ont une expérience énorme en matière de compilo ! Ils ont des règles définissant ce qu'on peut faire ou pas, en fonction des compilateurs. Par exemple les namespaces n'arrivent dans Qt4 que parce que maintenant assez de compilateurs sont aptes à gérer ça correctement.

            [+] [^]Re: C++ interdit de noyau.

            Posté par 007 () le 29/10/2004 à 09:59. (lien). Évalué à -6.

            T'aimes pas KDE ?

            • [+] [^]Re: C++ interdit de noyau.

              Posté par 007 () le 29/10/2004 à 12:23. (lien). Évalué à -2.

              Les gens n'ont pas d'humour. Je n'ai dit pas que le C était meilleur que le C++ ou l'inverse.
              Il est piquant de voir qu'un commentaire neure peut déchainer autant de [-].
              Sûr que les pro C ont autant noté [-] que les pro C++.
              
              Apparament la présence de "KDE" et "Gnome" ou "C" et "C++" en même temps braque les gens. Même si on ne dit rien.
              
              Je voulais dire que discuter des avantages du C par rapport aux avantages du C++ et vice versa relève de la "guerre de religion".
              
              Je l'ai dit et vous le démontrez avec la pluie de [-] que j'ai reçu.

              • [^]Re: C++ interdit de noyau.

                Posté par Gart Algar (Jabber id, ) le 29/10/2004 à 13:43. (lien). Évalué à 6.

                Je l'ai dit et vous le démontrez avec la pluie de [-] que j'ai reçu.

                
                Tu l'as pas vraiment dis, en fait pour moi tu as plutôt sorti un appeau à troll de la taille de l'arche de la défense. Et vu que la saison de la chasse n'a pas encore commencée, tu t'es fait arrêter en plein braconnage.
                Allez, file avec que j'appel le garde-chamêtre :)

                --
                Ubuntu is an ancient african word meaning : "I can't configure Debian"

                [^]Re: C++ interdit de noyau.

                Posté par Antoine () le 29/10/2004 à 16:07. (lien). Évalué à 5.

                Même si on ne dit rien.
                
                Apparemment le problème est surtout que tu ne dis rien...

    [^]Re: C++ interdit de noyau.

    Posté par Tennis Prono (page perso, ) le 28/10/2004 à 20:04. (lien). Évalué à 3.

    Bon, ce serait quoi, l'intérêt de supporter le C++ dans le noyau ?
    Utiliser des destructeurs pour s'assurer que tout est bien nettoyé quand tu sors d'une fonction.

    --
    Pas de bureau 3d libre sans drivers libres!

    • [^]Re: C++ interdit de noyau.

      Posté par Ramso (page perso, ) le 28/10/2004 à 20:37. (lien). Évalué à 4.

      Je suis sûr qu'il y a l'équivalent des destructeurs dans l'API du noyau et qui est appelé par exemple quand on retire un module (rmmod).

      --
      Groar !

      • [+] [^]Re: C++ interdit de noyau.

        Posté par Ayrton () le 28/10/2004 à 21:15. (lien). Évalué à -1.

        C'est kobject.

        [^]Re: C++ interdit de noyau.

        Posté par Christophe Lucas (page perso, ) le 29/10/2004 à 09:20. (lien). Évalué à 2.

        Bah c'est au programmeur de faire cela correctement dans module_exit()
        
        Bonne journée à tous :-)

        --
        - Christophe -

        [^]Re: C++ interdit de noyau.

        Posté par Tennis Prono (page perso, ) le 29/10/2004 à 11:26. (lien). Évalué à 2.

        Avec un destructeur d'objec C++ construit sur la pile, tu peux faire plein de trucs pratiques comme prendre un mutex dans un bloc de code et le libérer à la fin.
        
        static CMutex m_Mutex;
        
        {
        CMutextGuard guard(m_Mutex);
        // du code
        }
        
        Quand tu as des "return", "goto" ou des exceptions C++ dans une fonction, c'est vite fait d'oublier un cas de sortie de la fonction (et le C n'a pas de clause "try/finally" comme Java et en Python pour faire un nettoyage forcé).

        --
        Pas de bureau 3d libre sans drivers libres!

        • [^]Re: C++ interdit de noyau.

          Posté par zeSixty4Douille () le 31/10/2004 à 13:36. (lien). Évalué à 1.

          moi je vois un probleme dans ce type de code : tu ne sais pas QUAND ton mutex est desalloue. Si tu as plusieurs objects automatiques, dans quel ordre sont appeles les destructeurs (pas simplement dans l'ordre inverse d'allocation) ?
          
          Puis la taille du code pour gerer des objects automatiques peut vraiment devenir problematique lorsque tu utilises des objects haut niveau si il y a beaucoups de conditions de sortie.
          
          Enfin, lorsque l'on utilise des mutex/sections critique, si tu veux pas pourrir les perfos, tu limites au maximum la taille du code enclos. A la limite, tu evites meme de faire les appels pour eviter des exceptions.
          
          Je connais des gars qui utilisent RogueWave, qui font ce genre de code, ca ne fonctionne que si le code est compile en debug ...

      [^]Re: C++ interdit de noyau.

      Posté par manatane () le 28/10/2004 à 21:28. (lien). Évalué à 4.

      Bin justement un reproche fait au C++ dans la programmation d'un système d'exploitation : any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.