1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    février 2017
    Messages
    583
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 583
    Points : 19 832
    Points
    19 832

    Par défaut Une université canadienne propose C-for-All

    Une université canadienne propose C-for-All
    Un projet open source d’extension du C ISO avec des fonctionnalités « modernes »

    Qui pour assurer la succession du langage C ? La question revient constamment au sein des communautés de développeurs. Par le passé, des noms de candidats ont fait l’objet de fuites ; depuis 2009 on évoque Go, un langage de programmation développé par Google et inspiré de C et Pascal. Mozilla Research aussi œuvre dans le cadre de cette mouvance et, depuis 2006, propose Rust, un langage qui permet de faire la programmation sous plusieurs paradigmes. Cette liste s’allonge avec C-for-All, une initiative conjointe du géant chinois Huawei et de l’université de Waterloo au Canada.


    Le langage C a encore de beaux jours devant lui. Référence faite à un sondage paru sur cette plateforme en janvier de cette année, quatre raisons permettent de soutenir cette affirmation. Primo, n’en déplaise à ses détracteurs, C est encore largement utilisé. Secundo, il sera toujours nécessaire d’être à même de faire « joujou » de façon aisée avec le hardware et pour des tâches de ce type, le langage C continue de faire partie des premiers choix. Tertio, le langage est reconnu pour l’efficacité de son code source. Enfin, le langage se prête bien aux tâches de développement d’applications multiplateformes, ce à quoi les férus font souvent référence en parlant de portabilité.

    Le langage C dispose d’un atout supplémentaire dans sa manche : il continue d’évoluer. C++ est né en 1983 pour répondre à ce besoin et connait des mises à jour régulières : C++11, C++14 puis C++17, des révisions qui ont respectivement vu le jour en 2011, 2014 et 2017. Il faudra désormais compter avec C-for-All dont l’université de Waterloo a publié la liste des extensions qui en font un C ISO qui continuera de traverser les âges.

    Nom : image C.png
