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

Langages de programmation Discussion :

Vers un C++ plus sûr ? La communauté C++ contre-attaque avec les extensions Safe C++


Sujet :

Langages de programmation

  1. #41
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 707
    Points : 1 448
    Points
    1 448
    Billets dans le blog
    7
    Par défaut
    Citation Envoyé par mintho carmo Voir le message
    Qu'est-ce que tu racontes ? Les debuggeurs n'ont aucun problème à afficher le type et la valeur d'une variable déclarée avec auto. Pour au moins ce que j'utilise : MSVC, QtCreator, XCode.
    Tant tu as une expression à droite de la variable qui n'a pas une valeur de retour de type auto. Désolé, mais je ne vois pas l'intérêt de ce truc lorsque l'on peut déjà faire du polymorphisme d'une façon plus sécuritaire, avec les objets et l'héritage.[/QUOTE]


    Citation Envoyé par mintho carmo Voir le message
    C'est possible selon les cas. Slice existe depuis longtemps en C++. Et pleins de libs proposent cette fonctionnalité. Et les ranges aussi. Mais c'est pas parce que les devs Ruby trouvent ça élégant que les devs C++ aussi. Ou que c'est souhaitable d'avoir ça en C++. Si les devs C++ étaient intéressé, ça aurait été au moins proposé.
    Je ne dis pas qu'il n'existe pas des outils pour travailler avec les intervalles. Je dis que la notation du C++ est archaïque. Il y a un tas de nouvelles idées qui sont apparus qui auraient pu être intégré au langage. Si Carbon ne rend pas la programmation plus sécuritaire ou plus aisée. Il vaut mieux considéré Rust que s'embarrasser à utiliser Carbon.

    Et comme Google a l'habitude d'abonner ses projets sans les avoir finaliser. Ce truc est sans intérêt.


    Citation Envoyé par mintho carmo Voir le message
    Tout le monde s'en tape de Linus. C'est un dev C, son opinion sur le C++ a autant de valeur que celle de mon boulanger.
    Pourtant cela devrait être considéré dans cette discussion, puisque les "évolutions" sont presqu'uniquemen sur le volet C du langage, plutôt que le volet POO.


    Citation Envoyé par mintho carmo Voir le message
    Hein ???
    WebAssembly fonctionne sur un CPU virtuel. Une version évolué du Forth. Avec l'émergence de nouveau type de CPU qui ne sont pas basée sur le jeu d'instruction d'intel, il y a beaucoup d'application qui ne seront pas compiler en langage machine dans le futur.

  2. #42
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 707
    Points : 1 448
    Points
    1 448
    Billets dans le blog
    7
    Par défaut La solution serait peut-être de remettre la littérature à jour.
    Je suis tomber sur une vidéo. Et le type expliquait qu'il ne fabriquait pas des accesseurs que si c'était absolument nécessaire. Et n'utilisait jamais la directive Private. Est-ce différent de l'enseigenement que vous avez reçu? Ayant débuté la programmation-object sur Pascal, j'ai toujours trouvé bizarre cette fabrication systématique d'accesseurs. Je crois que cette pratique pénalise la performance des programmes en C++



    La gestion étroite de la mémoire avec le tas et la pile est-elle encore justifable pour des applications ?

  3. #43
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Tech Lead
    Inscrit en
    Avril 2016
    Messages
    1 491
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Tech Lead

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 491
    Points : 6 196
    Points
    6 196
    Par défaut
    Citation Envoyé par Madmac Voir le message
    ...
    Je vois que tu as créé un fil dédié, donc j'ai répondu là-bas.

  4. #44
    Membre expérimenté
    Homme Profil pro
    retraité
    Inscrit en
    Septembre 2014
    Messages
    626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Septembre 2014
    Messages : 626
    Points : 1 495
    Points
    1 495
    Par défaut
    Si je connais plusieurs langages de programmation, C et surtout C++ me sont étrangers à 99%. Mais en comparant les deux exemples, j'ai trouvé Carbon bien plus lisible que C++, et j'ai compris le code que fait le premier, pour le C++, non pas tout.

  5. #45
    Membre expert
    Profil pro
    programmeur du dimanche
    Inscrit en
    Novembre 2003
    Messages
    869
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : programmeur du dimanche
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2003
    Messages : 869
    Points : 3 712
    Points
    3 712
    Par défaut
    Citation Envoyé par TotoParis Voir le message
    Si je connais plusieurs langages de programmation, C et surtout C++ me sont étrangers à 99%. Mais en comparant les deux exemples, j'ai trouvé Carbon bien plus lisible que C++, et j'ai compris le code que fait le premier, pour le C++, non pas tout.
    Honnêtement, il y a pas grand chose de fondamentalement révolutionnaire entre les deux sources, sauf la volonté de remplacer les #include par un gestionnaire de dépendance.

    Le reste, c'est surtout du sucre syntaxique et étrangement des régressions. La syntaxe du c++ est tordue, mais on s'y fait (à reculons pour moi...)

    Le +
    • std:: c'est la gestion des namespace un peu lourde où les fonctions standards ont un namespace dédié, alors que carbon les met dans l'espace de nommage courant.
    • span<circle> c'est un template, la façon de gérer la généricité... alors que carbon semble utiliser une fonction du langage à la place.
    • cout << : les créateurs du c++ on trouvé que c'était génial de surcharger << l'opérateur de décalage de bit, dans la fonction d'affichage cout, au lieu d'utiliser la notation fonction habituelle...

    Le -
    • auto a disparu (typage automatique). Bon, ensuite auto résout un problème très c++ d'avoir des types longs à saisir...
    • quand carbon initialise son tableau de Circle, il faut préciser .r=valeur à chaque fois, alors même que .r est la seule variable en argument... c'est une étrangeté que je n'ai vue dans aucun autre langage.

  6. #46
    Membre régulier Avatar de selmanjo
    Homme Profil pro
    Savant en programmation orienté objet
    Inscrit en
    Janvier 2020
    Messages
    55
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Savant en programmation orienté objet
    Secteur : Conseil

    Informations forums :
    Inscription : Janvier 2020
    Messages : 55
    Points : 102
    Points
    102
    Par défaut Rust
    En ce moment Rust n'est pas encore enseigné dans mon école supérieur !
    Je me demande si mon école, en ce moment, en parlant de Rust, le verrouille.
    La syntaxe Rustique ne me parait pas facile à appréhender, mais il y a des
    efforts à fournir pour bien maîtriser ce magnifique langage de programmation.

    Bien que je ne fais que débuter dessus !

    Maintenant, dans le contexte du changement climatique , Carbon ne me semble
    pas être une bonne alternative.

  7. #47
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    2 073
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 2 073
    Points : 56 189
    Points
    56 189
    Par défaut Carbon va-t-il remplacer le C++ ? Le projet Carbon explore une direction future possible pour le C++
    Carbon va-t-il remplacer le C++ ? Le projet Carbon explore une direction future possible pour le C++ étant donné les difficultés à l’améliorer
    Et mise sur l’interopérabilité comme base de travail

    Le langage Carbon est encore expérimental. La feuille de route indique la période 2025-2026 pour la sortie de la version 0.2 qui marquera le terme de l’expérience. La version 1.0 est attendue après 2026. L’effort est porté par des ingénieurs logiciels de Google qui ont cessé de participer à la normalisation du C++, ont démissionné de leur rôle officiel au sein du comité. Motif : un vote (au sein du comité de normalisation) sur la question de la rupture de la compatibilité ABI en faveur de la performance ne leur a pas donné raison. C’est de cette mésentente que naît le projet Carbon annoncé comme successeur du C++.

    Les développeurs de Carbon expliquent que certes, le C++ est le langage dominant pour les logiciels à performances critiques, mais son héritage et sa dette technique signifient que son amélioration incrémentale est une tâche très ardue.

    Carbon est un nouveau langage qui vise à égaler les performances de C++ et à maintenir une interopérabilité bidirectionnelle transparente, ainsi qu'une courbe d'apprentissage douce pour les développeurs C++.

    L'équipe promet en sus un certain niveau de traduction de source à source pour le code C++. Le projet présente des parallèles avec TypeScript pour les développeurs JavaScript, ou Kotlin pour les développeurs Java, bien que la comparaison ne soit pas exacte. Carbon est conçu pour être interopérable avec le code C++ et pour faciliter la migration. La chaîne d'outils Carbon prendra en charge la compilation du code C++.

    Pourquoi le C++ est-il difficile à améliorer ? Parce que le langage lui-même a commencé comme une bifurcation du C. Selon l'équipe Carbon, les concepteurs du C++ ont ajouté plutôt que remplacé des fonctionnalités du langage au fil du temps, créant ainsi des interactions complexes entre les fonctionnalités. La préservation de la compatibilité binaire est un autre problème hérité. En outre, le comité C++ et le processus d'évolution sont orientés vers la normalisation plutôt que la conception, sont lents et ne parviennent pas toujours à prendre des décisions.

    Carbon s'efforce de contourner ces problèmes en adoptant une nouvelle approche fondée sur les principes de l'open source. « Nous tenterons même de combler une énorme lacune dans l'écosystème C++ avec un gestionnaire de paquets intégré », peut-on lire dans les documents.

    Le langage Carbon sera familier aux développeurs C++ et C, mais il y a aussi de nombreuses différences. Les fonctions sont déclarées avec le mot clé "fn" et les variables avec "var". Il existe également des tuples fortement typés. L'inférence de type est supportée par le mot clé "auto". Les pointeurs sont pris en charge, mais pas l'arithmétique des pointeurs ; les seules opérations sur les pointeurs sont l'adressage et le déréférencement. Les classes supportent l'héritage simple, mais pas l'héritage multiple.
    La sécurité de la mémoire est une considération importante, mais n'est pas l'objectif initial. « La différence entre l'approche de Rust et celle de Carbon est que Rust commence par la sécurité et que Carbon commence par la migration », peut-on lire dans la documentation. L'approche consiste à simplifier le langage afin de créer de l'espace pour les fonctionnalités de sécurité, puis à refaire l'ingénierie des fondations pour modéliser et appliquer la sécurité.


    Les développements autour du langage Carbon interviennent dans où Rust se démarque des autres langages présentés depuis des années comme des alternatives au C et au C++. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla.

    Après 31 ans, un deuxième langage fait son entrée pour le développement du noyau Linux : c’est le Rust. La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place de langages comme le C ou le C++.

    Source : Semaphore

    Et vous ?

    Êtes-vous en accord avec l’argumentaire (le langage C++ est difficile à faire évoluer) qui a mené au lancement du projet Carbon ?
    Êtes-vous développeur C++ ? Quelle plus-value reconnaissez-vous à ce projet ? Sinon qu’en attendez-vous ?
    Le projet Carbon vient-il avec une plus-value véritable en comparaison à un langage comme le Rust considéré le futur pour ce qui est du développement d’applications système ?

    Voir aussi :

    L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
    Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
    C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust

  8. #48
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 354
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 354
    Points : 1 419
    Points
    1 419
    Par défaut cppfront
    j'ai l'impression, après avoir essayé un peu, que cppfront serait mieux pour migrer du source c++ vers un sous ensemble plus sain.

    De plus, il n'y a rien de fonctionnel dans Carbon, ils sont juste dans le design.

  9. #49
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 707
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 707
    Points : 1 448
    Points
    1 448
    Billets dans le blog
    7
    Par défaut
    Citation Envoyé par grunk Voir le message
    Ce n'est pas un ramasse miette comme on peut en trouver en java mais simplement une comptge de référence par chaque pointer. Quand le nombre de référence tombe à 0 le pointer s'auto détruit. Ca ajoute un léger overhead par rapport à un pointer normal (en terme de taille) mais dans la majorité des cas c'est acceptable. Les situation cible ou ca peut être un problème sont de toute manière généralement développées en C..
    Ce que tu me décrit ressemble énormément au ramassage Mark and Sweep (https://en.wikipedia.org/wiki/Tracin...mark-and-sweep). Et c'est très ancien et c'est un modèle qui n'est pas très performant. Oracle a developpé un modèle concurrent, mais je doute qu'il soit du domaine publique.

    Citation Envoyé par grunk Voir le message
    A la vue de tes exemples je pense que tu ne pratique pas suffisamment le C++ ou en tout cas pas du C++ dit moderne.
    Oui clairement C++ ne deviendra pas Python,Ruby ou un langage fonctionnel en terme de syntaxe (et tant mieux j'ai envie de dire) , mais on est bien loin de ce qu'il a pu être.
    Effectivement, je trouve cela souffrant. Si la rareté des librairies n'étaient pas un problème important, je l'abandonnerais complètement au profit d'Objective C ou de D. Je ne comprend pas pourquoi ces deux langages soit autant ignoré.

    Mais je trouve que la syntaxe n'a pas évolué en introduisant des simplifications que l'on pourrait considéré comme du typage implicite. Si ce fait un boucle d'une longueur de 255, est-ce que c'est vraiment nécessaire de spécifier que c'est un "unsigned Int8"?

    Pourquoi il n'existe pas de Class String et PString Ascii et Unicode optimisés? Basé meilleurs algos existants.

    À mes yeux, faire de la programmation object à la façon d'Objective C devrait-être une possibilité avec une simple directive de compilation. Après tout, je ne crois pas qu'à l'exception de l'analyseur syntaxique qu'il existe une véritable différence entre les deux compilateurs.

    Plutôt que de réinventer la roue à chaque fois, je trouve que l'accent devrait être sur les transpileurs.

    Dans ce fil, je décris en quoi les objets sont plus conviviale pour le programmeur en Objet-Pascal: https://www.developpez.net/forums/d2.../#post11929238

    Citation Envoyé par Pyramidev Voir le message
    Je vois que tu as créé un fil dédié, donc j'ai répondu là-bas.
    J'étais très occupé à l'époque, je viens de répondre.

  10. #50
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 930
    Points : 206 860
    Points
    206 860
    Par défaut Les innovations de C++26 : comment les dernières améliorations vont transformer le développement en C++
    Les innovations de C++26 : comment les dernières améliorations vont transformer le développement en C++,
    dans un contexte où plusieurs entités recommandent de remplacer C++ par des alternatives

    Le langage de programmation C++ continue d'évoluer avec l'introduction de nouvelles fonctionnalités et améliorations. La version C++26, bien que toujours en cours de développement, apporte déjà plusieurs nouveautés : spécifier une raison pour la suppression d'une fonction, variables de remplacement sans nom, déclaration d'une liaison structurée en tant que condition. Mais certains encouragent plutôt le passage à Rust ou Carbon, pourquoi ?

    Spécifier une raison pour la suppression d'une fonction

    Depuis le C++11, il est possible de déclarer une fonction comme supprimée, afin que le compilateur empêche son utilisation. Cela peut être utilisé pour empêcher l'utilisation de fonctions membres spéciales d'une classe, mais aussi pour supprimer toute autre fonction.

    Introduits en C++11, = default et = delete ont rejoint = 0 en tant que spécification alternative possible pour le corps d'une fonction, au lieu d'un corps d'instructions ordinaire entouré d'accolades. La motivation initiale de la déclaration de fonction supprimée via = delete est de remplacer (et d'annuler) la pratique courante de l'ère C++98/03 consistant à déclarer les fonctions membres spéciales comme privées et à ne pas les définir afin de désactiver leur génération automatique. Cependant, l'ajout de = delete a acquis un pouvoir encore plus grand, car il peut être utilisé pour n'importe quelle fonction, et pas seulement pour les membres spéciaux.

    Aujourd'hui, dix ans après l'introduction des fonctions supprimées, nous pouvons conclure en toute confiance que = delete est devenu l'une des fonctionnalités clés de C++11 qui a grandement amélioré l'expérience des utilisateurs en cas d'erreurs dans l'utilisation des fonctions de la bibliothèque et a été une réussite de la révolution du « C++ moderne ».

    Il y a plusieurs raisons pour lesquelles les fonctions supprimées ont été préféré aux fonctions traditionnelles privées mais non définies, notamment une meilleure sémantique (friend et les autres membres sont toujours inaccessibles, ce qui transforme une erreur de l'éditeur de liens en une erreur à la compilation), de meilleurs diagnostics (au lieu d'erreurs cryptiques « fonction inaccessible », l'utilisateur sait directement que la fonction est supprimée) et une plus grande puissance (pas seulement pour les SMF).

    Au lieu d'une erreur déjà plus conviviale mais toujours un peu énigmatique « calling deleted function », les éditeurs veulent permettre directement aux auteurs de bibliothèques de présenter un message supplémentaire facultatif qui devrait être inclus dans le message d'erreur, de sorte que l'utilisateur connaisse le raisonnement exact de la raison pour laquelle la fonction est supprimée, et dans certains cas, vers quel remplacement l'utilisateur devrait se diriger à la place.

    Une fonction peut être supprimée comme suit (exemple tiré du document de proposition) :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    class NonCopyable
    {
    public:
        // ...
        NonCopyable() = default;
        // les membres de la copie
        NonCopyable(const NonCopyable&) = delete;
        NonCopyable& operator=(const NonCopyable&) = delete;
     
    };

    En C++26, vous pouvez spécifier la raison pour laquelle cette fonction est supprimée :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    class NonCopyable {
    public:
        NonCopyable() = default;
        NonCopyable(const NonCopyable&) = delete("Cette classe gère des ressources uniques, la copie n'est pas supportée; utilisez le déplacement à la place.");
        NonCopyable& operator=(const NonCopyable&) = delete("Cette classe gère des ressources uniques, la copie n'est pas supportée; utilisez le déplacement à la place.");
    };


    Variables de remplacement sans nom

    Il existe des cas où une variable doit être déclarée sans que son nom soit utilisé, comme dans les liaisons de structure ou les verrous (lock_guard). C++26 introduit la possibilité d’utiliser un seul trait de soulignement (_) pour définir une variable sans nom.

    Par exemple, dans l'exemple suivant, unused est une variable qui n'est pas utilisée :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    [[maybe_unused]] auto [data, unused] = get_data();

    En C++26, la variable unused peut être nommée _ (simple trait de soulignement) :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    auto [data, _] = get_data();

    Lorsque l'identificateur de soulignement unique est utilisé pour la déclaration d'une variable, d'une variable membre de classe non statique, d'une capture lambda ou d'une liaison de structure, l'attribut [[maybe_unused]] est implicitement ajouté, il n'est donc pas nécessaire de l'utiliser explicitement.

    Une déclaration portant le nom _ est dite indépendante du nom si elle déclare :
    • une variable avec une durée de stockage automatique
    • une liaison de structure, mais pas dans un espace de noms
    • une variable introduite par une capture init
    • un membre de données non statique

    Le compilateur n'émet pas d'avertissement quant à l'utilisation ou non d'une déclaration indépendante du nom. De plus, plusieurs déclarations indépendantes du nom peuvent être utilisées dans la même portée (qui n'est pas une portée d'espace de noms) :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    int main()
    {
      int _;
      _ = 0;         // OK
      std::string _; // OK, parce que _ est une déclaration indépendante du nom
      _ = "0";       // Erreur : référence ambiguë au caractère générique « _ », qui est défini plusieurs fois.
    }

    En revanche, ce qui suit n'est pas possible :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    int main()
    {
      int _;
      _ = 0;                // OK
      static std::string _; // Erreur : les variables statiques ne sont pas indépendantes du nom
    }

    L'opération suivante n'est pas non plus possible, car les déclarations se trouvent dans un espace de noms :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    namespace n
    {
      int f() {return 42;}
      auto _ = f(); // OK
      auto _ = f(); // Erreur : redéfinition de _
    }


    Déclaration d'une liaison structurée en tant que condition

    Une liaison de structure définit un ensemble de variables liées à des sous-objets ou à des éléments de leur initialisateur.

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    auto [position, length] = get_next_token(text, offset);

    Une liaison de structure peut apparaître dans une déclaration for-range, comme dans l'exemple suivant :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    for (auto [position, length] : tokenize(text, offset))
    {
      std::println("pos {}, len {}", position, length);
    }

    En revanche, les variables peuvent apparaître dans la condition d'une instruction if, while ou for :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    if (auto it = std::find_if(begin(arr), end(arr), is_even); it != std::end(arr))
    {
      std::println("{} est le premier nombre pair", *it);
    }

    Cependant, les liaisons de structure ne peuvent pas être déclarées dans la condition d'une instruction if, while ou for. Cela change en C++26, ce qui rend la chose possible :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    if(auto [position, length] = get_next_token(text, offset); position >= 0)
    {
      std::println("pos {}, len {}", position, length);
    }

    Un cas intéressant et très utile est présenté dans le document de proposition (P0963). Considérons l'exemple C++26 suivant pour l'utilisation de std::to_chars :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    if (auto result = std::to_chars(p, last, 42))
    {
    ​​​​    auto [ptr, _] = result;
    ​​​​    // ok pour continuer
    ​​​​} 
    else 
    {
    ​​​​    auto [ptr, ec] = result;
    ​​​​    // gestion des erreurs
    ​​​​}

    Lorsque la fonction réussit, seul le membre ptr de std::to_chars_result nous intéresse, car il contient un pointeur sur le pointeur de fin de ligne des caractères écrits. Si la fonction échoue, nous devons également examiner le membre ec (du type std::errc) qui représente un code d'erreur.

    Ce code peut être simplifié avec des liaisons de structure, en C++26, comme suit :

    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    ​​​​if (auto [ptr, ec] = std::to_chars(p, last, 42))
    {
    ​​​​    // ok pour continuer
    ​​​​} 
    else 
    {
    ​​​​    // gestion des erreurs
    ​​​​}

    Nom : simple.png
Affichages : 92382
Taille : 9,9 Ko

    Le projet Carbon, un successeur expérimental du C++, explore une direction future possible pour le C++ étant donné les difficultés à l'améliorer

    En février 2020, un vote crucial a eu lieu au sein du comité de normalisation du C++ sur la rupture de la compatibilité ABI en faveur de la performance. L’initiative principalement poussée par les employés de Google a échoué. Résultat : de nombreux Googlers ont cessé de participer à la normalisation du C++, ont démissionné de leur rôle officiel au sein du comité, et le développement de clang a considérablement ralenti. C’est de cette rupture que naît le projet Carbon annoncé comme successeur du C++. L’objectif : explorer une direction future possible pour le C++ étant donné les difficultés à l’améliorer. Le projet Carbon mise sur l’interopérabilité avec le C++ comme base de travail.

    Les développeurs de Carbon expliquent que certes, le C++ est le langage dominant pour les logiciels à performances critiques, mais son héritage et sa dette technique signifient que son amélioration incrémentale est une tâche très ardue. Carbon est un nouveau langage qui vise à égaler les performances de C++ et à maintenir une interopérabilité bidirectionnelle transparente, ainsi qu'une courbe d'apprentissage douce pour les développeurs C++.

    L'équipe promet en sus un certain niveau de traduction de source à source pour le code C++. Le projet présente des parallèles avec TypeScript pour les développeurs JavaScript, ou Kotlin pour les développeurs Java, bien que la comparaison ne soit pas exacte. Carbon est conçu pour être interopérable avec le code C++ et pour faciliter la migration. La chaîne d'outils Carbon prendra en charge la compilation du code C++.

    Pourquoi le C++ est-il difficile à améliorer ? Parce que le langage lui-même a commencé comme une bifurcation du C. Selon l'équipe Carbon, les concepteurs du C++ ont ajouté plutôt que remplacé des fonctionnalités du langage au fil du temps, créant ainsi des interactions complexes entre les fonctionnalités. La préservation de la compatibilité binaire est un autre problème hérité. En outre, le comité C++ et le processus d'évolution sont orientés vers la normalisation plutôt que la conception, sont lents et ne parviennent pas toujours à prendre des décisions.

    Carbon s'efforce de contourner ces problèmes en adoptant une nouvelle approche fondée sur les principes de l'open source. « Nous tenterons même de combler une énorme lacune dans l'écosystème C++ avec un gestionnaire de paquets intégré », peut-on lire dans les documents.


    La Maison Blanche invite les développeurs à abandonner le C et le C++ pour passer à des langages comme le Rust

    Faut-il arrêter d’initier de nouveaux projets en C ou C++ et passer à Rust ? La question divise dans la communauté des développeurs dont certains recommandent le langage Rust plutôt que le C ou le C++. Les raisons : la parité du Rust en termes de vitesse d’exécution en comparaison avec le C ; la sécurisation et la fiabilité du Rust en comparaison avec C ou C++. La comparaison entre Rust et C++ vient de prendre un coup de neuf avec un rapport de la Maison Blanche sur la sécurisation de la mémoire qui invite les développeurs à abandonner C ou C++ pour passer à des langages comme le Rust jugés supérieurs pour sécuriser les espaces mémoire des logiciels. C’est une sortie qui fait suite à la prise de position du créateur du langage C++ selon laquelle : « la sécurisation des logiciels par le Rust n’est pas supérieure à celle offerte par le C++. »

    Sources : OpenSTD (1, 2, 3), Carbon

    Et vous ?

    Quelle est votre fonctionnalité préférée parmi celles introduites dans C++26 et pourquoi ?
    Comment pensez-vous que la possibilité de spécifier une raison pour la suppression d’une fonction pourrait améliorer le développement en C++ ?
    Avez-vous déjà rencontré des situations où les variables de remplacement sans nom seraient particulièrement utiles ? Pouvez-vous partager un exemple ?
    Pensez-vous que ces nouvelles fonctionnalités de C++26 vont simplifier ou compliquer le processus de développement ? Pourquoi ?
    Quels autres aspects du langage C++ aimeriez-vous voir améliorés dans les futures versions ?
    Comment ces nouveautés de C++26 se comparent-elles aux améliorations récentes d’autres langages de programmation que vous utilisez ?
    Voyez-vous des défis potentiels à l’adoption de ces nouvelles fonctionnalités dans des projets existants ? Si oui, lesquels ?
    Comment ces améliorations pourraient-elles influencer votre approche de la programmation en C++ ?
    Que pensez-vous des projets comme Carbon ou des propositions comme celle de la Maison Blanche visant à se délester du C++ ?

    Voir aussi :

    Google affirme qu'il est non seulement possible, mais aussi relativement facile de remplacer C++ par Rust dans les firmwares. L'entreprise explique en quoi ce changement est avantageux
    « Les équipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++ », d'après un responsable de l'entreprise qui lance le débat de la productivité entre Rust et C++
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  11. #51
    Nouveau membre du Club
    Femme Profil pro
    Étudiant
    Inscrit en
    Octobre 2012
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2012
    Messages : 14
    Points : 28
    Points
    28
    Par défaut
    Ces nouvelles features sont anecdotiques, les variables anonymes pourquoi pas, au moins ils reprennent une convention existante en python.

    Mais concrètement, C++ serait bien meilleur si on simplifiait sa compilation (un seul compilo multi-plateforme, un gestionnaire de dépendances simple à utiliser, une structure de projets normalisée).
    Il faudrait aussi supprimer la syntaxe C (printf et compagnie).

  12. #52
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2019
    Messages
    232
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2019
    Messages : 232
    Points : 1 144
    Points
    1 144
    Par défaut
    il faudrait surtout "nettoyer" les fonctions existantes, peu utilisées/utilisables, mais ils ne peuvent s'empêcher de rajouter de nouvelles variantes de fonctions existantes. Je me demande qui les utilisent réellement. Par exemple, il existe maintenant 14 variantes de la fonction replace de std::basic_string !!
    Et pourtant, on n'a toujours pas une fonction simple pour remplacer une ou plusieurs occurrences d'une sous-chaîne par une autre (case sensitive/insenstive) dans une chaîne. On n'a toujours pas accès non plus à des fonctions de trim. Pour chaque nouveau poste en entreprise, chaque projet utilise soit boost ou a sa propre librairie pour manipuler les string !
    Pendant ce temps, le comité c++ invente des nouveaux concepts ou des nouvelles variantes de fonctions que je n'ai personnellement jamais croisées dans aucun projet. J'ai pourtant plus de 20 ans d'expérience !

  13. #53
    Expert confirmé
    Homme Profil pro
    Développeur
    Inscrit en
    Août 2003
    Messages
    1 349
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Août 2003
    Messages : 1 349
    Points : 4 372
    Points
    4 372
    Par défaut
    Quels autres aspects du langage C++ aimeriez-vous voir améliorés dans les futures versions ?
    Un gestionnaire de dépendances, je n'ai fais plus de C++ depuis 2006 mais j'ai parfois cherché à compiler certains programmes et c'est une galère à chaque fois car la bibliothèque manquante n'était pas clairement notée : il faut se baser sur le nom du fichier ou chercher dans le makefile et ça demande du temps à chaque fois.

  14. #54
    Membre éprouvé
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Mai 2015
    Messages
    248
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Mai 2015
    Messages : 248
    Points : 920
    Points
    920
    Par défaut Ce n'est que mon opinion...
    Bjarne Stroustup, le créateur original de C++, a dénoncé lui-même la dérive qu'a prit le comité qui dirigent les évolutions de C++.
    Ils leurs reproche d'ajouter des micro-fonctionnalités, qui ne sont utilent qu'à 0,01% des projets ou des développeurs, et qui pourrait être déjà fait avec l'existant. En fait, le C++ est maintenant piloté par un comité de gens certes très compétants, mais qui font de la masturbation intellectuel pour pondre des concepts qui sont très éloignés de ce dont ont besoin les développeurs dans le monde réel.

    C'est malheureux, car voilà un langage qui avaient du succès, qui répondait à un besoin, mais qui va crouler sous sont propre poids.

    BàV et Peace & Love.

  15. #55
    Membre régulier
    Profil pro
    Inscrit en
    Février 2003
    Messages
    29
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2003
    Messages : 29
    Points : 79
    Points
    79
    Par défaut
    Pour remplacer le C++ n'y a-t-il pas déjà le langage D ? C'est en tout cas son ambition affichée.

    Quitte a repenser le C++, ce serait judicieux d'éviter de créer un langage a la syntaxe moche.
    Car, selon moi, ce qui a fait le succès des langages comme Java et C# c'est aussi la lisibilité de leurs syntaxes.
    Et je ne parle même pas du fait que l'adoption d'un nouveau langage tien aussi au fait que chaque instruction soit non seulement documentée mais surtout accompagnée d'un exemple pratique et utile (codes snippets), afin de faciliter la mise en pratique.

  16. #56
    Membre émérite
    Profil pro
    retraité
    Inscrit en
    Décembre 2010
    Messages
    832
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Décembre 2010
    Messages : 832
    Points : 2 393
    Points
    2 393
    Par défaut
    Quitte a repenser le C++, ce serait judicieux d'éviter de créer un langage a la syntaxe moche.
    Quand j'ai dit cela à propos de Rust, en disant que c'était dommage de ne pas avoir conservé une syntaxe "C like" on m'a "moinsé" sans donner de contre argument. On est donc d'accord, et effectivement si java, C# ont décollé c'est en partie grâce à cela. Il suffit de regarder le Go, très performant aussi, il a plus de mal à décoller.

  17. #57
    Membre éprouvé
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Mai 2015
    Messages
    248
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Mai 2015
    Messages : 248
    Points : 920
    Points
    920
    Par défaut Ce n'est que mon opinion...


    Citation Envoyé par Brunoo Voir le message
    Pour remplacer le C++ n'y a-t-il pas déjà le langage D ? C'est en tout cas son ambition affichée.
    D aurait pu être ce "nouveau C++", mais il n'a pas décollé, parce qu'au moment où il est sorti:

    • il n'était pas rétrocompatible avec le C
    • C++ n'était pas encore devenu le monstre qu'il est aujourd'hui, et a prit naturellement la relève.
    • Grâce à sa compatibilité avec le C, il avait déjà tout un éco-système, et une communauté autours de lui.


    Quitte a repenser le C++, ce serait judicieux d'éviter de créer un langage a la syntaxe moche.
    Car, selon moi, ce qui a fait le succès des langages comme Java et C# c'est aussi la lisibilité de leurs syntaxes.
    La syntaxe, c'est une affaire de goût, d'habitude, mais surtout de lisibilité. Je dis souvent qu'on lit plus souvent son code qu'on ne l'écrit. Java, possédait (et possède toujours) des atouts, mais:

    • Il est très verbeux, rendant le code "surchargé" et difficile à lire.
    • Il tourne via une "machine virtuelle", qui même si elle possèce un JIT maintenant, ce n'était pas le cas à ses débuts.
    • Et à cause du fait qu'il tourne en s'appuyant sur une "machine virtuelle", il ne pouvait et ne peut pas être comparé au C/C++ qui peuvent compiler du code natif, pour plusieurs architecture. Il y a toujours un compilateur 'C' pour chaque architecture, de la plus petite à la plus grande.
    • Puis Python est arrivé est s'est fortement implenté. On dit qu'il est lent (parce que lui aussi tourne sur une machine virtuelle), mais il sait très facilemment utiliser du code 'C', ce qui fait que tout traitent "lourd" est souvent exécuté à la vitesse du 'C'.


    Pour C#, c'est un peu le "java" de microsoft. La puissance de microsoft est derrière ce langage, mais lui aussi tourne sur une "machine virtuelle", même s'il a maintenant aussi un JIT, il ne peut en rien être comparé (tout comme Java), question vitesse, à C/C++. Il a prit de l'importance et est très utilisé, car il y'a microsoft derrière, est ça "rassure" les entreprises quant à sa pérénité.

    Le Go, je ne connais pas, donc j'évite de faire des commentaires sur une technologie qui m'est inconnue.

    Et je ne parle même pas du fait que l'adoption d'un nouveau langage tien aussi au fait que chaque instruction soit non seulement documentée mais surtout accompagnée d'un exemple pratique et utile (codes snippets), afin de faciliter la mise en pratique.
    Il n'y a pas que ça, il faut tout un écosystème autours d'un langage. De la doc, oui, mais aussi des librairies, des éditeurs, bref, toute une floppée d'outils.
    Il faut aussi créer tout une communauté, qui perdure et sait acceuillir les développeurs qui se pencheront sur un langage.

    Et un petit dernier pour la route Il n'y a pas langage qui soit adapté à toutes les situations. Il ne me viendrait pas à l'idée de faire une grosse application en 'C'. C'est plutôt le C++ qui serait utilisé dans ce cas. Dans le domaine de l'embarqué, le seul langage que tu es certains d'avoir, c'est le 'C'. Dans le domaine banquaire, c'est toujours du COBOL qui est utilisé. Certains ont bien tenté de ré-écrire les vielles application COBOL en java ou en C++, mais tout les essais ont échoués, car c'est très difficile de reconstruire un système qui fonctionne à l'identique.

    Et il y a une grosse masse de code 'C' dans la nature, et on ne remplacera pas celui-ci du jour au lendemain.

    Actuellement, quelques langages se démarquent des autres:

    • Python chez les "data scientist", et les "ingénieurs", car il est trés simple à écrire et à relire, et à tout ce qu'il faut pour les satisfaire question librairires (numPy par exemple) pour s'affranchir sa "relative" lenteur.
    • lua, est lui aussi un langage "dynamique" comme Python, et est simple à utiliser. Sa machine virtuelle est aussi plus rapide que celle de Python, car c'est une "register based VM", là ou Python/Javan reposent sur des "stack based VM".
    • C# pour ceux qui ne veulent être "rassuré" par le fait que Microsift soit derrière.
    • Le 'C' reste indispensable grâce à sa vitesse, son éco-système, et qu'il reste le plus rapide, car très proche de ma machine. Son désavantage, c'est que si on ne fait pas très attention, on peut vite introduire des vulnérabilités. Mais dans l'embarqué, c'est toujours 'LA' référence, et avec la base de code installée, il est encore là pour très longtemps.
    • C++, car (tout comme le C), il il peut produire du code natif et est de ce fait très utilisé. Et il a profité de la vague POO à ses début. Il est également très installé.
    • COBOL reste utilisé dans le domaine bancaire.


    Et puis, il y'a maintenant le petit nouveau (enfin, a quand même 10 ans) Rust qui peut pratiquement égaler C/C++ niveau vitesse, mais qui est nettement plus sécurisé niveau gestion mémoire et évite pas mal d'erreurs qu'on peut faire en C/C++, car le langage (et son compilateur) fournira des erreurs et ne compilera pas un code dangereux.

    C'est je pense le seul langage (qui produit du code machine) qui peut/pourra rivaliser avec le C/C++. Je suis en train de me pencher dessus, et pour un vieux développeur 'C' comme moi, sa "syntaxe" me déroute énormément (mais avec le temps, ça viendra), et il faut parfois se battre avec le compilateur pour qu'il accepte de compiler un code, car les différents verrous qu'il possèdent pour être "sécure" sont parfois "lourds" a digérer pour les vieux développeurs 'C', qui savent ce qu'il font. Mais on fait tous des erreurs, et si le langage permet d'en éviter, ça ne peut être d'une bonne chose.

    [B]Rust[B] est déroutant, et il faut s'accrocher et persévérer, car oui, les concepts qu'il aborde sont traités différement que d'autres language, mais rend le code plus "sécure".

    Mais, je le répête, il n'y a pas de langage meilleurs qu'un autres. Il faut choisir son outils par rapport à ses besoins. On utilise un marteau pour enfoncer un clou, et un tournevis pour viser une vise. L'inverse n'aurait pas de sens.

    BàV et Peace & Love.

  18. #58
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 621
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 621
    Points : 15 704
    Points
    15 704
    Par défaut
    Citation Envoyé par archqt Voir le message
    Quand j'ai dit cela à propos de Rust, en disant que c'était dommage de ne pas avoir conservé une syntaxe "C like" on m'a "moinsé" sans donner de contre argument. On est donc d'accord, et effectivement si java, C# ont décollé c'est en partie grâce à cela. Il suffit de regarder le Go, très performant aussi, il a plus de mal à décoller.
    En effet certaines choses ne sont pas exactement identiques mais tout l’intérêt de faire un nouveau langage et que faire des choix mieux adaptés par défaut et pas se trainer des spécificités d'un vieux langage. C'est un gros défaut du C++ qui se traine l'héritage du C.

    Rust n'a jamais prétendu être un surensemble de C++. Il a quand même une syntaxe relativement inspirée du C++ (acolades, point-virgules, opérateurs, espace insignifiant, le let n'est pas très différent du auto,...). Il y a des spécificités mais elles font sens quand on apprend les fonctionnalités spécifiques du langage.

  19. #59
    Membre expert
    Profil pro
    undef
    Inscrit en
    Février 2013
    Messages
    1 002
    Détails du profil
    Informations personnelles :
    Localisation : France, Lot (Midi Pyrénées)

    Informations professionnelles :
    Activité : undef

    Informations forums :
    Inscription : Février 2013
    Messages : 1 002
    Points : 3 663
    Points
    3 663
    Par défaut
    Qui peut croire que les politiques savent ce qui est bon pour une industrie? Rust est poussé par une communauté actuellement anormalement puissante dans les milieux de pouvoirs ; ce n'est pas un mauvais langage, mais il n'est pas taillé pour la rentabilité/productivité et les faits d'armes de ce langage se résument à avoir réécrit des choses qui existent déjà et sans réelle nécessité de réécriture, on peut admirer la complexité du pattern mémoire résultant d'une compilation Rust réussie, louer son contrôle de l'espace mémoire... et cela répond sûrement aux besoins de certains domaines de pointe (aérospatial, armée...) Mais la seule chance pour Rust de dépasser le C++ c'est que ce dernier devienne aussi compliqué à appréhender que l'outsider.

  20. #60
    Membre éprouvé
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Mai 2015
    Messages
    248
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Mai 2015
    Messages : 248
    Points : 920
    Points
    920
    Par défaut Oui et non...
    Citation Envoyé par 23JFK Voir le message
    Mais la seule chance pour Rust de dépasser le C++ c'est que ce dernier devienne aussi compliqué à appréhender que l'outsider.
    Malgrè tout le mal que j'ai a comprendre (je ne parle pas d'utiliser, simplement de comprendre) ce que Rust apporte, le C++ n'a pas eu besoin de Rust pour commencer son auto-destruction. Le code C++ est un des plus laid et compliqué possible, sachant à peine donner un message d'erreur correcte et compréhensible. J'ai un autre avis sur le C, parce que je l'ai pratiqué toute ma vie, et il sera là pour encore très longtemps. Le C++ disparaîtra bien avant le 'C', qui reste compréhensible et n'a pas tendance a évoluer dans tous les sens.

    BàT et Peace & Love.

Discussions similaires

  1. Réponses: 0
    Dernier message: 29/11/2011, 09h20
  2. Création d'une base de données pour gérer des projets
    Par Rodrigue dans le forum Modélisation
    Réponses: 4
    Dernier message: 19/11/2010, 17h14
  3. Réponses: 2
    Dernier message: 11/04/2010, 11h53
  4. Besoin de directions de recherches pour mon projet.
    Par RudyWI dans le forum AWT/Swing
    Réponses: 1
    Dernier message: 19/12/2007, 12h19
  5. Réponses: 4
    Dernier message: 14/03/2007, 08h57

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