1 pièce(s) jointe(s)
Orthodox C++, un sous-ensemble minimal de C++ qui améliore C, mais évite les éléments inutiles du C++ moderne
Orthodox C++, parfois appelé C+, est un sous-ensemble minimal de C++ qui améliore C, mais évite tous les éléments inutiles du C++ moderne, Orthodox C++ est l'opposé de ce que le C++ moderne est censé être
Orthodox C++, parfois appelé C+, est un sous-ensemble minimal du C++ qui améliore le C, mais évite toutes les choses inutiles du C++ dit moderne. C'est exactement l'opposé de ce que le C++ moderne est supposé être.
Pourquoi pas le C++ moderne ?
À la fin des années 1990, nous étions des hipsters du C++ moderne, et nous utilisions les dernières fonctionnalités. Nous disions à tout le monde qu'il fallait aussi utiliser ces fonctionnalités. Avec le temps, nous avons appris qu'il n'était pas nécessaire d'utiliser certaines fonctionnalités du langage simplement parce qu'elles existaient, ou que les fonctionnalités que nous utilisions s'avéraient mauvaises (comme RTTI, les exceptions et les flux), ou encore qu'elles se retournaient contre nous en rendant le code inutilement complexe. Si vous pensez que c'est absurde, attendez encore quelques années et vous détesterez aussi le C++ moderne (« Why I don't spend time with Modern C++ anymore », article archivé).
Pourquoi utiliser Orthodox C++ ?
La base de code écrite avec les limitations d'Orthodox C++ sera plus facile à comprendre, plus simple, et sera compatible avec les compilateurs plus anciens. Les projets écrits dans le sous-ensemble Orthodox C++ seront mieux acceptés par les autres projets C++, car le sous-ensemble utilisé par Orthodox C++ ne risque pas de violer les préférences de l'adoptant en matière de sous-ensemble C++.
Hello World avec Orthodox C++
Code:
1
2
3
4
5
6
7
8
|
#include <stdio.h>
int main()
{
printf("hello, world\n");
return 0;
} |
Que dois-je utiliser ?
- Le C++ proche du C est un bon début, si le code ne nécessite pas plus de complexité, n'ajoutez pas de complexités C++ inutiles. En général, le code doit être lisible par toute personne familiarisée avec le langage C.
- Ne faites pas ceci, la fin de la « justification de la conception » en Orthodoxe C++ devrait être immédiatement après « Assez simple, et c'est utilisable. EOF ».
- N'utilisez pas les exceptions.
« La gestion des exceptions est la seule caractéristique du langage C++ qui nécessite un soutien important de la part d'un système d'exécution complexe, et c'est la seule caractéristique du C++ qui a un coût d'exécution même si vous ne l'utilisez pas - parfois sous forme de code caché supplémentaire à chaque construction et destruction d'objet, et à chaque entrée/sortie de bloc try, et toujours en limitant ce que l'optimiseur du compilateur peut faire, souvent de manière assez significative. Pourtant, les spécifications d'exception du C++ ne sont de toute façon pas appliquées à la compilation, de sorte que vous ne pouvez même pas savoir si vous n'avez pas oublié de gérer un cas d'erreur ! Sur le plan stylistique, le style de gestion des exceptions ne s'accorde pas très bien avec le style C des codes de retour d'erreur, ce qui provoque un véritable schisme dans les styles de programmation, car une grande partie du code C++ doit invariablement faire appel aux bibliothèques C sous-jacentes. » - N'utilisez pas le RTTI.
- N'utilisez pas le wrapper d'exécution C++ pour les inclusions d'exécution C (<cstdio>, <cmath>, etc.), utilisez l'exécution C à la place (<stdio.h>, <math.h>, etc.).
- N'utilisez pas de flux (<iostream>, <stringstream>, etc.), utilisez plutôt des fonctions de type printf.
- N'utilisez rien du STL qui alloue de la mémoire, sauf si vous ne vous souciez pas de la gestion de la mémoire. Voir CppCon 2015 : Andrei Alexandrescu "std::allocator Is to Allocation what std::vector Is to Vexation" (https://www.youtube.com/watch?v=LIb3L4vKZ7U), et Why many AAA gamedev studios opt out of the STL thread, pour plus d'informations.
- N'utilisez pas la métaprogrammation de manière excessive à des fins de masturbation académique. Utilisez-la avec modération, uniquement lorsque c'est nécessaire, et lorsqu'elle réduit la complexité du code.
- Méfiez-vous des fonctionnalités introduites dans le standard C++ actuel, attendez idéalement que ces fonctionnalités soient améliorées dans la prochaine itération du standard. Par exemple, le constexpr du C++11 devenu utilisable en C++14 (par Jason Turner cppbestpractices.com curator)
Est-il possible d'utiliser en toute sécurité les fonctionnalités du C++ moderne ?
En raison du retard dans l'adoption du standard C++ par les compilateurs, les distributions de systèmes d'exploitation, etc., il n'est généralement pas possible de commencer à utiliser immédiatement les nouvelles fonctionnalités utiles du langage. La règle générale est la suivante : si l'année en cours est C++year+5, il est possible de commencer à utiliser de manière sélective les fonctionnalités de C++year. Par exemple, si le standard est C++11 et que l'année en cours est >= 2016, il n'y a probablement pas de danger. Si le standard requis pour compiler votre code est C++17 et que l'année est 2016, il est évident que vous pratiquez la méthodologie « Resume Driven Development ». Si vous faites cela pour un projet open source, alors vous ne créez pas quelque chose que d'autres peuvent utiliser.
Le 14 janvier 2022, le comité Orthodox C++ a approuvé l'utilisation de C++17.
D'autres idées similaires ?
Exemples de code
Source : Orthodox C++
Et vous ?
:fleche: Qu'en pensez-vous ?
:fleche: Trouvez-vous les lignes directrices d'Orthodox C++ crédibles ou pertinentes ?
Voir aussi :
:fleche: Le C++ moderne « ne nous sauvera pas », car il est moins sécurisé que les nouveaux langages, selon Alex Gaynor
:fleche: Le langage C++ connaît-il un regain de popularité ? Il se hisse à la troisième place de l'index TIOBE et pourrait bientôt évincer le C de la deuxième place, le COBOL réintègre le Top 20 de l'index
:fleche: Les travaux sur la norme C++ 23 sont terminés et cette nouvelle version porte le nom de code "Pandemic Edition", C++ 23 cherche à améliorer la vitesse de compilation et l'hygiène du code
