On le voit souvent ce troll. Mais le C++ est pour moi mieux que le C.
Tant qu'on argumente de façon raisonnable, il n'est point de troll!
C'est un langage d'aussi bas niveau que le C, qui offre les mêmes possibilité de performence et d'être « près de la machine » mais tout an étant beaucoup plus expressif. On est donc beaucoup plus productif en C++ qu'en C.
D'un côté, tu as à peu près raison en ce qui concerne les performances: il n'est pas impossible en C++ d'écrire du code bien près de la machine… à ceci près que pour ce faire tu vas laisser tomber toutes les abstractions que tu peux pour ne travailler explicitement que sur des entiers, des pointeurs (au lieu d'itérateurs), et des flottants, si tu fais du calcul numérique.
À mon sens, on néglige trop souvent les interfaces permettant d'écrire des applications complexes dans plusieurs langages différents, à savoir
les ponts avec le C (de nombreux langages peuvent s'interfacer avec le C, notamment Lua, Python, Caml, Scheme/Guile, probablement Perl, … et C++ !)
les ponts avec le Shell (Unix, pipes et parfois tout simplement le système de fichiers).
D'un autre côté, je ne suis pas du tout d'accord en ce qui concerne l'accroissement supposé de la productivité. Le langage C++ a trois gros défauts:
la présence de types de données redondants (char* vs. std::string, pointeurs et références, conteneurs et tableaux, sans oublier les équivalents dans les différentes bibliothèques qu'on va utiliser!)
écrire une bonne hiérarchie d'objets est éminemment difficile car il faut introduire les bonnes abstractions: la méthode naïve consistant à associer une méthode à une classe en fonction de ses arguments (i.e. le C méthode(a,b) est remplacé par le C++ a.méthode(b)) donne des classes fourre-tout qui se comportent comme des programmes où toutes les variables sont globales!
le langage (privé de l'alchimique bibliothèque Boost) a plus de 7 types fonctionnels distincts et incompatibles entre eux (une fonction a -> b ->c peut être globale, membre statique d'une classe arbitraire, membre de la classe a, variantes avec const, variantes avec b = void comme type d'argument) qui oblige à écrire des boucles for. N'ayant pas écrit de boucle for pendant des années (Caml) j'ai redécouvert ce plaisir avec le C++…
La façon productive d'écrire une boucle for est bel et bien for x in container do f(x) et pas du tout ce que proposent les itérateurs!
[^] # Re: Les iles
Posté par Michaël (site web personnel) . En réponse au journal Conseils aux libristes, 3e partie : surmonter l’obsession du « toolkit ». Évalué à 3.
Tant qu'on argumente de façon raisonnable, il n'est point de troll!
D'un côté, tu as à peu près raison en ce qui concerne les performances: il n'est pas impossible en C++ d'écrire du code bien près de la machine… à ceci près que pour ce faire tu vas laisser tomber toutes les abstractions que tu peux pour ne travailler explicitement que sur des entiers, des pointeurs (au lieu d'itérateurs), et des flottants, si tu fais du calcul numérique.
À mon sens, on néglige trop souvent les interfaces permettant d'écrire des applications complexes dans plusieurs langages différents, à savoir
les ponts avec le C (de nombreux langages peuvent s'interfacer avec le C, notamment Lua, Python, Caml, Scheme/Guile, probablement Perl, … et C++ !)
les ponts avec le Shell (Unix, pipes et parfois tout simplement le système de fichiers).
D'un autre côté, je ne suis pas du tout d'accord en ce qui concerne l'accroissement supposé de la productivité. Le langage C++ a trois gros défauts:
la présence de types de données redondants (char* vs. std::string, pointeurs et références, conteneurs et tableaux, sans oublier les équivalents dans les différentes bibliothèques qu'on va utiliser!)
écrire une bonne hiérarchie d'objets est éminemment difficile car il faut introduire les bonnes abstractions: la méthode naïve consistant à associer une méthode à une classe en fonction de ses arguments (i.e. le C méthode(a,b) est remplacé par le C++ a.méthode(b)) donne des classes fourre-tout qui se comportent comme des programmes où toutes les variables sont globales!
le langage (privé de l'alchimique bibliothèque Boost) a plus de 7 types fonctionnels distincts et incompatibles entre eux (une fonction a -> b ->c peut être globale, membre statique d'une classe arbitraire, membre de la classe a, variantes avec
const, variantes avec b =voidcomme type d'argument) qui oblige à écrire des boucles for. N'ayant pas écrit de boucle for pendant des années (Caml) j'ai redécouvert ce plaisir avec le C++…La façon productive d'écrire une boucle
forest bel et bienfor x in container do f(x)et pas du tout ce que proposent les itérateurs!