Linus Torvalds : le "C++ est un langage horrible"
En justifiant le choix du C pour le système de gestion de version Git

Le , par Idelways, Expert éminent sénior
Cet article n'est pas proprement né d'une nouveauté, mais fait écho à une tempête que soulève la découverte d'un email vieux de quatre ans.

Des « cyberspéléologues » ont sorti des méandres sournois des archives du Net un email fort polémique. Son auteur n'est autre que Linus Torvalds, le célèbre créateur du noyau Linux, tout aussi connu parmi les développeurs pour avoir initié le projet Git, le système de gestion de version (très) à la mode.

En réponse à un contributeur qui s'interrogeait en 2007 sur les raisons qui ont conduit au choix du C (plutôt que du C++), Torvalds s'en est donner à coeur joie pour avouer son désamour au C++ qu'il qualifie d’« horrible langage ».

Il est vrai que son interlocuteur n'a pas dû tourner deux fois les doigts sur son clavier avant de qualifier l'argument de portabilité d'un délicat « bullshit » (foutaise), mais l'avis de Torvalds est tellement tranché — sur le langage, mais surtout sur ses développeurs — qu'il semblait attendre une telle opportunité pour l'étaler.

« C++ est un langage horrible. Ce qui le rend d'autant plus horrible est le fait que beaucoup de programmeurs “substandard” l'utilisent, au point qu'il est nettement plus facile de générer de la merde totale et absolue avec », sic.

Le choix du langage de Git, avoue le développeur, n'est là que pour « garder les programmeurs C++ loin, c’est en soi, un énorme argument en faveur de l'utilisation du C », surenchérit-il.

Après un autre paragraphe tout aussi scatologique à l'encontre des développeurs C++, Torvalds passe aux arguments techniques. « C++ entraîne à des choix de conception très très mauvais. Vous commencez invariablement par utiliser les fonctionnalités “sympas” de la librairie standard du langage comme STL, Boost et autres conneries totales et absolues, ça peut aider votre programme, mais ça engendre : »

Il énumère, d'abord : « la souffrance infinie quand ça ne marche pas ». Sur ce point, il remet en cause la stabilité et la portabilité de la bibliothèque standard et « surtout de Boost ». Puis de s'attaquer à « l'abstraction inefficace des modèles de programmations, où, deux ans plus tard, vous vous rendez compte que certaines abstractions n'étaient pas très efficaces, alors que maintenant, tout votre code dépend de ces beaux modèles objets, et vous ne pouvez corriger tout ça sans réécrire votre application ».

À se demander si Torvalds n'a pas plutôt une dent contre toute la programmation orientée objet pour les usages de niveau système. « La seule manière de faire du C++ bien, efficace, de niveau système et portable revient à vous limitez à tous les trucs que sont à la base disponible en C », déclare-t-il avec force de conviction.

Torvalds explique par la suite et en substance que l'efficacité est le premier objectif à atteindre sur des projets tels que Git, et en prime « emmerder les personnes incapables de le comprendre », et de comprendre « les problèmes de bas niveau ».

Peu accueillant sur son projet, il invite les développeurs désireux d'écrire un CVS en C++ d'aller voir du côté de Monotone, un projet qui s'enorgueillirait d'après lui de décisions de conceptions « reluisantes pour les gars des sciences informatiques », mais qui conduisent finalement à « une pagaille horrible et non-maintenable ».

Nourrie par une forte intensité dans le verbe et d'une perceptible volonté de blesser, une véritable polémique est née entre les partisans du langage. La rivalité entre les deux camps n'est pas nouvelle, mais l'intervention aussi virulente d'un personnage emblématique ne contribue certainement pas à faire avancer sereinement le débat.

Il n'empêche que des arguments techniques sont là, et nous vous invitons à y répondre objectivement.

Source : l'email original de Torvalds

Voir aussi sur C++ :

Cours et tutoriels C++.
La FAQ C++.
Le Forum C++.

Et vous ?

