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. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    2 070
    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 070
    Points : 56 127
    Points
    56 127
    Par défaut Vers un C++ plus sûr ? La communauté C++ contre-attaque avec les extensions Safe C++
    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
    Et mise sur l’interopérabilité comme base de travail

    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.

    Lors d'un récent évènement dédié au langage C++ cette semaine à Toronto, Chandler Caruth, ingénieur logiciel chez Google, a présenté le langage Carbon, décrit comme un successeur expérimental du C++, suscitant un vif intérêt au sein de la communauté C++.

    « Nous comprenons l'intérêt de la communauté pour cette keynote. Nous publierons l'enregistrement selon un calendrier accéléré », ont déclaré les organisateurs de la conférence sur Twitter. Carruth est responsable technique des principaux langages de programmation et de l'évolution des langages de Google. Il représente Google au sein du comité des normes C++ et contribue à LLVM et Clang.

    Nom : 1.png
Affichages : 134566
Taille : 64,8 Ko

    Les développeurs de Carbon expliquent que si le C++ est le langage dominant pour les logiciels à performances critiques, son héritage et sa dette technique signifient que l'amélioration incrémentale du C++ est extrêmement difficile.

    Une solution consiste à migrer vers d'autres langages tels que Rust, Kotlin, Swift ou Go, mais il est difficile de migrer vers ces derniers à partir du C++. De plus, dans certains cas, ces derniers présentent une surcharge de performance. 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. Le langage C a 50 ans, il n'est donc pas surprenant qu'il y ait beaucoup d'héritage. 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 feuille de route actuelle vise à terminer la version 0.1 du langage cette année, la 0.2 en 2023 et la version 1.0 en 2024 ou 2025.

    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.

    Nom : 2.png
