Cette section couvre les réponses aux questions fréquemment posées à propos de ces lignes directrices.
Consultez le haut de cette page. Il s’agit d’un projet open‑source visant à maintenir des lignes directrices modernes et autoritaires pour la rédaction de code C++ en utilisant le standard C++ actuel. Les lignes directrices sont conçues pour être modernes, exécutable automatiquement lorsqu’il est possible, et ouvertes aux contributions et aux forks afin que les organisations puissent facilement les intégrer à leurs propres directives de codage corporate.
Il a été annoncé par Bjarne Stroustrup lors de son discours d’ouverture à CppCon 2015, « Writing Good C++14 ». Consultez également le blog d’isocpp.org et, pour le raisonnement derrière les directives sur la sécurité des types et de la mémoire, le discours de Herb Sutter lors de CppCon 2015, « Writing Good C++14 … By Default ».
Les auteurs et mainteneurs initiaux principaux sont Bjarne Stroustrup et Herb Sutter, et les lignes directrices ont été développées jusqu’à présent grâce à des contributions d’experts du CERN, de Microsoft, de Morgan Stanley et d’autres organisations. À l’époque de leur publication, les lignes directrices étaient à l’état « 0.6 », et les contributions sont les bienvenues. Comme le dit Stroustrup dans son annonce : “We need help!”
Voir le fichier CONTRIBUTING.md. Nous apprécions l’aide des volontaires !
En contribuant d’abord beaucoup et en faisant reconnaitre la qualité constante de vos contributions. Voir le fichier CONTRIBUTING.md. Nous apprécions l’aide des volontaires !
Non. Ces lignes directrices ne font pas partie du standard. Elles sont destinées à soutenir le standard et à être maintenues comme des lignes directrices actuelles sur l’usage du standard C++ actuel. Nous visons à les tenir à jour en synchronisation avec le standard à mesure qu’il évolue.
github.com/isocpp ?Parce que isocpp est la Fondation du Standard C++. Les dépôts du comité se trouvent sous github.com/cplusplus. Une entité neutre doit posséder le copyright et la licence afin que clairement il ne s’agisse pas d’une domination par une seule personne ou un seul fournisseur. La Fondation est l’entité naturelle qui existe pour promouvoir l’usage et la compréhension à jour du Standard C++ moderne ainsi que du travail du comité. Ce schéma ressemble à celui que isocpp.org a adopté pour la [FAQ C++] (https://isocpp.org/faq), initialement créé par Bjarne Stroustrup, Marshall Cline et Herb Sutter et contribué aux projets de la même manière.
Non. Ces lignes directrices concernent la meilleure utilisation du C++ moderne, et la rédaction de code en partant du principe que vous disposez d’un compilateur moderne et conforme.
Non. Ces lignes directrices traitent de la meilleure utilisation du C++ moderne, et ne proposent que les fonctionnalités déjà existantes.
Ces normes de codage sont écrites en utilisant CommonMark, et les ancres <a> HTML. Nous envisageons d’utiliser les extensions suivantes de GitHub Flavored Markdown (GFM) :
À ce jour, nous ne sommes pas encore cohérents avec ce style.
Le GSL est l’ensemble des types et alias définis dans ces lignes directrices. À l’heure actuelle, la spécification est trop compacte ; nous prévoyons d’ajouter une spécification d’interface de type WG21 afin d’assurer la compatibilité des différentes implémentations, et de proposer une contribution de possible standardisation, sujet à la décision habituelle du comité.
Non. Il s’agit simplement de la première implémentation apportée par Microsoft. D’autres implémentations par d’autres fournisseurs sont encouragées, tout comme les forks et contributions à cette implémentation. À l’heure actuelle, une implémentation open‑source sous GPLv3 existe déjà. Nous prévoyons de produire une spécification d’interface de type WG21 afin d’assurer la compatibilité des implémentations.
Nous hésitons à sanctionner une implémentation particulière car nous ne voulons pas que les gens la considèrent comme la seule, ni étouffer les implémentations parallèles. Et si ces lignes directrices incluaient une implémentation réelle, ceux qui la avaient contributeuraient faussement un influence trop importante. Nous privilégions la longue tradition du comité, à savoir spécifier les interfaces, pas les implémentations. Parallèlement, nous souhaitons au moins une implémentation disponible ; nous espérons qu’il y en aura plusieurs.
Parce que nous voulons les utiliser immédiatement, et parce qu’ils sont temporaires au sens où nous voulons les retirer dès qu’il existe des types remplissant le même besoin dans la bibliothèque standard.
Non. Le GSL n’existe que pour fournir quelques types et alias qui ne se trouvent pas encore dans la bibliothèque standard. Si le comité décide d’adopter des versions standardisées (de ceux‑ci ou d’autres types remplissant le même besoin), ils pourront les retirer du GSL.
span<char> du GSL est‑il différent du string_view dans la Technical Specification Libraries Fundamentals 1 et le Working Paper C++17 ? Pourquoi ne pas simplement utiliser le string_view approuvé par le comité ?Le consensus sur la taxonomie des vues de la bibliothèque standard C++ est que « view » signifie « lecture uniquement », et « span » signifie « lecture/écriture ». Si vous avez besoin d’une vue lecture‑uniquement de caractères sans avoir besoin d’un contrôle de borne garanti et que vous avez C++17, utilisez std::string_view. Sinon, si vous avez besoin d’une vue lecture/écriture sans contrôle de borne garanti et que vous avez C++20, utilisez std::span<char> de C++20. Sinon, utilisez gsl::span<char>.
owner est‑il le même que le observer_ptr proposé ?Non. owner possède, est un alias, et peut être appliqué à tout type d’indirection. L’intention principale du observer_ptr est de signifier un pointeur sans possession.
stack_array est‑il le même que le array standard ?Non. stack_array est garanti d’être alloué sur la pile. Bien qu’un std::array contienne son stockage directement à l’intérieur de lui‑même, l’objet array peut être placé n’importe où, y compris sur le tas.
dyn_array est‑il le même que vector ou le dynarray proposé ?Non. dyn_array est un conteneur, comme vector, mais il n’est pas redimensionnable ; sa taille est fixe au moment de la construction. C’est un moyen sûr de référencer un tableau « pile‑alloué » de taille fixe. Contrairement à vector, il est destiné à remplacer l’allocation dynamique d’un tableau par new[]. Contrairement au dynarray proposé dans le comité, il ne prévoit aucune magie de compilateur/language pour allouer sur la pile lorsqu’il est membre d’un objet alloué sur la pile ; il ne fait que référencer un tableau « dynamique » ou alloué sur le tas.
Expects est‑il le même que assert ?Non. Il s’agit d’un espace réservé pour un soutien linguistique aux préconditions de contrat.
Ensures est‑il le même que assert ?Non. Il s’agit d’un espace réservé pour un soutien linguistique aux postconditions de contrat.