Que pensez-vous de la position de Linux Torvalds et de ses arguments ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de koala01 koala01 - Expert éminent sénior http://www.developpez.com
le 07/01/2012 à 11:50
Salut
Citation Envoyé par rt15  Voir le message
Beaucoup de programmeur C++ critiquent d'autres programmeurs C++ qui utilisent printf, des pointeurs classiques, des tableaux ou encore qui utilisent le C++ uniquement pour faire classes (Ils parlent de C with classes).
Ils considèrent que ce sont des codeurs C qui se sont mis au C++, et qui ont gardé de mauvais réflexes. Ils pensent que ces pseudo codeurs C++ devraient systématiquement profiter des (fantastiques, ou pas) évolutions : streams (cout...), références, smartpointers (Et RAII), templates, STL...

Quand on voit tous les problèmes que ca évite, c'est un peu normal
Citation Envoyé par rt15  Voir le message
Utiliser un compilo C++ pour compiler du code C s'apparente plus à faire du C que du C++.

Oui, le gros malheur de C++ est d'avoir voulu respecter la compatibilité avec C... Mais c'est aussi une de ses forces car cela permet, malgré tout, de récupérer l'existant
Citation Envoyé par rt15  Voir le message
Il y en a quelques autres. Rien que compiler un bête main vide avec un compilo C et un compilo C++ (Et des options de compilation classiques) ne donne pas le même résultat.
-> La librairie standard utilisé n'est pas la même (En C++ le binaire est souvent plus gros, et le code d'initialisation entre le point d'entrée et le main est souvent plus lent).
-> Le temps de compilation est bien souvent plus élevé pour le C++.

Ca, je n'en suis pas sur...
Citation Envoyé par rt15  Voir le message
-> Le binaire C++ nécessite généralement plus de dépendances ce qui peut poser plus de problèmes de déploiement ->

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
prompt> cat test.c 
int main() 
{ 
  return 0; 
} 
 
prompt> cp test.c test.cpp 
prompt> gcc test.c -o test.exe 
prompt> ldd test.exe 
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000003919100000) 
        /lib64/ld-linux-x86-64.so.2 (0x0000003918f00000) 
prompt> g++ test.cpp -o test.exe 
prompt> ldd test.exe 
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003920100000) 
        libm.so.6 => /lib64/tls/libm.so.6 (0x0000003919400000) 
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000391fb00000) 
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000003919100000) 
        /lib64/ld-linux-x86-64.so.2 (0x0000003918f00000)

Attends, il y a une malhonnêteté morale manifeste dans ce que tu écris:

D'abord, tu mens au compilateur en lui faisant croire que le code C est du C++... Comme ce n'est "qu'un programme", il n'a pas les moyens de faire autrement que de te croire !

Il n'a donc pas d'autre choix que de rajouter les bibliothèques qu'on lui a indiquées comme étant indispensables pour linker du C++.

Mais, comme tu linke avec les versions dynamiques de ces bibliothèques, l'exécutable ne prend pas de surpoids de ce fait, et, bien qu'il y ait deux dépendances de plus, l'exécution fera apparaitre que tu n'utilises sans doute jamais les fonctions apportées par ces bibliothèques.

Si tu comparais la compilation avec la version statique des bibliothèque, tu te rendrais compte qu'il n'y a plus la moindre différence entre les deux binaires obtenus
Citation Envoyé par rt15  Voir le message
Les compilos C (Et surtout les compilo C89) sont bien plus répandus, légers et facile à coder que les compilos C++. Les compilos C respectent tous à peu près le C 89. Le standard C++ est bien plus vaste et plus complexe, la librairie standard bien plus fournie. Il n'est donc pas rare qu'une syntaxe passe sur 4 ou 5 compilateurs et pas sur le 6ème. Le support peut varier aussi d'une version d'un compilateur à une autre. Cela devient vite un casse tête.

Là encore, tu fais preuve de malhonnêteté mentale:

