• # c++ su><or

    Posté par . Évalué à -10.

    de toute facon ls c++ n'est qu'un espece de surcouche mal foutu du c, C'est vraiment pas ce qu'on fait de mieux dans la serie des language objets.
    meme l'objective C c'est mieux
    Si on veut faire de l'oo propre faut prendre des languages propres du genre effel

    bon -1 pour lancer de troll abusif :-)
    • [^] # Re: c++ su><or

      Posté par (page perso) . Évalué à -10.

      .............
      .............




      Non, je marcherai pas dedans !
      • [^] # Re: c++ su><or

        Posté par (page perso) . Évalué à -10.

        Pffff, arrete de troller toi, on t'a vu.

        Tu me range ce c++ de merde. Tout le monde sais
        que c'est pourri.
      • [^] # Re: c++ su><or

        Posté par . Évalué à -7.

        VIVE LE GOTO++

        Ce merveilleux langage a été implémenté tout récemment d'une nouvelle fonction compatible avec les anciennes versions du goto++ !
        Etonnant non ?
        Cette fameuse fonction est :

        GOTO error

        Fallait y penser ;)

        Bientôt une implémentation pour le C++ ?
    • [^] # Re: c++ su><or

      Posté par (page perso) . Évalué à -10.

      Pour répondre à ton troll abusif, un autre:
      Le C++, c'est comme le C, il y a des milliers de librairies que personne ne sait utiliser à fond et que leurs concepteurs annoncent "standard". Résultat : Ca pullule à mort et tout le monde réinvente la roue à chaque fois ou y va de sa "petite" lib.
      A bas le C et le C++ !!!

      Ceci dit, ce serait bien cool si les libs standards étaient un peu plus fournies (et imposées d'ailleurs).
      • [^] # Re: c++ su><or

        Posté par . Évalué à 10.

        Je trouve la librairie standard (STL) déjà assez bien fournie et bien foutue. Elle est rapide à maîtriser et depuis que je l'utilise je gagne du temps en développement et je trouve mon code plus facilement lisible après quelques mois d'abandon...

        Il existe un excellent bouquin gratos sur le C++ contenant de nombreux chapitres très instructifs, écrits avec une approche pédagogique à l'adresse suivante :
        http://www.bruceeckel.com(...)
        Ca c'est écrit en anglais.
        En français on a (en GNU FDL) : http://casteyde.christian.free.fr/cpp/cours/index.html(...)
        Je ne l'ai pas encore lu entièrement, mais j'ai trouvé l'approche assez bonne pour le conseiller. Il y a évidemment une partie sur la STL.
        • [^] # Re: c++ poa....

          Posté par . Évalué à 10.

          Je trouve aussi (pour l'avoir longtemps utilise) que la STL apporte beaucoup de facilites. Elle demande un petit investissement, mais les concepts de conteneurs et d'iterateurs sont vraiment interessants/utiles.

          Un guide de reference est disponible la:
          http://www.sgi.com/tech/stl/(...)

          On peut cependant regretter qu'il manque des pointeurs intelligents (autoptr est bien mais pas toujours)... Comme "bonne librairie" on peut trouver la lib boost ( www.boost.org ), elle fournit pleins de trucs (dont des ptrs intellignents) qui ont vocation a etre introduit dans le standard pas la suite.
          • [^] # Re: c++ poa....

            Posté par . Évalué à 2.

            As tu réussi a faire utilisé boost dans une très grosse structure ?
            Si oui : avec qu'elles arguments ?
            J'ai un collègue que ne parle que de boost, mais c'est percu comme un gadget.
            • [^] # Re: c++ poa....

              Posté par . Évalué à 5.

              Non et pour cause j'ai jamais travaille pour ou dans une grosse structure. J'ai utilise boost pendant ma these pour developper quelques trucs dont j'avais besoin.

              L'argument le plus "simple" est que c'est dans l'esprit de la lib standard et que ca ajoute certains trucs qui manquent, sinon c'est bien portable et bien maintenu.
              • [^] # Re: c++ poa....

                Posté par (page perso) . Évalué à 10.

                L'argument le plus "simple" est que c'est dans l'esprit de la lib standard et que ca ajoute certains trucs qui manquent, sinon c'est bien portable et bien maintenu.

                C'est à dire que boost est réalisé en grande partie par des types qui font aussi partie du comité de normalisation C++; donc Boost suit bien sûr «l'esprit» de la STL, mais surtout, est considéré un peu comme un laboratoire d'idée, une espèce de «pré-STL» si on veut, plusieurs libs de boost sont candidates à une future normalisation dans la STL.
                Il y a certaines libs dans boost qui valent le coup d'oeil, par exemple regex pour les expressions régulières.
    • [^] # Ca trolle déja sec dans l'interview

      Posté par . Évalué à 10.

      Considérez-vous le succès de KDE (développé en C++), et la rapidité de son développement (face à un Gnome développé en C qui stagne) comme une démonstration de la supériorité de C++ sur de tels développements ?

      Ils nous ressortent le vieux troll gnome/kde de derriere les fagots. Sont pas aware chez DR.
    • [^] # Re: c++ su><or

      Posté par . Évalué à -7.

      Pour parler d'une telle façon du C++, tu ne dois pas vraiment connaître ce langage.
      Essayes par exemple de coder en C l'algo cité dans l'article de B. Stroustrup
      On verra si tu continues après à garder le même opinion !
      • [^] # Re: c++ su><or

        Posté par . Évalué à 10.

        Tu parles du truc qui trie les mots ? C'est pas le langage qu'il utilise là, mais les libs...

        En C avec la GLib on fait pareil en à peu près autant de lignes, je vois vraiment pas la différence, à part que la lib standard C++ intègre des trucs qui se trouvent ailleurs en C (dans la GLib par exemple)
        • [^] # Re: c++ su><or

          Posté par (page perso) . Évalué à -6.

          Oui, avec la glib ... qui est une lib en plus du C. fait ca avec la glibc par contre !

          L'interet c que toutes les implementations standards de C++ peuvent utiliser cet algo. ce qui n'est pas vrai d'une appli C/glib qui n'est pas utilisable sur tout les systemes.
          • [^] # Re: c++ su><or

            Posté par . Évalué à 10.

            Euh... tu sais sur combien de systèmes elle est portée la GLib ? Et sincérement, porter la GLib sur un nouveau système c'est _beaucoup_ plus simple que de porter un compilo C++ ou la STL, alors bon...

            Si on dit "tel langage est meilleur parce que son API de base est plus complète" on est bien mal barrés...
            • [^] # Re: c++ su><or

              Posté par (page perso) . Évalué à 10.

              Si on dit "tel langage est meilleur parce que son API de base est plus complète" on est bien mal barrés...

              La grande leçon de C++, c'est précisément qu'un langage doit avoir une librairie standard aussi complète que possible. Si C++ avait eu tout de suite la lib standard qu'il a maintenant, ça aurait évité énormément de merdes.

              C'est bien pour ça que Java et C# ont été designé dès le départ avec des libs standard très complètes.

              Donc oui, bien évidemment, un langage est meilleur si son API de base est plus complète.
              • [^] # Re: c++ su><or

                Posté par . Évalué à 10.

                Sauf que c'est dur de considerer qu'une API puisse faire partie d'un langage. Enfin je dis ça, je dis rien. Le coup de l'"API de base", je découvre, mdr.

                Ensuite pour Java, quand on parle des libs, on parle de "plateforme" Java (lang+lib+jvm), itou pour C++ où BS parle de "framework".

                Déjà faites bien la distinction entre le langage et le framework, et vos trolls seront plus beaux, plus forts.
                • [^] # Re: c++ su><or

                  Posté par (page perso) . Évalué à 0.

                  Sauf que c'est dur de considerer qu'une API puisse faire partie d'un langage.

                  Essaie, tu vas voir ça vient tout seul.

                  Ce qui compte c'est ce que tu as à ta disposition en standard pour développer une fois que tu as installé le langage.

                  Après, chipoter sur "ça c'est dans le langage, ça c'est dans la lib", juste pour pouvoir dire "ah mais oui mais évidemment C c'est aussi facile que Java y a qu'a prendre les bonnes libs", c'est bien pour faire le neuneu sur linuxfr mais ça fait pas avancer ton code quand tu dois vraiment faire un truc qui marche.
                  • [^] # t'es trop ouf toi...

                    Posté par . Évalué à 4.

                    Ben j'essaye, mais plus j'essaye plus je pense que tu es à coté de la plaque. Ou alors il faudrait redéfinir ce qu'est un langage, mais j'ai pas le temps là. En plus une API c'est avant tout une interface, donc lier une API à un langage c'est du suicide. Ou alors il faudrait redéfinir le concept d'interface, oui mais j'ai pas le temps là. Nan, tu délires là, tu me trolles ou tu me charries ?

                    Si tu veux faire avancer ton code, le plus rapide c'est d'arreter les trolls et d'utiliser les design patterns sur une plateforma adéquate et le langage adapté aidé par un framework solide. Java c'est plus qu'un langage, et STL c'est en plus du C++ mais intimement lié à C++. Question de relations, de jargon.
                    • [^] # Re: t'es trop ouf toi...

                      Posté par (page perso) . Évalué à 10.

                      Ben j'essaye, mais plus j'essaye plus je pense que tu es à coté de la plaque

                      Non, je suis pragmatique. std::vector<> c'est du C++. Tu peux dire "c'est pas du C++, c'est une lib", en pratique ça fait partie de ce que tu peux utiliser en standard quand tu fais du C++. Pareil pour les libs Java.

                      Si tu veux faire avancer ton code, le plus rapide c'est d'arreter les trolls et d'utiliser les design patterns sur une plateforma adéquate et le langage adapté aidé par un framework solide.

                      T'es consultant dans la vie réelle ? :-)

                      Java c'est plus qu'un langage, et STL c'est en plus du C++ mais intimement lié à C++.

                      Oui, on est d'accord.
                    • [^] # Re: t'es trop ouf toi...

                      Posté par . Évalué à 7.

                      « et STL c'est en plus du C++ mais intimement lié à C++. »

                      Non ça en fait partie, même cas que Java. (en fait Java comprend aussi des choses en plus, mais ça ne concerne plus la bibliothèque).

                      Ou alors, veux-tu dire de la même manière que printf() ne fait pas partie du C ? Évidemment on peut réduire un langage à une grammaire, sa sémantique, mais aucune norme de langage ne se limite pas à ça.

                      Regarde par exemple sur les newsgroups fclc/fclc++ : tout ce qui concerne les bibliothèques standard de chacun de ces langages est valable. Or c'est plutôt le genre de groupe ou on ne trainera pas à te dire d'aller poster ailleurs si tu t'écartes du langage.
                      • [^] # Re: t'es trop ouf toi...

                        Posté par . Évalué à 7.

                        A l'origine la C n'a pas de bibliothèque, mais une bibliothèque a toujours été livrée avec
                        les compilateurs, elle est devenu standard est a été standardisées par la suite.

                        Alors que pour le C++, il y a toujours eu une lib standard (ne serait ce que c'elle du C).

                        Il est plus facile en C de se passer de la lib, alors que pour le C++ il faut bien connaître.
                        Le C++ est beaucoup plus dépendant de ca lib que le C.
              • [^] # Re: c++ su><or

                Posté par . Évalué à 10.

                Une autre grande lecon de C++ : c'est mieux quand on a le source.

                Version longue : Avec le C, tu peux linker des libraries et des objets produits par des compilos différents. En C++, la plupart du temps ce n'est pas possible, parce que, entre autre, la décoration des noms n'est pas standardisée.
                Et quand un éditeur ne fournit sa librarie en binaire que pour le compilo natif de la plateforme (au hasard, CC sur Solaris), pas moyen de l'utiliser avec g++ (qui est nettement moins cher ;) Bien sur, si l'éditeur fournit le source, on peut recompiler.
                Conclusion: c'est mieux quand on a le source.
                • [^] # Re: c++ su><or

                  Posté par (page perso) . Évalué à 7.

                  Non, c'est mieux quand on spécifie l'ABI (encore un truc que Java et C# ont fait).

                  Paradoxalement, C++ a beau être énorme, il n'a pas spécifié assez de choses (la lib standard et l'ABI).
                  • [^] # Re: c++ su><or

                    Posté par . Évalué à 8.

                    Le problème de l'ABI, c'est que c'est dépendant de l'architecture processeur (à moins bien sûr de tout foutre sur la pile avec un alignement énorme genre 128 bits - mais même là il faut encore définir quel registre fait office de pointeur de pile, ou de tas). Java et Cchose produisent un unique type de bytecode en sortie, donc c'est plus facile pour eux.
                    • [^] # Re: c++ su><or

                      Posté par (page perso) . Évalué à 2.

                      Ah, je savais bien qu'il y avait une bonne raison pour laquelle ça n'avait pas été fait. Ça plus les vendeurs de compilo qui se tirent la bourre pour faire leur sauce.
            • [^] # Re: c++ su><or

              Posté par . Évalué à 10.

              Bin non, regarde :
              On

              On est barré correctement,non ?

              [-1etjesorsencourant]
            • [^] # Re: c++ su><or

              Posté par (page perso) . Évalué à 8.

              Euh... tu sais sur combien de systèmes elle est portée la GLib ? Et sincérement, porter la GLib sur un nouveau système c'est _beaucoup_ plus simple

              D'un autre côté, il y a très peu d'applis qui utilisent la glib, en dehors d'applis graphiques.

              En pratique, sur les 1800 applis portées sous OpenBSD, seule une poignée (5 environ) dépendent sur la glib sans utiliser X, et la seule que je connais est irssi.

              Cela tend bien à prouver qu'en C, on préfère en général réinventer la roue, plutôt que de se reposer sur des libs existantes.
            • [^] # Re: c++ su><or

              Posté par . Évalué à 10.

              Et sincérement, porter la GLib sur un nouveau système c'est _beaucoup_ plus simple que de porter un compilo C++ ou la STL, alors bon...

              Ah. Je manque à voir la logique dans ce pseudo-argumentaire. Notament l'incohérente comparaison entre la portabilité de la glib (une bibliothèque) et, diable, un compilateur.

              La glib utilise le C, la STL le C++, où est donc le problème?

              Pour reprendre tes propos. Euh... Tu sais sur combien de systèmes est porté GCC? Généralement, il y a un compilateur C++ qui vient avec...
              • [^] # Re: c++ su><or

                Posté par . Évalué à 5.

                Euh... Tu sais sur combien de systèmes est porté GCC? Généralement, il y a un compilateur C++ qui vient avec...

                Tsss, faut pas le dire, voyons, tu vas les perturber.... Déjà qu'on essaie de leur faire accepter progressivement que leur *nix permet de faire des threads en plus du fork() tellement moderne.... ;))

                (-1, car n'importe quoi)
                • [^] # Re: c++ su><or

                  Posté par . Évalué à 5.

                  T'as oublié le -1, et oui, c'est n'importe quoi, tu vas me dire aussi qu'on a pas de threads en C ou en C++ parce qu'il n'y en a pas dans l'API standard du langage ? Ben oui, c'est du même niveau ce que vous me dites là...

                  Avoir des fonctionalités comme les tables de hachage, les listes chainées, ... dans une lib externe au lieu de les avoir dans le langage lui-même, c'est beaucoup mieux, ne serait-ce que parce que si tu veux développer dans un environement minimum (comme pour faire de l'embarqué), tu peux; que si tu veux utiliser une autre implémentation c'est bcp plus simple, ...
          • [^] # Re: c++ su><or

            Posté par . Évalué à -10.

            Sauvons le monde de l'horrible C++ la glib doit faire parti de la nouvelle norme du C.

            -1 car beaucoup mais beaucoup trop gros.
        • [^] # Re: c++ su><or

          Posté par (page perso) . Évalué à 2.

          En C avec la GLib on fait pareil en à peu près autant de lignes

          Vas-y, fais voir le code.
        • [^] # Re: c++ su><or

          Posté par . Évalué à 6.

          La grosse différence entre la STL et la GLib c'est que la STL est fournie avec le compilateur C++. De nos jours (et depuis plusieurs années d'ailleurs) cette bibliothèque est donc disponible sur tous les compilos proprios ou libres. C´est comme le stdio.h, etc. du C.
          Cela présente l'avantage de pouvoir travailler n'importe où en utilisant une bibliothèque que tu connais bien et maîtrises sans avoir à en compiler une, à la tester, etc.
          • [^] # Re: c++ su><or

            Posté par . Évalué à -6.

            Mais oui bien sûr, donc intégrons tout ce qui concerne le graphisme, le son, la reconnaissance vocale, les formats d'images, et la décompression de vidéo en standard dans les langages, comme ça on les a partout...
            • [^] # STL = Standard Template Library

              Posté par . Évalué à 10.

              Rien à voir.
              La STL est une librairie très générale (conteneurs, flux d'e/s...). Avec évidemment tu peux faire tout ce que dis (décompression, graphisme). Faudrait voir à ne pas amalgamer.
              Imagines-tu un C sans fonctions d'entrées/sorties par exemple ? Ca limiterait grandement son utilisation par exemple.
              On dirait plutôt que tu ne sais pas ce qu'est la STL et que tu as juste envie de la descendre ! Libre à toi remarque.
              • [^] # Re: STL = Standard Template Library

                Posté par . Évalué à 3.

                AMA, pour convaincre de l'interet de la STL dans un premier
                temps j'aurais tendence à dire qu'elle facilite l'écriture d'algo
                plus ou moins complexes avec un minimum d'expressions. Au début
                quand on parlait conteneur ou chinois je voyais pas la différence :)
          • [^] # Re: c++ su><or

            Posté par (page perso) . Évalué à -2.

            Ha ha, mais c'est pas compil'e pour une bonne partie de la lib car contenue dans des headers ... c'est pour ca qu'un programme C++ met 3heures a ce compiler ...

            Enfin bon ...
        • [^] # Re: c++ su><or

          Posté par . Évalué à 10.

          La différence est qu'en C++ tu le fais avec des conteneurs (templates), alors qu'avec la glib tu fais ça avec des pointeurs sur fonction. En pratique, le code généré en C fait des indirections à gogo, alors que dans le C++ tout peut être optimisé à fond.
          • [^] # Re: c++ su><or

            Posté par . Évalué à -2.

            Comment expliques-tu alors qu'un code généré par un compilo C soit toujours plus petit et rapide que l'équivalent en C++ ?
            • [^] # Re: c++ su><or

              Posté par . Évalué à 6.

              Si tu compiles du C avec le compilo C de X alors tu auras un code au moins aussi rapide que si tu le compiles avec le compilo C++ de X, cela me parait normal (ou alors X a laisse tombe son compilo C).

              Sinon, ca depend du code, les templates permettent de faire du code tres efficace quand c'est necessaire. Mais la vitesse du code est rarement un critere, la vitesse d'ecriture est souvent plus importante.
            • [^] # Re: c++ su><or

              Posté par (page perso) . Évalué à 6.

              On ne l'explique pas, parce que c'est faux (à moins d'avoir un compilo C++ vraiment pourri).

              Ou alors tu as une notion très particulière de ce qui est "équivalent".
              • [^] # Re: c++ su><or

                Posté par . Évalué à 8.

                Non non, il y a vraiment des compilos C++ vraiment pourris. En fait ce ne sont pas des compilos, juste des merdes qui traduisent le C++ en C. Donc dur d'avoir de l'optim C++ à la compil, et au debug tu prends tes jambes à ton coup...
                • [^] # Re: c++ su><or

                  Posté par . Évalué à 7.

                  Ca c'était y a dix ans, quand t'as découvert l'existence de C++ alors que t'essayais de reprogrammer emacs en Prolog. Depuis, les outils ont évolué, Johnny....
                  • [^] # Re: c++ su><or

                    Posté par . Évalué à 0.

                    pas dix ans, aujourd'hui, chez un grand fondeur européen qui commence par S et finit par M, et qui se la pete à la télé quand le permier ministre vient inaugurer en grandes pompes leur dernière usine (en retard d'une génération ;)...
            • [^] # Re: c++ su><or

              Posté par (page perso) . Évalué à -1.

              peut etre justement parce que il ne l'est pas!
              cf qsort vs. sort
            • [^] # Re: c++ su><or

              Posté par . Évalué à 0.

              Rapide c'est ton affirmation, pour la taille cf nm
          • [^] # Re: c++ su><or

            Posté par . Évalué à 8.

            La différence qu'en C, ta fonction g_list_length() qui te renvoie la taille d'une liste chainée (ou tout autre fonction de la GLib), elle est une fois et une seule fois dans /usr/lib/libglib.so.2.0.1 et une et une seule fois en mémoire.

            En C++, ta fonction elle se trouve une fois par fichier cpp et par type de données manipulé.

            Après, il ne faut pas chercher loin pour voir tous les inconvénients de la méthode C++: polution du cache, de la TLB [1], de la mémoire, du disque dur, temps de compilation affreusement longs, nécessité de recompiler toutes les application si un bugfix ou une mise à jour est appliqué dans la lib, ...

            Sans compter que la méthode C à base de pointeurs de fonction permet de faire des choses qui ne sont pas réalisables avec la méthode C++, car le type n'a pas besoin d'être connu lors de la compilation.

            [1] Translation Look-aside Buffer, table interne au processeur qui cache les converions addresse virtuelle => addresse physique.
            • [^] # Re: c++ su><or

              Posté par (page perso) . Évalué à 4.

              Sans compter que la méthode C à base de pointeurs de fonction permet de faire des choses qui ne sont pas réalisables avec la méthode C++, car le type n'a pas besoin d'être connu lors de la compilation.

              Du genre ?
              Reste la possibilité de faire dériver tes classes d'une même classe root.

              Ho et puis de toute façon, ObjectiveC + GNUstep ro><or . Au moins c'est du vrai objet et un vrai bon framework objet.

              C++ c'est bien, mais bon... Enfin ceci dit y'a pas photo entre C++ et C ! ne charrions pas quand même.
              • [^] # Re: c++ su><or

                Posté par . Évalué à 1.

                Enfin moi je dis: vivement que le patch de mac pour gcc soit accepte... comme ca on pourra jouer avec l'objective-c++ :-)
                • [^] # Re: c++ su><or

                  Posté par (page perso) . Évalué à 2.

                  Disons que d'un point de vue GNUstep c'est bien car on pourra avoir par exemple chimera sous linux ;)
                  D'un point de vue purement langage c'est pas indispensable, mais c'est pratique (coopérations c++/objectiveC)
                  • [^] # Re: c++ su><or

                    Posté par (page perso) . Évalué à 5.

                    Mais vous etes completements fous...
                    melanger du C++ avec de l'objective C, c'est bien une idee de programmeur C++ ca, car cela n'a aucun interet. Franchement quand on utilise l'Objective C, on peut se passer des problemes du C++....

                    C'est peut etre pour developper des machins KDE en Objective C ?
                    • [^] # Re: c++ su><or

                      Posté par (page perso) . Évalué à -2.

                      melanger du C++ avec de l'objective C, c'est bien une idee de programmeur C++ ca, car cela n'a aucun interet.

                      Grandis un peu.

                      Entre autres interêts, il n'y a pas de toolkit graphique pour Objective C (à part celle de Mac OSX bien sur, mais ailleurs...), et les wrappers GTK+ ont été abandonnés depuis longtemps parce que personne ne les utilisait. Ou trouve un bon parser XML en Objective C par exemple.

                      Ensuite, compare la taille minimale d'une classe Objective C avec celle d'une classe C++. Si tu dois manipuler un grand nombre de petits objets, il est pratique de t'affranchir du runtime ObjC.
            • [^] # Re: c++ su><or

              Posté par (page perso) . Évalué à 10.

              polution du cache
              Sans m'y connaitre a fond dans les caches, je trouverais logique que si tu appliques un algo a N elements:
              - il va y avoir une mise en cache une seule fois du bout de code (du style si c'est un sort) sur lequel on va boucler
              - pour les donnees, pas de pitie. Si c'est des tableaux ok (donnees contigues en memoire). Si c'est des listes chainees tant pis. Si t'as vraiment besoin de perfs de la mort, tu peux toujours t'adapter en C++.

              En C++, ta fonction elle se trouve une fois par fichier cpp et par type de données manipulées.
              Deja, qu'appelles-tu une fois ? Une fois par fichier objet ? OK. Mais ca c'est seulement a la compil. Une fois passe au link, les fonctions template non inlineees (imagine que std::sort<Voiture> soit trop gros pour que le compilo puisse le faire inline) sont en un seul exemplaire dans l'exe.

              la méthode C à base de pointeurs de fonction
              La methode C++ te laisse le choix:
              - tu veux des perfs qui tuent avec les templates qui "inline" tes algos, c'est bon
              - tu veux la "flexibilite" (hum) dont tu parles avec le C ? Pas de probleme, le C++ fait ca aussi. C'est tres simple de refaire par exemple une fonction qsort a base de fonction std::sort...
              • [^] # Re: c++ su><or

                Posté par (page perso) . Évalué à 2.

                Bon alors toi, t'a rien compris ...

                En C++, un template genere des fonctions specifique a chaque type de donnees, donc code different, donc entre l'appel a la meme fonction pour le type X et le type Y, il y aura un defaut de cache et le processeur devra refaire le chargement, decodage de la fonction.

                Donc au link, les fonctions peuvent etre inlinees, donc dupliquees, et cela prend plus de place en rame qu'une fonction completement generique et cela va aussi dans le sens de ce qui est ecrit au dessus.

                Tout le probleme du C++ c'est de ne pas pouvoir vraiment supporter le typage dynamique (celui qui est completement inconnu a la compilation, ce que permet l'objective C)
                • [^] # Re: c++ su><or

                  Posté par . Évalué à 8.

                  En general ce qui pose le plus de probleme au niveau des caches c'est les donnees ! C'est pas parceque t'as une fonction template qui va etre exprimee (en assembleur) quatre fois (parceque tu tries des entiers, des floats, des string, et des dates pex) que cela tuera les perfs ! Un defaut de cache n'est pas genant, c'est la repetition de defaut de cache qui tuent le perfs. A mon avis l'indirection est ici beaucoup plus couteuse !

                  Pour le typage, oui C++ est plutot axe typage statique, cela a toujours etait voulu parce que cela a des avantages (bug a la compil plutot qu'a l'exec pex !), mais C++ supporte le typage dynamique (voir dynamic_cast<T>).

                  ps: moi je pense que c'est toi qui n'a rien compris.
                • [^] # Re: c++ su><or

                  Posté par (page perso) . Évalué à 2.

                  Tout ce que je voulais dire, c'est que la mon avis les fonctions inline generes par les templates ont plus de benefice dans les perfs (pas d'indirection dues au typage dynamique) que d'inconvenients (problemes de cache).
            • [^] # Re: c++ su><or

              Posté par . Évalué à 2.

              Si tu reecris le meme algo dans chaque classe uniquement parce que le type change, pas etonnant que tu dises que C++ c'est de la merde.

              Mais dans ce cas c'est parce que t'as rien compris a l'approche objet.

              Les fonctions virtuelles c'est pas la pour faire joli.
              • [^] # Re: c++ su><or

                Posté par . Évalué à -1.

                T'as rien compris à mon message, j'ai pas dit que je réécrivais l'algo, mais qu'avec les templates le compilo générait le code à chaque fois que l'algo est appelé justement au lieu de l'avoir une fois pour toute dans une lib.
                • [^] # Re: c++ su><or

                  Posté par . Évalué à 7.

                  Justement, avec C++ t'as le choix entre:

                  - templates --> bouffe un peu plus de place car specifique a chaque type de donnee mais le code est optimal pour ton type de donnee

                  - fonctions virtuelles --> bouffe moins de place, le code est identique pour tous les types de donnees, mais est un peu plus lent.

                  En C, le truc identique aux templates, ca n'existe pas, faut tout te degotter a la main
                  Le coup des fonctions virtuelles, tu peux magouiller pour faire un truc qui ressemble, mais le resultat est assez difficile a maintenir.
                  • [^] # Re: c++ su><or

                    Posté par . Évalué à -2.

                    > - templates --> bouffe un peu plus de place car specifique a chaque type de donnee mais le code est optimal pour ton type de donnee

                    bouffe _beaucoup_ plus de place, avec des conséquences sur la vitesse d'exécution (cache, TLB, ...) et surtout les autres limitations dont j'ai parlé (absence de compilation séparée, ...)

                    > En C, le truc identique aux templates, ca n'existe pas, faut tout te degotter a la main

                    Si, ça fait avec des #define, c'est pas joli joli, mais ça revient exactement au même que les templates, c'est le même niveau de saleté (du code dupliqué lors de la compilation)
                    • [^] # Re: c++ su><or

                      Posté par . Évalué à 5.

                      Si les templates te conviennent pas pour des raisons de place, rien ne t'empeche d'utiliser des classes et des methodes virtuelles, t'as l'overhead d'avoir un acces a la vtable, mais ca prend moins de place.

                      Resultat: en C++, t'as le choix des 2 approches, en C, tu ne peux pas faire l'approche template, et l'approche 'methodes virtuelles' (equivalente a jouer avec des pointeurs de fonctions en C) est bien plus chiante a faire en C qu'en C++ ou le compilo se charge de bcp de choses a ta place.

                      (me parle pas des define pour des templates, ca donne du code illisible, absolument pas maintenable et t'as 10x moins de possibilites, genre les parametres par defaut,...)
                      • [^] # Re: c++ su><or

                        Posté par . Évalué à 1.

                        Non, les méthodes virtuelles sont _très loin_ de permettre tout ce que permettent les pointeurs de fonction, mais alors très loin.

                        Et c'est justement parce que le compilo fait des trucs d'une manière et que moi j'aimerais bien les faire d'une autre...

                        Quand au code illisible, les templates c'est assez fort dans ce genre là
                        • [^] # Re: c++ su><or

                          Posté par . Évalué à 2.

                          Tu peux toujours utiliser des pointeurs de fonctions en C++ si tu veux.
                          L'avantage du C++, c'est que c'est (quasiment) un sur-ensemble du C. Il fournit (presque) tout ce que permet le C, et bien plus encore, tout en générant un code aussi optimisé, si le compilo est correct.
                          Programmer les templates en C avec des macros, j'ai déjà donné. Je crois que je ne referai plus jamais ça.
                          • [^] # Re: c++ su><or

                            Posté par . Évalué à -2.

                            Complètement faux, essaie de passer une méthode "char *foo(char *)" là où le compilo attend une méthode "void (*)(void *)" et ça ne marchera jamais, essaie de passer un pointeur sur une attribut ou une méthode d'une surclasse à une méthode d'une sous-clase, ...

                            Ce sont des trucs qui sont rendus impossibles car ils rentrent en conflit avec les méchanismes objets _très_ limités du C++.

                            Quand au code aussi optimisé, je l'ai expliqué des dizaines de fois, c'est complètement faux aussi, ou en tous cas avec les compilateurs que j'ai pu tester.
                            • [^] # Re: c++ su><or

                              Posté par . Évalué à 1.

                              Si tu passes une methode char *foo(char *) la ou le compilo attend une methode voir (*)void(*), pour moi tu as un bug dans ton code.

                              J'appelle pas ca de la programmation mais un hack douteux.

                              Quand a passer un pointeur sur la methode d'une surclasse je vois pas ou est le probleme:
                              #include<iostream.h>

                              class CHello
                              {
                              public:
                              CHello() {}
                              const char* GetName() {return m_Name;}
                              private:
                              static char m_Name[20];
                              };
                              char CHello::m_Name[20]="CHello";

                              typedef const char* (CHello::*pmfGetName)(void);

                              class CHelloWorld : public CHello
                              {
                              public:
                              CHelloWorld() {}
                              const char* GetName(pmfGetName MyFunc) { return (this->*MyFunc)(); }
                              };

                              int main(int argc, char *argv[])
                              {
                              pmfGetName FuncName=&CHello::GetName;
                              CHelloWorld TestClass;
                              cout<<TestClass.GetName(FuncName)<<endl;
                              return 0;
                              }
                              • [^] # Re: c++ su><or

                                Posté par . Évalué à 2.

                                > J'appelle pas ca de la programmation mais un hack douteux.

                                Tu appelles ça comme tu veux...

                                > Quand a passer un pointeur sur la methode d'une surclasse je vois pas ou est le probleme:

                                C'est tout l'inverse que je disais moi... passer à une méthode de CHello un pointeur sur une méthode fournie par CHelloWorld, sans que CHello ne connaisse même l'existence de CHelloWorld.
                            • [^] # Re: c++ su><or

                              Posté par . Évalué à 2.

                              #include <iostream>

                              void toto(void *(*f)(void *))
                              {
                              f(0);
                              }

                              char *titi(char *x)
                              {
                              cout << "OK" << endl;
                              return 0;
                              }

                              int main()
                              {
                              toto((void *(*)(void *))titi);
                              }
                            • [^] # Re: c++ su><or

                              Posté par (page perso) . Évalué à 2.

                              Complètement faux, essaie de passer une méthode "char *foo(char *)" là où le compilo attend une méthode "void (*)(void *)" et ça ne marchera jamais

                              Ben non, encore heureux (à moins de caster violemment, mais tu cours au coredump). Et ça ne marchera pas en Java ou en ObjC non plus, ni même en Ruby ou Python (tu aura une exception au runtime si tu essaies d'utiliser la méthode en question).

                              Au fait, en C++ on utilise plutôt std::string que char*.

                              essaie de passer un pointeur sur une attribut ou une méthode d'une surclasse à une méthode d'une sous-clase

                              C'est tout à fait possible, mais pourquoi le faire ? La sous-classe a déjà accès aux méthodes et attributs de la sur-classe. Ça sent très mauvais ton truc. Passer un objet et un pointeur de méthode à une classe complètement différente (genre map()/apply()) ça par contre c'est déjà plus utile, et ça marche aussi.

                              Ce sont des trucs qui sont rendus impossibles car ils rentrent en conflit avec les méchanismes objets _très_ limités du C++.

                              Je ne comprends pas. Ce dont tu parles est possible, sauf l'erreur de type qui ne l'est pas pour de très bonnes raisons. Et tu dis que le C est mieux, alors que C n'a même pas ces mécanismes là.

                              Quand au code aussi optimisé, je l'ai expliqué des dizaines de fois, c'est complètement faux aussi, ou en tous cas avec les compilateurs que j'ai pu tester.

                              Lesquels ?
                        • [^] # Re: c++ su><or

                          Posté par (page perso) . Évalué à 1.

                          Non, les méthodes virtuelles sont _très loin_ de permettre tout ce que permettent les pointeurs de fonction, mais alors très loin.

                          Exemple ?
                        • [^] # Re: c++ su><or

                          Posté par . Évalué à 5.

                          Tu sais, la magie de C++, c'est que non seulement tu as les templates et les methodes virtuelles, mais tu as aussi les pointeurs de fonction et les pointeurs sur fonctions membres si t'as des besoins hyper-specifique ou bien si tu aimes faire des trucs degueulasses et impossible a maintenir.

                          Quand aux templates illisibles, c'est a se demander si:
                          - tu n'as vu que des templates codes par des schtroumpfs
                          - tu es ivre
                          - tu sais de quoi tu parles

                          Les templates sont un procede 10x plus propre que l'equivalent en C(les macros), 10x plus puissant, et qui ont l'avantage d'etre traites par le compilo et non pas par le preprocesseur.

                          Mon experience perso(je parles meme pas du boulot la) c'est un soft de +100'000 lignes ecrit en C++ pur a 2, qui est oriente perf(moteur de recherche), portable sur freeBSD, IRIX, Solaris, NT et Linux.
                          C'est pas du 'faux C++' mais du vrai C++ avec une hierarchie de classes, des classes templates,...

                          Ca fait plus de 9 ans perso que je code en C, et environ 5 ans en C++, je suis bien plus performant en C qu'en C++ et pourtant je me rends compte tres clairement qu'ecrire ce soft en C au lieu de C++ aurait eu pour resultat:
                          - un nombre de bugs bien plus gros
                          - un soft tres difficile a maintenir vu la taille et la complexite du soft
                          - un temps de developpement bien plus long
                          - une portabilite bien plus difficile a etablir

                          Quand aux perfs, elles sont tres bonnes, et je doutes tres fort qu'une version en C pur ait ete plus rapide tout simplement car l'ecrire en C aurait ete tellement complique qu'on aurait pas pu optimiser correctement la chose sans faire un merdier pas possible.

                          Ensuite, j'oses meme pas te parler de ce qu'on fait au boulot, c'est des projets qui depassent les 10 millions de lignes de code, et la tu vois tout de suite a quel point C++ ecrase C pour ce qui est maintenance de code.
                          • [^] # Re: c++ su><or

                            Posté par . Évalué à 1.

                            Je passe sur la première partie qui tient plus des attaques personnelles et le diffamation que de l'argumentation.

                            Je ne jamais dit que les templates étaient plus crades que des #define, mais qu'au niveau des concepts c'est la même chose, et que c'est beaucoup moins lisible qu'un vrai code générique comme on le fait en C.

                            Ensuite, non, tu ne peux pas utiliser les méchanismes du C (pointeurs et pointeurs de fonction) lorsque tu utilises les méchanismes du C++, cf ce que j'ai dit ailleurs, ça ne marche pas, tu buttes sans arrêt sur les limites que le compilo est obligé de te mettre...

                            Maintenant, peut-être quoi ça te convient mieux pour je ne sais quelles raisons, mais pour faire du C++ au taf 40h/semaine, je peux t'assurer que tous les jours ou presque je butte sur des trucs qui seraient beaucoup simple à faire de manière élégante en C...

                            Quand à ce que tu fais à ton boulot, quoi on voit le résultat, bon, sans commentaires ;)
                            • [^] # Re: c++ su><or

                              Posté par (page perso) . Évalué à 1.

                              Je ne jamais dit que les templates étaient plus crades que des #define, mais qu'au niveau des concepts c'est la même chose

                              Non, les templates sont beaucoup plus puissants et flexibles.

                              Maintenant, peut-être quoi ça te convient mieux pour je ne sais quelles raisons, mais pour faire du C++ au taf 40h/semaine, je peux t'assurer que tous les jours ou presque je butte sur des trucs qui seraient beaucoup simple à faire de manière élégante en C

                              Comme quoi par exemple ?

                              Pour l'instant tu donnes plutôt l'impression de quelqu'un qui fait du C++ sans savoir bien s'en servir.
                              • [^] # Re: c++ su><or

                                Posté par . Évalué à -2.

                                > Pour l'instant tu donnes plutôt l'impression de quelqu'un qui fait du C++ sans savoir bien s'en servir.

                                STP, évite de juger les gens que tu ne connais pas, merci, et c'est valable dans le cas général, pas seulement ici.

                                -1 car HS
                                • [^] # Re: c++ su><or

                                  Posté par (page perso) . Évalué à 2.

                                  Je te juge sur les bétises que tu ecris ici, le fait que tu ne répondes jamais quand on te demande d'étayer tes dires avec des exemples ou du code, et ton CV sur ton site qui est celui d'un débutant.

                                  La façon dont tu réponds aux mises en doute de tes compétences est également révélatrice.
                                  • [^] # Re: c++ su><or

                                    Posté par . Évalué à 0.

                                    Je suis étudiant donc mon avis ne compte pas et j'ai forcément tord ? Et ben bravo...

                                    décidément... ça devient n'importe quoi ici :(
                                    • [^] # Re: c++ su><or

                                      Posté par (page perso) . Évalué à 3.

                                      Je suis étudiant donc mon avis ne compte pas et j'ai forcément tord ?

                                      Non. Tu es un étudiant, tu n'as pratiquement aucune expérience, et il te reste encore beaucoup à apprendre.

                                      Tu as 2 personnes (moi et pasBill), beaucoup plus expérimentées que toi, qui te disent que tu as tort à propos de ce que tu dis sur C++, un langage que tu connais à peine. Ces deux personnes connaissent C++ bien mieux que toi, et le pratiquent depuis plus longtemps.

                                      Tu préfères continuer de penser que tu as raison, et de rejeter sans refléchir ce que te dit pBpG simplement parce qu'il travaille pour Microsoft. Ça aussi, c'est typique d'un étudiant inexpérimenté.

                                      Si un mec qui n'a jamais essayé Linux t'affirme que Windows est mieux, tu vas le prendre au sérieux ?
                            • [^] # Re: c++ su><or

                              Posté par . Évalué à 3.

                              Ca n'a rien a voir avec de l'attaque personnelle, c'est une constatation tiree de :
                              - ce que fait l'industrie du software en general
                              - ce que j'ai vecu depuis des annees
                              - ce que fait Microsoft, boite qui quoi qu'on en dise est tout de meme a la pointe dans un grand nombre de domaines concernant le software

                              Quand tu bosses sur des projets ou un tas de gens differents vont relire ton code, changer ton code,... tu peux pas te permettre de mettre des trucs vaseux dans ton code que toi seul comprend, quand tu developpes un soft de la taille de Windows, tu peux pas te permettre de laisser chacun faire sa petite cuisine de son cote,...

                              Les templates SONT efficaces.

                              Quand aux pointeurs de fonction, ils ne posent aucun probleme en C++, ca MARCHE.
                              Maintenant, je te ferais juste remarquer un petit truc en passant:
                              Si tu veux passer un pointeur sur une methode d'une classe fille a une classe parente, c'est que tu code de maniere tres SALE.

                              Qui te dit que la fonction de la classe fille n'accede pas a des donnees membres de la classe fille uniquement ? La classe parente n'en sait RIEN, et faire un truc de ce genre n'est encore une fois rien d'autre qu'un HACK.

                              Sinon quand a mon boulot, perso je vois une boite qui a des softs au top niveau dans les domaines OS, mail server, DB server, development tools, ... bref dans la plupart des domaines, et qui arrive a integrer tous ces softs ensemble pour en faire un tout homogene et qui est plus puissant que la somme des qualites de ces produits.
                              J'attends de voir une autre societe ou des dev libres faire un truc equivalent en complexite et efficacite.
                              • [^] # Re: c++ su><or

                                Posté par . Évalué à 3.

                                Bien évidemment je parle du cas où l'objet est de la classe fille, par exemple la classe mère a une méthode apply() qui prend un pointeur sur une méthode et fait des trucs avec, et une méthode de la classe fille veut appeler apply() avec l'une de ses méthodes à elle en paramètre.

                                Pour le reste, bon, entre les attaques personelles et l'éloge d'une société qui produit AMHA les pires softs ayant jamais existé, surtout d'un point de vue de la sécu (win 9x, IIS, Outlook, IE, ...), il n'y a _rien_
                                • [^] # Re: c++ su><or

                                  Posté par . Évalué à 0.

                                  C'est incroyable ce que tu peux etre borne quand meme....

                                  Va demander aux gens de chez IBM, va demander chez Motorola, chez Sun,... TOUTE l'industrie du software est d'accord la dessus.
                                  Tu as remarque qu'une tres grande partie du code de Mozilla est en C++ ? Tu crois que c'est un pur hasard ?
                                  Tu t'es jamais demande pourquoi BeOS a ete ecrit en C++ ?

                                  Avec ca, toi tu debarques avec aucune experience de developpement sur des projets de grosse taille et tu comptes expliquer a tout le monde qu'ils font n'importe quoi et que tu en sais plus qu'eux la dessus ?

                                  Quand a MS, ils font peut-etre les pires softs ayant jamais existe, il n'empeche que:
                                  - Windows detient les records en rapport perfs/prix du benchmark TPC
                                  - meme chose pour SAP
                                  - il a des capacites de management a distance qui font palir bon nombre de systemes
                                  - DirectX est sans equivalent valable
                                  - COM, WMI,... C'est marrant mais Windows est le seul OS a integrer ce type de technologies, et tout l'OS ainsi que les applications en tirent parti.

                                  SQL Server est dans le top 3 des bases de donnees
                                  Office n'a aucun equivalent, OpenOffice/StarOffice est plus lourd, plus lent, moins complet
                                  ...

                                  Developper tout ca, faire que toute cela marche ensemble correctement, que le developpement soit fait en un temps raisonnable et que ce soit maintenable, ca demande certaines competences contrairement a ce que tu peux croire, mais bon, tu es le bienvenu pour aller expliquer a Dave Cutler, Mark Lukovsky et autres comment faire du developpement, apres tout il ont seulement plus de 20 ans d'experience dans le domaine.

                                  Si t'es meme pas capable d'avoir un brin d'objectivite, ca devient inutile de discuter.
                                  • [^] # Re: c++ su><or

                                    Posté par . Évalué à 1.

                                    Windows detient les records en rapport perfs/prix du benchmark TPC

                                    C'est pas possible pour la bonne raison que le meilleur rapport perfs/prix est détenu par tous les systèmes qui sont gratuits : linux, *bsd, ... pour ceux là, le rapport est infini...

                                    -1 parce que bon...
                                    • [^] # Re: c++ su><or

                                      Posté par . Évalué à -1.

                                      Eh non, car t'as besoin de plus de hardware pour arriver aux memes perfs.

                                      Va donc jeter un oeil sur www.tpc.org, et compares les rapports prix/perfs des 2 systemes Linux et des systemes Windows, c'est un rapport x2
                                  • [^] # Re: c++ su><or

                                    Posté par . Évalué à -2.

                                    > TOUTE l'industrie du software est d'accord la dessus.

                                    parce que si l'industrie le fait c'est qu'elle a raison ? si on a plus de x86 c'est que x86 c'est mieux, si on a plus de windows c'est que windows c'est mieux ?

                                    Pour Mozilla, si c'est en C++ c'est qu'ils se sont basé au départ sur du code de Netscape qui était en C++.

                                    Pour le reste, je me demande vraiment qui manque d'objectivité...

                                    -1 (débat de sourd entre un "connard susceptible borné qui fait chier" (d'après la tribune) et un employé de chez MS qui se contente de faire des éloges infondées sur sa boite)
                                    • [^] # Re: c++ su><or

                                      Posté par . Évalué à -2.

                                      Ce que tu comprends pas c'est que :

                                      - L'industrie a INTERET a utiliser le langage le plus facile a maintenir, qui est le plus rapide pour developper.

                                      - L'industrie faisait du C avant, et elle est passee au C++, c'est pas comme si ils ne connaissaient pas le C, ils ne faisaient que ca, et ils ont change car ils ont trouve que C++ repondait mieux aux besoins.
                              • [^] # Re: c++ su><or

                                Posté par . Évalué à -2.

                                Windows est un OS au top niveau,
                                Access est une DB au top niveau,
                                Outlook est un mail server au top niveau,
                                SafeSource est un dev tool au top niveau,

                                et moi je suis la reine d'Angleterre ! Au top niveau !

                                Au caniveau ton FUD !
                                • [^] # Re: c++ su><or

                                  Posté par . Évalué à -4.

                                  Windows est un OS au top niveau,
                                  Access est une DB au top niveau,
                                  Outlook est un mail server au top niveau


                                  Windows est effectivement un OS au top niveau
                                  Access, remplaces le par SQL Server qui detient un certain nombre de records, ca ira mieux
                                  Outlook c'est pas un mail server mais un client
                                  SafeSource c'est pas top a ce qu'il parait.

                                  Mon FUD, tu peux te le foutre au c*l, mais ca je crois que tu le sais deja. Si t'as rien de plus interessant et argumente a dire que 'il FUD', reste dans ton coin ca rendra la discussion bien moins chiante.
                                  • [^] # Re: c++ su><or

                                    Posté par . Évalué à -1.

                                    > Windows est effectivement un OS au top niveau

                                    dis, je peux l'encadrer ? ou au moins le rajouter parmi les fortunes... s'il te plait...

                                    mwarf qu'est-ce qu'on se marre :)

                                    -1
                    • [^] # Re: c++ su><or

                      Posté par . Évalué à 5.


                      Si, ça fait avec des #define, c'est pas joli joli, mais ça revient exactement au même que les templates, c'est le même niveau de saleté (du code dupliqué lors de la compilation)


                      Arrete c'est deguelasse et difficilement maintenable les #define. Pourquoi pas mettre une couche de m4 au dessus ? Exemple:

                      #define MAX(x,y) if (x < y) \\ x; \\ else y;
                      et ensuite dans le code
                      x = max(i++, j)
                      et boom i est incremente deux fois ou une fois c'est selon !

                      Au niveau des "templates code bloat" et des avantages des templates pour les performances je te conseille la lecture de l'excellent article:
                      http://osl.iu.edu/~tveldhui/papers/techniques/(...)
                      • [^] # Re: c++ su><or

                        Posté par . Évalué à 3.

                        x = max(i++, j)


                        Moi le mec qui me pond un code comme ca, je le jette tout de suite... que max soit issu d'un #define ou pas...

                        Ca fait trop mal au cul d'écrire deux lignes ??
                        Ah ben ouais, c'est bien plus mieux de montrer qu'on est un w4rl0rD qu'on déchire tout à écrire du code condensé...

                        Alors je suis plutot d'accord avec toi : Arrete c'est deguelasse et difficilement maintenable...

                        Bon je sais, t'a pris un exemple volontairement farfelu, mais c'etait juste pour poser ma gueulante sur les gens qui codent comme des gros sales, en C comme en C++.
                    • [^] # Re: c++ su><or

                      Posté par (page perso) . Évalué à -1.

                      Si, ça fait avec des #define

                      Montre-moi comment tu fais de la spécialisation de templates avec des #define, par exemple.
            • [^] # Re: c++ su><or

              Posté par (page perso) . Évalué à 10.

              En C++, ta fonction elle se trouve une fois par fichier cpp et par type de données manipulé.

              Le linker ne garde évidemment qu'un exemplaire de la fonction pour chaque type, c'est à dire pas tant que ça (tu n'appliques pas un sort<> sur des centaines de types différents non plus), et vu les capacités des machines actuelles, c'est négligeable.

              polution du cache

              Ça c'est un vieux mythe dont l'origine semble être l'inlining à outrance dans des templates mal écrit. Les templates ne posent pas de problèmes de perf à l'execution, c'est même le contraire : il n'y a qu'avec des templates que tu aura les meilleures perfs, justement parce que tu peux génèrer le code optimal pour ton cas. Ça n'est pas un hasard si Blitz++, une lib de calcul scientifique pour C++ dont les perfs également ou dépassent le code équivalenet en Fortran, est entièrement à base de templates.

              de la mémoire, du disque dur

              Tu as regardé les prix de ces choses-là dernièrement ? Ça ne coute plus rien. Ça n'est pas avec du code que tu vas bouffer ta mémoire, c'est avec les données qu'il traite. Avoir une fonction instanciée même une centaine de fois n'aura aucune différence.

              temps de compilation affreusement longs, nécessité de recompiler toutes les application si un bugfix ou une mise à jour est appliqué dans la lib

              Ça c'est hélas vrai.

              Sans compter que la méthode C à base de pointeurs de fonction permet de faire des choses qui ne sont pas réalisables avec la méthode C++

              C'est bien sur totalement faux. C'est même l'inverse, les templates t'affranchissent de la contrainte d'avoir une interface commune. Quand std::sort<> est instanciée sur un tableau d'int, derrière tu te retrouves avec l'operateur [] pour acceder directement au tableau, au lieu d'appels à des fonctions pseudo-virtuelles. Et si tu veux avoir une hierarchie globale, rien ne t'empèche de la faire.

              Et bien sur, avec les templates tu restes type-safe et tu n'as pas besoin de caster dans tous les sens.

              Ceci dit, le style tout objet (Ruby, Java) marche aussi très bien, l'expérience prouve qu'on développe plus vite avec, et l'absence de vérification de type n'est pas un si gros problème. Restent les perfs, ou C++ reste imbattable.
            • [^] # Re: c++ su><or

              Posté par . Évalué à 2.

              Oui, via un conception à la java les fonctions n'apparaitraient
              qu'une fois. L'aventage des templates c'est un code optimisé en
              fonction du type/objet utilisé.
        • [^] # Re: c++ su><or

          Posté par . Évalué à 4.

          Vas y fait voir le code avec la Glib apres on compare les avantages et les inconvenients sur cet example. J'ai un assez mauvais souvenir de la glib. Pour moi ca ressemblait a un sac de macros C, mais je ne demande qu'a etre convaincu..


          ps: ca utilise intensivement les templates son exemple.
    • [^] # Re: c++ su><or

      Posté par . Évalué à 2.

      mouaf... kael expert ès-programmation... retourne jouer à l'admin NT.... :-)
  • # POA

    Posté par . Évalué à 10.

    concretement, c'est quoi la programmation orienté aspect ?
    • [^] # Re: POA

      Posté par . Évalué à 10.

      La programmation orientée aspect est (à peu près) ceci, pour AspectJ, qui est l'implémentation Java de la POA :

      Tu ajoutes de fonctions au compilateur Java standard pour accepter un nouveau type de structure, les aspects. Un aspect est construit très similairement à une classe.

      L'autre point important est, dans le corps de ces aspects, du définis des points dans ton code. Ce peut être l'entrée dans une méthode d'une classe, les sorties de toutes les méthodes publiques d'une classe, la sortie sur exception de toutes les fonctions get*(String) dans un paquet... Bref, c'est très puissant pour définir des points dans ton code.

      Ensuite, quand tu as défini ces points, tu définis des "méthodes" dans ton aspect qui vont se déclencher à ces points précis. Note bien que tu peux configurer tes points pour avoir accès au contexte d'appel de la méthode (la valeur d'une String par exemple, et suivant cette valeur, tu fais des choses différentes dans ta méthode d'aspect).

      C'est en fait assez puissant, car toutes les fonctions remplies en plusieurs endroits du code peuvent être regroupées en un seul endroit, comme le logging par exemple. Au lieu d'appeler Logger.log(qqch) dans le code de ma méthode de classe, je ne touche pas à mon code, mais je crée un aspect qui va logger la réussite ou l'exception qui a eu lieu dans ma méthode. Et il est aussi facile de virer tous les logs en un seul endroit.

      C'est un exemple de l'utilisation des aspects, si vous connaissez un peu Java, le site d'AspectJ est vraiment bon pour la doc (en anglais bien sûr ;-)

      A+ Hugo
  • # c'est quoi cette merde ?

    Posté par . Évalué à -10.

    Cet article est vieux, et il a déjà été donné sur la tribune et IRC suite à une dicussion avec ?? (jjb ?).

    Ca sert à rien cette news !
    • [^] # Re: c'est quoi cette merde ?

      Posté par . Évalué à -3.

      Oh tu me décois beaucoup, de ta part je m'attendais à un bus de trolls en colonie...
      Il est pas beau le C++ nouveau avec un GC customisé à la jacky ?

      Bon ben il est vraiment trop vieux ce troll, ça me fait de la peine, il va falloir l'achever ?
      • [^] # Re: c'est quoi cette merde ?

        Posté par . Évalué à -4.

        Nan mais vu le niveau de culture de la population ici présente, je prèfère passer 1h en IRC avec JJB à lui expliquer les bases du fonctionnel que de parler de haut niveau avec [pas d'attaques perso] (qui est soit-disant rigoureux mais utilise _toujours_ le C quelque soit l'application mais te fait chier avec des GNU/le Linux ou un truc du genre).
        Je reviens à l'instant de la lecture d'un ouvrage sur GTK, j'ai envie de vomir, c'est du pointeur dans tous les axes, du pointeur vers l'instance de la classe parente etc. et de la macro.
        Les mecs n'ont _rien_ compris à la théorie des langages de programmation ! Un langage est là pour automatiser des taches répétitives, les langages objets sont compris dedans, créer des structures de données qui ressenblent à de l'objet dans un langage qui ne l'est pas relève du crétinisme (ou de l'opportunisme étant donné la mode de l'objet) alors qu'une application écrite en langage objet pourra souvent ne pas avoir une tronche objet une fois en mémoire.

        Même si je ne suis pas encore un caïd du domaine, j'ai au moins compris la différence entre le niveau langage et le niveau run-time.

        Franchement, je me détourne de plus en plus du libre, dégoûté par cette atmosphère de branlage de nouilles .
        Il devient de plus en plus clair que l'open-source n'a rien à voir avec la qualité.
        Je préfèrerais utiliser une application closed-source écrite pas Robert C. Martin que xinetd ou wu-ftpd par ex.
        • [^] # Excellent ! C'est un vrai meta-troll ! Regardez ça les jeunes !

          Posté par . Évalué à 10.

          Justement j'en parlais d'ailleurs avec Knuth et Meyer hier soir au bistrot et puis RMS est arrivé et on est allé au ciné...
        • [^] # Re: c'est quoi cette merde ?

          Posté par (page perso) . Évalué à 7.

          Plutot que de te plaindre, montre nous ce qu'il faut faire. C'est ca l'interet de l'open source. Moi je tiens a la qualit'e de mon code car ce code reste pour la post'erit'e, c'est mon moyen d'expression comme la po'esie...

          C'est clair que tout le monde ne comprend de la meme facon la programmation objet, mais de la a critiquer l'open source, je vois pas le rapport.

          Enfin bon, tout le monde peut exprimer son avis.
          • [^] # Re: c'est quoi cette merde ?

            Posté par . Évalué à 2.

            J'ai pas de solution miracle mais c'est pas en étant coincé sur ses buffers overflows que ça va boujer, c'est sur.

            Je ne critique pas l'O-S mais je préviens que ce n'est pas un gage de qualité, et que l'O-S ne semble pas augmenter la qualité des applications.
            • [^] # Re: c'est quoi cette merde ?

              Posté par . Évalué à 10.

              Ben nan, personne a dit le contraire, mais c'est quoi le rapport là ? C'est bizarre de faire la critique d'une application sur le langage dans lequel elle est codée plutot que sur son execution.

              M'enfin, c'est vrai que c'est tres la mode ces temps-ci de parler du fait que telle nouvelle technologie de décideur pressé est developpée selon les toutes dernieres méthodes de devel/conception à la mode plutot que de montrer une bouse finale qui rame et qui coute cher

              En pratique, je me fous completement de savoir que Linux est codé en C et Win95 en C++, tout ce que je veux, c'est utiliser un truc stable et bien.

              [je critique absolument pas tel où tel langage/méthode de devel, juste la débilité du post "anti-opensource"]
        • [^] # Re: c'est quoi cette merde ?

          Posté par . Évalué à -3.

          GTK+ c'est pas très joli et libre mais ca ne remet pas en cause le libre. Tu as Qt, Pascal et plein d'autres outils de développement objets disponibles qui sont libres.

          A toi de choisir.
          • [^] # Re: c'est quoi cette merde ?

            Posté par . Évalué à -4.

            Nan mais y'a pas que GTK+ qui soit douteux :
            wu-ftpd
            xinetd
            bind
            php
            wmcoincoin
            le module eci
            le noyau (les 100Mo dans /usr/src/linux)
            ...

            Mais je ne remets pas en cause le libre, juste le fait de dire open-source => qualité, c'est faux.
            La qualité est indépendante de l'aspect open-source.

            D'autre part j'ai pas parlé de libre (ou alors par erreur) mais uniquement d'open-sorce (simplement un truc dont tu peux voir les sources comme Windows dans une certaine mesure, QNX, les logiciels libres etc.).
            • [^] # Re: c'est quoi cette merde ?

              Posté par . Évalué à 2.

              Sauf que quand on parle d'open source, on fait référence à http://opensource.org/docs/definition.php(...) en général, pas juste au "source ouvert", et surtout en français quand tu utilises le terme anglais, c'est bien parce que tu veux parler de l'Open Source défini par l'OSI et non le nom commun "source ouvert".

              Maintenant, si tu ne penses qu'à la qualité du soft et pas du tout aux aspects éthiques qui sont soulevés, c'est AMHA que tu n'as rien compris à la raison d'être du logiciel libre.
              • [^] # Re: c'est quoi cette merde ?

                Posté par . Évalué à -5.

                y'a 8000 mort par an en voiture, bientôt on donnera le nombre des morts annuels à cause de l'informatique, donc oui, la qualité m'intéresse.

                Même un éditeur de texte tout con s'il chie au moment de la sauvegarde de 1 caractère ça pourrait faire des morts.

                Je ne m'intéresse pas que à ça mais je m'y intéresse beaucoup d'où mon intérêt pour les "méthodes de production" du logiciel (langages, compilos, environnements etc.).

                Si personne n'a la volonté de nettoyer la crasse dans laquelle le secteur de l'informatique se situe, on va dans le mur. Le "logiciel dont on peut voir le code source" aurait pû être la voix mais non, on a autant de merde dans ce secteur (qui comprend pas mal de libre en plus) que dans les trucs fermés. J'en viens presque à adhérer avec le tissu de conneries de MS : tant que tout le monde produira de la merde, autant la cacher ça limite la découverte des failles de sécrité. Quand les informaticiens se pencherons massivement sur les outils, les langages, les environnements etc. peut-être qu'on sera prêt à faire de la qualité.
                Mais pour l'instant, y'a toujours les P4 qui bootent en 16 bits et un bloatware de 100Mo de C dans /usr/src/linux qui est prêt à te pêter à la tronche à chaque démarrage.

                Maintenant si j'ai utilisé le mot open-source c'est parceque j'ai pensé que c'était plus clair mais si je me suis planté parce que je ne sait que organisme a utilisé un terme simple pour en faire un truc vachement moins simple et qu'en plus j'était pas au courant désolé.

                Donc ce que j'ai dit avant c'était valable pour "les machins dont on peut lire le code source" ça va ? c'est pas déposé par un consortium de sauveurs du monde ça ? les-machins-dont-on-peut-lire-le-code-source.org n'a pas l'air déposé donc j'espère que je suis pas fait avoir et que ça veut pas dire un truc plus compliqué dont je me fous.
                • [^] # Re: c'est quoi cette merde ?

                  Posté par . Évalué à 2.

                  Je marche dans le troll (ca tache ?)

                  un bloatware de 100Mo de C dans /usr/src/linux

                  On attends tous avec impatience ta version C++ qui ne tiendra que 10Mo evidement.

                  En particulier, je suis curieux de voir comment tu va t'y prendre pour optimiser le biniou mieux que le bloatware actuel. Sur les passages critiques (critical path, huh ?), ils en sont a pondre le code C qui va bien pour que la version de gcc utilisée produise le bon code. [ce qui est mal (tm) je le concède volontier].
                  Dans ta version C++ avec moult templates et autres heritages, je suis impatient de voir comment tu pourrais optimiser mieux ...


                  Le C++ a bien des avantages, mais il est des domaines ou le C est suffisant. J'ai relu le code du vfs ce WE [<ma_vie>je voulais modifier le systeme dnotify</ma_vie>], le code est limpide meme s'il utilise des pointeurs de fonction a chaque fois que necessaire.
                • [^] # A quand un OS "INBUGABLE" ?

                  Posté par (page perso) . Évalué à 5.

                  Je suis d'accord sur le fond du problème avec nraynaud (et non sur la forme).
                  Avec les outils actuels, on ne peut pas prouver que le code est "bug-free" et avec les évolutions constanes (sources de nouveaux bugs), ça peut pêter à la figure.

                  C'est vrai que si cet OS parfait existait, l'industrie du logiciel aurait du soucis à se faire :-)

                  <disgression // avec le sujet>
                  L'argument avancé est la "performance", vraiment, on s'en fout complètement, c'est parce que les logiciels sont de plus en plus gourmands qu'on est passé d'un 386@16mhz/4Mo/HD 40mo en 1990 a un PIV@2.2ghz/256mo/HD 40go.
                  Et en 1990, on pouvait déjà faire de la bureautique wysiwig sous win3.1 ou sur amiga ou sur mac, sur unix, c'était du Latex(d'ailleurs le seul soft qui n'a pas de bug depuis plusieurs années et c'est bizarre, ça a été codé par un mathématicien et non pas par un haxor), X11 avec 4mo et un logiciel bureautique c'était un peu de la SF.
                  Fondamentalement, est-ce que WORD XP fait beaucoup plus de choses que WORD 2.0 (je prend cet exemple parce que c'est grosso-modo le même soft qui a évolué sur 10 ans).
                  est ce que word 2.0 ne suffit pas pour faire 99% des documents actuellements produits dans le monde. Est-ce que l'ergonomie de ce logiciel a si fondamentallement changée qu'on écrit un document 10 fois plus rapidement ? La réponse est NON, il est seulement plus lent, a surement plus de bugs même si les anciens sont corrigés, il faut une machine beaucoup plus puissante qui consomme plus de courant et qui est moins fiable parce qu'elle chauffe beaucoup plus.
                  Finallement, c'est quoi le "PLUS", ben c'est plus joli, c'est tout, on va me dire qu'il y a plus de fonctions, mais elles ne sont pas utilisés.
                  Et ne commencez pas à lancer un troll MSOffice/OpenOffice, OpenOffice à besoin de X11 sur un bureau moderne pour fonctionner il est peut être meilleur techniquement, mais il lui faut aussi au moins 64mo de RAM pour être utilisable.
                  </disgression // avec le sujet>

                  Bref il n'y aucun effort qui est fait pour "améliorer les performances" et ce n'est pas le choix JAVA/C# ou C++ ou C qui infléchieront la tendance (ponctuellement, on ira 2 fois plus vite avec un code C qu'en JAVA, bah l'industrie informatique stagnera sur 18 mois :-)

                  Enfin non on ne s'en fout pas de la performance, mais si je dois choisir entre une machine garantie sans bugs 10 fois plus lente et une techno actuelle, j'ai vite fais mon choix.

                  Les premiers systémes unix devaient tourner avec 128ko de ram environ (c'est l'ordre de grandeur). Et c'est sur ces machines que les premiers compilos C ont été développés.

                  Maintenant, on considére que Linux est utilisable avec 8mo en mode console (128mo avec X).
                  Maintenant qu'on est 1000 fois plus rapide et 1000 fois plus de mémoire, on pourrait peut être penser à developper de nouveaux langages ou de nouveaux concepts de programmation.

                  Le soft n'a pas évolué en 30 ans (a part la notion d'objet, mais l'algorithmie ça vient des années 70).

                  On va se retrouver avec des architectures qui héritent des erreurs du passées "parce que c'est comme ça", comme on a la semaine de 7 jours et des journée de 24 heures, on va peut être se payer le format doc pendant des millénaires, parce qu'on ne va pas toucher l'existant.

                  Qu'en entreprise, les gars soient traditionalistes, ça ne me choque pas, mais à la fac ça n'évolue pas non plus.

                  ça me fait penser aux articles sur la reconnaissance vocale qui ressortent tous les 2 ans en disant "ça y est, cette fois ça marche".

                  Mais pratiquement tous les algo ont été développés entre 1960 et 1980, on ne fait que les affiner, il n'y a pas de révolution.

                  Pour moi, le C++ quelque soit ses qualitées ou ses défauts va se retrouver dans des niches, balayé au fur et à mesure par le C# et le Java, parce ne pas gérer ses pointeurs, ça te fait gagner un max de temps, et pour les petits dév bas niveau, le C remplit trés bien son rôle de "macro-assembleur portable".

                  L'histoire aurait été largement changé si effectivement la STL était sortie avec le C++ en 1985, il y aurait eu une bascule beaucoup plus visible sur des dev C++, car ils auraient été beaucoup plus rapide et standard qu'en C.

                  Maintenant, il est beaucoup plus rapide de développer en JAVA/C#, et c'est le coût d'un développeur à la journée qui est plus important que le matériel, 3 jours de dev=1 machine, un projet de 50 personnes avec 6 jours de retard correspondent à 100 machines.
                  Donc même si il faut acheter un serveur à 100K euros au lieu de 50K euros pour combler le manque de performances du JAVA/C# sur le C++/C le client s'y retrouve rapidement sur les frais de développement.
                  • [^] # Re: A quand un OS "INBUGABLE" ?

                    Posté par (page perso) . Évalué à 2.

                    c'est le coût d'un développeur à la journée qui est plus important que le matériel
                    Dans une optique SSII / Editeur sans doute, pas quand tu programmes en interne pour ta boite. Je ne peux en aucun cas dire à mon chef : "j'ai besoin de trucmuche v2.0 qui ne tourne que sur P4 pour développer plus vite, il va falloir changer les 3000 machines du site pour qu'elles puisse faire tourner les libs de ce que je développe.".
                    • [^] # Re: A quand un OS "INBUGABLE" ?

                      Posté par (page perso) . Évalué à 2.

                      c'est vrai que dans certains cas, il faut privilégier ta performance, mais en général les développements internes sont fait en langage interprétés (VB & Macros pour la bureautique, Perl & scripts pour l'admin).
                      Un article démontrait que si tu devais lancer un calcul qui devait prendre plus de 26 mois, c'était plus rentable d'attendre la génération des machines 2 fois plus puissantes et faire un calcul de 8 mois pour arriver au même résultat.
                      En gros si tu dois mettre 2 fois plus de temps pour coder une application optimisée, il vaut mieux l'écrire de manière moins optimisée (à condition que les temps de réactions soient raisonnables) et propre. Et Si en plus elle est faite pour durer, même si les 3000 postes sont à 500mhz pour le moment, et bien dans 5 ans ils seront à 5ghz.

                      Donc l'optimisation vaut le coup pour :
                      -une application de calcul pur (ex modélisation, traitements temps réels, etc).
                      -une application quick&dirty jettable (ex jeux).


                      Bon maintenant, si tu es un dieu en C++/C que tu codes du premier coup sans avoir de fuites de mémoires, autant prendre le langage le plus rapide. ça vaut surtout le coup pour les applications graphiques ou il y a beaucoup d'interactivité et peu de répétitions.
                      Pour tout ce qui est opérations répétitives sans interactivité (filtrage constant d'un flux par ex) JAVA devient trés performant, parce que la JIT va affinner le code assembleur généré, et au bout de 10 passes tu obtiens un code presque aussi performant que du C.
                      C'est comme tout, il faut choisir l'outils le plus adapté à ta situation.
                      Reste que pour moi C++ va vers des niches ou la performance prime tout en ayant un peu plus de rigueur dans le codage que le C qui est un "assembleur évolué".
                      • [^] # Re: A quand un OS "INBUGABLE" ?

                        Posté par (page perso) . Évalué à 3.

                        en général les développements internes sont fait en langage interprétés
                        Eh bien, ici c'est plutôt du Delphi, mais ça ne change pas grand chose de toutes manières: les libs et mécanismes utilisés sont gourmands. Le facteur limitant chez moi n'est certainement pas le CPU (sauf peut-être sur les serveurs, et encore) mais la mémoire. Dans ce contexte, Java est totalement inimaginable.

                        même si les 3000 postes sont à 500mhz pour le moment
                        Snif, si seulement c'était vrai ! La moyenne dans ma boite (centre de recherche pour l'état), ça doit être le celeron 300/400 avec 64 Mo, parfois 128Mo. Pour ma part, je suis un gros privilégié avec mon celeron 700 à 128Mo. Allez, soyez sympa, dites moi que c'est pareil chez vous, je me sentirai moins seul :)

                        il faut choisir l'outils le plus adapté à ta situation.
                        Oui je pense que c'est le fin mot de l'histoire. De toutes façons, rares doivent être les "grouillots" qui choississent l'environnement de developpement eux-même sans subir les choix/lubies de leurs décideurs pressés et l'historique de la boite.
                        • [^] # Re: A quand un OS "INBUGABLE" ?

                          Posté par . Évalué à 3.

                          Java est asymptotiquement plus efficace en gestion de la mémoire qu'une désallocation explicite (grace au GC).
                          Par-contre il bouffe au démarrage (surtout si t'es en JIT).

                          Tout ce que vous faites en désallocation explicite, le GC peut le faire (en général plus vite que vous) mais lui il sait faire des trucs que vous pouvez pas faire sans utiliser un ref_counter et un détecteur de cycles.
                          L'avantage du GC c'est qu'il n'utilise que l'infrastructure d'un détecteur de cycles (parcours du graphe et marquage) et pas une série de compteurs.
                          D'autre part tu peux régler le ratio bouffage de temps/bouffage de mémoire et jouer sur la durée de vie de la mémoire.
                          Même en temps réel, on commence à pourvoir controler le temps de réponse (avec des systèmes spéciaux).
                          Il faut vraiment étudier ls GC avant de pouvoir dire qu'on en a pas besoin.
                          • [^] # Re: A quand un OS "INBUGABLE" ?

                            Posté par (page perso) . Évalué à 2.

                            Connaissant le parc de machine sur lequel doit développer Toufou (célerons+64Mo) il y a pas photo, Java est inutilisable surtout si tu dois faire une IHM.

                            Non il faut arrêter de rigoler, Java bouffe énormement de mémoire au démarrage, même si le GC est plus efficace que la gestion à la main (ce que je crois sans problème, cf fuites de mémoires) il n'en reste pas moins qu'en moyenne, une JIT, c'est 12~14mo de pris, plus les 2 ou 3 initialisations de bases, et si tu commences à mettre pleins de gadgets swing, tu arrive trés facile vers les 40mo. Avec 64mo de RAM ça un peu trop juste.

                            Si en plus tu lances 3 applis jave, tu as 3 fois 12~14mo qui sont pris pour rien, il faudra attendre le jdk 1.5 ou 1.6 pour lancer plusieurs applis avec une JVM.
                            Si tu commences à faire une calculette .class~100ko, une appli de calcul .class~800ko, et bien au démarrage c'est quand même ~29mo au lieu de ~1mo qui seront utilisés.
                            Tu ne peux pas t'amuser à developper une floppée d'utilitaires en JAVA.

                            C'est vrai que je pensais plutôt à des postes "mono-application" spécifique (un serveur quoi :-).
                            Je me vois mal avec un ordi ou tous mes utilitaires seraient en JAVA

                            C'est un peu la faute de sun, JAVA est bien conçu, mais il n'ont jamais vraiment fait d'effort pour optimiser leur JVM (cf JVM microsoft qui est 2 fois plus rapide en applet que la jdk 1.4 sur des démos java du groupe equinox http://equinox.planet-d.net/java/(...) )

                            Donc je suis d'accord que JAVA est construit sur des bases solides, j'aime bien le java, mais la JVM c'est pas ça du tout.
                            • [^] # Re: A quand un OS "INBUGABLE" ?

                              Posté par . Évalué à 1.

                              le CLR .net est là pour résoudre ce problème mais personne ne veut en entendre parler sur ce site.

                              Le but est simple : une seule instance en mémoire des infrastructures.
                              Smalltalk c'est planté sur cet objectif, peut-être MS arrivera à quelquechose.

                              Il semblerait hélas que certains n'aient pas compris ce problème et préfèrent fustiger Mono que d'essayer (ben oui, c'est pas gangé) de passer la seconde dans le secteur de l'informatique.
                              Ceci à plusieurs avantages : ça leur permet de vivre sur leurs acquis (le C et son environnement pile d'appels, représentation mémoire etc.) mais surtout de continuer à faire partie d'une élite qui serait sinon vite balayée par une génération formée plus tôt à une informatique plus moderne.

                              Il reste un pb MS n'est pas précisément connue pour ça capacité à faire progresser l'informatique. Le fait de mettre un PC sur chaque bureau sans former les utilisateur à la "science du traitement automatisé" ou à la "science de l'information" peut difficilement être qualifié de progrès. C'est pas en noyant un domaine de boulets qu'on fait progresser une science. Bien au contraire.

                              Donc le CLR .net est incontestablement une bonne idée mais il ne faut pas en faire n'importe quoi et c'est pas en faisant l'autruche que l'on l'aprivoisera.
          • [^] # Re: c'est quoi cette merde ?

            Posté par . Évalué à -1.

            > GTK+ c'est pas très joli et libre

            oulàlà, ton troll, il est vraiment pas joli non plus.

            [-1]
  • # OCM 2002

    Posté par . Évalué à 10.

    J'ai assisté à la conférence de Bjarne Stroustrup durant l'OCM 2002 (Objet Composant Modèle) à Nantes au mois de mars (le 21 pour être précis).

    Sa présentation était relativement technique et il semblait vouloir dire à la communauté objet présente que le C++ était vraiment génial et qu'il permettait d'écrire du vrai code objet comme en Java (par exemple) mais avec une plus grande souplesse (redéfinition de opérateurs, templates ...).

    Pour ma part, j'ai été un peu déçu de sa prestation ... je n'ai rien appris de plus que pendant des cours de C++ (notion objet: héritage multiples, templates ...).

    <ma vie>
    Pour ma part je préfére toujours utiliser un vrai langage objet (Eiffel, SmallTalk, Java?) plutôt que du C++. Le problème(l'avantage???) de C++ pour moi, c'est qu'il faut être très strict dans sa façon de développer si on ne veut pas se retrouver avec un programme écrit moitié objet/moitié procédural (ou avec des segfault à chaque coin de méthode :o).

    Quand tu écris un programme en SmallTalk ou Eiffel(avec les notions de contrats) (voire Java) tu es obligé d'écrire du code réellement Objet.

    Le problème de Eiffel et surtout SmallTalk, c'est que très peu de personnes les utilisent. Heureusement il nous reste encore Python et Ruby pour les petites(et moyennes) applis.

    Je pense toute de même que le C++ garde un grand intêret pour les applications scientifiques complexes et que le C est certainement le meilleur choix pour le developpement d'un noyau.
    </ma vie>
    J'espère ne pas trop nourrir le troll (si c'est le cas je suis réellement désolé) :o)
    • [^] # Re: OCM 2002

      Posté par (page perso) . Évalué à 3.

      Le problème de Eiffel et surtout SmallTalk, c'est que très peu de personnes les utilisent. Heureusement il nous reste encore Python et Ruby pour les petites(et moyennes) applis.

      Un peu de serieux... Tu trouves vraiment que Python et Ruby sont très utilisés ? Je n'ai rien à leur reprocher, sinon le peu de developpeurs, justement.
      • [^] # Re: OCM 2002

        Posté par . Évalué à 3.

        Ruby c'est sûre, c'est pas tellement utilisé, pourtant c'est assez puissant(mélange de Perl et de SmallTalk) comme langage de script.

        Pour python, il y a quand même qq appli qui existe (Sketch et pyCoinCoin par exemple).

        De plus python est très pratique pour faire du prototypage (c'est mon cas pour un projet de mise en place de contrats/classes-autotestable (à rapprocher à junit)) avant de faire une version stable en Java (ou autres).

        Enfin je ne voulais pas vraiment dire que Python et Ruby était super utilisés mais juste que tu pouvais toujours programmer une appli dans ces langages et qu'une personne voulant l'utiliser y arriverait relativement facilement (comme pour Perl). Ce n'est pas vraiment le cas avec Smalltalk, je ne suis pas sûre que grand monde est un compilateur(interpréteur) ST sur sa machine.

        -1 car je me suis mal exprimé dans mon premier commentaire.
      • [^] # Re: OCM 2002

        Posté par . Évalué à 5.


        Un peu de serieux... Tu trouves vraiment que Python et Ruby sont très utilisés ? Je n'ai rien à leur reprocher, sinon le peu de developpeurs, justement.


        c'est pas tout à fait vrai car la communauté se dévellope avec par exemple ILM (la boite effet spéciaux de Lucas) :
        "`The compositor plugins are in Python'', he notes. ``We're a big Python shop...and MEL.'' MEL is the Maya scripting language. "

        source : http://www.linuxjournal.com/article.php?sid=6011(...)

        A+
    • [^] # Re: OCM 2002

      Posté par (page perso) . Évalué à 10.

      Quand tu écris un programme en SmallTalk ou Eiffel(avec les notions de contrats) (voire Java) tu es obligé d'écrire du code réellement Objet.

      Et en quoi est-ce que ça garantit que ton code soit meilleur ?

      Le paradigme objet n'est pas universel. Il y a des choses qui se représentent très bien en procédural de base, et les représenter en Objet va juste compliquer le code inutilement.
      • [^] # Re: OCM 2002

        Posté par . Évalué à 9.

        Je suis tout à fait d'accord avec toi. Je n'ai jamais dit que le paradigme objet générait un meilleur code.

        Le paradigme objet permet, comme l'a mis en évidence B. Meyer, de représenter d'une façon simple des problèmes mettant en actions un nombre d'acteurs importants (exemple de la modélisation d'un champ de bataille avec des chars).

        De plus, des langages comme Eiffel (ou Java avec des surcouches comme iContract) mettent en place la notion de contrats(pré/post condition sur les méthodes et invariants de classe) qui permet de spécifier le protocole d'utilisation d'une classe plus formellement que sa signature seule et ainsi augmente la confiance que l'on peut avoir sur du code fournit par une tierce personne (principe de réutilisation).

        De plus, il existe nombre de méthodes (classes-autitestable, génération de mutants ...) de développement permettant encore d'augmenter la confiance que l'on peut avoir dans du code objet. Mais cela est une autre histoire qui n'a pas grand chose à voir avec cette news.
        • [^] # Re: OCM 2002

          Posté par (page perso) . Évalué à 6.

          la notion de contrats(pré/post condition sur les méthodes et invariants de classe) qui permet de spécifier le protocole d'utilisation d'une classe plus formellement que sa signature seule et ainsi augmente la confiance que l'on peut avoir sur du code fournit par une tierce personne (principe de réutilisation).

          En théorie oui. En pratique, c'est le genre de truc que les programmeurs detestent parce que c'est extrèmement chiant à maintenir. Trop lourd, trop contraignant. Chaque fois que tu changes le code d'une méthode, il faut changer le contrat aussi.

          A part pour du code "mission critical", tu ne vas jamais réussir à imposer ça à une équipe de développeurs.
          • [^] # Re: OCM 2002

            Posté par . Évalué à 10.

            En théorie oui. En pratique, c'est le genre de truc que les programmeurs detestent parce que c'est extrèmement chiant à maintenir. Trop lourd, trop contraignant. Chaque fois que tu changes le code d'une méthode, il faut changer le contrat aussi.

            Normalement si tes contrats (preconditions et postconditions) sont bien écrit, ils ne doivent pas être modifié quand le code change, sauf si tu t'es planté dans tes specifs (en effet, le mieux est d'écrire tes contrats à partir des spécif (diagrammes UML), et d'ensuite coder les méthodes). Je te l'accorde, c'est assez idéaliste comme point de vue.

            Exemple: tu écrit une classe Set (tableau ne pouvant pas contenir de doublons, ex: (8,2,3,6)=>OK, (2,3,2,6)=>KO) avec une méthode add (pour ajouter un éléments), tu auras des contrats du type :

            signature:
            public void add (int member // élément à ajouter )

            précondition:
            @pre !has(member) implies size() < MAX_SIZE // Verification que tu peux encore ajouter un élément dans ton Set si l'élement passé en paramètre n'est pas déjà dedans

            postcondition:
            @post has(member) == true // l'élément que tu as ajouté est bien dans ton Set à la fin de ta méthode

            @post has(member)@pre implies size() == size()@pre // Si l'élément était déjà dans ton Set alors la taille de celui-ci doit être le même à la fin de ta méthode

            @post ! has(member)@pre implies size() == size()@pre + 1 // Si l'élément n'était pas dans ton Set alors celui-ci doit avoir un élément de plus à la fin de ta méthode.

            has() et size() étant une méthode de la classe Set


            Ca parrait assez lourd à mettre en place, mais ça permet de vraiment spécifier comment fonctionne ta classe, du coup tu fais moins de doc, et il y a moins d'ambiguité sur la façon de mettre le code en place. Un des avantages est que les postconditions peuvent servir d'oracle durant tes tests. De plus, il existe de bon bouquin d'initiation à la programmation contractuelle (par exemple :Design by Contract, by Example de Richard Mitchell and Jim McKim)

            Etant moi même un flemmard de la programmation (j'aime pas mettre des commentaires et vérifier pendant trois plombes mon code), j'ai vite compris l'intéret de cette approche.

            Je t'accorde qu'il n'est pas facile d'imposer une telle approche dans une équipe, mais c'est un choix de méthode de développement (comme par exemple pour l'eXtreme Programming). Il y a des avantages et des inconvénient.

            J'essayerais de faire un condensé (ou d'en trouver un) sur cette approche si j'ai le temps.

            -1 car c'est vraiment pas le sujet de la news
            • [^] # Re: OCM 2002

              Posté par (page perso) . Évalué à 3.

              Normalement si tes contrats (preconditions et postconditions) sont bien écrit,

              Donc, en pratique, tu sais qu'ils ne le seront pas

              ils ne doivent pas être modifié quand le code change, sauf si tu t'es planté dans tes specifs

              Et en pratique, les spécifs changent.

              Je te l'accorde, c'est assez idéaliste comme point de vue.

              Oh, si peu :-).
              • [^] # Re: OCM 2002

                Posté par . Évalué à 4.

                Donc, en pratique, tu sais qu'ils ne le seront pas

                Et en pratique, les spécifs changent.


                Oui et non, en fait il faut rapprocher la programmation contractuelle à un cycle de maintenance (ou comme XProgramming) :
                Tu fait tes specifs (contrats + tests) -> tu codes -> tu lances tes tests -> tu peux avoir des erreurs de violation de contrat (code faux ou contrat faux), dans ce cas tu modifie tes contrats/codes ou alors t'obtiens pas le résultat attendu (normalement détecté par une postcondition), donc tu modifie tes spécifs (donc tes contrats et ton code) et tu cycles jusqu'à avoir un niveau de confiance assez fort.

                En gros ce sont des cycles très courts basés sur 3 points : Specification->Tests->Implémentation.

                En plus tu peux générer des mutants (insertion d'erreur dans une classe) pour vérifier que tes contrats détectent bien les erreurs générées dans ces mutants.
            • [^] # Contexte....

              Posté par . Évalué à -2.

              précondition:
              @pre !has(member) implies size() < MAX_SIZE // Verification que tu peux encore ajouter un élément dans ton Set si l'élement passé en paramètre n'est pas déjà dedans


              Résumons en reprenant le contexte.... Le post original parle de l'interview du créateur de C++, un langage où une classe nommée std::vector permet de faire des tableaux de taille arbitraire. Il y a aussi une classe std::set permettant de faire des ensembles de taille arbitraire. Tout ça avec la librairie standard.

              Et là, pour nous expliquer que son langage est tellement plus mieux, un zigue nous sort l'exemple roulé sous les aisselles d'un Set codé à la main et limité en taille par une constante figée.

              Ben moi, je sais pas pourquoi, je trouve ça marrant .... ! ;))
              • [^] # Re: Contexte....

                Posté par . Évalué à -1.


                Et là, pour nous expliquer que son langage est tellement plus mieux, un zigue nous sort l'exemple roulé sous les aisselles d'un Set codé à la main et limité en taille par une constante figée.


                Pour ta gouverne la taille de la constante figée est en rapport avec la taille maximal que Java peut atteindre avec un int. A l'origine le Set en question était un Set d'entier donc logiquement tu ne peux pas avoir plus d'entier dans ton Set que ce que Java peut représenter, d'où la vérification que tu n'essayes pas d'ajouter un élément dans un Set complètement rempli.

                D'autre part il est bon de se rappeler, même dans les langages haut niveau, que ton espace mémoire est limité, la constante même si elle a une valeur importante permet de spécifier une taille maximal pour ton Set.

                Enfin, mieux vaut trop que pas assez. La notion de contrat permet l'incomplétude (t'es pas obligé de tout spécifer pour que ton programme tourne) mais il est toujours préférable de prévoir tous les cas possibles même si on les considère comme peu probable (dans le cas du Set d'entier, tu auras certainement saturé ta mémoire avant de l'avoir rempli entièrement :o).

                Ca peut sembler un peu capilotracté comme approche, mais c'est pas sur 5 commentaires que je peux expliquer une telle notion.

                -1 Car j'ai déjà écrit la moitié des commentaires de ce thread :o).
    • [^] # Vive Java et à mort l'oppression qui nous réprime

      Posté par . Évalué à 4.

      si on ne veut pas se retrouver avec un programme écrit moitié objet/moitié procédural

      Ouaip parce qu'après il y a des gens sensibles qui ont des maladies graves en tombant sur ce genre de choses. Faut pas déconner.

      Moi, je trouve qu'on devrait dire aux programmeurs du noyau Linux que c'est que des brêles qu'ont rien compris au développement, regardez : ils mélangent de l'assembleur avec du C ! Un langage super bas niveau avec un langage moins bas niveau ! Alors que dans ma super école d'informatique où j'ai appris la vie en dix leçons (garanti satisfait ou remboursé), on m'a bien dit qu'il fallait pas mélanger et que si des gars ne suivaient pas les préceptes de la programmation bénie-oui-oui telle qu'enseignée par des mangeurs de quiche frustrés qui n'ont jamais pondu un bout de code inventif, alors je pouvais leur dire que c'était des abrutis et tout reprogrammer à leur place (pas pour de vrai non plus, faut pas exagérer, j'ai des tas de bouquins intéressants à lire sur la programmation objet). Alors quoi hein, vive Java et à mort les langages qui permettent de faire des choses. Amen.

      Signé :

      Un étudiant en informatique qui sait plein de choses vachement importantes.
      • [^] # Re: Vive Java et à mort l'oppression qui nous réprime

        Posté par . Évalué à 6.

        Ouaip parce qu'après il y a des gens sensibles qui ont des maladies graves en tombant sur ce genre de choses. Faut pas déconner.

        Faut savoir ce que l'on fait, je n'ai jamais dit que c'était mal de mélanger du C et de l'assembleur, mais je trouve tout de même abérrant qu'une personne disant 'je programme en C++ pour faire du langage objet' puisse se dire 'mince, pour cette fonction c'est plus simple de coder en C' (alors que la plupart du temps, c'est juste parcequ'il à la flemme d'aller chercher une solution propre en Objet).

        C'est, je pense, un peu ce que veux dire Bjarne Stroustrup, il est tout à fait possible d'écrire des programmes objets d'une qualité bien meilleur qu'en Java. Le problème du C++ c'est que, étant dérivé du C, il permet d'écrire du code pas du tout objet.

        Enfin, je ne suis pas un fan de Java, je le trouve bien trop frilleux sur certain point (pourquoi avoir gardé un système de structure de contrôle procédural (if then else, while ...) ? pourquoi avoir des types primitif, et une classe mi objet/mi primitif (String) ? en fait la réponse est simple : Sun à préféré privilégié la performance et le faut pas perturber les personnes venant du procédural :o().

        De même, je ne m'amuse pas à écrire mes scripts en Java :o), j'utilise (trop?) souvent Perl et quand j'ai le temps en Python (ou Ruby).

        Pour conclure :
        Il y plein de types de programmations (procédural, fonctionnel, objet ...)
        Il y plein de langages dans chaque type de programmation (SmallTalk, Eiffel, C++, Java entre autre pour l'objet)
        Il y plein de types d'applications différentes (kernel, office, applet ...)

        Le tout est de trouver le meilleur langage pour programmer ton application selon ses besoins (vitesse d'execution, espace mémoire nécessaire, portabilité, qualité(ou plutôt confiance), vitesse de développement ...).

        Il faut de tout pour faire un monde (libre) (comme nous l'a si bien appris le générique d'Arnold et Willy :o)

        nb: Je suis aussi étudiant en informatique, et suis surtout pragmatique, je préfére de loin coder plutôt que lire 3 tonnes de bouquin. Par contre je suis plutôt orienté programmation haut niveau (j'aime pas ce terme, il y a une notion de supériorité par rapport au bas niveau que je ne trouve pas fondée), il n'empeche que je suis l'un des premiers à trouver génial(et à utiliser) ce que font les développeurs du Kernel Linux(je ne pourrais jamais faire ce qu'ils font)
        • [^] # Re: Vive Java et à mort l'oppression qui nous réprime

          Posté par (page perso) . Évalué à 2.

          Enfin, je ne suis pas un fan de Java, je le trouve bien trop frilleux sur certain point (pourquoi avoir gardé un système de structure de contrôle procédural (if then else, while ...) ?

          Qu'attendait tu à la place ?

          pourquoi avoir des types primitif, et une classe mi objet/mi primitif (String) ?

          Ca c'est clair que c'est assez pourri, conceptuellement, de ne pas avoir les types de base en objet.
          D'un autre côté, c'est pragmatique :)
    • [^] # Re: OCM 2002

      Posté par . Évalué à 3.

      >Pour ma part je préfére toujours utiliser un vrai langage objet (Eiffel, SmallTalk, Java?) plutôt que du C++. Le problème(l'avantage???) de C++ pour
      >moi, c'est qu'il faut être très strict dans sa façon de développer si on ne veut pas se retrouver avec un programme écrit moitié objet/moitié procédural
      >(ou avec des segfault à chaque coin de méthode :o).

      L'inconvénient de la compatibilité avec le C, quand tu as surtout développé en procédural, tu as
      du mal à passer à l'objet. Une fois les notions objets bien acquises je ne pense pas que tu ais
      de problème pour faire du bon code.

      De plus, perso, je ne pense pas que le C est meilleur que le C++ ou inversement,
      mais que la programation procédurale me parait complètement obsolète par rapport
      à ce qu'apporte l'objet.

      Quand tu fais des bidouilles l'objet est chiant, et j'ai l'impression que
      souvent si l'objet est critiqué c'est que l'on parle d'avantage de conception
      notion qui echappe parfois à certains.
  • # Et si on parlait de design patterns ?

    Posté par . Évalué à 7.

    Dans pas mal de comments au dessus, on confuse bien entre "langage" et "plateforme". On peut gausser de la STL, mais c'est vrai que la libc n'avait pas encore en soi le concept porteur des design patterns (un exemple de pattern, l'itérateur, cf les ".each"). Donc comparons les choux avec les choux et les carottes avec les carottes. C'est C++ plus que C qui a introduit le concept de framework avant que Java n'enfonce le clou, le langage n'est pas tout, les librairies sont aussi importantes, à condition de souscrire aux design patterns, autrement dit d'être réellement universelles de plateforme en plateforme.
  • # C++ c'est trop de la ...

    Posté par . Évalué à -10.

    merde ;-)

    Non sérieusement pourquoi ce faire chiez avec ce langage alors qu'il en existe d'autres tout aussi puissant et beaucoup moins chiant a utiliser.

    Je pense en particulier a OCaml (http://caml.inria.fr(...))
    • [^] # Re: C++ c'est trop de la ...

      Posté par . Évalué à -10.

      pouet !

      P.S Ceci est un test de post ! Ne cliquez pas sur "-" SVP !
    • [^] # Re: C++ c'est trop de la ...

      Posté par . Évalué à 6.

      Non sérieusement pourquoi ce faire chiez avec ce langage alors qu'il en existe d'autres tout aussi puissant et beaucoup moins chiant a utiliser

      Sans doute parce que le C++ est très utilisé dans l'industrie. Industrie au sens large : tu sais la vraie vie, dans une entreprise, où tu dois maintenir du code existant, où on ne te laisse pas le choix du langage sur un nouveau projet parce que des directeurs techniques en ont fait le choix à ta place.

      C'est moche la vie ;-)
  • # C - -

    Posté par . Évalué à 4.

    Depuis que Java existe je ne vois plus trop l'interet du C++.

    - pour le bas niveau : kernel, drivers et qq applis specifiques => C
    - pour le reste (90% AMHA) => Java

    Depuis que je programme en Java (et plus en C++), je consacre beaucoup plus de temps à mes algos et à l'architecture de mes softs qu'a les debugger et ca, ca fait vraiment du bien.
    • [^] # Re: C - -

      Posté par . Évalué à -4.

      Ouais, mais java, c'est pas libre :þ
    • [^] # Re: C - -

      Posté par (page perso) . Évalué à 1.

      - pour le bas niveau : kernel, drivers et qq applis specifiques => C

      Ben non, C++ justement.

      - pour le reste (90% AMHA) => Java

      Sauf les applis desktop, genre traitement de texte, mailer, etc... Tu ne refera pas un équivalent de KDE en Java par exemple.

      Ceci dit, je suis d'accord, Java est un bien meilleur langage que C++, et c'est bien dommage qu'il ne puisse pas le remplacer partout.
      • [^] # Re: C - -

        Posté par . Évalué à 2.

        et pourquoi pas, le jour ou le compilo GCC/java fonctionnera aux petits oignons, plus de problemes de perfos, rien que la qualité Java.
    • [^] # Re: C - -

      Posté par . Évalué à 3.

      Ouaip moi par exemple je me dis que les bases de données c'est super lent et ça bouffe de la mémoire à mort. Alors qu'Oracle ou Postgresql par exemple, une fois réécrit en Java, qu'est-ce que ce serait rapide, tain, une vraie fusée ! Et puis la mémoire qu'on gagnerait tellement que ce serait léger !

      On peut la refaire pour les serveurs Web aussi, et puis les applis statistiques, les routeurs, l'imagerie 2D et 3D, le traitement vidéo.... Putain Java ça va torcher tout ça grave.

      Et puis au final, même les JVM on les écrira en Java, parce qu'il faut bien que le système reste fluide :))
      • [^] # Re: C - -

        Posté par . Évalué à -2.

        Il me semble qu'il y a quelque mois (années ?) une comparaison des temps de traitement d'un programme de rendu 3D réalisé sous Java ( ou C ++ à vérifier) et en C avait été faite et diffusé sur Linuxfr. Je ne remet pas la main sur le lien, mais il été question d'un programme de "test" / projet scolaire pour tester les vitesses. Quelqu'un a l'URL ?

        A ma grande surprise, dans ce cas particulier les programmes n'avaient pas un grand écart de duréée de traitement pour la même image. Il est vrai cependant que :

        -la majorité du programme était du pur calcul matriciel
        -le programme OO _était_ fortement optimisé
        -je ne sais pas si le programme C était particulièrement optimisé lui.

        -1 parce que pas sur des infos

        A+
      • [^] # Oracle et Java

        Posté par . Évalué à 2.

        Ca tombe bien puisqu'il me semble qu'Oracle, et depuis quelques temps déjà, est pour une bonne partie codé en Java : le moteur de base (genre les entrées/sorties), ça reste du C (ou un truc du genre (C++)) véloce, mais tout ce qui est interfaces (pas seulement au sens graphique) avec le reste du monde, genre analyse et traitement des requêtes, c'est du Java (c'est bien plus portable)
        Compare PostgreSQL (du pure C) et Oracle, et PostgreSQL sera bien plus rapide, seulement il supporte pas (encore) tout ce qui est clustering...
        • [^] # Re: Oracle et Java

          Posté par . Évalué à 4.

          Oracle en Java ... ça explique pourquoi le plancher sous les serveurs faisant tourner Oracle est tout fissuré.

          Sinon, moi, depuis que je code en Java mes applis sont automatiquement thread-safe, gèrent le partage mémoire comme jamais et tout ça sans rien coder ! Java c'est d'la balle (tm) ! J'ai le clustering gratuit avec !

          [-1, je rale, je rale]
        • [^] # Re: Oracle et Java

          Posté par . Évalué à 3.

          Compare PostgreSQL (du pure C) et Oracle, et PostgreSQL sera bien plus rapide, seulement il supporte pas (encore) tout ce qui est clustering...

          Moi je veux bien te parier 1 million de $ que sur des bases de grosse taille Oracle eclate PostgreSQL en vitesse.

          Oracle c'est pas fait pour gerer les recettes de cuisine de grand-mere ou la gestion de stock d'une petite PME de 4 employes, par contre quand il s'agit de gerer les bases de donnees d'une societe de 10'000 employees qui sont accedees/updatees/... journalierement, ton PostgreSQL fond comme un glacon au soleil pendant qu'Oracle continue sont petit bonhomme de chemin.

          C'est toute la difference entre faire du 0 a 100 en 1.2s mais pas pouvoir faire du 100 pendant plus de 500m, ou faire du 0 a 100 en 1.4s mais faire du 100 pendant des kilometres.
          • [^] # Re: Oracle et Java

            Posté par . Évalué à 1.

            C'est clair. Ils ne jouent pas [encore] dans la meme cours.

            De plus, contrairement a ce qui a été écrit plus haut, cela m'etonnerai que le moteur sql d'oracle ait été ré-implementé en java.
            Dans oracle, il y a maintenant des interfaces java, la possibilité de faire des procédures stockées en java, mais l'optimiseur interne et le moteur sql il sont certainement encore en C.
            • [^] # Re: Oracle et Java

              Posté par . Évalué à 3.

              Bon déjà, c'est exactement ce que j'ai dit : le moteur d'Oracle, c'est clair que c'est du C, pour tout ce qui est gestion des entrées/sorties, maintenant le reste c'est du Java : décodage des requêtes et tout ce qui est interface (pas qu'au sens graphique merci) : ca simplifie la portabilité.

              Pour ce qui est de la comparaison Oracle/PostgreSQL, c'est pas du facile ni du régulier mais bon, pas de problèmes (sauf mon compte en banque) : on prend deux machines identiques, une avec Oracle et une avec PostgreSQL, on fait les mêmes tests sur des trucs bien différents : requêtes simples/complexes, tables vides/remplies et on verra qui gagne !

              Ce qui fait la force d'Oracle, c'est la possibilité, super bien exploité, de chainer et de parallèliser les bases sur plusieurs ordinateurs, point barre.

              Alors une base assez conne avec assez d'utilisateurs supportables par une machine, PostgreSQL te grille Oracle, le reste c'est des idées reçues.

              MySQL suffit pour la plupart des sites Web, c'est surtout parce que c'est pas critique, surtout de la lecture de données et pourtant c'est pas une vraie base relationnelle comme PostgreSQL et Oracle (sauf avec l'ajout de patch et autres bidouilles bientôt supportés de base)

              Maintenant cite moi une utilisation d'Oracle critique : ou elle ne soit pas déployée sur plusieurs stations, ce qui manque cruellement à PostgreSQL (avec une intégration aisée avec tout le monde transactionnel distribué)
              • [^] # Re: Oracle et Java

                Posté par . Évalué à 2.

                Oracle a lance un concours, avec 1 million de $ a gagné si ton bdd est plus rapide que le leur.

                Postule et gagne.

                C'est assez complexe de comparer des bdd.
                Le base mirorée en directe (oracle joue les redo log d'une base sur une autre distante pour etre pret a reprendre a chaud) c'est pas du pipo. Je connais des bases qui sont mirrorées en France et en Angleterre par exemple, a chaud, au cas ou ...

                Maintenant en terme de perfs, il faut bencher sa propre application. Il faut savoir qu'au temps d'oracle 7, les requetes sql des applis etaient souvent ecritent de facon a faire produire le bon code par l'optimiseur oracle (comme Alan Cox ecrit du C de facon a ce que gcc produise l'assembleur qui va bien derriere). Puis oracle a changé d'optimiseur de requetes ....
                Donc je disais,
                -il n'y a pas de vérité absolue en termes de bench. PostgreSQL bat certainement oracle pour plein d'applis, oracle va certainement plus vite que PostgreSQL pour plein d'autres ....
                -il ne faut pas sous estimer les autres aspects (features) et les contraintes d'exploitation (vaccumm ?).

                Maintenant c'est clair, si PostgeSQL fait le taf, je ne vois pas pourquoi j'irai investir dans des licenses Oracle !!
          • [^] # Re: Oracle et Java

            Posté par . Évalué à 1.

            "Oracle c'est pas fait pour gerer les recettes de cuisine de grand-mere ou la gestion de stock d'une petite PME de 4 employes"

            Ca veut dire que postgresql n'est fait que pour ca ?

            http://www.pgsql.com/user_gallery/(...)

            J'ai eu aussi un contact avec une boite 2500+ salariés, implenté un peu partout en france qui utilise postgresql. Et, étrangement, sur leur site tu trouves des outils de migration oracle -> postgresql.

            Arrête de raconter des conneries. Oracle, c'est très souvent overkill.

            Bonjour chez toi.
    • [^] # Re: C - -

      Posté par . Évalué à -2.

      Bon aller je me lance aussi :

      Franchement, non mais vraiement franchement, le c++ ca pulpaté.

      Moi je vois que 2 cas dans la vie :
      - soit on veut être efficace et on programme en assembleur (regardez moi ces sodomiseurs de drosophiles qui codent un kernel en C ... je me marre)
      - soit on veut faire des applis vraiement pro et là on se rabat sur un bon script php et du XML comme format universel.

      Une fois qu'on est d'accord sur ces bons principes de base, on peut se concentrer sur ses algorithmes, son code et y'a même plus besoin de débuggage.
      • [^] # Re: C - -

        Posté par . Évalué à 0.

        Là où je trouve plutôt timoré voire archaïque, c'est qu'il vaudrait mieux carrément tout faire en XML, qui est le langage de l'avenir. Et puis, avec l'avènement des processeurs qui font le XSL en natif, ça va torcher (comme pour Java :-)).
  • # Un nouveau paradigme : la corbeille

    Posté par . Évalué à 10.

    Hello,

    Le ramasse-miettes a fait ses preuves en termes de gestion avancée de la mémoire, mais il commence en même temps à montrer ses limites. Notamment, le problème numéro un est qu'il ne donne pas le droit à l'erreur, ce qui est problématique quand on fait des erreurs.

    Je propose donc un nouveau paradigme de gestion mémoire. Avec la corbeille, l'objet désalloué n'est pas détruit tout de suite. Au contraire, il est placé dans une corbeille. Ainsi, le programme peut éventuellement le récupérer s'il se rend compte qu'il a fait une erreur. C'est un progrès inestimable dans la programmation de haut niveau, qui mettra probablement Java au niveau de Smalltalk et oCaml réunis.

    La version actuelle de la corbeille nécessite Swing, AWT, et une souris deux boutons.
    • [^] # Re: Un nouveau paradigme : la corbeille

      Posté par . Évalué à 4.

      Mais c'est génial cette idée ... hop je dépose un brevet.

      De plus on pourrait paramétrer la durée de rétention des objets dans la corbeille: de quelques heures à plusieurs jours, voire à jamais.

      Ce n'est pas un probleme, avec le cout dérisoir de la ram de nos jours, et l'avancée des techniques "hot plug", notre language d'avenir assurera une facilité de développement sans précédent.
      Bien sur il faudra une machine avec barettes de ram hot-plug pour etendre la ram régulièrement sans reboot, mais c'est le prix du progrès !!

Suivre le flux des commentaires

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