Affichages : 7024
Taille : 4,2 Ko

    C-for-All propose la gestion des exceptions comme extension à l’ISO C. La fonctionnalité dérive d’une thèse de génie informatique de 2017.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    exception_t E {};                              // exception type
    void f(...) {
    	... throw E{}; ...                          // termination
    	... throwResume E{}; ...             // resumption
    }
    try {
    	f(...);
    } catch( E e ; boolean-predicate ) {                    // termination handler
    	// recover and continue
    } catchResume( E e ; boolean-predicate ) {      // resumption handler
    	// repair and return
    } finally {
    	// always executed
    }
    La surcharge de routines, d’opérateurs, de variables et de symboles est également à prendre en compte dans les extensions proposées par C-for-All. La fonctionnalité dérive des travaux d’une thèse de génie informatique de 1989.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    // selection based on type and number of parameters
    void f( void );                                // (1)
    void f( char );                               // (2)
    void f( int, double );                      // (3)
    f();                                                // select (1)
    f( 'a' );                                          // select (2)
    f( 3, 5.2 );                                    // select (3)
     
    // selection based on  type and number of returns
    char f( int );                                  // (1)
    double f( int );                              // (2)
    [ int, double ] f( int );                    // (3)
    char c = f( 3 );                              // select (1)
    double d = f( 4 );                          // select (2)
    [ int, double ] t = f( 5 );                 // select (3)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    int ++?( int op );                            // unary prefix increment
    int ?++( int op );                            // unary postfix increment
    int ?+?( int op1, int op2 );             // binary plus
    int&nbsp;?<=?( int op1, int op2 );           // binary less than
    int&nbsp;?=?( int * op1, int op2 );           // binary assignment
    int&nbsp;?+=?( int * op1, int op2 );         // binary plus-assignment
     
    struct S { int i, j; };
    S&nbsp;?+?( S op1, S op2 ) {                 // add two structures
    	return (S){ op1.i + op2.i, op1.j + op2.j };
    }
    S s1 = { 1, 2 }, s2 = { 2, 3 }, s3;
    s3 = s1 + s2;                                  // compute sum: s3 == { 2, 5 }
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    short int MAX = ...;   int MAX = ...;  double MAX = ...;
    short int s = MAX;    int i = MAX;    double d = MAX;   // select MAX based on left-hand type
    Cette liste d’extensions n’est pas exhaustive et intègre d’autres éléments dont on perçoit mal l’impact réel sur des problèmes auxquels les utilisateurs du langage C font face. Illustration avec les instructions fallthru et fallthrough qui, au regard du code, sont des équivalents de goto.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    choose ( ... ) {
      case 3:
    	if ( ... ) {
    		... fallthru;  // goto case 4
    	} else {
    		...
    	}
    	// implicit break
      case 4:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    choose ( ... ) {
      case 3:
    	... fallthrough common;
      case 4:
    	... fallthrough common;
      common: // below fallthrough at case level
    	...	 // common code for cases 3 and 4
    	// implicit break
      case 4:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    choose ( ... ) {
      case 3:
    	choose ( ... ) {
    	  case 4:
    		for ( ... ) {
    			... fallthru common; // multi-level transfer
    		}
    		...
    	}
    	...
      common: // below fallthrough at case-clause level
    Quoi qu’il en soit, C-for-All fait bien partie du paysage des nombreux remplaçants ou extensions du langage C. En génie logiciel, chaque projet impose de porter son choix sur un langage particulier en raison de l’existence de fonctionnalités que d’autres n’offriront pas. À chacun donc de juger et d’intégrer ce dernier à son flux de travail en fonction de la pertinence.

    Source

    uWaterloo

    Votre opinion

    Que pensez-vous de C-for-All ?

    Quelles sont d’après vous les extensions qui sont les bienvenues ?

    Quelles sont celles qui n’ont aucun impact sur la productivité ? Pourquoi ?

    Voir aussi

    Quel avenir pour le langage C ? Un développeur expérimenté fait ses adieux au langage et livre ses inquiétudes quant à son avenir
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre averti
    Profil pro
    Inscrit en
    septembre 2009
    Messages
    159
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2009
    Messages : 159
    Points : 395
    Points
    395

    Par défaut

    Ajouter des exceptions au langage C sans RAII, quelle bonne idée! Bonjour les crashs ou memory/ressources leak a tout va. Et le C est un des rares langages qu'il faut faire évoluer doucement. Pour moi le C est destiné aujourd'hui a des secteurs bien spécifiques ou sa simplicité apparente a plus de valeurs que sa productivité assez faible (en comparaison avec des langages de plus haut niveau). Bref non merci, laissez le C tel qu'il est.

  3. #3
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 215
    Points : 3 140
    Points
    3 140
    Billets dans le blog
    12

    Par défaut

    Je suis déçu des features proposés par C-for-All, je trouve les features d'import et de paradigme objet léger de C2 bien plus intéressants.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  4. #4
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2004
    Messages
    10 833
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : octobre 2004
    Messages : 10 833
    Points : 24 848
    Points
    24 848

    Par défaut

    Salut,

    Je crois que C doit, comme tout langage, évoluer ou risquer d'être de plus en plus "mis au rencart"...

    Mais je crois aussi que nous aurions tout à perdre à essayer de le faire évoluer trop vite, car c'est aussi un langage qui n'a aucun précédent. Et pour cause: il est plus ou moins reconnu comme... le père (ou l'aïeul) de tous les autres.

    De plus c'est aussi le langage (de troisième génération s'entend) qui propose à la base le niveau d'abstraction le plus bas: avec moins d'abstraction que C, on écrit en assembleur.

    Et le fait est que l'on aura toujours besoin d'un langage à très faible niveau d'abstraction, ne serait-ce que parce que l'informatique est (très) loin de se limiter aux PC de plus en plus puissants, équipés de windows ou de linux!!! L'informatique, c'est aussi tout un tas de "micro puces" que l'on peut programmer dans "une certaine mesure", mais qui n'ont pas la joie d'être soutenue par un système d'exploitation digne de ce nom, ou qui n'ont pas l'occasion d'attendre qu'une machine virtuelle ait pris le relais.

    Or, pour cette partie (certains parleront sans doute de niche) de l'informatique, sans le C (même si C++ peut -- dans une certaine mesure -- prendre le relais), on n'a plus rien, si ce n'est l'assembleur...

    Alors, nous pourrions envisager que "quelqu'un" développe un langage avec des caractéristiques fort semblable au C, en évitant (si possible) certains de ses affres, et que ce "quelqu'un" en fasse dont à l'ANSI ou à l'ISO. Peut-on rêver, ce langage *** pourrait *** être considéré --y compris par les développeurs C les plus intransigeants -- comme le digne successeur de C.

    A ceci près qu'il y a toute la base de code écrite en C qui est purement phénoménale, qu'il faudra sans doute encore maintenir pendant des années. Ce qui fait que, quel que soit la qualité de ce nouveau langage hypothétique, il risque malgré tout d'avoir du mal à se faire sa "place au soleil"
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  5. #5
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    6 918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 6 918
    Points : 18 402
    Points
    18 402

    Par défaut

    Attention aux &nbsp;


    Sinon, je détestes cette manie de vouloir réinventer la roue en permanence. Avoir 36 000 langages de programmation ne sert à rien.
    Pourquoi ne pas utiliser/partir de ce qui existe déjà ? Pourquoi ne pas utiliser directement C++ ?


    C'est comme pour générer de la documentation en JavaScript, on a 50 alternatives pour le faire, alors que Doxygen est utilisé pour les autres langages et marche très bien (et mieux que ces alternatives), au pire créer un plugin pour mieux gérer cela.

    C'est comme les entreprises qui veulent héberger elles-même leurs propres services pour des raisons de sécurité... qui refont leur propre trucs ou choisissent des services obsolètes qui ne seront au final pas utilisées...


    On déjà suffisamment de langages :
    • Python
    • C++
    • LaTeX
    • CSS
    • JSON
    • XML


    Rien qu'avec cela on pourrait couvrir 99,99% des usages.

    Regardez-moi ça, je parie que vous n'en connaissez même pas la grande majorité, et que la grande majorité est juste inutile.
    On dit "chiffrer" pas "crypter" !

    On dit "bibliothèque" pas "librairie" !

    Ma page DVP : http://neckara.developpez.com/

  6. #6
    Membre actif
    Profil pro
    retraité
    Inscrit en
    décembre 2010
    Messages
    128
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : retraité

    Informations forums :
    Inscription : décembre 2010
    Messages : 128
    Points : 267
    Points
    267

    Par défaut

    Bonjour,
    autant faire du C++ qui donne du code aussi rapide et léger que du C. Il suffit pour s'en convaincre de regarder des vidéos de conférences comparant les 2.
    Bonne fin de journée

  7. #7
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 665
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 665
    Points : 8 825
    Points
    8 825

    Par défaut

    Citation Envoyé par Patrick Ruiz Voir le message
    quatre raisons permettent de soutenir cette affirmation. Primo, n’en déplaise à ses détracteurs, C est encore largement utilisé. Secundo, il sera toujours nécessaire d’être à même de faire « joujou » de façon aisée avec le hardware et pour des tâches de ce type, le langage C continue de faire partie des premiers choix. Tertio, le langage est reconnu pour l’efficacité de son code source. Enfin, le langage se prête bien aux tâches de développement d’applications multiplateformes, ce à quoi les férus font souvent référence en parlant de portabilité.
    - Primo, En effet C est largement utilisé un peu partout dans l'industrie pour tout ce qui est du bas niveau, et c'est une référence dans le domaine universitaire a cause d'UNIX. C'est sa principale qualité comme sont plus gros défaut : il est utilisé dans des domaines très conservateurs, ce qui explique qu'il peine tant a évoluer.

    - Secundo et Tertio, Il est vrai que le C est très efficace et adapté au bas niveau, mais ça n'est pas le seul a pouvoir faire ça, il y en a d'autres qui sont tout autant capable comme le C++, le Nim ou le Rust par exemple.

    - Enfin en ce qui concerne la portabilité, il faut reconnaitre qu'il existe un compilateur C pour quasiment toutes les architectures de processeur existantes, et que aucun langage ne peut prétendre en faire autant.
    Mais si on regarde strictement du point de vue des spécificités du langage, le C est loin d'être ce qui ce fait de mieux. Sa norme est volontairement imprécise. Pour faire un programme C vraiment portable, il faut faire très attention a ce que l'on fait car beaucoup de chose vont réagir différemment en fonction de la plateforme. Si le C a pu être portable c'est surtout grâce a la norme POSIX et beaucoup d'huile de coude.

    Citation Envoyé par Patrick Ruiz Voir le message
    Cette liste d’extensions n’est pas exhaustive et intègre d’autres éléments dont on perçoit mal l’impact réel sur des problèmes auxquels les utilisateurs du langage C font face. Illustration avec les instructions fallthru et fallthrough qui, au regard du code, sont des équivalents de goto.
    Je suppose que le but de "fallthru", comme pour les blocs avec label, c'est justement de pouvoir traiter le goto, qui est connu comme pouvant être abusé en C, comme une fonctionnalité déprécié. Du coup il faut remplacer les cas ou son usage se justifie encore par des syntaxes spécifiques.

    Citation Envoyé par codec_abc Voir le message
    Ajouter des exceptions au langage C sans RAII, quelle bonne idée!
    L'article ne le précise pas, mais il y a aussi des constructeurs/destructeur, dont potentiellement moyen de faire de la RAII, avec ce langage.

    Citation Envoyé par Gugelhupf Voir le message
    Je suis déçu des features proposés par C-for-All, je trouve les features d'import et de paradigme objet léger de C2 bien plus intéressants.
    Pour moi C2 était bâtard, il est certes plus propre au niveau de ce qu'il propose, mais ça se faisait au dépend de la compatibilité avec le C. Et quitte a avoir une syntaxe incompatible autant aller voir du coté de Rust ou Nim qui proposent bien plus qu'une petite amélioration du C.

    Pour le coup C-for-All réussi a garder une meilleure compatibilité avec la syntaxe C actuelle que ce que proposait C2. Même si certains choix ne ne convainquent pas vraiment, surtout au niveau de la syntaxe (on sent la contrainte de l'héritage du C), il y a des fonctionnalité intéressantes.

    Citation Envoyé par koala01 Voir le message
    Or, pour cette partie (certains parleront sans doute de niche) de l'informatique, sans le C (même si C++ peut -- dans une certaine mesure -- prendre le relais), on n'a plus rien, si ce n'est l'assembleur...
    Non, il y a d'autre langages qui sont tout a fait capable d'en faire autant comme le C++, Nim ou Rust par exemple.

    Citation Envoyé par koala01 Voir le message
    A ceci près qu'il y a toute la base de code écrite en C qui est purement phénoménale, qu'il faudra sans doute encore maintenir pendant des années. Ce qui fait que, quel que soit la qualité de ce nouveau langage hypothétique, il risque malgré tout d'avoir du mal à se faire sa "place au soleil"
    C'est fou cette vision Highlander ("il ne peut en rester qu'un") des langages informatiques. A peu près tous les langages savent s'interfacer avec le C, particulièrement les langages bas niveau comme le C++/Nim/Rust. Il y a moyen d'introduire de nouveaux langages bas niveau sans avoir a tout réécrire.

  8. #8
    Membre habitué
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    octobre 2011
    Messages
    85
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

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

    Informations forums :
    Inscription : octobre 2011
    Messages : 85
    Points : 128
    Points
    128

    Par défaut

    Après les hypothétiques remplaçants du C, l'hypothétique dénature du C (peut-être dans l'espoir d'éclipser le C pour mettre en avant un hypothétique remplaçant ?)...

    "Leave C language alone "

  9. #9
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2004
    Messages
    10 833
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : octobre 2004
    Messages : 10 833
    Points : 24 848
    Points
    24 848

    Par défaut

    Citation Envoyé par Neckara Voir le message
    Regardez-moi ça, je parie que vous n'en connaissez même pas la grande majorité, et que la grande majorité est juste inutile.
    Peut être, justement, parce que nous n'en connaissons pas la grande majorité...

    Il se peut donc, effectivement, que certains (bon, peut-être seulement un ou deux, ce qui serait déjà énorme ) puissent prendre le relais du C...

    Mais, à part C++ (qui peut s'approcher énormément des cas d'utilisation de C, mais qui a quand même aussi un bon nombre d’incompatibilités avec lui), aucun de ceux que tu as cités ne peut prendre la "niche" du C.

    Et, quand bien même, on dirait "merde" à la compatibilité -- ce qui pourrait à la fois faire le plus grand bien et le plus grand mal -- si on n'arrive pas avec un dossier béton qui démontre que l'on a pu faire avec un langage tout ce que C permet de faire, sans sacrifier les performances (car avec de meilleures, ca risque d'être dur ) mais avec moins de risques d'erreurs, moins de chausses trappes à gauche et à droite et (sans doute surtout) sans *** trop *** bousculer les habitudes des développeurs, j'ai bien peur que la sauce ne prenne jamais
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  10. #10
    Membre chevronné
    Homme Profil pro
    Consultant Ingenierie mécanique
    Inscrit en
    mars 2006
    Messages
    920
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Consultant Ingenierie mécanique
    Secteur : Transports

    Informations forums :
    Inscription : mars 2006
    Messages : 920
    Points : 1 994
    Points
    1 994

    Par défaut

    Citation Envoyé par Neckara Voir le message
    Attention aux &nbsp;


    Sinon, je détestes cette manie de vouloir réinventer la roue en permanence. Avoir 36 000 langages de programmation ne sert à rien.
    Pourquoi ne pas utiliser/partir de ce qui existe déjà ? Pourquoi ne pas utiliser directement C++ ?


    C'est comme pour générer de la documentation en JavaScript, on a 50 alternatives pour le faire, alors que Doxygen est utilisé pour les autres langages et marche très bien (et mieux que ces alternatives), au pire créer un plugin pour mieux gérer cela.

    C'est comme les entreprises qui veulent héberger elles-même leurs propres services pour des raisons de sécurité... qui refont leur propre trucs ou choisissent des services obsolètes qui ne seront au final pas utilisées...


    On déjà suffisamment de langages :
    • Python
    • C++
    • LaTeX
    • CSS
    • JSON
    • XML


    Rien qu'avec cela on pourrait couvrir 99,99% des usages.

    Regardez-moi ça, je parie que vous n'en connaissez même pas la grande majorité, et que la grande majorité est juste inutile.
    Python, c++ ok
    Latex, je sais pas
    mais css ? un simple langage descriptif rien a voir avec de la programmation
    Json, une simple structure de donnée
    Xml langage descriptif, comme le html, plus une structure de donné qu'un langage de programmation.

    rien a voir avec le c donc... mais je suppose que c'est voulu ?

  11. #11
    Membre émérite
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    667
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 667
    Points : 2 937
    Points
    2 937

    Par défaut

    Citation Envoyé par Neckara Voir le message
    Sinon, je détestes cette manie de vouloir réinventer la roue en permanence. Avoir 36 000 langages de programmation ne sert à rien.
    Pourquoi ne pas utiliser/partir de ce qui existe déjà ? Pourquoi ne pas utiliser directement C++ ?

    [...]

    On déjà suffisamment de langages :
    • Python
    • C++
    • LaTeX
    • CSS
    • JSON
    • XML


    Rien qu'avec cela on pourrait couvrir 99,99% des usages.
    Je suis d'accord pour dire qu'il y a trop de langages, mais ta liste est trop restreinte :
    • Python est accessible aux débutants et permet d'écrire du code concis, mais n'est pas performant. Cela conduit des chercheurs à coder deux fois la même chose : un prototype en Python puis un programme dans un langage plus performant, comme C++. On a donc besoin d'un langage avec les principaux avantages du Python, mais plus performant. Peut-être Julia.
    • C++ est riche et performant. Mais, même avec une telle richesse, il est plus compliqué qu'il ne devrait et contient plus de pièges qu'il ne devrait. En outre, il est lent à compiler, surtout s'il y a trop de code dans les fichiers d'entête, ce qui restreint l'utilisation des templates dans un gros projet. On a donc besoin d'un meilleur C++, beaucoup plus rapide à compiler, plus simple à apprendre et, tant qu'à faire, encore plus riche. Peut-être le langage D. D'ailleurs, je me demande si ce dernier peut aussi remplacer Julia.
    • Dans ta liste, je ne vois pas de langage qui supporte vraiment le paradigme fonctionnel comme Haskell. L'inconvénient de ce paradigme est qu'il est plus difficile à apprendre que la programmation orientée objet. Mais l'avantage est qu'il permet d'écrire du code beaucoup plus modulaire.


    De manière générale, les langages au sommet du classement TIOBE ne sont pas assez bons. On a besoin de mieux.

    Cela dit, les concepteurs de nouveaux langages ne devraient pas se contenter d'essayer de faire mieux que les langages au sommet du classement TIOBE. Ils devraient aussi, s'ils y arrivent, essayer de faire mieux que les langages moins connus qui ont du mal à s'imposer. Sinon, on augmente la liste des langages inutiles. Or, je pense que le C-for-All s'ajoute à cette liste.

  12. #12
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2004
    Messages
    10 833
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : octobre 2004
    Messages : 10 833
    Points : 24 848
    Points
    24 848

    Par défaut

    Citation Envoyé par Uther Voir le message
    C'est fou cette vision Highlander ("il ne peut en rester qu'un") des langages informatiques. A peu près tous les langages savent s'interfacer avec le C, particulièrement les langages bas niveau comme le C++/Nim/Rust. Il y a moyen d'introduire de nouveaux langages bas niveau sans avoir a tout réécrire.
    Oh, si seulement c'était vrai (du moins pour C++, vu que Nim et rust, je connais pas)...

    Je ne nie pas qu'il y aurait très certainement moyen de prendre une bonne part du code existant et de le filer "tel quel" à un "autre compilateur" (comprend un compilateur pour "un autre langage que le C") et de s'en sortir encore très raisonnablement, mais, pour ne parler que de C++ que je connais suffisamment, il ne faut pas oublier qu'il ne supporte qu'une partie de la norme C.

    Non pas parce qu'il considère ce qu'il ne supporte pas comme "inutile", mais bel et bien à cause d'une incompatibilité réelle avec sa propre norme.

    Alors, je ne sais pas exactement quelle est la proportion de C qui n'est pas supportée en C++ (et, quelque part, je m'en fous :p ) mais, même si ca ne devait être que de l'ordre de 1/100 ou de 1/1 000, je ne voudrais pas vraiment être le type qui devrait s'occuper de rendre le noyau linux compatible !

    Et, surtout: même dans de si petites proportions, il faudrait combien de gars pour arriver à rendre la base de code (même en se limitant à celle qui est effectivement encore utilisée) compatible

    Quand on voit que le seul bug de l'an deux mille a couté plus de 3 000 milliards de dollars pour être évité, combien couterait cette "petite mise à niveau" selon toi
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  13. #13
    Membre émérite
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    667
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 667
    Points : 2 937
    Points
    2 937

    Par défaut

    @koala01 : Uther ne parlait pas de compiler directement du code C avec un compilateur C++, Nim ou Rust, mais d'appeler du code compilé en C depuis du code écrit dans un autre langage, par exemple C++, Nim ou Rust.

  14. #14
    Expert éminent Avatar de Uther
    Homme Profil pro
    Inscrit en
    avril 2002
    Messages
    3 665
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : avril 2002
    Messages : 3 665
    Points : 8 825
    Points
    8 825

    Par défaut

    @koala01> Bien évidement que si tu compiles du C directement avec un compilateur C++, tu vas avoir des problèmes. Les langage ont beau être proches, leur normes ne sont pas prévues pour être compatible.

    Tu confonds interfacer et remplacer. Encore une fois, je ne parle pas de remplacer le C en mode "tout doit disparaitre".
    Quand je parle d'interfacer, je veux dire que le code C qui n'a pas besoin de changement lourd restera compilé par un compilateur C. Mais que les nouveaux développement importants que l'on peut bien isoler peuvent être réalisés dans un autre langage qui s'interface avec le C via les mécanisme prévus pour, comme extern "C" en C++.

    On peut ainsi introduire les nouveaux développement dans un nouveau langage, tout en continuant a travailler avec une base de code existante en C.

  15. #15
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    6 918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 6 918
    Points : 18 402
    Points
    18 402

    Par défaut

    Citation Envoyé par koala01 Voir le message
    Mais, à part C++ (qui peut s'approcher énormément des cas d'utilisation de C, mais qui a quand même aussi un bon nombre d’incompatibilités avec lui), aucun de ceux que tu as cités ne peut prendre la "niche" du C.
    Citation Envoyé par Aiekick Voir le message
    Python, c++ ok
    Latex, je sais pas
    mais css ? un simple langage descriptif rien a voir avec de la programmation
    Json, une simple structure de donnée
    Xml langage descriptif, comme le html, plus une structure de donné qu'un langage de programmation.

    rien a voir avec le c donc... mais je suppose que c'est voulu ?
    Le C ne permet pas de tout faire, c'est bien pour cela que j'ai cité une liste de langages. On a besoin de plusieurs langages pour plusieurs utilisations, mais pas de plusieurs clones d'un même langage.

    Du JSON/XML pour des données formatées, CSS pour tout ce qui est design, Python pour tout ce qui est scripts, C++ pour les perfs, LaTeX pour de la rédaction de documents.


    Citation Envoyé par Pyramidev Voir le message
    Je suis d'accord pour dire qu'il y a trop de langages, mais ta liste est trop restreinte
    Ma liste est non-exhaustive, et bien sûr il faudrait regarder plus en détails.

    D'ailleurs, il faudrait ajouter un langage de requête, e.g. SQL.

    Citation Envoyé par Pyramidev Voir le message
    Python est accessible aux débutants et permet d'écrire du code concis, mais n'est pas performant. Cela conduit des chercheurs à coder deux fois la même chose : un prototype en Python puis un programme dans un langage plus performant, comme C++.
    Je dois avouer ne pas avoir beaucoup creusé sur point là.

    À voir déjà si les outils d'optimisations ainsi que le fait de réduire la complexité algorithmique ne sont pas suffisant. Est-ce aussi des contraintes liées au langage en lui-même, ou à ses implémentations d'interpréteurs ?

    Citation Envoyé par Pyramidev Voir le message
    C++ est riche et performant. Mais, même avec une telle richesse, il est plus compliqué qu'il ne devrait et contient plus de pièges qu'il ne devrait.
    As-tu des exemples en tête ?

    Citation Envoyé par Pyramidev Voir le message
    En outre, il est lent à compiler, surtout s'il y a trop de code dans les fichiers d'entête, ce qui restreint l'utilisation des templates dans un gros projet.
    Vivement les modules.

    Citation Envoyé par Pyramidev Voir le message
    Dans ta liste, je ne vois pas de langage qui supporte vraiment le paradigme fonctionnel comme Haskell. L'inconvénient de ce paradigme est qu'il est plus difficile à apprendre que la programmation orientée objet. Mais l'avantage est qu'il permet d'écrire du code beaucoup plus modulaire.
    On peut en effet l'ajouter si tu veux.

    Citation Envoyé par Pyramidev Voir le message
    Cela dit, les concepteurs de nouveaux langages ne devraient pas se contenter d'essayer de faire mieux que les langages au sommet du classement TIOBE. Ils devraient aussi, s'ils y arrivent, d'essayer de faire mieux que les langages moins connus qui ont du mal à s'imposer. Sinon, on augmente la liste des langages inutiles. Or, je pense que le C-for-All s'ajoute à cette liste.
    Je suis tout à fait d'accord.

    De même, essayer d'avoir des syntaxes identiques, par exemple avoir du C++ avec une syntaxe de python serait pas mal et éviterait les problèmes d’accolades.
    Et même plutôt que de proposer des nouveaux langages, proposer des sucres syntaxiques qui serait convertis en un langage-cible (e.g. C++ avec syntaxe python -> C++).


    Citation Envoyé par koala01 Voir le message
    Et, surtout: même dans de si petites proportions, il faudrait combien de gars pour arriver à rendre la base de code (même en se limitant à celle qui est effectivement encore utilisée) compatible

    Quand on voit que le seul bug de l'an deux mille a couté plus de 3 000 milliards de dollars pour être évité, combien couterait cette "petite mise à niveau" selon toi
    Justement, quand on doit gérer que 5 ou 6 langages, c'est bien plus facile que si on devait en gérer 36 000.
    On dit "chiffrer" pas "crypter" !

    On dit "bibliothèque" pas "librairie" !

    Ma page DVP : http://neckara.developpez.com/

  16. #16
    Membre émérite
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    667
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 667
    Points : 2 937
    Points
    2 937

    Par défaut

    Citation Envoyé par Neckara Voir le message
    Citation Envoyé par Pyramidev Voir le message
    C++ est riche et performant. Mais, même avec une telle richesse, il est plus compliqué qu'il ne devrait et contient plus de pièges qu'il ne devrait.
    As-tu des exemples en tête ?
    Voici quelques exemples de pièges qui ne viennent pas de la richesse du langage, mais d'erreurs de conceptions, soit héritées du langage C (à cause de la rétrocompatibilité), soit ajoutées en C++ :
    • Dans une classe, les variables membres sont accessibles même avant d'avoir été construites.
      Explication : Dans une classe MaClasse, si m_variable_membre_1 a été déclarée avant m_variable_membre_2, alors m_variable_membre_1 est initialisée avant m_variable_membre_2, quel que soit l'ordre dans lequel on les écrit dans le code du constructeur.
      Malgré cela, le code suivant compile :
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      6
      MaClasse() : m_variable_membre_2{}, m_variable_membre_1{m_variable_membre_2} {}
       
      // Le code ci-dessus équivaut à :
      // MaClasse() : m_variable_membre_1{m_variable_membre_2}, m_variable_membre_2{} {}
       
      // Donc on construit m_variable_membre_1 en lui passant en argument une donnée non initialisée !!!
    • Quand un constructeur peut n'avoir qu'un seul paramètre, si on oublie le mot-clé explicit, alors on définit par mégarde une conversion implicite, ce qui affaiblit le typage. À la place, il aurait fallu un mot-clé implicit qu'on écrit uniquement si on décide consciemment de définir une conversion implicite.
    • Quand une classe Base a un destructeur public non virtuel et qu'on définit une classe dérivée Deriv, ça compile. Mais, si on fait un delete (directement ou indirectement) d'un Base* qui pointe vers un objet Deriv, le comportement est indéterminé. Il aurait été préférable qu'on ait une erreur de compilation quand on fait un delete sur un Base* si Base est dérivable. Pour cela, il aurait fallu que C++98 permette de distinguer une classe dérivable d'une classe non dérivable. Mais il a fallu attendre C++11 pour avoir le mot-clé final.
    • Par défaut, quand il le peut, le compilateur génère tout seul un constructeur de copie public et une affectation de copie publique, même si le destructeur a été redéfini, ce qui est un piège, parce que cela conduit souvent à libérer plusieurs fois la même ressource (exemple : double delete). Il aurait été préférable d'obliger l'utilisateur à les générer explicitement avec = default si le destructeur a été déclaré explicitement. Mais il a fallu attendre C++11 pour avoir = default. En pratique, ce piège concerne surtout ceux qui n'utilisent pas la règle du zéro, mais cela reste un piège.
    • Quand on fait un delete d'un pointeur vers un type incomplet (typiquement une classe déclarée en avance), ça compile, mais le destructeur de cette classe ne sera pas appelé. De même, si cette classe a un opérateur delete spécifique, celui-ci ne sera pas appelé. Ce piège ne touche que ceux qui utilisent delete au lieu de std::unique_ptr, dont l'instanciation du deleter provoque une erreur de compilation si le type de la donnée pointée est incomplet, mais ça reste un piège.
    • Dans un switch, oublier des case ne provoque aucune erreur de compilation, même si la valeur testée est un type énuméré. Ce problème est imposé par la rétrocompatibilité avec le langage C.
    • En C++, quand on initialise une variable globale x à partir d'une variable globale y d'une autre unité de compilation, on n'a pas de garantie que y est initialisé avant x. En D, par contre, l'ordre des initialisations statiques est déterminé par l'ordre d'import des modules (lien). En C++, ce piège touche surtout ceux qui abusent des variables globales, mais ça reste un piège.
    • Il y a trop de conversions implicites en booléens, ce qui affaiblit le typage. Si on combine ça avec le fait que l''opérateur = retourne une lvalue de même type que l'opérande de gauche au lieu de retourner void, cela démultiplie les risques d'erreurs, par exemple si on écrit par mégarde if(unEntier = unAutreEntier) au lieu de if(unEntier == unAutreEntier). C'est la faute du langage C.
    • >> sur un entier signé strictement négatif a un implementation defined behaviour. C'est encore une bêtise héritée du langage C.


    Une partie des problèmes ci-dessus sont palliés par les avertissements du compilateur. Mais, parfois, on récupère du mauvais code pour lequel les nouveaux avertissements du compilateur sont noyés dans une masse d'avertissements déjà existants. D'autres fois, on travaille avec un compilateur qui n'est pas assez bon et omet certains avertissements.

    Voici aussi quelques exemples de complexité inutile qui ralentissent l'apprentissage du langage :
    • Le mot-clé static a deux sens différents : durée de vie statique et lien interne. Il aurait fallu deux mot-clés différents : static et intern ou internal. En plus, static dans le sens de lien interne fait doublon avec les espaces de noms anonymes. Pour complexifier les choses, les variables globales constantes non volatiles non inlines ont un lien interne par défaut, alors que ce n'est pas le cas en C.
    • Il est possible de surcharger l'opérateur unaire &. Alors, en programmation par template, on utilise la bidouille std::adressof.
    • Il y a le problème du Most vexing parse.


    Citation Envoyé par Neckara Voir le message
    Vivement les modules.
    C'est vrai que ce sera un grand pas en avant.

    Citation Envoyé par Neckara Voir le message
    De même, essayer d'avoir des syntaxes identiques, par exemple avoir du C++ avec une syntaxe de python serait pas mal et éviterait les problèmes d’accolades.
    Personnellement, je pense qu'un langage idéal devrait laisser le choix entre les deux, comme le fait Haskell.
    Par exemple, avec Haskell, voici deux bouts de code qui font la même chose : un avec des point-virgules et des accolades et un autre avec de l'indentation :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
    liftM2 f m1 m2 = do { x1 <- m1; x2 <- m2; return (f x1 x2) }
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
    liftM2 f m1 m2 = do
        x1 <- m1
        x2 <- m2
        return (f x1 x2)
    Edit 2018-03-26-20h52 : ajout d'un petit paragraphe sur les avertissements du compilateur.
    Edit 2018-03-26-22h01 : correction de fautes de français.

  17. #17
    Membre expérimenté
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    341
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 341
    Points : 1 397
    Points
    1 397

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Personnellement, je pense qu'un langage idéal devrait laisser le choix entre les deux, comme le fait Haskell.
    Par exemple, avec Haskell, voici deux bouts de code qui font la même chose : un avec des point-virgules et des accolades et un autre avec de l'indentation :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
    liftM2 f m1 m2 = do { x1 <- m1; x2 <- m2; return (f x1 x2) }
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
    liftM2 f m1 m2 = do
        x1 <- m1
        x2 <- m2
        return (f x1 x2)
    mouais, enfin la "vraie" syntaxe de ce code c'est quand même :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
    liftM2 f m1 m2 = m1 >>= (\ x1 -> (m2 >>= (\x2 -> return $ f x1 x2)))
    et question lisibilité, ça se discute...

  18. #18
    Membre émérite
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    667
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 667
    Points : 2 937
    Points
    2 937

    Par défaut

    La version sans le sucre syntaxique de la do-notation est effectivement moins lisible, mais où veux-tu en venir ?

  19. #19
    Membre expérimenté
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    341
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 341
    Points : 1 397
    Points
    1 397

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    La version sans le sucre syntaxique de la do-notation est effectivement moins lisible, mais où veux-tu en venir ?
    Nulle part, c'était juste pour la boutade car Haskell est plus souvent cité comme un langage étrange avec une syntaxe exotique.

  20. #20
    Membre éclairé Avatar de Madmac
    Homme Profil pro
    Responsable de projet fonctionnel
    Inscrit en
    juin 2004
    Messages
    612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Alimentation

    Informations forums :
    Inscription : juin 2004
    Messages : 612
    Points : 841
    Points
    841

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Je suis d'accord pour dire qu'il y a trop de langages, mais ta liste est trop restreinte :
    [LIST][*]Python est accessible aux débutants et permet d'écrire du code concis, mais n'est pas performant. Cela conduit des chercheurs à coder deux fois la même chose : un prototype en Python puis un programme dans un langage plus performant, comme C++. On a donc besoin d'un langage avec les principaux avantages du Python, mais plus performant. Peut-être Julia.
    La lenteur d'un interpréteur n'a pas que des désavantages. La vitesse est souvent un arbre qui cache la forets, parce qu'un langage rapide a tendance à être plus permissive pour du code sub-optimal. Si votre code est suffisamment performant sur un langage interprété, vous avez de la marge de manœuvre si la demande augmente.

    Julia semble un bon candidat, mais je ne sais pas s'ils ont adopté l'unicode. Crystal me semble être déjà un choix prometteur. À moins, d'utiliser les particularités d'un langage interprété. il exécute en général le code en Ruby 5 fois plus vite.
    intel i7
    OpenSuse Leap 42.2
    Plasma et Cinnamon

Discussions similaires

  1. Réponses: 1
    Dernier message: 11/03/2008, 01h36
  2. Réponses: 8
    Dernier message: 28/11/2007, 13h55
  3. Bosser en France pour une boite Canadienne
    Par popogendarme dans le forum Emploi
    Réponses: 9
    Dernier message: 09/07/2007, 21h43
  4. [XSL-FO] Modifer une structure de tableau dans for-each
    Par serwol dans le forum XSL/XSLT/XPATH
    Réponses: 24
    Dernier message: 17/06/2005, 17h38

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