C89 date d'il y a plus de vingt ans, et je suis persuadé que, si tu regardais les compilateurs sortis entre 88 et 92, tu te retrouverais sans doute aussi avec un support plus ou moins hétéogène et aléatoire de la norme!!

J'ai presque envie de dire qu'il encore heureux que la plupart des compilateur C sortis sans doute depuis 1995 respectent la norme, ce serait malheureux autrement

D'un autre coté, on peut etre persuadé que le support de la norme fournit par les compilateurs C varie aussi d'une version à une autre, dans les versions proches de la sortie de celle-ci, étant donné les difficultés qu'il peut y avoir à respecter l'ensemble des prescriptions fournies par elle
Citation Envoyé par rt15  Voir le message

Au niveau du cout, tu en oublies quelques uns, tel que celui du temps d'exécution passé à mettre en place les gestionnaires d'exceptions.

A priori, les gestionnaires d'exceptions sont mis en place une bonne fois pour toutes...

Au pire, tu remarqueras sans doute meme pas le délais supplémentaire tant cela prend peu de temps (il faudrait un vérification du nombre de cycles d'horloge pour s'en rendre compte )
Citation Envoyé par rt15  Voir le message
Les implémentations telles que celles de la STL peuvent aussi être pénalisantes, par exemple en initialisant inutilement les valeurs d'un vector là ou un tableau C n'est pas initialisé (Sauf si calloc est utilisé).

cf les réactions précédentes
Citation Envoyé par rt15  Voir le message
Certains diraient aussi que le C pousse à faire du code rapide (Il n'y a pas de code caché, on manipule les données finement), tandis que le C++ pousse à faire du code plus lent (Code de plus haut niveau, temps d'exécution caché dans des constructeurs/destructeurs...).

Si ce n'est que tout ce que les constructeurs et destructeurs font, tu le fais aussi en C (ou du moins, tu es sensé le faire en C)

La seule différence, c'est que tu finis simplement et plus facilement par respecter un principe cher à tout paradigme de programmation: la délégation des responsabilité et la responsabilité unique
Citation Envoyé par rt15  Voir le message
Autre problème, l'ABI. En C++, la décoration a tendance à franchement gêner l'interopérabilité (Y compris entre deux binaires générés avec des compilo C++ différents). D’où le fameux extern "C". De ce fait, s'arranger pour qu'une librairie C++ soit utilisable depuis un autre langage n'est pas forcément trivial et implique un coût à l'exécution.

Essaye d'utiliser sous windows une bibliothèque C compilée pour être utilisée sous linux, tu auras les même problèmes

Le extern "C" permet uniquement de faire en sorte qu'un programme C (ou de tout autre langage susceptible de faire appel à des fonctions C ) soit éventuellement en mesure de faire appel à des fonctions compilées en C++.

C reste en effet le "plus petit langage commun", mais C++ n'a pas la prétention de prendre sa place
Après, on pourrait discuter des couts de lecture du code. Certains affirmeraient que le C est plus lisible, d'autre que c'est le C++.
Citation Envoyé par rt15  Voir le message
Le C est souvent considéré comme peu lisible à cause des pointeurs, de la pollution code de gestion des erreurs (On est souvent obligé de tester tous les codes de retours de fonctions), de la quantité de code à écrire pour faire peu de chose.

Et il est souvent difficile d'arriver, quand on arrive sur une fonction donnée sans avoir suivi l'ensemble des appels, de s'assurer que le paramètre passé correspond bien à ce que l'on attend dans cette fonction
Citation Envoyé par rt15  Voir le message
Le C++ est souvent considéré comme peu lisible à cause de sa syntaxe pléthorique qui oblige à être spécialiste : toutes les possibilités C++ ne s'apprennent pas en quelques jours même si on connait bien un autre langage objet. L'enchevêtrement de classes est parfois aussi considéré comme un problème.

C++ est, en effet, un langage complexe.

