Journal Le futur du langage ISO C++ : les nouvelles librairies PCL

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
9
4
fév.
2012

Je vous conseille de lire cette article qu'un ami a publié sur son blog.

La norme C++11 a été publiée il y a quelque mois à peine, et l’on parle déjà de la version d’après ! Peut-être C++16 ?

C++11 est plus ou moins supporté à ce jour par les différents compilateurs C++ (visual C++, gcc, clang…). Microsoft a encore pas mal de travail, mais l’équipe Visual C++ y travaille pour la prochaine version de Visual Studio.

C++11 est devenu un langage moderne et sûr. Mais C++11 a un énorme point faible par rapport à d’autres langages, comme Java ou C#. Ce point faible, ce sont…

Les librairies du langage !

http://www.blogmfc.com/n2012/02/04/le-futur-du-langage-iso-c-les-nouvelles-librairies-pcl/

  • # Bibliothèques

    Posté par  . Évalué à 10.

    C'est vrai qu'il n'a que des bibliothèques.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Vidéos !

    Posté par  . Évalué à 5.

    Mouais, l'article n'est pas très détaillé. Je pense que les vidéos de la conférence C++ going native en question seront beaucoup plus intéressantes. Pour ceux qui pourront passer outre de lire une vidéo sur le site de Microsoft, ils pourront regarder les talks de Herb Sutter, Bjarne Stroustrop et cie. Je pense vraiment que ça vaut le coup.

    Ils ont l'air de dire qu'il faut installer - horresco referens - silverlight, mais ca l'air de tourner en natif sur mon iceweasel.
    La keynote de Bjarne, par exemple.

    Bon film !

  • # Mais pourquoi...

    Posté par  . Évalué à -1.

    ...s'embêter à faire évoluer un langage qui est de toute façon dépassé au lieu de travailler sur des vrais langages modernes?

    Oh pardon! À chaque fois qu'on voit un journal sur un langage qui en mentionne d'autre, je me sens Vendredi dans les commentaires...

    --------------------> [ ]

    • [^] # Re: Mais pourquoi...

      Posté par  . Évalué à 3.

      À chaque fois qu'on voit un journal sur un langage qui en mentionne d'autre

      C'est très rare d'ajouter quelque chose à un langage qui ne se trouve pas déjà sous une forme ou une autre dans un autre. Le C++ n'était pas le premier langage objet.

      Et de toute manière je pense qu'il est sain de comparer les langages entre eux. C'est une émulation et ça permet d'ouvrir son esprit à d'autres pratiques. En l’occurrence, il est vrai que C#, Java ou python ont une énorme bibliothèque standard.

      Enfin, je doute que quelqu'un comme Stroustrup considère le C++ comme un langage dépassé.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Mais pourquoi...

        Posté par  . Évalué à 5.

        Quand on regarde les langages avec une grosse bibliothèque standard, on fini souvent par tomber soit sur des langages ou il n'y a qu'une seule implémentation utilisée par la majorité, soit sur un langage qui nécessite une bibliothèque ou il n'y a qu'une seule implémentation écrite dans le langage lui-même. Ça veut généralement dire que le langage n'est pas indépendant.

        Aujourd'hui tu à plusieurs implémentations indépendantes et conformes de C++ et sa bibliothèque standard. J'ai pas suivi pour Java et C#, mais il me semble que au mieux il y avait deux ou trois implémentation qui tiennent la route, dont une majoritaire. Pour Python, c'est un peu mieux, parce que la bibliothèque standard est en grande partie écrite en Python, et c'est d'ailleurs quand ça l'est pas qu'on se paye les incompatibilités dans les autres implémentations.

        Après il faut choisir : grosse bibliothèque ou langage durable dans le temps ?

        • [^] # Re: Mais pourquoi...

          Posté par  . Évalué à 1.

          Alors d'après toi Java et C# ne seraient pas durable dans le temps ?

          C'est très osé comme point de vue, c'est même très contestable... ;-)

          • [^] # Re: Mais pourquoi...

            Posté par  . Évalué à 7.

            C'était beaucoup moins contestable lorsque Sun était en train de faire faillite et de se faire racheter par Oracle. J'ai aussi vus des articles de dev C# qui se disaient "abandonnés par microsoft" qui délaissait Silverlight et d'autres trucs, pour faire du HTML5...

            Avoir un langage et des implémentations indépendantes, ça à ses avantages.

          • [^] # Re: Mais pourquoi...

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

            Tu m'aurais parlé de Python, passe encore.
            Mais Java et C#? Pilotés par une seule boite, le jour où il n'y aura plus de business à faire...

            • [^] # Re: Mais pourquoi...

              Posté par  . Évalué à 5.

              Pour Java il a pris trop d'importance pour pouvoir disparaître, je pense. Même sans Oracle, IBM, Google et des communautés comme Apache pourraient le maintenir. Seul le JCK pourrait poser problème.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Mais pourquoi...

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

                A condition qu'Oracle n'ait pas envie, comme ça, de foutre des procès à quiconque s'amuserait à y toucher de trop près... Ah, on me dit dans l'oreillette que Google a déjà quelques soucis à ce niveau. Ca donne envie : libre, oui, mais on se jette sur un truc verrouillé quand on peut, quand même bizarre!

                • [^] # Re: Mais pourquoi...

                  Posté par  . Évalué à 1.

                  Je sais pas si tu as vu les brevets dont se sert Oracle pour le proces contre google, mais ils pourraient les utiliser contre a peu pres n'importe quelle autre machine virtuelle / language.

                  • [^] # Re: Mais pourquoi...

                    Posté par  . Évalué à 2.

                    C'est bien d'ailleurs pour cela qu'ils sont annules les uns apres les autres. Oracle veut un proces rapide car si cela traine les chances d'invalidation de tous les brevets sont tres grandes et faire un proces sur du vide ca le fait pas trop, tandis que sur des mirages ca peut durer (cf SCO et la derniere decade).

                    • [^] # Re: Mais pourquoi...

                      Posté par  . Évalué à 2.

                      Oui, c'est tellement du vent que google a dit en interne:

                      “If Sun doesn’t want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language – or – 2) Do Java anyway and defend our decision, perhaps making enemies along the way.”

                      Et:

                      “What we’ve actually been asked to do (by Larry and Sergey) is to investigate what technical alternatives exist to Java for Android and Chrome. We’ve been over a bunch of these, and think they all suck. We conclude that we need to negotiate a license for Java under the terms we need.”

                      Et ce que le juge en pense:

                      Google may have simply been brazen, preferring to roll the dice on possible litigation rather than to pay a fair price.

                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                • [^] # Re: Mais pourquoi...

                  Posté par  . Évalué à 5.

                  Attention a pas melanger j2se/j2ee et j2me. Les deux premiers sont gentils, le dernier est un champ de mine. J2me n'a jamais ete libre, meme de loin.

                  Google a joue au plus con, et ils le savaient tres bien (cf les derniers rebondissements dans leur proces contre oracle). Ils pensaient pouvoir baiser un sun mourrant et ont maintenant a faire face a oracle. Toujours est il qu'ils ont toujours su ce qu'ils faisaient et qu'ils allaient se prendre un proces dans la gueule.

                  Autant j2se/ee a eu un passe mouvemente niveau ouverture, mais ca a finit par se resoudre ya qq annees (openjdk, c'est du gpl), et oracle sait tres bien que le succes de java tient en grande partie a la richesse de son ecosysteme libre.
                  Jusqu'a ce que sun libere le jdk, la seule partie non libre qui tournait sur la majorite des serveurs d'applis, c'etait la jvm/jre (et les boulets du genre weblogic, effectivement).
                  Ca en est a point que les dev java sont habitues a avoir les sources de 100% de leur stack accessible en un click (merci maven pour le coup).
                  Il reste encore qq zones d'ombre, au grand dam d'apache harmony, mais l'idee c'est en gros "passe la certif une fois, ensuite tu fais ce que tu veux".

                  Autant j2me a toujours ete un champ de mine, ca a toujours ete tres clair qu'il fallait passee a la caisse pour mettre java sur un telephone, et ca l'est toujours.

                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                  • [^] # Re: Mais pourquoi...

                    Posté par  . Évalué à 4.

                    C'est quoi "les derniers rebondissements dans leur proces contre oracle" ?

                    • [^] # Re: Mais pourquoi...

                      Posté par  . Évalué à 3.

                      Cf mon autre messsage au dessus, sont pas super recents les rebondissement en question (mais ils sont bien en phase avec la tendance "don't be (too) evil" de google ces derniers temps)

                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                  • [^] # Re: Mais pourquoi...

                    Posté par  . Évalué à 2.

                    Autant j2se/ee a eu un passe mouvemente niveau ouverture, mais ca a finit par se resoudre ya qq annees (openjdk, c'est du gpl), et oracle sait tres bien que le succes de java tient en grande partie a la richesse de son ecosysteme libre.

                    Assez vite fait quand même. Le JCK n'est pas libre.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Mais pourquoi...

                      Posté par  . Évalué à 2.

                      D'un autre cote, on peut aussi legitimement se demander quel est l'interet d'un test de compatibilite que quiconque peut modifier pour l'arranger a sa sauce.

                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                      • [^] # Re: Mais pourquoi...

                        Posté par  . Évalué à 3.

                        Librement accessible serait un minimum. Parce qu'on peut se demander à quoi sert un test de compatibilité que seul l'implémentation de référence a le droit d'utiliser.

                        Pour ce qui est de la liberté de le modifier, ils peuvent très bien n'apposer le nom Java Compatibility Kit uniquement sur les versions qui sont prises en charge. Ça permettrais à la communauté de pouvoir y contribuer à minima pour l'améliorer (gagner en performance/légèreté) sans modifier son comportement.

                        Puis ça leur aurait évité de se couper d'Apache qui demande simplement à pouvoir l'utiliser (et pas forcément à pouvoir le modifier).

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Mais pourquoi...

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

          Quand on regarde les langages avec une grosse bibliothèque standard, on fini souvent par tomber soit sur des langages ou il n'y a qu'une seule implémentation utilisée par la majorité, soit sur un langage qui nécessite une bibliothèque ou il n'y a qu'une seule implémentation écrite dans le langage lui-même. Ça veut généralement dire que le langage n'est pas indépendant.

          Et c'est mal?

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Mais pourquoi...

          Posté par  . Évalué à 5.

          Ça veut généralement dire que le langage n'est pas indépendant.

          Je ne comprend pas ?

          on fini souvent par tomber soit sur des langages ou il n'y a qu'une seule implémentation utilisée par la majorité, soit sur un langage qui nécessite une bibliothèque ou il n'y a qu'une seule implémentation écrite dans le langage lui-même.

          De toute manière tu veut l'écrire en quoi la bibliothèque standard du C++ ? Pour Python/C#/Java qui sont des langages qui ne génèrent pas du code natif on peut chercher à écrire des bibliothèque en code natif mais pour le C++, quel serait l'intérêt de passer à un autre langage ?

          D'ailleurs ça se vois sur les bibliothèques déjà existantes. Combien de bibliothèques pour C++ sont écrite dans un autre langage que le C++ ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Mais pourquoi...

            Posté par  . Évalué à 4. Dernière modification le 04 février 2012 à 20:05.

            De toute manière tu veut l'écrire en quoi la bibliothèque standard du C++ ?

            En ce que tu veux, du moment qu'il y a plusieurs implémentations par des acteurs indépendants, de telle sorte que le langage ne meure pas si un acteur principal tombe.

            Si il n'y a qu'un seul acteur qui décide de la bibliothèque standard et qui lui ajoute des fonctionnalités tout les 4 matins sans que les autres puissent suivre, j'ai un peu moins confiance.

            • [^] # Re: Mais pourquoi...

              Posté par  . Évalué à 5.

              C'est un langage ISO implémenté actuellement par GCC, clang (lié à Apple), Visual Studio (Microsoft) et icc (Intel). On est loin de C#, python ou Java qui ont une implémentation de référence et une (ou des) implémentation qui tente de suivre (à noter pour Java que la manière de faire avec des JSR permet d'avoir tout de même des implémentations alternatives tout à fait correctes de parties de Java EE, par exemple pour JPA l'implémentation de référence est EclipseLink mais Hibernate est tout a fait fonctionnel).

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Mais pourquoi...

                Posté par  . Évalué à 5.

                Pour completer la liste des gros fournisseurs, il y a aussi xlc (IBM) et acc (HP).

  • # À quoi sert la standardisation?

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

    • À faciliter l'interopérabilité entre composants. De ce point de vue là, les primitives de base ont tout intérêt à être standardisées. Il n'y a qu'à voir les soucis causés par les vieilles bibliothèques n'utilisant pas std::string, ou encore maintenant le bazar sans nom autour des chaines Unicode, chaque framework débarquant avec le sien. Cela alourdit inutilement les applications avec du "boilerplate code" (des idées pour la traduction?)
    • À ne pas avoir à redémarrer de zéro en débarquant dans un nouveau projet. Si tous les projets C++ de la planète utilisent la même bibliothèque réseau, sérialisation, accès à la BDD, GUI, l'on est plus rapidement opérationnel.
    • Enfin, c'est aussi un moyen de guider les développeurs vers certains paradigmes. La bibliothèque standard, de ce côté là, a montré une approche très fonctionnelle qui a eu une influence énorme sur la manière d'approcher le langage.

    Mais peut-être qu'une différence fondamentale du C++ avec les monstres Java, C# et Python est que l'on a de nombreuses implémentations, et une décision par comité. Cela veut dire une longue recherche de consensus, pour au final un résultat souvent à minima (par exemple, std::thread n'a ni les verrous partagés, ni les thread groups...).

    Le résultat? La communauté se prend par la main. Boost propose de nombreuses bibliothèques, certaines très matures, d'autres plus expérimentales. À un problème, de nombreux développeurs vont apporter des solutions, parfois très différentes (comparez Boost Asio et SDL_net, QT et WxWidgets...), et les meilleures survivre. Peut-on espérer la totalité des Intel Threading Blocks dans la bibliothèque standard? Ou une API d'accès aux bases de données suffisamment puissante et suffisamment générique?

    Standardisons donc le bas niveau, et les problèmes pour lesquels il n'existe vraiment qu'une seule solution. Pour le reste, pas touche!

    • [^] # Re: À quoi sert la standardisation?

      Posté par  . Évalué à 5.

      Si tous les projets C++ de la planète utilisent la même bibliothèque réseau,

      Hm avec tout le monde qui fait des sockets depuis 30 ans de la même manière, c'est effectivement jouable pour les besoins classiques.

      sérialisation,

      Mwai dans le contexte du C++, je sais pas. Les données sérialisées seront probablement incompatible binaire pour commencer (même si ça ne serait pas un grave inconvénient dans tous les domaines)

      accès à la BDD, GUI

      Rêve

      l'on est plus rapidement opérationnel.

      • [^] # Re: À quoi sert la standardisation?

        Posté par  . Évalué à 3.

        Mwai dans le contexte du C++, je sais pas. Les données sérialisées seront probablement incompatible binaire pour commencer (même si ça ne serait pas un grave inconvénient dans tous les domaines)

        Ah bon ? pourquoi ?
        Qu'est ce qui empêche de sérialiser vers du XML ou vers une ribambelle de formats de sérializations tout aussi bizarres les uns que les autres ?

        Et de toute façon, tu peux de toute façon pas dumper un objet dans un fichier à cause de tes pointeurs... Alors autant sérialiser avec Boost::Serialization en utilisant/écrivant le backend de tes rêves.

        • [^] # Re: À quoi sert la standardisation?

          Posté par  . Évalué à 3.

          Ouai au niveau applicatif tu peux avoir intérêt à être aidé par un truc qui te facilite la vie et te permet de programmer toi-même la sérialisation d'une manière plus simple. Et dans une certaine mesure il est de toute manière virtuellement indispensable dans n'importe quel programme de programmer soi-même une partie de la sérialisation, ne serait ce que parce que pas tous les objets sont à sérialiser. Mais je ne pense pas qu'on puisse atteindre en C++ l'automatisme, la transparence et la compatibilité qu'on peut atteindre en, par exemple, Python (même si le cas où le programmeur n'a presque rien à faire n'est pas non plus adapté à tous les usages, notamment à cause des problèmes de sécu).

        • [^] # Re: À quoi sert la standardisation?

          Posté par  (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 08 février 2012 à 10:29.

          Qu'est ce qui empêche de sérialiser vers du XML ou vers une ribambelle de formats de sérializations tout aussi bizarres les uns que les autres ?

          C'est clair que c'est pas ce qui manque les formats, binaires ou pas d'ailleurs :)
          En plus, y en a même des normalisés comme XDR.

Suivre le flux des commentaires

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