Discussion :

[Anthony]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

• C++ embarqué
• Nominal C++
• C++ sain
• Pourquoi votre C++ doit être simple
• C++, ce n'est pas vous. C'est moi.
• « Keep It C-mple » Alexander Radchenko Sydney C++ Meetup (https://www.youtube.com/watch?v=lTXHOOwfTAo)
• Un dialecte du C++

Exemples de code

• Toute source C qui se compile avec le compilateur C++.
• DOOM 3 BFG
• Qt (lorsqu'il est compilé avec no-rtti, no-exceptions)
• dear imgui
• bgfx
• TheForge
• Oryol
• Network Next SDK

Source : Orthodox C++

Et vous ?

Qu'en pensez-vous ?
Trouvez-vous les lignes directrices d'Orthodox C++ crédibles ou pertinentes ?

Voir aussi :

Le C++ moderne « ne nous sauvera pas », car il est moins sécurisé que les nouveaux langages, selon Alex Gaynor

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

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

[deedolith]

Si je résume, c'est du "C with class" ?

A part sur de l'embarqué (et encore), je ne suis pas sûr de voir l'intérêt.

[Luc Hermitte]

A refuser les surcharges de <cheader> il manque comme un truc important pour écrire du code simple et robuste genre les surcharges qui éviteront de dégrader les sacro-saintes performances (l'excuse pour virer les exceptions) à cause de l'appel de la mauvaise fonction abs(). Pareil pour le RAII (la base du C++ moderne), exception ou pas.

Réécoutez/relisez plutôt ce que racontait Dan Saks concernant l'utilisation du C++ en embarqué. Il y a plus de réflexion derrière.

[stardeath]

Qu'en pensez-vous ?
Trouvez-vous les lignes directrices d'Orthodox C++ crédibles ou pertinentes ?

c'est dommage, je pense justement que garder les trucs archaïque du C et la sacro sainte compatibilité (que ça soit envers le C ou les versions antérieures du C++ et j'en passe) font que le C++ est aujourd'hui imbouffable.

[Aurelien.Regat-Barrel]

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

J'aurais inversé le propos : utilisez la STL si vous vous souciez de gérer correctement votre mémoire. La gestion des strings et tableaux en C est une source énorme de problèmes et difficultés, y compris pour les performances (connaitre la longueur d'une chaine...). Le manque de structures de données (set, map, ...) est aussi quelque chose qui n'aide pas à écrire un code plus simple, lisible, et même efficace. Quand au formatage à la printf, ça reste fragile...

Du coup je suis surpris que Qt soit donné en exemple car précisément cette lib diverge fortement de ces recommandations sur ces points là. Et à raison à mon humble avis.

Qt est un bon exemple je pense d'une mise en oeuvre prudente des fonctionnalités récentes de C++. Sans s'interdire de le faire là où ça apporte quelque chose.

PS: salut Luc !

[deedolith]

Je me permet d'ajouter que je ne voit pas l'intérêt de se passer des exceptions.

S'en passer implique une gestion par code erreur de retour, avec:
Multiplication des paramètres de sortie (pas très naturel de nos jours).
Multiplication des instructions de test à l'appel de chaque fonction, résultant en une lisibilité sévèrement dégradée.

L'abandon de la librairie standard ...., ça implique de réinventer la roue (dans l'immense majorité des cas: En moins bien). C'est au mieux stupide, au pire suicidaire.

Là ou je rejoint leurs idées, est à propos de la conservation de la sacro-sainte compatibilité descendante. A un moment donnée, il faut savoir jeter ce qui est obsolête (par exemple le membres at() des conteneurs vector, array ect ...)

[Luc Hermitte]

si vous vous souciez de gérer correctement votre mémoire. La gestion des strings et tableaux en C est une source énorme de problèmes et difficultés,

Je me permet d'ajouter que je ne voit pas l'intérêt de se passer des exceptions.

C'est une population qui veut du C avec des objets et sans trucs fait dans notre dos comme des libérations sur destruction. Limite un compilo qui optimise une boucle pour la remplacer par une formule mathématique, ça les dérange. Comment ça je suis mauvaise langue?

Pour les exceptions, il y a les problèmes de:
- implicite: ça fait des choses dans notre dos
- binaire plus gros (même sans déclenchement ni même un seul throw)
- surcoût énorme en cas de déclenchement (RTTI avec le modèle actuel, et gros cache miss du cache de code) -- mais perf probablement meilleures sinon (car on n'a pas un if toutes les deux lignes qui rempli le cache d'instructions de test+jmp)
- et beaucoup de FUD venant de traditions de langages sans exceptions (ils veulent du C avec des classes).
- EDIT: et population qui n'a pas été éduquée à la libération déterministe (RAII, with, using, finally, try-with-resources...) et pour qui rien ne vaut un bon "goto error". Ou rien, parce qu'on ne vérifie pas les codes de retours...
(toutes les cases ne sont pas cochées par tout le monde, mais ça reste un mélange de ces raisons)

Si tu regardes les sondages d'il y a quelques années, on a 50% des répondants qui disaient travailler sans exceptions. Pour cette population, c'est codes de retours, et pour les plus renseignés des monades-like (std::expected ou ancêtres)

Multiplication des instructions de test à l'appel de chaque fonction, résultant en une lisibilité sévèrement dégradée.

A ce propos ceci m'a fait doucement rigoler

La base de code écrite avec les limitations d'Orthodox C++ sera plus facile à comprendre

quand on regarde ce que la production d'un code correct implique dans un monde sans exceptions -> "Retour de fonctions ou exceptions ?" par Aaron Lahman

A un moment donnée, il faut savoir jeter ce qui est obsolête (par exemple le membres at() des conteneurs vector, array ect ...)

A un moment, après le papier de Sutter sur les exceptions déterministes, la citation de Bugs Aren’t Recoverable Errors! de Duffy, j'ai cru à la mise au ban des `std::logic_error`. Mais depuis les derniers embrasements autour de la safety, il y a un retour en force de la programmation excessivement défensive. On le voit à l'arrivée récente de `std::span::at()` dont il était encore hors de question il y a quelques années.

PS: Sault Aurélien

[Bousk]

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.

Ou alors apprenez à utiliser les allocateurs..? Toute la STL supporte les allocateurs personnalisés, qui permettent donc de contrôler la gestion de la mémoire.