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 :

Carbon va-t-il remplacer le C++ ? Le projet Carbon explore une direction future possible pour le 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 695
    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 695
    Points : 1 417
    Points
    1 417
    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 695
    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 695
    Points : 1 417
    Points
    1 417
    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
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 482
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 482
    Points : 6 149
    Points
    6 149
    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
    610
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : Septembre 2014
    Messages : 610
    Points : 1 458
    Points
    1 458
    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
    831
    Détails du profil
    Informations personnelles :
    Localisation : France

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

    Informations forums :
    Inscription : Novembre 2003
    Messages : 831
    Points : 3 529
    Points
    3 529
    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 : 101
    Points
    101
    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
    1 996
    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 : 1 996
    Points : 54 793
    Points
    54 793
    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 695
    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 695
    Points : 1 417
    Points
    1 417
    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.

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