Cette section couvre les réponses aux questions les plus souvent posées à propos de ces directives.
Voir le haut de cette page @TODO-LINK. Il s’agit d’un projet open‑source visant à maintenir des directives modernes et autoritaires pour écrire du code C++ en utilisant la norme C++ actuelle. Les directives sont conçues pour être modernes, applicables automatiquement par machine autant que possible, et ouvertes aux contributions et aux forks afin que les organisations puissent facilement les intégrer à leurs propres normes de codage d’entreprise.
Il a été annoncé par Bjarne Stroustrup dans son discours d’ouverture du CppCon 2015, « Writing Good C++14 ». Voir également le post de blog accompagnant sur isocpp.org, et pour la justification des directives de sûreté de types et de mémoire, consultez la présentation de suivi de Herb Sutter au CppCon 2015, « Writing Good C++14 … By Default ».
Les premiers auteurs et mainteneurs principaux sont Bjarne Stroustrup et Herb Sutter, et les directives ont été développées avec les contributions d’experts du CERN, de Microsoft, de Morgan Stanley et de plusieurs autres organisations. Au moment de leur sortie, les directives sont à l’état « 0.6 », et les contributions sont les bienvenues. Comme Stroustrup l’a déclaré dans son annonce : « We need help! » → « Nous avons besoin d’aide ! »
Voir le CONTRIBUTING.md. Nous apprécions l’aide bénévole !
En contribuant beaucoup d’abord et en faisant reconnaître la qualité constante de vos contributions. Voir le CONTRIBUTING.md. Nous apprécions l’aide bénévole !
Non. Ces directives sont extérieures à la norme. Elles sont destinées à soutenir la norme et sont maintenues comme directives actuelles sur la façon d’utiliser efficacement le C++ standard actuel. Nous nous efforçons de les maintenir synchronisées avec la norme à mesure qu’elle évolue grâce aux travaux du comité.
github.com/isocpp ?Parce que isocpp est la Standard C++ Foundation ; les dépôts du comité sont sous github.com/cplusplus. Une organisation neutre doit posséder les droits d’auteur et la licence afin de clarifier que ce projet n’est dominé ni par une personne ni par un fournisseur. L’entité naturelle est la Fondation, qui existe pour promouvoir l’utilisation et la compréhension à jour du C++ standard moderne et le travail du comité. Ce modèle suit le même schéma que celui employé par isocpp.org pour la C++ FAQ, initialement élaborée par Bjarne Stroustrup, Marshall Cline et Herb Sutter, puis ouverte à la communauté.
Non. Ces directives portent sur la meilleure utilisation du C++ standard moderne et supposent que vous disposez d’un compilateur moderne conforme.
Non. Elles portent sur la meilleure utilisation du C++ standard moderne et se limitent à recommander uniquement les fonctionnalités existantes.
Ces standards de codage sont rédigés en utilisant CommonMark et des ancres HTML <a>.
Nous envisageons les extensions suivantes de GitHub Flavored Markdown (GFM) :
Évitez les autres balises HTML et les autres extensions.
Note : Nous ne sommes pas encore cohérents avec ce style.
La GSL (Guidelines Support Library) est le petit ensemble de types et alias spécifiés dans ces directives. À l’heure actuelle, leur spécification ici est trop succincte ; nous prévoyons d’ajouter une spécification d’interface de type WG21 afin de garantir que différentes implémentations soient d’accord, et de proposer cela comme contribution pour une éventuelle standardisation, sous réserve du jugement habituel du comité.
Non. Il s’agit simplement d’une première implémentation fournie par Microsoft. D’autres implémentations par d’autres fournisseurs sont encouragées, tout comme les forks et les contributions à cette implémentation. À l’heure actuelle, une semaine après le lancement public du projet, au moins une implémentation open‑source sous licence GPLv3 existe déjà. Nous prévoyons de produire une spécification d’interface de type WG21 afin d’assurer la concordance des différentes implémentations.
Nous sommes réticents à favoriser une implémentation particulière, car nous ne voulons pas laisser penser qu’il n’en existe qu’une, ce qui risquerait d’étouffer les implémentations parallèles. De plus, si ces directives incluaient une implémentation réelle, le contributeur pourrait être perçu comme trop influent. Nous préférons suivre l’approche de longue date du comité : spécifier les interfaces, pas les implémentations. Mais en même temps nous souhaitons qu’au moins une implémentation soit disponible ; nous espérons qu’il y en aura plusieurs.
Parce que nous voulons les utiliser immédiatement, et parce qu’ils sont temporaires : nous souhaitons les retirer dès que des types remplissant les mêmes besoins existent dans la bibliothèque standard.
Non. La GSL n’existe que pour fournir quelques types et alias qui ne sont pas encore dans la bibliothèque standard. Si le comité décide d’une version standardisée (de ceux‑ci ou d’autres types remplissant les mêmes besoins), ils pourront être retirés de la GSL.
gsl::span<char> diffère‑t‑il du string_view de la Specification Technique Library Fundamentals 1 et du papier de travail C++17 ? Pourquoi ne pas simplement utiliser le string_view approuvé par le comité ?Le consensus sur la taxonomie des vues pour la bibliothèque standard C++ est que « view » signifie « lecture‑seule », et « span » signifie « lecture/écriture ». Si vous avez seulement besoin d’une vue en lecture‑seule de caractères qui ne nécessite pas de vérification de limites garantie et que vous avez C++17, utilisez std::string_view de C++17. Sinon, si vous avez besoin d’une vue lecture‑écriture qui ne nécessite pas de vérification de limites garantie et que vous avez C++20, utilisez std::span<char> de C++20. Dans les autres cas, utilisez gsl::span<char>.
owner est‑il identique à l’observer_ptr proposé ?Non. owner possède, est un alias et peut s’appliquer à tout type d’indirection. L’objectif principal de observer_ptr est de signifier un pointeur non‑possédant.
stack_array est‑il identique à array standard ?Non. stack_array est garanti d’être alloué sur la pile. Bien qu’un std::array contienne son stockage directement en son sein, l’objet array peut être placé n’importe où, y compris sur le tas.
dyn_array est‑il identique à vector ou au dynarray proposé ?Non. dyn_array est un conteneur, comme vector, mais il n’est pas redimensionnable ; sa taille est fixe à l’exécution lorsqu’il est construit. C’est un moyen sûr de référencer un tableau de taille fixe alloué dynamiquement sur le tas. Contrairement à vector, il est destiné à remplacer l’allocation new[]. Contrairement au dynarray proposé dans le comité, celui‑ci n’anticipa pas de « magie du compilateur/langage » pour l’allouer sur la pile lorsqu’il est membre d’un objet placé sur la pile ; il se contente de référencer un tableau « dynamique » (sur le tas).
Expects est‑il identique à assert ?Non. C’est un espace réservé pour le support du langage des préconditions de contrat.
Ensures est‑il identique à assert ?Non. C’est un espace réservé pour le support du langage des postconditions de contrat.