Il serait difficile de dire le contraire ou d'arriver à faire de manière à ce qu'il ne le soit pas du simple fait que c'est sans doute le seul langage qui ait choisi de permettre la programmation multi paradigme et de ne pas placer de restrictions quant à l'utilisation de certaines possibilités de ces paradigmes (je pense, entre autre, au fameux héritage multiple )

Des langages exclusivement impératifs (comme C) ou exclusivement OO (comme java ou C#) sont très certainement moins complexes, je n'en disconvient pas, mais ils sont aussi beaucoup moins souples quant au code qu'il permettent d'écrire

Il est, très certainement, plus facile de maitriser C, java ou C# que de maitriser C++, mais c'est aussi le prix de la liberté (ou, du moins, d'une certaine liberté )
Citation Envoyé par rt15  Voir le message
Bref, entre C et C++, on aboutit pas au mêmes codes, pas au mêmes binaires, donc pas aux mêmes couts de développement et de maintenance.

Un programme mal conçu restera un programme mal conçu, avec les problème de développement et de maintenance que cela implique quel que soit le langage utilisé!

C++ implique effectivement qu'il faut être beaucoup plus prudent dés les phases de conception et d'analyse technique, mais est-ce un mal

Ceci dit, comme je l'ai écrit dans la discussion précédente (et comme on m'a déjà cité ici ) le choix d'un langage plutôt qu'un autre reste, avant tout, une question personnelle et le fait d'apprécier un langage plus qu'un autre aussi, un peu à la manière des religions ou du fait de préférer les épinards aux brocolis.

Pour en revenir à Linus, il a peut être raison dans le fond, si on se place de son point de vue (qui implique sans doute une méconnaissance du paradigme objets) mais il a tord dans la forme par l'agressivité et l'impolitesse dont il fait preuve.

Il devient cependant de plus en plus difficile de retrouver le contexte dans lequel ce mail a été écrit, à cause du temps qu'il a pu se passer entre le moment où il a été écrit et le moment où il a été, une fois de plus, déterré, et il devient donc de plus en plus difficile de justifier la forme utilisée, mais, s'il était possible de retrouver le contexte original (les mails précédents qui l'on peut etre un peu tanné, les problèmes professionnels ou personnels auxquels il devait faire face à l'époque,... ), il y aurait sans doute moyen de comprendre de tels propos (à défaut de les excuser).

La guerre des langages de programmation a toujours fait rage, et ce, depuis qu'il en existe plus d'un!

Chaque langage a, très certainement, ses avantages et ses inconvénients, et il appartient à tout à chacun d'évaluer personnellement ceux-ci afin de choisir celui qui présente le "meilleur rapport" comme langage de prédilection.

Mais il appartient aussi à tout à chacun de laisser son voisin décider aussi "en son ame et conscience" d'en utiliser un autre, meme si le choix qu'il peut faire n'a pas l'heure de nous plaire.

Et il convient aussi de nous rappeler que l'on est parfois aussi plus énervé certains jours que d'autres et qu'il peut donc aussi nous arriver d'avoir des réactions "disproportionnées" par rapport à une question "simple".

La seule différence avec Linus, c'est peut etre qu'il est (beaucoup) plus connu, et donc "placé sous la loupe" des médias, qui ne manqueront pas de faire tout un foin d'une bagatelle finalement sans importance
Avatar de rt15 rt15 - Membre confirmé http://www.developpez.com
le 10/01/2012 à 20:40
Concernant le coût des exceptions, cf la vidéo http://video.google.com/videoplay?do...99597330548749. Diaporama .

Pour le coût de l'initialisation/finalisation de la runtime (Le temps entre le vrai point d'entré du programme et le main), il semble être effectivement proche sur les tests que je viens de réaliser (gcc vs g++ sous windows, petit programme). Mais par exemple, l'une des différence est que certains que pour du C++ on risque d'y trouver la gestion des constructeurs statiques. Cf "The Dark Underbelly of Constructors" ici.

Etude des différents overheads du C++ ici.

Pour la complexité de la compilation, il existe un fameux tiny C compiler. Il n'existe pas de tiny C++ compiler. Je trouve que ça résume l'idée. Un homme seul peut espérer faire un compilo C dans ses rêves. Un compilo C++, il a même pas le droit d'en rêver.

Niveau temps de compilation, les templates ont toujours eu la réputation d'être lent à la compilation (Quoique comme partout il y a des amélioration, les headers précompilés...). Mais perso c'est surtout le côté visuel (Défilement des logs de compilation) de la chose qui m'a impressionné sur des projets mixtes C et C++.

Mais il est vrai que tout ça ce sont des détails. Des détails qui, cumulés, ou dans certains contextes, peuvent cependant s'avérer gênant.

Linus pointe du doigts des problèmes (Existant ou non) plus important tels que des mauvais design liés à l'objet (Et lié à des programmeurs objet, donc plutôt haut niveau).
Mais sa position est totalement indéfendable car il n'y a pas de réalité technique derrière. Un design n'est pas uniquement le fruit du langage utilisé, et sa qualité est purement subjective (Temps de dev ? Maintenabilité ? Perfs ? Adoption du logiciel ? Beauté des schémas UML ?).
Avatar de Klaim Klaim - Membre expert http://www.developpez.com
le 10/01/2012 à 23:14
Un compilo C++, il a même pas le droit d'en rêver.