Affichages : 9258
Taille : 44,7 Ko

    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é.

    Le projet est sous licence Apache 2 avec des exceptions LLVM. L'équipe prévoit de créer une fondation open source et de lui transférer tous les droits liés à Carbon. « Notre objectif est que la configuration de la fondation soit similaire à d'autres projets open source tels que LLVM ou Kubernetes », ajoute-t-elle. Cependant, le projet exige actuellement que les contributeurs acceptent le CLA (contributor license agreement) de Google, ce qui peut poser problème à certains. Google finance également l'infrastructure de Carbon.

    Sur la question de savoir pourquoi ne pas utiliser d’autres langages comme Rust, les têtes derrière l’initiative répondent : « Si vous voulez utiliser Rust, et que c'est techniquement et économiquement viable pour votre projet, vous devriez utiliser Rust ». Toutefois, la question de Rust est au cœur de la réussite future du projet Carbon. En effet, Rust est de l’avis de plusieurs observateurs en passe de devenir le langage de bas niveau standard. Néanmoins, on continue de compter plus de lancements de projets pilotés en C++ qu’en Rust et donc toute possibilité d’aller au-delà du C++ tout en conservant l’interopérabilité doit faire office de bonne nouvelle.

    Source : Carbon

    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 :

    Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

    Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

    Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

    Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

  2. #2
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    Avril 2002
    Messages
    2 837
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : Avril 2002
    Messages : 2 837
    Points : 19 224
    Points
    19 224
    Par défaut
    Très bon article

    C++ est devenu clairement une usine à gaz compliquée et incompréhensible sauf pour quelques experts.
    La syntaxe de Carbon semble ressembler pas mal à Rust, comment un tel projet pourrais t'il se positionner par exemple par rapport à C++, D et Rust ?

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

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Décembre 2010
    Messages : 831
    Points : 2 389
    Points
    2 389
    Par défaut
    Je ne vois pas l'intérêt si la syntaxe ressemble à Rust, autant prendre Rust qui vise aussi la performance.

  4. #4
    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 195
    Points
    6 195
    Par défaut
    Citation Envoyé par archqt Voir le message
    Je ne vois pas l'intérêt si la syntaxe ressemble à Rust, autant prendre Rust qui vise aussi la performance.
    Les auteurs de Carbon ont répondu dans leur FAQ : Why not Rust?

    Je ne copie-colle pas la réponse en entier, mais seulement le début :

    If you can use Rust, ignore Carbon

    If you want to use Rust, and it is technically and economically viable for your project, you should use Rust. In fact, if you can use Rust or any other established programming language, you should. Carbon is for organizations and projects that heavily depend on C++; for example, projects that have a lot of C++ code or use many third-party C++ libraries.

    We believe that Rust is an excellent choice for writing software within the pure Rust ecosystem. Software written in Rust has properties that neither C++ nor Carbon have. When you need to call other languages from Rust, RPCs are a good option. Rust is also good for using APIs implemented in a different language in-process, when the cost of maintaining the FFI boundary is reasonable.

  5. #5
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Développeur
    Inscrit en
    Juillet 2013
    Messages
    1 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 1 424
    Points : 8 713
    Points
    8 713
    Billets dans le blog
    43
    Par défaut
    Plutôt sceptique après un premier survol de l'article, un nième langage de plus, je commence à être convaincu, ou en tout cas davantage ouverts aux arguments avancés par l'équipe de ce projet Carbon.

    Si cela peut aider à migrer les grosses bases de code écrites en C++ vers une syntaxe plus lisible et proche des nouveaux langages tout en garantissant les performances et l'interopérabilité bi-directionnelle avec le C++, ça peut être une solution intéressante.

    Après, il est dommage que la syntaxe de Carbon est tout de même bien différente du C++ et n'est pas un sur-ensemble de ce dernier comme peut l'être TypeScript envers JavaScript, exemple qui est cité mais un peu abusivement je trouve.

    Pourquoi pas en tout cas. Attendons de voir.

  6. #6
    Membre émérite Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    Mai 2007
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2007
    Messages : 1 047
    Points : 2 251
    Points
    2 251
    Par défaut
    Je suis d'accord avec le constat sur l'état du C++. Les décisions prises sont discutables sur de nombreux points. Un super article ici qui compare le move C++ et Rust et pourquoi C++ n'est pas fait pour ça!
    Jason Turner a fait une vidéo intéressante sur le sujet de l'ABI C++ et qu'il fallait la casser pour sauver le C++.
    C'est très intéressant et je suis entièrement d'accord avec ça.
    Maintenant faire un nouveau langage en disant uniquement que c'est fait pour être brancher avec le C++ je ne vois pas l'intérêt... Pour avoir un gestionnaire de paquets? une nouvelle syntaxe?
    C'est bien dans l'idée mais dans les faits, il existe déjà Conan, certes c'est pas terrible... Mais est-ce que un gestionnaire de paquets justifie à lui seul un nouveau langage? Non je ne pense pas.

    De plus, une fois que Carbon est branché au C++. Qui va maintenir la partie C++ et la partie Carbon? Un mouton à 5 pattes qui connait les 2? Ou embaucher 2 programmeurs et doubler les couts de maintenance? Migrer dans ce cas?
    Si la solution est une migration petit à petit... Rust peut le faire, brique par brique, réécrire, fournir une interface C et C++ peut l'utiliser.

    D'un point de vue financier, ressource humaine et sur le long terme je ne vois aucun intérêt à ce langage comparé à l'existant.

  7. #7
    Membre éclairé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Juin 2008
    Messages
    522
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Chercheur en informatique

    Informations forums :
    Inscription : Juin 2008
    Messages : 522
    Points : 725
    Points
    725
    Par défaut
    Bof.
    Première remarque, je n'aime pas la syntaxe . Mais bon passons.
    Je n'ai pas envie de changer pour carbone parce que j'aime le c++. On n'est pas obligé de connaitre tout le c++ pour commencer à l'utiliser.
    J'aime le fait d'avoir un fichier header pour référencer les classes/fonctions de manière compacte.
    J'aime le fait d'avoir le contrôle en c++. Je peux créer ma structure de donnée qui utilise des pointeurs nus et est efficace pour mes besoins. Et je peux utiliser des pointeurs intelligents quand je ne veux pas me casser la tête.

    Mais ouais, le c++ n'est pas sûr pour le novice. On peut faire n'importe quoi avec les pointeurs ou autre. Alors oui, on peut créer un langage pour virer tout potentiel problème de sécurité. Mais on va perdre en performance. Et c'est ainsi qu'on se retrouve avec des programmes qui consomment beaucoup trop pour ce qu'ils font.

    Vous voulez améliorer le c++, j'ai des pistes sans créer un nouveau langage :
    Améliorer la compilation des templates.
    Changez l'ABI si ça vous chante.

    La stl ne fait pas partie du langage, mais l'enrichir est une bonne chose

  8. #8
    Membre émérite Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    Mai 2007
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2007
    Messages : 1 047
    Points : 2 251
    Points
    2 251
    Par défaut
    Citation Envoyé par raphchar Voir le message
    J'aime le fait d'avoir un fichier header pour référencer les classes/fonctions de manière compacte.
    Et le fait qu'il soit recompilé pour CHAQUE translation unit aussi? Que l'on dois jouer avec les namespaces et les collisions de noms? Et donc qu'on se retrouve avec des préfixes dans les noms pour comblé un problème du langage?

    Citation Envoyé par raphchar Voir le message
    J'aime le fait d'avoir le contrôle en c++. Je peux créer ma structure de donnée qui utilise des pointeurs nus et est efficace pour mes besoins. Et je peux utiliser des pointeurs intelligents quand je ne veux pas me casser la tête.
    Et le mainteneur ou collègue qui passe derrière dois se plonger dans la tête de l'ancien programmeur? C'est pas une vision égoïste du travaille? "Moi je comprends ce que j'ai fais c'est pas compliqué, ils sont nulles les autres si il arrive pas a passer derrière".
    Après plusieurs années à faire du C++, mon principal sujet quand je code c'est "comment protégés mon code", "comment le rendre maintenable sans effort" sans ajouter de commentaire partout en disant "Attention c'est super compliqué".

    Citation Envoyé par raphchar Voir le message
    Mais ouais, le c++ n'est pas sûr pour le novice. On peut faire n'importe quoi avec les pointeurs ou autre.
    Il n'est sûr pour personne, et le novice pense toujours être un dieu en C++ jusqu’à ce qu'il se plante et généralement c'est dans la semaine après son embauche...

    Citation Envoyé par raphchar Voir le message
    Alors oui, on peut créer un langage pour virer tout potentiel problème de sécurité. Mais on va perdre en performance. Et c'est ainsi qu'on se retrouve avec des programmes qui consomment beaucoup trop pour ce qu'ils font.
    Renseigne toi avant de dire ça. Rust est plus rapide que C++ sur de nombreux points ET apporte de la sécurité. La contrepartie n'est pas la performance, c'est plus d'effort de la part du programmeur pour penser correctement son application en terme de design, architecture et utilisation mémoire.
    D'autres aspect rentre en compte, comme l'aliasing de pointeur.

    Citation Envoyé par raphchar Voir le message
    Vous voulez améliorer le c++, j'ai des pistes sans créer un nouveau langage :
    Améliorer la compilation des templates.
    Changez l'ABI si ça vous chante.
    Je t'invite à leur proposer tes solutions = > https://isocpp.org/std/meetings-and-...s-and-mailings

    Citation Envoyé par raphchar Voir le message
    La stl ne fait pas partie du langage, mais l'enrichir est une bonne chose
    Ah bon? sur de sur? alors où placer std::initializer_list? Comment faire std::vector<int> v = {1,2,3}; sans ça? c'est pourtant dans la std... et l'implémentation dépend de la librairie standard qui est fortement lié au compilateur.
    Et ou placer std::construct_at qui est le seul autorisé à construire un objet à un emplacement mémoire spécifique dans une évaluation constante (aka constexpr)?

    Le C++ est coincé, il se débloque en ajoutant un peu plus de flou et de complexité partout mais ça ne fait que grossir la complexité et au final le ralentir dans certains cas.
    Un peu comme les instructions x86 des processeurs Intel ou AMD qui sont toujours ajoutés, jamais retiré, jamais modifié. Résultat... plus de 1300 instructions dans les CPU X86 contre ~40 pou RISC-V 32bits et ~500 pour ARM 32 bits... Et pour faire la meme chose.

  9. #9
    Membre éclairé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Juin 2008
    Messages
    522
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Chercheur en informatique

    Informations forums :
    Inscription : Juin 2008
    Messages : 522
    Points : 725
    Points
    725
    Par défaut
    Citation Envoyé par Astraya Voir le message
    Et le fait qu'il soit recompilé pour CHAQUE translation unit aussi? Que l'on dois jouer avec les namespaces et les collisions de noms? Et donc qu'on se retrouve avec des préfixes dans les noms pour comblé un problème du langage?
    C'est vrai pour les templates, mais une déclaration n'est pas compilée. Donc je l'accorde, il faudrait améliorer la compilation des templates, mais sans template, un header ne devrait pas être compilé.
    Je ne vois pas en quoi les collisions de noms seraient spécifiques au c++.

    Citation Envoyé par Astraya Voir le message
    Et le mainteneur ou collègue qui passe derrière dois se plonger dans la tête de l'ancien programmeur? C'est pas une vision égoïste du travaille? "Moi je comprends ce que j'ai fais c'est pas compliqué, ils sont nulles les autres si il arrive pas a passer derrière".
    Je vais commencer par clarifier un point : quand je parle de structure de donnée, je parle d'un objet bien défini, qui n'a pas vocation à être modifié (Un code contient à priori très peu de structures de données). Donc, en théorie, si une structure de donnée est bien faite, elle devrait être auto-suffisante, et la cuisine interne n'est pas le problème de l'utilisateur, seule l'interface compte. Maintenant, si le travail est bien fait, un document explique le fonctionnement de la structure parce qu'il n'est pas forcément trivial. Oui, il va falloir se plonger dans la tête de l'ancien programmeur en lisant la doc, parce qu'il s'est cassé la tête à faire une structure qui fonctionne bien et qui est efficace. Je ne vois rien d'égoïste là-dedans. (À ne pas confondre avec, les variables n'ont pas des noms explicites, pas de documentation)

    Citation Envoyé par Astraya Voir le message
    Après plusieurs années à faire du C++, mon principal sujet quand je code c'est "comment protégés mon code", "comment le rendre maintenable sans effort" sans ajouter de commentaire partout en disant "Attention c'est super compliqué".
    Oui, mais ça rejoint mon point précédent, une structure de donnée est auto-suffisante, donc pour le reste qui est susceptible d'être modifié fréquemment, je suis d'accord qu'on va utiliser des précautions.

    Citation Envoyé par Astraya Voir le message
    Il n'est sûr pour personne, et le novice pense toujours être un dieu en C++ jusqu’à ce qu'il se plante et généralement c'est dans la semaine après son embauche...
    D'accord, c'est pour cela qu'on n'accepte pas n'importe qui sur un projet C++. C++ n'est pas fait pour faire du prototypage et requiert une réflexion en amont. C'est pour cela qu'il y a d'autres langages aussi.
    Je n'ai fait qu'expliquer pourquoi, moi, j'aime le c++. Je n'attends pas des autres qu'ils adorent le c++.


    Citation Envoyé par Astraya Voir le message
    Renseigne toi avant de dire ça. Rust est plus rapide que C++ sur de nombreux points ET apporte de la sécurité. La contrepartie n'est pas la performance, c'est plus d'effort de la part du programmeur pour penser correctement son application en terme de design, architecture et utilisation mémoire.
    D'autres aspect rentre en compte, comme l'aliasing de pointeur.
    Okay, je ne connais pas Rust.


    Citation Envoyé par Astraya Voir le message
    Je t'invite à leur proposer tes solutions = > https://isocpp.org/std/meetings-and-participation/papers-and-mailings
    Je suis sûr que ces personnes sont au courant de ces problèmes, et ont sans doute bien plus de compétences en compilation pour trouver des solutions.

  10. #10
    Membre expert
    Profil pro
    undef
    Inscrit en
    Février 2013
    Messages
    1 001
    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 001
    Points : 3 658
    Points
    3 658
    Par défaut
    C'est la mode du moment de tout "révolutionner" avec des var et de fn, et pourquoi pas aussi des begin et des end... Mais au final, l'original restera dominant et ces forks vulgaires péricliteront avec leurs utilisateurs.

  11. #11
    Membre actif
    Femme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Décembre 2017
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 32
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : Décembre 2017
    Messages : 59
    Points : 281
    Points
    281
    Par défaut
    "Les pointeurs sont pris en charge mais pas l'arithmétique des pointeurs"

    Non mais avec ça et le changement de syntaxe c'est un autre langage là, les références au C++ c'est juste du pipeau marketing ?

  12. #12
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 676
    Points : 188 686
    Points
    188 686
    Par défaut
    Citation Envoyé par lsbkf Voir le message
    "Les pointeurs sont pris en charge mais pas l'arithmétique des pointeurs"

    Non mais avec ça et le changement de syntaxe c'est un autre langage là, les références au C++ c'est juste du pipeau marketing ?
    L'idée est plutôt de retirer de C++ des éléments obsolètes de C qui mènent à des problèmes de sécurité, tout en ayant à sa disposition des constructions équivalentes mais plus sûres. Ainsi, avec Carbon, il n'est normalement plus possible d'avoir un pointeur qui ne pointe sur rien : si on veut cette possibilité de ne pointer sur rien, il faut le rendre explicite, via Optional(T*).

    Pour l'arithmétique, est-ce quelque chose de véritablement plus utile que néfaste ? Les concepteurs de Carbon ont décidé que les problèmes de sécurité qui en découlaient étaient plus importants : l'utilité principale de l'arithmétique de pointeur, c'est de pointer vers un élément dans un tableau qui n'est pas le premier, d'où l'objet Slice (équivalent de std::span en C++20), qui est une bien meilleure solution (voir https://stackoverflow.com/a/45723820, par exemple) et pas plus chère en temps de calcul (après optimisation par le compilateur).

  13. #13
    Membre habitué
    Profil pro
    Inscrit en
    Avril 2009
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2009
    Messages : 35
    Points : 134
    Points
    134
    Par défaut
    Citation Envoyé par raphchar Voir le message
    La stl ne fait pas partie du langage, mais l'enrichir est une bonne chose
    Sisi, la STL figure dans la norme ISO du langage, son API et les contrats avec dès fois des contraintes d'implémentation. Tout est publié dans le même fichier de norme : core langage + STL.

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

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

    Informations forums :
    Inscription : Novembre 2003
    Messages : 866
    Points : 3 697
    Points
    3 697
    Par défaut
    Citation Envoyé par raphchar Voir le message
    Je ne vois pas en quoi les collisions de noms seraient spécifiques au c++.
    Je pratique plus le c++, mais de ce que je sais, il "suffit" d'utiliser des namespaces dans chaque source pour éviter le problème. Les choses deviennent plus compliquées si on inclue des sources ou des binaires qui ne l'ont pas fait...
    En python le problème n'existe pas avec le système des modules. Chaque module (ou fichier) a son propre espace de nommage par défaut, et on peut changer ce nom à l'importation s'il ne nous plait pas.
    Je suppose que ce problème a de même été résolu dans les divers langages modernes.

    Code Python : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    import tkinter.messagebox as msg # importation du module externe binaire dans un espace arbitraire "msg" par flemme d'écrire plus de 3 caractères
    msg.showinfo("coucou","le monde") #appel de la méthode externe par la syntaxe objet

  15. #15
    Membre émérite Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    Mai 2007
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2007
    Messages : 1 047
    Points : 2 251
    Points
    2 251
    Par défaut
    Citation Envoyé par dourouc05 Voir le message
    L'idée est plutôt de retirer de C++ des éléments obsolètes de C qui mènent à des problèmes de sécurité, tout en ayant à sa disposition des constructions équivalentes mais plus sûres. Ainsi, avec Carbon, il n'est normalement plus possible d'avoir un pointeur qui ne pointe sur rien : si on veut cette possibilité de ne pointer sur rien, il faut le rendre explicite, via Optional(T*).

    Pour l'arithmétique, est-ce quelque chose de véritablement plus utile que néfaste ? Les concepteurs de Carbon ont décidé que les problèmes de sécurité qui en découlaient étaient plus importants : l'utilité principale de l'arithmétique de pointeur, c'est de pointer vers un élément dans un tableau qui n'est pas le premier, d'où l'objet Slice (équivalent de std::span en C++20), qui est une bien meilleure solution (voir https://stackoverflow.com/a/45723820, par exemple) et pas plus chère en temps de calcul (après optimisation par le compilateur).
    Sur ce point justement je suis toujours étonné que le std::span soit un ensemble pointeur + taille plutôt que pointeur + pointeur de fin en interne.
    Cela veux dire que à chaque fois que l'on veut faire une boucle, il faut calculer le pointeur de fin. C'est le principe même des itérateurs et des ranges de pouvoir faire des boucles while(ptr < ptr_end). Je trouve ce choix en contradiction avec le reste de la STL.

    EDIT: En faite, ce n'est pas juste pour représentation du collection continue en mémoire... Au temps pour moi.

  16. #16
    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 Pierre Louis Chevalier Voir le message
    Très bon article

    C++ est devenu clairement une usine à gaz compliquée et incompréhensible sauf pour quelques experts.
    La syntaxe de Carbon semble ressembler pas mal à Rust, comment un tel projet pourrais t'il se positionner par exemple par rapport à C++, D et Rust ?
    Simple question. Pourquoi Objective C n'est pas inclus dans ton analyse?

  17. #17
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    Août 2008
    Messages
    26 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2008
    Messages : 26 676
    Points : 188 686
    Points
    188 686
    Par défaut
    Probablement parce que Objective-C n'a pas vraiment de futur (contrairement au C, au C++, etc.) ? Il est plus ou moins limité aux plateformes Apple et est en cours de remplacement par Swift, qui est lui en développement plus actif.

  18. #18
    Membre éprouvé
    Homme Profil pro
    Administrateur Systèmes, Clouds et Réseaux /CAO/DAO/Ingénierie Electrotechnique
    Inscrit en
    Décembre 2014
    Messages
    454
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Administrateur Systèmes, Clouds et Réseaux /CAO/DAO/Ingénierie Electrotechnique

    Informations forums :
    Inscription : Décembre 2014
    Messages : 454
    Points : 998
    Points
    998
    Par défaut
    Est ce que la perte de l'héritage multiple ne va pas poser problème ?

  19. #19
    Membre actif
    Femme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Décembre 2017
    Messages
    59
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 32
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : Décembre 2017
    Messages : 59
    Points : 281
    Points
    281
    Par défaut
    Citation Envoyé par dourouc05 Voir le message
    L'idée est plutôt de retirer de C++ des éléments obsolètes de C qui mènent à des problèmes de sécurité, tout en ayant à sa disposition des constructions équivalentes mais plus sûres. Ainsi, avec Carbon, il n'est normalement plus possible d'avoir un pointeur qui ne pointe sur rien : si on veut cette possibilité de ne pointer sur rien, il faut le rendre explicite, via Optional(T*).

    Pour l'arithmétique, est-ce quelque chose de véritablement plus utile que néfaste ? Les concepteurs de Carbon ont décidé que les problèmes de sécurité qui en découlaient étaient plus importants : l'utilité principale de l'arithmétique de pointeur, c'est de pointer vers un élément dans un tableau qui n'est pas le premier, d'où l'objet Slice (équivalent de std::span en C++20), qui est une bien meilleure solution (voir https://stackoverflow.com/a/45723820, par exemple) et pas plus chère en temps de calcul (après optimisation par le compilateur).
    Je comprend les arguments qui poussent à créer un nouveau langage, mais ce qui me chiffonne dans l'affaire c'est qu'on parle de successeur à C++ et pas de "nouveau langage" qui s'en inspire au même titre que Rust ou Go. Tu peux argumenter comme tu veux si c'est mieux ou pas, c'est pas la question, la syntaxe est différente, les idiomes sont différents, ce n'est pas un candidat de remplacement du C++ et je maintiens que c'est une lubie marketing pour tenter de maintenir l'illusion que ce n'est pas juste un énième langage de programmation.

  20. #20
    Chroniqueur Actualités
    Avatar de Bruno
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Mai 2019
    Messages
    1 928
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2019
    Messages : 1 928
    Points : 37 500
    Points
    37 500
    Par défaut Carbon, le nouveau langage de programmation lancé par Google peut-il remplacer le C++ mieux que Rust ?
    Carbon, le nouveau langage de programmation lancé par Google peut-il remplacer le C++ mieux que Rust ?
    Carbon est destiné aux développeurs qui disposent déjà de bases de code importantes en C++

    Frustrés par la lenteur de l'évolution du C++, les ingénieurs de Google ont lancé un nouveau langage de programmation open source « expérimental », appelé Carbon, qui pourrait succéder au vénérable C++ qui, pour certains, serait vieillissant. « Il est difficile pour les grands projets de convertir les bases du code C++ existantes en Rust », affirment les ingénieurs de Google.

    Chandler Carruth, ingénieur logiciel principal de Google, a présenté Carbon cette semaine lors de la conférence C++ CPP Northà Toronto. Selon certains observateurs, « la nouvelle version de Carbon devrait être interopérable avec le populaire code C++, mais pour les utilisateurs qui souhaitent passer à la vitesse supérieure, la migration devrait être assez facile. » Pour ceux qui ne sont pas sûrs de vouloir changer complètement, Carruth a expliqué plus en détail certaines des raisons pour lesquelles Carbon devrait être considéré comme un successeur puissant du langage C++, notamment une grammaire plus simple et des importations d'API plus fluides.

    Les ingénieurs de Google construisent déjà des outils pour traduire C++ en ce nouveau langage. Bien que Carbon ait commencé comme un projet interne de Google, l'équipe de développement souhaite réduire les contributions de Google, ou de toute autre entreprise, à moins de 50 % d'ici la fin de l'année. Les concepteurs veulent publier une version de base 0.1 d'ici la fin de l'année. Carbon sera construit sur une base de principes de programmation modernes, notamment un système générique, qui supprimerait la nécessité de vérifier et revérifier le code pour chaque instanciation.

    La sécurité de la mémoire est une autre fonctionnalité indispensable qui fait défaut au C++. Les bogues d'accès à la mémoire sont l'une des principales causes d'exploitation de la sécurité. Les concepteurs de Carbon chercheront des moyens de mieux suivre les états non initialisés, de concevoir des API et des idiomes qui prennent en charge les vérifications dynamiques des limites et de créer un mode de construction de débogage par défaut complet. Les concepteurs prévoient de construire un sous-ensemble sûr de Carbon. Selon la documentation, le langage supportera :

    • développement rapide et évolutif ;
    • les logiciels à performances critiques ;
    • l'évolution des logiciels et du langage ;
    • un code facile à lire, à comprendre et à écrire ;
    • des mécanismes de sécurité et de test pratiques ;
    • plateformes OS modernes, architectures matérielles et environnements ;
    • interopérabilité avec le code C++ existant et migration à partir de celui-ci.
    L'équipe de développement s'attachera également à créer un gestionnaire de paquets intégré, ce qui fait cruellement défaut au C++.

    Voici un code C++ traduit en Carbon. Tout d'abord, le code C++ :

    Nom : cod.png
