IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Anthony
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Novembre 2022
    Messages
    1 033
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Rédacteur technique

    Informations forums :
    Inscription : Novembre 2022
    Messages : 1 033
    Points : 17 094
    Points
    17 094
    Par défaut 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é).

    Nom : 53454879-839a6480-39dd-11e9-9915-41baca494461.jpg
Affichages : 67418
Taille : 54,3 Ko

    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 ?


    Exemples de code


    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
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre chevronné
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 242
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 242
    Points : 1 822
    Points
    1 822
    Par défaut
    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.

  3. #3
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 279
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 279
    Points : 11 011
    Points
    11 011
    Par défaut
    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.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  4. #4
    Expert confirmé

    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 386
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 386
    Points : 4 959
    Points
    4 959
    Par défaut
    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.

  5. #5
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 752
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 752
    Points : 10 681
    Points
    10 681
    Billets dans le blog
    3
    Par défaut
    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 !

  6. #6
    Membre chevronné
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 242
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 242
    Points : 1 822
    Points
    1 822
    Par défaut
    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 ...)

  7. #7
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 279
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 279
    Points : 11 011
    Points
    11 011
    Par défaut
    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
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  8. #8
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 124
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 124
    Points : 33 028
    Points
    33 028
    Billets dans le blog
    4
    Par défaut
    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.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

Discussions similaires

  1. sous ensembles & permutation de liste
    Par LlufRuS dans le forum Algorithmes et structures de données
    Réponses: 5
    Dernier message: 06/12/2006, 10h22
  2. Réponses: 2
    Dernier message: 27/01/2006, 09h48
  3. sous ensemble d'une liste
    Par adel25 dans le forum C++
    Réponses: 1
    Dernier message: 23/08/2005, 15h50
  4. [DBGrid] Affichage d'un sous-ensemble de données
    Par Jean-Jacques Engels dans le forum Bases de données
    Réponses: 3
    Dernier message: 02/09/2004, 16h31
  5. Sous-ensembles de tuples
    Par HPJ dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 07/10/2003, 16h24

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo