Voir le flux RSS

Blog d'Aurélien Regat-Barrel

[Actualité] Le premier compilateur C++ fête ses 30 ans. Son créateur revient sur les grandes étapes du langage.

Note : 2 votes pour une moyenne de 5,00.
par , 14/10/2015 à 11h18 (1049 Affichages)
Le 14 octobre 1985 sortait (en version commerciale) Cfront 1.0, le tout premier compilateur C++. Cette sortie était accompagnée, le même jour, de celle du livre de référence sur le sujet : "The C++ Programming Language" (première édition). Ce double événement marqua le début d'une aventure qui perdure encore de nos jours : celle de l'évolution de C++.

Outre leur date de sortie, le compilateur et le livre ont comme point commun le même auteur : Bjarne Stroustrup. Ce dernier a accepté de revenir sur les 30 dernières années de sa vie passées à développer C++ dans un entretien publié aujourd'hui même. Son interview est accompagnée d'une illustration qui permet de se faire une meilleure idée des grandes étapes de C++ depuis ses débuts jusqu'à nos jours.

Nom : timeline-800.png
Affichages : 2768
Taille : 183,6 Ko

Le créateur danois aime rappeler que dès sa première version, C With Classes (qui n'est pas encore C++) disposait des classes, des constructeurs et destructeurs, de la visibilité public / protected, de la surcharge ainsi que de la redéfinition (virtualité). Rappelons que dans le contexte de l’époque, la plupart des programmeurs étaient hostiles à la POO, perçue comme trop complexe et trop gourmande.

La programmation paramétrique était elle aussi présente très tôt, implémentée via des macros (un fichier d'en-tête <generic.h> était même livré). Bjarne avoue d'ailleurs s'être lourdement trompé quant à la possibilité de supporter ainsi la programmation générique, et il faudra attendre la fin des années 80 pour voir arriver les templates si chers à C++.

Mais il précise aussi que si C++ est parvenu à rencontrer le succès malgré les inévitables erreurs de parcours, c'est parce que tout au long de son développement, il a fait très attention à introduire des changements graduels en réponse à des problèmes réels : "C++ n'a jamais été un projet de type Tour d'Ivoire". C'est ce qui explique selon lui que C++ ait réussi à percer comme langage majeur, du fait qu'il répond à des besoins critiques pour beaucoup de programmeurs.

Pour autant, 30 ans est une longue période de temps, et Bjarne avoue avoir été tenté plusieurs fois de se lancer dans la création d'un autre nouveau langage : "mais C++ m'a toujours ramené à lui". En effet, il est très difficile de concevoir un système à partir de zéro, d'autant plus quand il s'agit d'entrer en compétition avec C++ sur son terrain de prédilection. Ainsi, il préfère oeuvrer à améliorer C++. Car ce n'est certes pas facile d'intégrer une idée nouvelle dans un langage aussi complexe. Mais quand on y parvient, elle peut bénéficier immédiatement à des millions de programmeurs plutôt qu'à quelques centaines.

Bjarne parle ensuite de l'emballement du public à une certaine époque pour la POO, au point qu'il en venait à donner des conférences du type "C++ n'est pas qu'un langage de programmation orienté objet". Par la suite, la mode changera et s'enthousiasme démesuré se portera sur les templates. Il aborde alors un problème majeur de C++ selon lui : le faible niveau de compréhension du langage de la part de ceux qui l'enseignent, mais aussi de ceux qui l'utilisent couramment. C'est pourquoi lui et d'autres membres du comité travaillent à faciliter le bon usage du langage via la mise à disposition d'outils, de bibliothèques et d'un guide de bonnes pratiques. Ces dernières, explique-t-il, permettent de se passer efficacement d'un ramasse-miettes (garbage collector) tout simplement parce que le style de programmation utilisé ne génère pas de déchets (garbage) à ramasser.

Enfin, au sujet des nouveautés à venir dans C++17, il s'attend à un changement majeur au niveau du langage, au même titre que C++11 l'a été. Il espère voir arriver:
  • les concepts (utilisation plus simple des templates)
  • les modules (compilation plus rapide)
  • une STL améliorée : fini les begin()…end()
  • les co-routines
  • une bibliothèque réseau standard
  • un meilleur support de la programmation concurrente et parallèle
  • et plus encore


Nous en saurons plus à l'issue de la rencontre prochaine du comité de normalisation. A ce propos, il est encore temps de partager vos questions et interrogations sur le langage afin d'espérer une réponse de la part de ceux qui le font évoluer !

Source : Bjarne Stroustrup on the 30th anniversary of Cfront (the first C++ compiler)

Envoyer le billet « Le premier compilateur C++ fête ses 30 ans. Son créateur revient sur les grandes étapes du langage. » dans le blog Viadeo Envoyer le billet « Le premier compilateur C++ fête ses 30 ans. Son créateur revient sur les grandes étapes du langage. » dans le blog Twitter Envoyer le billet « Le premier compilateur C++ fête ses 30 ans. Son créateur revient sur les grandes étapes du langage. » dans le blog Google Envoyer le billet « Le premier compilateur C++ fête ses 30 ans. Son créateur revient sur les grandes étapes du langage. » dans le blog Facebook Envoyer le billet « Le premier compilateur C++ fête ses 30 ans. Son créateur revient sur les grandes étapes du langage. » dans le blog Digg Envoyer le billet « Le premier compilateur C++ fête ses 30 ans. Son créateur revient sur les grandes étapes du langage. » dans le blog Delicious Envoyer le billet « Le premier compilateur C++ fête ses 30 ans. Son créateur revient sur les grandes étapes du langage. » dans le blog MySpace Envoyer le billet « Le premier compilateur C++ fête ses 30 ans. Son créateur revient sur les grandes étapes du langage. » dans le blog Yahoo

Catégories
Programmation , C++

Commentaires

  1. Avatar de Markand
    • |
    • permalink
    J'espère qu'un jour on aura un vrai support de l'unicode. Parce que char32_t c'est bien gentil, std::u32string aussi. Mais on a rien qui permet de tester si un caractère unicode est une lettre, un chiffre.
  2. Avatar de Gugelhupf
    • |
    • permalink
    Moi en tant que développeur C++, plusieurs choses me dérangent :
    1. La mise en place de l'environnement C++ sur sa machine (cf : l'IDE + compilateur). Je me souviens qu'il y a 4-5 ans que code::blocks m'avait donné du fil à retordre, récemment j'ai installé Qt et des problèmes similaires voir pires sont apparues : installation en mode online interrompu pour des raisons des raisons différentes à essai (messages d'erreurs différents à chaque fois), installation en mode offline ne fonctionne qu'avec MinGW (portage de GCC sous Windows), donc adieu les installateurs Qt version Visual C++ alors que ça devrait fonctionner bon sang vu que juste avant j'ai installé 15Go de Visual Studio Community avec toutes ses cliques et ses claques (compilateurs etc), l'environnement Visual est détecté dans les options de l'IDE mais il y a une erreur non résolvable qui vous empêche de faire du C++ avec. J'ai même installé Clang pour m'amuser en ligne de commande, même ça ça ne fonctionne pas sous Windows ! Donc voilà je suis Windows et je suis limité à faire du C++ avec Visual Studio si j'utilise le compilateur de Visual et MinGW pour le reste (Code Once And Pain in the neck if Windows bravo !).
    2. L'incohérence de la STL. L'autre jour j'ai effectué des recherches pour connaitre les plages maximum et minimum d'une variable, c'est cool parce que C++11 apporte un bon moyen de le faire avec la classe std::numeric_limits<T> avec ses méthodes static, donc pour obtenir la plage max il faut utiliser max() rien de bien méchant jusque là, et pour obtenir la plage min il faut utiliser lowest() là on commence à sentir l'incohérence mais on tient le coup... mais il existe une troisième méthode min() qui n'est pas un synonyme de lowest() et qui sert à autre chose !!! Bref c'était un exemple de l'incohérence de la STL malgré l'évolution du langage avec C++11. Pour ma part ayant déjà passé plusieurs années avec différents langages je ressens de l'amateurisme dans la conception des API (ce que je dis là est grave j'en suis conscient), mais j'aurais attendu mieux de la part des concepteurs du langage C++ parce que chaque couche ajouté trainera dans le langage pour les 30 années à venir, et généralement avoir des API incohérents ne fera pas en sorte que les développeurs se plairont à utiliser ce langage.
  3. Avatar de Invité
    • |
    • permalink
    [QUOTE=Gugelhupf]Moi en tant que développeur C++, plusieurs choses me dérangent :
    [LIST=1][*][B]La mise en place de l'environnement C++ sur sa machine[/B] (cf : l'IDE + compilateur). [/LIST][/QUOTE]

    Merci de préciser "sous Windows" parce que sous Linux/Unix il n'y a quasiment rien à faire pour que çà fonctionne.

    [QUOTE=Gugelhupf]
    [B]L'incohérence de la STL[/B].
    [/QUOTE]

    Absolument pas d'accord.
    Qualifier la STL d'incohérente parce que quelques noms ne te plaisent pas c'est vraiment n'importe quoi. C'est vrai que "ArrayList" en Java, c'est super logique...
    À ma connaissance, la STL "actuelle" date de 1994 et utilise massivement les templates, ce qui était plutôt novateur à l'époque. Depuis, elle a évolué sans grosse rupture de compatibilité et a même intégré les lambdas comme si de rien n'était. Elle n'est bien-sûr pas parfaite mais si elle était vraiment incohérente, je ne pense pas qu'elle aurait survécu jusqu'ici. Remarque Windows a survécu jusqu'ici... Oups un troll s'est échappé.

    [B]Edit :[/B]

    [QUOTE=Gugelhupf]
    mais il existe une troisième méthode min() qui n'est pas un synonyme de lowest() et qui sert à autre chose !!!
    [/QUOTE]

    Donc que deux méthodes qui ne font pas la même chose portent des noms différents, c'est incohérent...
    Autant, pour moi, je n'avais pas compris que c'était de l'humour.
    Mis à jour 15/10/2015 à 22h51 par Invité
  4. Avatar de Gugelhupf
    • |
    • permalink
    @groharpon42,
    Merci pour les templates et lambdas mais je ne suis pas novice, cela va bientôt faire 8 ans que je côtoie ce langage donc voilà je le connais un minimum.

    Oui le nom ArrayList en Java est logique vu que c'est une implémentation de l'interface List qui utilise des tableaux.

    Non, il n'y avait pas d'humour concernant le nom des méthodes min() et lowest() et je ne suis pas le seul à penser qu'il y a des incohérences dans la STL (tu peux voir sur les commentaires de ce lien). Mais ce n'était là qu'un simple exemple.

    La devise du C++ c'est Write Once Compile Anywhere, donc même s'il n'y a aucun problème avec les IDE et Clang sous Linux, je trouve dommage de ne pas trouver cette stabilité ailleurs.
  5. Avatar de Traroth2
    • |
    • permalink
    Citation Envoyé par groharpon42
    Donc que deux méthodes qui ne font pas la même chose portent des noms différents, c'est incohérent...
    Autant, pour moi, je n'avais pas compris que c'était de l'humour.
    Tu es sûr d'avoir lu le commentaire ?
  6. Avatar de Traroth2
    • |
    • permalink
    Faudrait vraiment que je m'y remette. La dernière fois que j'ai fait du C++, ce langage ne proposait pas de traitement des exceptions. Ca doit dater de 1997, en gros.

    L'ennui, c'est que je n'arrive pas à trouver de version e-book de "Le langage C++" de Stroustrup, dans une édition récente (la plus récente est de 2013, je crois).
  7. Avatar de Gugelhupf
    • |
    • permalink
    @Traroth2
    Les livres c'est pas mal, mais sinon tu peux aller sur le site officiel du C++ : https://isocpp.org/ pour apprendre pas mal de choses sur les nouveautés du langage.
  8. Avatar de Invité
    • |
    • permalink
    [QUOTE=Gugelhupf]@groharpon42,
    Merci pour les templates et lambdas mais je ne suis pas novice, cela va bientôt faire 8 ans que je côtoie ce langage donc voilà je le connais un minimum.
    [/QUOTE]

    Je n'ai jamais prétendu le contraire et je ne suis pas un novice non plus.
    Je voulais simplement dire que l'ensemble de la bibliothèque tourne autour de quelques concepts genre conteneur/itérateur/algorithme... + généricité, ceci depuis plus de 20 ans et sans avoir nécessité de refactoring tous les 6 mois.
    Personnellement, je trouve que c'est un signe de cohérence globale et de maturité.

    [QUOTE=Gugelhupf]
    je ne suis pas le seul à penser qu'il y a des incohérences dans la STL (tu peux voir sur les commentaires de [URL="http://stackoverflow.com/a/17654460/2389207"]ce lien[/URL]). Mais ce n'était là qu'un simple exemple.
    [/QUOTE]

    Je suis d'accord avec toi qu'il y a des incohérences ponctuelles, comme dans toutes les bibliothèques j'imagine.
    Cependant, ce n'est pas ce que tu disais dans ton post initial où tu qualifiais la bibliothèque elle-même d'incohérente et faisant preuve d'amateurisme dans sa conception (ou alors j'ai mal compris ton propos); et là je ne suis pas d'accord (cf ma remarque précédente).
    Quant à l'exemple du nom de fonction, si c'est çà le plus gros inconvénient de la STL...

    Cela dit, merci pour le lien. A noter qu'on y trouve un draft du livre "A tour of C++" ([url]https://isocpp.org/tour[/url]) que je trouve pas mal pour sa concision et ses petits conseils.
    Mis à jour 16/10/2015 à 18h43 par Invité