Affichages : 157930
Taille : 43,3 Ko

    Voici la même fonction écrite en carbone :

    Nom : cod2.png
Affichages : 26273
Taille : 42,9 Ko

    Carbon pourra mieux remplacer le C++ que Rust ?

    Rust est un langage de programmation compilé multiparadigme, conçu par Graydon Hore alors employé chez Mozilla Research, avec la contribution du créateur de JavaScript Brendan Eich. Utilisé par plusieurs grandes entreprises et par de nombreux développeurs dans le monde, Rust est devenu le langage de base pour certaines des fonctionnalités fondamentales du navigateur Firefox et de son moteur Gecko, ainsi que pour le moteur Servo de Mozilla.

    Microsoft

    Microsoft fait partie des membres fondateurs de la fondation Rust et dit vouloir collaborer avec la communauté pour continuer à améliorer le langage. L’entreprise promet de fournir des outils, une bibliothèque pour le langage et des ressources d’apprentissage.

    Selon Nell Shamrell Harrington, Ingénieur logiciel chez Microsoft et directeur du conseil d'administration de la Fondation Rust, les logiciels et les langages open source sont d'une importance capitale pour son entreprise et pour l'ensemble de l'industrie technologique.

    En outre, Microsoft a récemment formé une équipe Rust pour contribuer aux efforts d'ingénierie de l'écosystème du langage. L’entreprise spécialisée dans le développement de logiciel prévoit de travailler avec la communauté Rust sur le compilateur, les outils de base, la documentation et bien plus.

    Google

    Dans une annonce faite sur son blog ce 8 février, Google dit être ravie d’avoir rejoint la fondation Rust et se dispose pour travailler sur des questions comme l'interopérabilité avec C++. « S'appuyant sur les investissements de longue date de Google dans le C/C++ et les compilateurs et chaînes d'outils, nous sommes ravis d'annoncer notre adhésion à la fondation Rust », a annoncé Google sur son blog. « Nous sommes impatients de participer davantage à la communauté Rust, en particulier de travailler dans l'ensemble sur des questions importantes, notamment l'interopérabilité avec C++, la coordination des examens de sécurité, la réduction des coûts des mises à jour et de continuer à accroître nos investissements dans les projets Rust existants », a ajouté l'entreprise.

    Selon Google, les défauts de sécurité de la mémoire menacent fréquemment la sécurité des appareils, en particulier pour les applications et les systèmes d'exploitation. Par exemple, sur le système d'exploitation mobile Android, Google dit avoir constaté que plus de la moitié des vulnérabilités de sécurité traitées en 2019 résultaient de bogues de sécurité de la mémoire. Et ce, malgré les efforts considérables déployés par l'entreprise et d'autres contributeurs au projet Open Source Android, pour investir ou inventer diverses technologies, notamment l'AddressSanitizer, des allocateurs de mémoire améliorés et de nombreux fuzzers et autres outils de vérification du code.

    Amazon Web Service (AWS)

    Amazon a pour sa part clairement reconnu qu’elle est principale bénéficiaire du langage Rust et des travaux de sa communauté. L'entreprise se dit heureuse de pouvoir participer aux futurs succès de Rust. Selon Shane Miller, responsable de l'équipe Rust chez AWS et également professeur d'université, la raison pour laquelle les ingénieurs choisissent Rust pour créer des services est que cela leur permet d'offrir aux clients des expériences qui répondent à leurs exigences de qualité et de sécurité beaucoup plus rapidement et à moindre coût.

    AWS utilise Rust pour fournir des services tels qu'Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon CloudFront, et plus encore. Récemment, l’entreprise a lancé Bottlerocket, un système d'exploitation basé sur Linux et écrit en Rust. L’équipe Amazon EC2 utilise le langage Rust pour développer les nouveaux composants du système Nitro d'AWS, y compris les applications sensibles, telles que les enclaves Nitro. Pour Shane Mille, en tant que membre fondateur de la Fondation Rust, l’entreprise se consacrera à l’un des objectifs de la fondation Rust qui consiste à donner aux responsables de Rust les moyens de faire joyeusement leur travail.

    Pourquoi ne pas utiliser Rust ?

    Longtemps, le langage de prédilection pour la création d'applications critiques en termes de performances, le C++ souffre d'un certain nombre de problèmes qui gênent les développeurs modernes, a expliqué Carruth. Il a accumulé des décennies de dettes techniques, entraînant avec lui de nombreuses pratiques dépassées qui faisaient partie du prédécesseur du langage, le C. Les gardiens du C++ donnent la priorité à la rétrocompatibilité, afin de continuer à soutenir des projets largement utilisés tels que Linux et son écosystème de gestion des paquets, explique Carruth.

    L'évolution du langage est également entravée par un processus de comité bureaucratique, orienté vers la normalisation plutôt que la conception. Ce qui peut rendre difficile l'ajout de nouvelles fonctionnalités. Le C++ a largement un processus de développement séquestré, dans lequel un comité restreint prend les décisions importantes, dans un processus en cascade qui peut prendre des années.

    La comparaison entre Rust et C++ reste un sujet d'actualité, car ces langages de programmation sont en concurrence dans des domaines comme le développement système et l'embarqué. Du point de vue technique, les deux langages partagent de nombreuses similitudes dans leur syntaxe. Cependant, Rust et C++ présentent des différences significatives.

    C++ est un langage de programmation compilé permettant la programmation sous de multiples paradigmes, dont la programmation procédurale, la programmation orientée objet et la programmation générique. Ses bonnes performances, et sa compatibilité avec le C en font un des langages de programmation les plus utilisés dans les applications où la performance est critique.

    En outre, c'est un langage polyvalent, ce qui signifie qu'il peut être utilisé dans presque tous les cas. Cependant, en raison de ses règles syntaxiques complexes et de son utilisation globalement difficile, il est principalement dominant dans les applications qui nécessitent une grande vitesse, la simultanéité et un examen plus approfondi du fonctionnement du matériel.

    Toutefois, la sécurité de la mémoire est une autre fonctionnalité indispensable qui fait défaut au C++. Les bogues d'accès à la mémoire sont l'une des principales causes d'exploitation de la sécurité. Les concepteurs de Carbon chercheront des moyens de mieux suivre les états non initialisés, de concevoir des API et des idiomes qui prennent en charge les vérifications dynamiques des limites et de créer un mode de construction de débogage par défaut complet.

    Pour certains analystes, le C++ possède des bases plus solides en ce qui concerne la communauté et les informations générales sur ses principes. En outre, par rapport au C++, Rust est un nouveau venu dans le monde de la programmation, et de nombreux développeurs hésitent à s'y intéresser.

    La fin du C++ ?

    De même que Microsoft a créé Typescript pour mettre à jour JavaScript et que Kotlin a été créé pour pallier les faiblesses de Java, Carbon pourrait servir de langage successeur à C++, un langage qui offre aux développeurs un point de départ facile vers un langage plus récent qui prend en compte les concepts de développement modernes tels que la sécurité de la mémoire et les génériques.

    « La structure du comité est conçue pour assurer la représentation des nations et des entreprises, plutôt que de construire une équipe et une communauté inclusive et accueillante d'experts et de personnes contribuant activement au langage », écrit Carruth. « L'accès au comité et à la norme est restreint et coûteux, la présence est nécessaire pour avoir une voix, et les décisions sont prises par des votes des personnes présentes. »


    Carruth veut construire Carbon par un environnement plus ouvert et dirigé par la communauté. Le projet sera maintenu sur GitHub, et discuté sur Discord. Bien que Carbon ait commencé comme un projet interne de Google, l'équipe de développement souhaite réduire les contributions de Google, ou de toute autre entreprise, à moins de 50 % d'ici la fin de l'année. Elle souhaite finalement confier le projet à une fondation logicielle indépendante, où son développement sera dirigé par des bénévoles.

    Dans sa présentation à CPP North, Carruth a conseillé à ceux qui utilisent Rust de continuer à l'utiliser. Carbon est destiné aux développeurs qui disposent déjà de bases de code importantes en C++, difficiles à convertir en Rust. Carbon est spécifiquement ce que Carruth appelle un « langage successeur », qui est construit au-dessus d'un écosystème déjà existant, C++ dans ce cas.

    « Il est conçu autour de l'interopérabilité avec C++ ainsi que de l'adoption et de la migration à grande échelle pour les bases de code et les développeurs C++ existants », expliquent les concepteurs. Cela signifie que le langage doit être aussi performant que C++, qu'il doit offrir une interopérabilité transparente et bidirectionnelle avec C++.

    Source : Google

    Et vous ?

    Quel est votre avis sur le sujet ?

    Google essaie-t-il de tuer le C++ ?

    Pourquoi Carbon plutôt que le Rust pour améliorer les problèmes de sécurité et de mémoire en C++ ?

    Selon vous, la fin du C++ est-elle envisageable ?

    Voir aussi :

    Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

    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 et mise sur l'interopérabilité comme base de travail

    C3 : un langage de programmation système basé sur le C, permet un accès sécurisé aux tableaux, les conteneurs de haut niveau et manipulation des chaînes de caractères

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