Digital Mars est un compilo C++ tout a fait décent et utilisé dans pas mal de boites et qui est développé par 1 personne (et c'est pas son premier).

Niveau temps de compilation, les templates ont toujours eu la réputation d'être lent à la compilation (Quoique comme partout il y a des amélioration, les headers précompilés...). Mais perso c'est surtout le côté visuel (Défilement des logs de compilation) de la chose qui m'a impressionné sur des projets mixtes C et C++.

C'est a confirmer a partir de la prochaine assemblée du commité C++ mais en gros ces points vont être le focus de la prochaine version du standard. En fait on aurait pu avoir les Concepts pour régler le problème des logs mais comme diraient mes camarades Strasbourgeois, c'était pas vraiment "sec".

C'est déjà pas mal qu'on ai des solutions (même partielles) en vu je trouve... les temps de compilation et la lisibilité/le debuggage des templates quand on fait de la metaprog sont vraiment les deux gros points noir du language à mon avis.

L'avantage c'est que les couts d'utilisation du C++ sont évident (pour un dev C++ avertis). Les avantage de l'utilisation sont parfois sacrément plus importants que ses couts, naturellement.
Avatar de Flob90 Flob90 - Membre expert http://www.developpez.com
le 10/01/2012 à 23:56
Le coût des exceptions est vraiment discutable, dans un article posté sur C++Next, l'auteur compare les codes assembleurs d'un programme (simple mais l'idée reste vrai) utilisant les exceptions et d'un utilisant les codes de retours. Au final en situation normal (ie si il n'y a pas de "problèmes"), les performances runtimes sont identiques (même nombre de jump), par contre il y a en effet un surcoût en cas d'exceptions. Sauf que le besoin de performence en cas d'exception est une question qui doit se poser au cas par cas (a-t-on besoin de performance si ce qu'on avait prévu de faire doit déjà être corrigé ?).

Pour le pdf sur les surcoût dans le C++, je l'ai pas lu en entier, mais en survolant, les seuls surcoûts avérés sont ceux relatif au polymorphisme et au RTTI (faibles en mémoire, un peu plus conséquent en temps), mais comme c'est ce qui se "simule" difficilement en C, c'est normal (on paye l'ajout d'une nouvelle fonctionnalité). Il reste aussi ceux relatif au temps de compilation en utilisant les templates, mais de ce côté là il me semble que c'est en train de diminuer (cf les performances de clang je crois).
Avatar de koala01 koala01 - Expert éminent sénior http://www.developpez.com
le 11/01/2012 à 6:16
Citation Envoyé par rt15  Voir le message
Un design n'est pas uniquement le fruit du langage utilisé,

Exactement
et sa qualité est purement subjective (Temps de dev ? Maintenabilité ? Perfs ? Adoption du logiciel ? Beauté des schémas UML ?).

La qualité du design est peut etre subjective, mais celle de la conception l'est déjà, à mon sens, beaucoup moins

Même avec un design qui, d'après certain, peut sembler excellent, il n'empêche qu'il est possible d'avoir des applications particulièrement mal conçues, et, inversement, une application particulièrement bien conçue peut parfaitement présenter un desing "dégueulasse" selon les critères de quelqu'un

Mais au final, on peut quand meme juger de la qualité d'une application sur certain critère particulièrement objectifs:
  • fait elle (ou non) correctement ce que l'on attend d'elle
  • Fait-elle ce que l'on attend d'elle aussi vite que ce que l'on espérait
  • Est-elle facile à faire évoluer quand le client arrive avec un "mais, on vous a pas dit ca a changé (ou il faut ca en plus)"
  • En cas de bug, avec quelle facilité serons nous en mesure d'y remédier
  • J'en oublie sans doute ;-)
Vouloir comparer la rapidité de développement devient déjà subjectif, car il faudrait alors comparer des projets similaires (voir identique) et, surtout, cela dépendra beaucoup trop d'un critère sur lequel nous n'avons aucune prise : la compétence , dans un langage donné, du (des) type(s) qui sera derrière son clavier pour implémenter tout cela:

Certains seront incompétents, quoi qu'il arrive et dans tous les langages, d'autres seront très compétent dans un langage impératif et incompétent dans les langages OO, et pour d'autres encore, ce sera l'inverse.

Le problème, c'est que la (l'in) compétence des développeurs ne va pas seulement intervenir sur les temps de développement, mais également sur la plupart des aspects que je viens de citer
Avatar de oodini oodini - Membre émérite http://www.developpez.com
le 12/01/2012 à 16:14
Citation Envoyé par koala01  Voir le message
Même avec un design qui, d'après certain, peut sembler excellent, il n'empêche qu'il est possible d'avoir des applications particulièrement mal conçues, et, inversement, une application particulièrement bien conçue peut parfaitement présenter un desing "dégueulasse" selon les critères de quelqu'un

Tes propos me troublent, car en anglais, design signifie conception.
Dès lors, quand tu écris "bon design avec une mauvaise conception" (ou l'inverse), cela me rend perplexe. Que veux-tu dire ?
Avatar de Joel F Joel F - Membre chevronné http://www.developpez.com
le 12/01/2012 à 20:23
pour les templates, apprendre a s'en servir bien a propos aide aussi.
Une biblitoheque template qui leak de smessages de 5km ets une ibrairie buggée et doit etre corrigé.
Avatar de - http://www.developpez.com
le 12/01/2012 à 23:02
je trouve que vous avez été très dur avec rt15 sur ce coup, car j'ai beau être 100% codeur C++ et detester le C (simplement comme certains aiment le jaune et d'autre le rouge, pas pour polémiquer), et en ayant beaucoup de respect pour les codeurs d'autres langages qui en savent bien plus que moi sur leur langage et parfois aussi sur le C++, tout ce qu'il a dit dans son premier post était vrai et très bien argumenté.

Il n'a pas eu recours a de nombreux outils utilisés fréquemment sur ce forum, et qui ont bien aidé dans vos réponses, a savoir:
- la mauvaise foi ("au pire, tu ne remarquerais même pas le cout supplémentaire", pour justifier qu'il n'y a pas de cout supplémentaire...)
- l'attaque personnelle ("je ne te trouve pas crédible", "C'est vraiment ergoter", "il y a malhonnêteté morale")
- le manque de connaissance sur le sujet (cf la compatibilité binaire entre les langages, possible en C mais impossible en C++ du a la décoration)
- l'etroitesse d'esprit (défendre son petit bout de connaissance pour éviter de se retrouver vieux, usé et dépassé?)

au contraire, rt15 a semblé faire très attention:
- a ne parler que (presque que) de concret, avec des exemples a la clé
- a pris soin de ne pas exagérer ses chiffres ou ses informartions "le temps de compilation est bien souvent plus élevé et non pas bien plus élevé)
- a nuancé ses propos en citant a la fois des avatanges du C et du C++, pour bien montrer qu'il respectait aussi le point "adverse"
- a conclus de manière normande (ptetre ben qu'oui, ptetre ben qu'non) en disant simplement ce que tout le monde devrait dire depuis le début; c'est pas forcément mieux ou moins bien, c'est surtout différent

ce post devrait être en première page pour les gens qui veulent apprendre le C++ pour avoir une liste objective (et pas une liste faite par les programmeurs C++ pour leur beau langage) (ni le concentré de mauvaise foi de la "frequently questionned answers" sur le C++)

et au lieu de ca vous luis collez des pouces rouges et vous lui dites qu'il y connait rien

comme quoi on est bien dans le domaine de la religion plus que de la science, et que les plus scientifiques d'entre nous sont toujours brulés a feu vif pour hérésie.
Avatar de jblecanard jblecanard - Membre expert http://www.developpez.com
le 16/01/2012 à 15:31
Moi je trouve que tu es très dur avec tous les autres, rt15 a argumenté et les autres aussi. Ce n'est qu'un échange d'arguments comme un autre.

Au contraire de toi, je ne trouve pas que le premier post de rt15 soit justement très bien étayé, en revanche, je trouve que ses suivants le sont. Pas de quoi en faire un fromage.

Je suis d'accord sur le fait qu'il est moralement irréprochable dans la forme des propos. Cela mérite d'être salué.
Avatar de GeantVert13 GeantVert13 - Membre actif http://www.developpez.com
le 07/02/2012 à 16:38
Pendant le GoingNative 2012. Bjarne Stroustrup a répondu, sans le nommer, à Linus Torvalds :
Interactive-Panel-The-Importance-of-Being-Native
à 1h02m50s

En substance :
"Of course C++ is much better for kernel work than C... I mean.... Who'd be stupid enough to say otherwise ?"

Mais bon il ne s'arrête pas là, il argumente...
Avatar de rt15 rt15 - Membre confirmé http://www.developpez.com
le 07/02/2012 à 20:34
Il dit aussi que l'on doit s'adapter au contexte, que certaines features du C++ ne sont pas forcément adaptée à ce cas.

Il dit aussi que pour certains développement, il faut bien connaître non seulement le langage, mais aussi savoir comment cela va se re-transcrire niveau hardware. C'est généralement mieux connu par les développeurs C.

Pour ce qui est du développement niveau kernel, à l'heure actuelle, les OS les plus utilisés sont en C (Tout du moins les points clés).

De même, la plupart des drivers sous Windows sont en C. Voici un document qui parle de l'utilisation du C++ pour les drivers sous windows. Je sais pas vous mais moi ça me donne pas envie. Il y a beaucoup de "limitations" et de "contraintes" en kernel mode (Tout du moins sous windows, je n'ai jamais fait de kernel mode sous un autre OS), que ce soit en C ou en C++. En travaillant en C++ j'aurais vraiment peur de violer une de ces contraintes sans le faire exprès, sans le savoir, à cause de code généré derrière mon dos.

[edit]
Un langage de bas niveau me semble quand même plus approprié pour faire des couches de bas niveau. Après, si on se fiche des perfs, ont peut bien sûr faire de la décoration et de l'encapsulation dans un langage quelconque.
Offres d'emploi IT
Développeur c++ qt
EXTIA - Languedoc Roussillon - Montpellier (34000)
[Qt] Jeu open source, QGV -> QtQuick2
Herman infogerance - Autre - Paris
Chef de projet
SECOND BRIDGE - Ile de France - Paris (75015)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique Qt : Thibaut Cuvelier -