Journal C++14

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
38
31
août
2014

C'est officiel, depuis le 18 août dernier, une nouvelle version de C++ est sorti : C++14 ! Ce qui est le plus surprenant, c'est que les compilateurs du monde libre fournissent déjà cette version (alors qu'il avait fallu attendre de nombreux mois voire de nombreuses années pour les versions précédentes).

Pour rappel, C++14 n'est pas une révolution comme a pu l'être C++11, mais plutôt une évolution et une amélioration de C++11 avec quelques fonctionnalités supplémentaires. Pour le langage lui-même, on peut citer (parmi d'autres) :

  • les variables templates
  • des améliorations sur les fonctions lambdas
  • la possibilités d'utiliser des boucles et des variables dans les fonctions constexpr
  • les litéraux binaires : 0b10010011
  • le séparateur de chiffre : ça sera ' et pas _

Pour la bibliothèque standard :

  • std::make_unique qui vient compléter std::make_shared
  • std::shared_timed_mutex et std::shared_lock
  • std::integer_sequence pour faciliter l'écriture de template
  • std::exchange pour échanger une valeur par une autre
  • des opérateurs de litéraux pour les chaînes et les durées

  • # En entreprises…

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

    Chez nous, c'est toujours GCC 4.3.2, et C++98/03.

    Dans 7 ans, peut-être…

    • [^] # Re: En entreprises…

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

      pareil ;) Visual 2005, qui doit péniblement faire du C++98 et gcc 4.3…

      • [^] # Re: En entreprises…

        Posté par  . Évalué à 1.

        Par curiosité, quelles sont les raisons qui font que vous n'utilisez pas des versions plus récentes ?

        • [^] # Re: En entreprises…

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

          Changer cela veut dire s'exposer au changement. Cela veut dire revalider les logiciel, cela veut dire s'assurer que ce qui fonctionnait avant fonctionne encore. Par exemple, quand tu compiles avec un vieux gcc, tu as des chances que la libc++ utilisée soit disponible sur la plupart des distributions, donc cela simplifie ton packaging. Quand tu as tout un environnement de build automatique, mettre a jour une partie de ta toolchain te force a de nombreuses mises à jour, potentiellement de nombreuses dépendances pour lesquelles tu doit maintenir ton code. En gros, c'est beaucoup de temps (et donc de cout) pour un gain qui n'est pas forcement important (hormis en qualité, mais la qualité a un cout, et n'est pas forcement la priorité numéro 1).

          Autre chose, malheureuse, mais quand tu dois maintenir un logiciel sur de nombreuses plateforme, tu as tendance à niveler vers le bas.

          • [^] # Re: En entreprises…

            Posté par  . Évalué à 5.

            Mouais, j'ai eu droit à cette rhétorique il y a quelques années. La boîte utilisait alors un gcc 3.4.6, et ils ne voyaient pas l'intérêt de mettre à jour.
            Un jour, j'ai écrit un truc du genre:

            int * a = new int[LENGTH]();

            j'ai mis un moment avant de comprendre que mon code déconnait sévère parce que le compilo refusait d'initialiser les valeurs à zéro, et encore un moment pour comprendre que je pouvais me brosser pour avoir un correctif.

            Alors refuser les versions récentes sous prétexte que la qualité a un coup, OK, mais le risque est de se retrouver sur des versions obsolètes, non maintenues qui t'obligent à écrire des contournements qui n'ont pas lieu d'être.

            Je préfère un modèle de mise à jour régulière et progressive de la toolchain (on est pas obligé de toujours mettre du bleeding edge, hein), avec une procédure de validation bien définie, voire automatique. D'une part on le fait souvent, du coup on intègre des bonnes pratiques et ça évite d'avoir la « peur du changement ». D'autre part, le manque de qualité a également un coût, et sur le long terme, une boîte qui traine une grosse dette technique se fera ramasser par ses concurrentes, simplement parce qu'elle sera incapable de faire des changements importants dans un laps de temps raisonnable.

            • [^] # Re: En entreprises…

              Posté par  . Évalué à 4.

              et mmmhhhh, la qualité a un coût, pas un coup, bon sang de bonsoir !

            • [^] # Re: En entreprises…

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

              Il faut peser le pour et le contre entre le coût de mettre à jour, et le gain en productivité du aux technologies plus moderne.

              En fonction des cas, ce n'est pas toujours la même réponse.

              Par contre, avec de bons tests, je pense que mettre à jour le compilateur n'est pas insurmontable. La pluspart des problèmes sont des erreur de compilation assez facile à résoudre. Je ne me souviens pas avoir eu affaire à un problème dû à une mise à jour du compilateur qui ne soit pas une erreur de compilation.

  • # Séparateur de chiffre

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

    • le séparateur de chiffre : ça sera ' et pas _

    Quelqu'un sait pourquoi ? C'est pour pas faire comme les autres langages, tel qu'Ada ?

    • [^] # Re: Séparateur de chiffre

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

      Qu'est-ce que c'est qu'un séparateur de chiffres ? L'espace ou le point qu'on met en français pour séparer les tranches de milliers à des fins de lisibilité ?

      • [^] # Re: Séparateur de chiffre

        Posté par  . Évalué à 2.

        C'est ça. Là tu peux les mettre où tu veux, ça peut être pratique pour séparer les octets en hexa ou en binaire.

        • [^] # Re: Séparateur de chiffre

          Posté par  . Évalué à 4.

          eh beh ! Eh ben ca va gentiment mettre la grouille dans la coloration syntaxique, si le truc garde aussi sa fonction première pour désigner les caractères.

          • [^] # Re: Séparateur de chiffre

            Posté par  . Évalué à 3.

            C'est pas le premier langage à le faire et j'ai pas vu de problème par rapport à ça, comme pour :

            long value = 1l;

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

            • [^] # Re: Séparateur de chiffre

              Posté par  . Évalué à 4.

              Je ne suis pas sur qu'on se comprenne. Faut que le machin soit capable de faire la différence entre les single quotes de ça :

              char a='a';

              et les single quotes de ça :

              über long l = 1'000'000'000;

              J'ai déjà vu des choses pas nettes nettes avec la coloration syntaxique de vim (quand on commence à mélanger les commentaires et chaînes de caractères), alors que je me demande comment ça va se gérer.

              • [^] # Re: Séparateur de chiffre

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

                Non, ça ne pose pas tant de problème que ça parce que dans le deuxième cas, tu ne peux pas avoir de quotes au début alors que pour un caractère, il doit obligatoirement apparaître au début (c'est un peu le même genre d'argument que pour le x dans les nombres hexadécimaux).

          • [^] # Re: Séparateur de chiffre

            Posté par  . Évalué à 10.

            D'un autre cote, vu le bordel que c'est de parser du c++, ca va pas rendre les choses tellement plus compliquee.

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: Séparateur de chiffre

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

      D'après N3499, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3499.html

      Underscores work well as a digit separator for C++03 [N0259] [N2281]. But with C++11, there exists a potential ambiguity with user-defined literals [N2747]. While the likely resolution will be some form of "max munch" rule, some mechanism must be present to disambiguate when max munch is too much.

    • [^] # Re: Séparateur de chiffre

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

      Oui, je crois que c'est à cause des litéraux définis par l'utilisateur (les trucs qu'on ajoute derrière un litéral pour préciser son type, comme 1L ou 0.1f). Dans la norme, il est dit que ceux qui ne font pas partie de la bibliothèque standard doivent être préfixés par _ (comme 1_km) et du coup, si le choix avait été fait sur _, ça aurait été un peu perturbant, sans compter que ça aurait complexifié le parsing (on tombe sur _, est-ce un séparateur de chiffre où le début d'un suffixe de litéral ?).

      • [^] # Re: Séparateur de chiffre

        Posté par  . Évalué à 5.

        … alors que l'apostrophe va rendre le parsing tellement plus facile :-)

      • [^] # Re: Séparateur de chiffre

        Posté par  . Évalué à 4.

        En lex, ça s'exprimerait assez simplement : _ suivi d'un nombre c'est un séparateur de chiffres, _ suivi d'une lettre c'est un littéral.

        • [^] # Re: Séparateur de chiffre

          Posté par  . Évalué à 2.

          Oui, ça ne parait pas plus ambigu que la "surcharge" des ', d'autant plus que je pense que les "user defined literal" ne doivent pas pouvoir commencer par un chiffre (comme tout les identificants en C/C++).

          Le _ étant déjà utilisé comme séparateur pour les nombres dans pleins de langages, c'est vraiment à se demander si le comité n'a pas sélectionner le ' pour faire ch… le mondel'originalité?

          • [^] # Re: Séparateur de chiffre

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

            le _ fait partie du nom, donc on pourrait très bien avoir un user defined literal qui serait _42, c'est là qu'est l’ambiguïté (qui ne peut se résoudre qu'à un niveau sémantique).

            • [^] # Re: Séparateur de chiffre

              Posté par  . Évalué à 0.

              le _ fait partie du nom

              Merci, je ne savais pas, encore un truc pas très bien fichu en C++ (à mon avis), ils cumulent..

              • [^] # Re: Séparateur de chiffre

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

                Si tu as de meilleurs idées, tu n'as qu'a participer aux discussion de l'ISO. C'est publique et ouvert à tous.

                _ fait partie du nom puisque c'est un identifier.

                En C++11 les user defined literal permettent d'écrire des truc du genre

                speed_t vitesse = 42m / 1s

                le m et s sont des user defined literal, mais ce sont juste des identifier. Et comme le dit moi1392 plus bas, _42 est aussi un identifier.

                Pas facile de faire évoluer un langage existant sans cassé la compatibilité.

                Rappelons que c'est cette compatibilité qui est la plus grande force du C++.
                Je travaille en C++11 qui est un language moderne, avec des grosses bases de code qui ont 15 ans ou même plus. Le passage à C++11 c'est fait sans trop de problème après avoir corrigé les quelques erreur de compilations.

                En ce qui concerne le séparateur de nombre, personnelement j'aurais préféré espace. (mais ça causais des problème en Objective C++)
                Ce document explique la discussion:
                http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3499.html

                • [^] # Re: Séparateur de chiffre

                  Posté par  . Évalué à 3.

                  Et bien personnellement j'aurai pris le choix suivant: le _ est ignoré DANS et IMMÉDIATEMENT APRÈS un nombre donc
                  123_456 est interprété comme 123456, 123456_ aussi.
                  123_42_m est équivalent à 42m (literal m)
                  mais abc_def est toujours interprété comme abc_def.

                  Il y a peut être un problème avec cette règle mais je ne le vois pas..

                  Le seule défaut que je vois est que ça qui implique qu'on ne pourrait pas avoir d'user definied literal commençant par un _ mais bon déjà il me semble que les noms commençant par un _ sont "réservé", non?

                  • [^] # Re: Séparateur de chiffre

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

                    Oui, sauf que C++11 est venu avant C++14, et que ce sont les préfix qui ne commencent pas par un underscoe qui sont réservés.

                    Et aussi: 0xdead_beef_db est-ce que il y a un user defined literal?

                    Le comité de standardisation a trouvé que le ' était le meilleur choix. Et perso je trouve 123'456 plus joli que 123_456.

                    • [^] # Re: Séparateur de chiffre

                      Posté par  . Évalué à 3.

                      +1 les identifiants hexadécimal fichent le bazar en effet.

                      Bon bah va pour le ' c'est moche, mais c'est mieux que rien!

          • [^] # Re: Séparateur de chiffre

            Posté par  . Évalué à 1. Dernière modification le 01 septembre 2014 à 15:26.

            Oui, ça ne parait pas plus ambigu que la "surcharge" des ',

            Si, parce pour l'aprostrophe, c'est dans un cas un truc qui doit marcher par pair et de l'autre un truc qui peut-être là une fois, deux fois, n fois.

            • [^] # Re: Séparateur de chiffre

              Posté par  . Évalué à 3. Dernière modification le 01 septembre 2014 à 16:40.

              D'une manière générale, on peut se poser la question de la pertinence du recyclage des caractères pour des sémantiques totalement différentes. En C++ par exemple, les caractères < et > ont au moins quatre sémantiques (la comparaison, les opérateurs de flux << et >>, les décalages de bits comme en C, et les templates). Et parfois, ça coince, comme par exemple pour les vector<vector<int> > qui ne compilent pas sans le disgracieux espace entre les deux >.

              Évidemment, ça ne présente de problèmes que pour les débutants, et les débutants auront de toutes manières beaucoup d'autres trucs à régler. Bon, les éditeurs de code vont aussi devoir revoir leurs règles de coloration syntaxique, mais c'est assez mineur. En pratique, ça n'a donc pas énormément d'effet, mais ça superpose des trucs peu intuitifs à d'autres trucs peu intuitifs, et ça manque d'élégance au final.

        • [^] # Re: Séparateur de chiffre

          Posté par  . Évalué à 4.

          _ suivi d'un nombre peut aussi être un nom de variable.

          int _3 = 3;

          • [^] # Re: Séparateur de chiffre

            Posté par  . Évalué à 3.

            Ah, oui j'avais oublié..

            Donc pour qu'une règle simple fonctionne il faudrait interdire de commencer les variables par des _, ça ne parait pas une mauvaise restriction, mais évidemment ça n'est pas compatible avec l'historique et pour un langage autre que le C/C++ ça créerait des problèmes pour l’interopérabilité avec le C..

        • [^] # Re: Séparateur de chiffre

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

          Un nombre en hexadécimal, ça comporte des lettres non ?

Suivre le flux des commentaires

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