Discussion :

[Freem]

Je suis assez d'accord avec ceux qui, au cours de la discussion, ont mis en avant la complexité du C++.

Cependant, ils oublient un truc très simple: le C++ compile du C presque correctement (il existe quelques différences, genre le fait que i++ et ++i aient autre chose que la priorité des opérateurs comme différence, une sombre histoire de constructeur par copie pour les objets...).

Autre chose, la complexité plus grande du C++ par rapport au C, n'est pas obligatoire à l'usage.
On peut très bien ne pas faire de classes. Ou on peut très bien ne pas utiliser les templates. On peut ne pas utiliser les exceptions (quoiqu'il me semble que C les gère? J'ai un doute à ce sujet, il n'y a pas une lib standard qui les traite?)...

Le C++ possède simplement des possibilités supérieures au C. En contrepartie, il possède un léger embonpoint dès que l'on utilise ses ajouts au C, dépendant des implémentations des compilateurs (ce qui, d'ailleurs, est aussi vrai pour le C, vu que la norme fonctionne de la même façon pour ces langages: l'implémentation est libre, seul le "contrat" si je puis dire, est fixé). En gros, le fait de devoir passer l'adresse de l'objet aux méthodes non statiques (et non-inline, mais d'une certaine façon ce ne sont pas vraiment des fonctions, plus des macros) qu'il possède coûte un peu de mémoire et de processeur. Cela dis, utiliser une structure en C et passer son adresse à une fonction à le même coût.
Un autre embonpoint est causé par le support de la RTTI, mais une fois encore, il faut utiliser cette fonctionnalité du C++, pour "subir" cette charge supplémentaire.
Et il en va ainsi pour toutes les fonctionnalités ajoutées du C++, à l'exception des template, dont le coût n'est pas répercuté à l'exécution du programme, mais à la compilation (quoique, ils génèrent du code supplémentaire, donc une augmentation de la consommation mémoire du segment ".text" - pour les assemblistes -- s'ils sont utilisés à tord et à travers.)

Mais chacune de ces fonctionnalités, bien utilisée, permet l'augmentation soit de la stabilité, soit des performances, soit de la maintenabilité du code (laquelle peut d'ailleurs résulter résulter en stabilité et performance...) ou de sa réutilisabilité (bien que quand on me sors qu'avant la POO le code était pas réutilisable - et un prof me l'a dis et répété à plusieurs reprises encore il y a peu de temps... j'aurai peut-être pas dû reprendre mes études après avoir bossé... - cela me file de l'urticaire!).
Les problèmes causés par ces baisses de performance sont en fait de simples maux moindres comparé à ceux que ces fonctionnalités résolvent.

Bien sûr, abuser d'une fonctionnalité - en fait, ne pas savoir s'en servir, ou ne savoir se servir que d'elle - cause plus de problème que ça n'en corrige. Utiliser une massette pour enfoncer un clou parce qu'on ne sait pas utiliser un marteau, par exemple, vous brisera vite les mains, et utiliser la même masse pour couper une planche...
Pour autant, la massette est un outil merveilleux lorsqu'utilisée correctement.

Un langage doit être utilisé selon le contexte? Je ne suis pas entièrement d'accord. Pour moi, la plupart des langages peuvent résoudre la plupart des problématiques. Les gens confondent trop souvent langage et bibliothèque officielle du langage. C'est pour ça que "C++ n'est pas fait pour faire des scripts CGI alors que JAVA est super pour ça" me fait sourire. C++ avec une bibliothèque pour gérer les CGI tiens la route aussi. C'est juste que c'est pas "par défaut", pas intégré officiellement. (Je parle de JAVA parce que c'est le 1er qui me viens à l'esprit, hein, et uniquement pour cette raison)
L'utilisation d'un langage plutôt qu'un autre, a mon humble avis est décidée par le fait que les programmeurs devant développer un programme ont une préférence/facilité pour tel ou tel langage ou que la base de code existant est en tel autre langage. Ensuite, niveau technique, toujours selon moi, la seule réelle distinction se situera sur le fait qu'un langage soit compilé "pour de vrai" en code machine (asm, C, C++, d'autres que je ne connaît pas), "pseudo-compilé" en un code machine fait pour tourner sur une machine virtuelle (C#, JAVA, je crois OBJ-C mais j'ai peur de dire une immense co***rie) ou encore juste interprété (vba, python, php, perl), qui, selon le cas, permettent de refiler plus ou moins rapidement un programme sur une quantité variée d'architectures (d'où l'utilisation pour moi pertinente de java pour les applets que l'on trouve sur certaines pages web), selon les contraintes que cette architecture impose (on va pas utiliser du JAVA dans une puce électronique, je pense... et pas que pour son manque de fonctionnalités matérielles, mais parce que la JVM pèse son poids).

Par contre, chaque fonctionnalité d'un langage/framework (ou bibliothèque, peu importe le nom) doit être utilisée selon le contexte.
Utiliser une liste doublement chaînée pour gérer un vulgaire tableau alloué dynamiquement est fonctionnel mais stupide: augmentation du coût en temps et en mémoire du programme, alors qu'un vector, ou mieux, une allocation de variable via un pointeur intelligent (ou pointeur classique, si on veut vraiment les performances maximum) est bien plus approprié.

Donc, en conclusion, oui, j'ai envie de dire que Linus à été beaucoup trop loin dans son mail (quand à qualifier comme il le fait les gens qui font boost et la stl, qui sont quand même des pointures (et pas pointeurs xD) c'est tout simplement une belle démonstration de bêtise). Mais pour autant, vu que Linus est bien plus à l'aise avec le C qu'avec le C++, il a eu entièrement raison d'utiliser ce langage pour GIT.
Par contre, clairement, le C++ est supérieur au C, parce qu'il permet de faire les mêmes choses, et bien plus encore (hummm pourquoi la chanson "denver le dernier dinosaure[...]c'est mon ami et bien plus encore[...]" me reviens en tête? Faut vraiment que je dorme plus moi...).

Voila pour ma contribution au troll ^^ (bon, j'ai essayé de pas trop troller quand même, notez l'effort )

Ah, petit commentaire final tout de même:
L'ASM permet de faire des choses plus souplement que le C et le C++: il est possible de passer un nombre dynamique d'arguments aux fonctions... (Je suis précisément en butte sur un problème de ce type en ce moment...) alors Linus devrait coder en ASM, parce que, franchement, les dev C, ce sont vraiment des boulets qui ne savent rien faire proprement, le C c'est vraiment la porte ouverte à toutes les fenêtres, et je suis sûr que vous serez tous d'accords avec moi xD

[r0d]

L'ASM permet de faire des choses plus souplement que le C et le C++: il est possible de passer un nombre dynamique d'arguments aux fonctions...

En C et en C++ également (et de plusieurs façons, cf. fonctions variadiques).

[Sahengette]

Einstein a dit « Quand il n’y aura plus d’abeilles, l’homme disparaîtra rapidement ».
Einstein fut peut-être un grand physicien, il était médiocre en SVT, l'abeille étant un petit polénisateur par rapport à tous les autres insectes ...

Même histoire,Linus Torvalds, il est trés bon pour programmer des noyaux, il nous l'a prouvé, maintenant est ce qu'il est bon en programmation 3D ? Parceque John Carmack, qui fut lomgtemps un défenseur du C, a finit par lui avouer certains avantages, pour finalement l'utiliser dans ses moteurs, et entre un programmateur de noyau et un programmateur de moteur, je sais qui est le plus adapté à la question d'un langage sur un moteur.

Le C et le C++ sont trés bien comme ils sont, et ont chacun leur "petit domaine de prédilection".

AMHA.

[rt15]

Autre chose, la complexité plus grande du C++ par rapport au C, n'est pas obligatoire à l'usage.

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...

Utiliser un compilo C++ pour compiler du code C s'apparente plus à faire du C que du C++.

Le C++ possède simplement des possibilités supérieures au C. En contrepartie, il possède un léger embonpoint dès que l'on utilise ses ajouts au C.

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++.
-> 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 - Visualiser dans une fenêtre à part

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)

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.

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.

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é).

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...).

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.

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++.
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.
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.

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.

(C#, JAVA, je crois OBJ-C mais j'ai peur de dire une immense co***rie)

En effet, l'objective-C est généralement compilé vers du code natif.

L'ASM permet de faire des choses plus souplement que le C et le C++: il est possible de passer un nombre dynamique d'arguments aux fonctions... (Je suis précisément en butte sur un problème de ce type en ce moment...) alors Linus devrait coder en ASM, parce que, franchement, les dev C, ce sont vraiment des boulets qui ne savent rien faire proprement, le C c'est vraiment la porte ouverte à toutes les fenêtres, et je suis sûr que vous serez tous d'accords avec moi xD

Heureusement, les pauvres développeurs C, C++ et Delphi ont la chance de pouvoir faire de l'ASM inline quand c'est intéressant (Exemple, optimisation dans la jvm). L'asm a cependant un désavantage fondamental : la portabilité du code. C'est gérable pour quelques bouts d'asm inline avec de la compilation conditionnelle, mais pour une appli complète, faut tout réécrire. L'apport du C par rapport à l'asm peut paraître donc bien plus intéressant que l'apport du C++ par rapport au C.

[jblecanard]

Salut rt15

Désolé de te dire ça, bien que ton post contienne beaucoup de vérités, je ne te trouve pas crédible.

Utiliser un compilo C++ pour compiler du code C s'apparente plus à faire du C que du C++.

Qui l'eut cru

-> Le binaire C++ nécessite généralement plus de dépendances ce qui peut poser plus de problèmes de déploiement

Des exemples précis ? A part l'installation d'un binaire supplémentaire (gratuit) sur windows dans certains cas, je ne vois pas. C'est vraiment ergoter.

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.

Les compilateurs C++ respectent eux aussi tous à peu près la norme . C'est un joli troll que tu nous sors là.

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é).

Cet argument n'a aucun sens. Les tableaux C sont présents en C++, std::vector est un autre outil qui offre d'autres fonctionnalités, et n'est pas un tableau C++. De plus, les vectors n'initialisent pas leur contenu, alors je me demande où tu as été chercher ça.

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.

Tu peux développer ? S'il est vrai que la décoration peut poser des problèmes, une fois que l'édition de lien a eu lieu, je ne vois pas en quoi ça se traduit à l'exécution. Je veux bien quelques sources qui appuient ton argument, ça m'intéresse (ce n'est pas ironique).

L'apport du C par rapport à l'asm peut paraître donc bien plus intéressant que l'apport du C++ par rapport au C.

Ca n'a aucun sens : l'apport du C à l'ASM a révolutionné le monde de l'informatique car il a créé un nouveau niveau de codage. C++ est situé au même niveau que C.

[rt15]

Des exemples précis ? A part l'installation d'un binaire supplémentaire (gratuit) sur windows dans certains cas, je ne vois pas. C'est vraiment ergoter.

Il est vrai que sous windows, le déploiement de l'éventuel dépendance C++ msvcpXX.dll va de paire avec l'éventuel dépendance C msvcrXX.dll vu quelle font toutes les deux parties du redistribuable package.
Mais bon, pour du C on facilement se rabattre sur msvcrt.dll de manière à faire un binaire plus portable tout en restant petit (Sans link statique avec la runtime). Impossible en C++.
Concernant les autres plateformes, cf ci-dessus par exemple, le copier coller de mon message précédent ->
Sur ce linux 64 bits, le binaire C nécessite 2 dépendances là ou le binaire C++ en nécessite 5.
La lib libstdc++.so.6 n'est pas dans le même package que libc.so.6 (Du moins sur un certain nombre de distribution linux utilisant des packages) et est donc un peu moins répandue.

Mais c'est vrai que je chipote un peu.

Les compilateurs C++ respectent eux aussi tous à peu près la norme . C'est un joli troll que tu nous sors là.

On respècte plus facilement une norme de 683 pages qui a plus de 20 ans qu'une norme de "683" + XXXXX pages (Je ne connais pas la taille totale du standard C++, mais ça doit être assez impressionant j'imagine).

Producing a reasonably standards-compliant C++ compiler has proven to be a difficult task for compiler vendors in general. For many years, different C++ compilers implemented the C++ language to different levels of compliance to the standard, and their implementations varied widely in some areas such as partial template specialization.

Par exemple, Visual studio a toujours eu la réputation d'avoir du retard par rapport à la norme, surtout jusqu'à VC6 inclus (Exemple bateau, le scope des variables dans les boucles for...).
(A noter qu'ils n'ont et ne vont probablement jamais implémenter complètement C99).
Et VS est a nouveau en train de prendre du retard avec l'arrivée de C++11 qui n'est pas LA priorité pour eux. Pour VC++11, ils travaillent plutôt sur une extension de C++ pour WinRT, au grand dam d'une bonne partie des développeurs.

Voir par exemple la première réponse sur cette page pour des liens vers la non conformance de VC au standard.

Et il n'y a pas que VC et gcc/g++. Il y a aussi xlc_r/xlC_r sur aix, aCC sur HP, cc/CC sur solaris...

Au final difficile de contester qu'il est quand même plus facile d'écrire un code C portable qu'un code C++ portable. Ce n'est pas forcément beaucoup plus dur mais ça l'est toujours un peu et ça vient s'ajouter sur les problèmes de compatibilité POSIX.

Désolé, je ne me souviens plus d'exemple de la vraie vie.

Cela dit, j’admets que je chipote un peu aussi à ce niveau.

Cet argument n'a aucun sens. Les tableaux C sont présents en C++, std::vector est un autre outil qui offre d'autres fonctionnalités, et n'est pas un tableau C++. De plus, les vectors n'initialisent pas leur contenu, alors je me demande où tu as été chercher ça.

On peut bien sur utiliser les tableaux C en C++. Mais ça revient à faire du C, à ne pas profiter des facilités du C++.

Prenons le code suivant (Qui accessoirement appelle size() à chaque tour de boucle):

Code cpp :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <iostream>
#include <vector>
 
using namespace std;
 
int main() 
{
  vector<int> myVector(2000);
 
  for (unsigned int i = 0; i < myVector.size(); i++)
  {
    myVector[i] = i + 1;
  }
 
  for (unsigned int i = 0; i < myVector.size(); i++)
  {
    cout << myVector[i] << endl;
  }
 
  return 0;
}

Sur une bonne partie des implémentation de STL (Toutes ?), les éléments vont être settés deux fois, une fois à zéros par la STL, et une deuxième fois par nous dans la première boucle. La première initialisation n'a aucun intérêt.

Il suffit d'aller voir le constructeur de vector correspondant (Facile avec un débogueur), sous VC6 dans vector:

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
	explicit vector(size_type _N, const _Ty& _V = _Ty(),
		const _A& _Al = _A())
		: allocator(_Al)
		{_First = allocator.allocate(_N, (void *)0);
		_Ufill(_First, _N, _V);
		_Last = _First + _N;
		_End = _Last; }

Le _UFill fait le boulot.

Sous gcc, dans stl_vector.h:

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
     explicit
      vector(size_type __n)
      : _Base(__n, allocator_type())
      { this->_M_impl._M_finish = std::uninitialized_fill_n(this->_M_impl._M_start,
						    __n, value_type()); }

Le uninitialized_fill_n fait le boulot.

D'accord, un très bon compilo pourrait voir que la première initialisation ne sert à rien et ne pas générer le code nécessaire.
Mais dans les faits les compilos ont encore beaucoup de mal à voir ce genre de truc. Et là j'ai un peu la flemme d'étudier l'asm généré (Avec optim) par le code ci-dessus car il est vraiment, vraiment long, moche et bourré de call. Pour deux boucles c'est juste honteux (Le code d'initialisation n'est probablement pas dans le code ci-dessous, mais est très certainement exécuté suite à l'appel du premier call) ->

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
0040135f c745d800000000   mov     dword ptr [ebp-0x28],0x0
00401366 83ec10           sub     esp,0x10
00401369 c745dc00000000   mov     dword ptr [ebp-0x24],0x0
00401370 c745e000000000   mov     dword ptr [ebp-0x20],0x0
00401377 c70424401f0000   mov     dword ptr [esp],0x1f40
0040137e c7459802000000   mov     dword ptr [ebp-0x68],0x2
00401385 e8361a0000       call    image00400000+0x2dc0 (00402dc0)
0040138a 8945d8           mov     [ebp-0x28],eax
0040138d 8d4d90           lea     ecx,[ebp-0x70]
00401390 bfd0070000       mov     edi,0x7d0
00401395 894c2408         mov     [esp+0x8],ecx
00401399 8d98401f0000     lea     ebx,[eax+0x1f40]
0040139f 8945dc           mov     [ebp-0x24],eax
004013a2 895de0           mov     [ebp-0x20],ebx
004013a5 c7459000000000   mov     dword ptr [ebp-0x70],0x0
004013ac 897c2404         mov     [esp+0x4],edi
004013b0 890424           mov     [esp],eax
004013b3 e8b8c00300       call    image00400000+0x3d470 (0043d470)
004013b8 8945dc           mov     [ebp-0x24],eax
004013bb 31c9             xor     ecx,ecx
004013bd eb09             jmp     image00400000+0x13c8 (004013c8)
004013bf 90               nop
004013c0 8d7101           lea     esi,[ecx+0x1]
004013c3 89348a           mov     [edx+ecx*4],esi
004013c6 89f1             mov     ecx,esi
004013c8 8b45dc           mov     eax,[ebp-0x24]
004013cb 8b55d8           mov     edx,[ebp-0x28]
004013ce 29d0             sub     eax,edx
004013d0 c1f802           sar     eax,0x2
004013d3 39c8             cmp     eax,ecx
004013d5 77e9             ja      image00400000+0x13c0 (004013c0)
004013d7 c7458800000000   mov     dword ptr [ebp-0x78],0x0
004013de 8b75dc           mov     esi,[ebp-0x24]
004013e1 8b55d8           mov     edx,[ebp-0x28]
004013e4 29d6             sub     esi,edx
004013e6 c1fe02           sar     esi,0x2
004013e9 3b7588           cmp     esi,[ebp-0x78]
004013ec 0f8697000000     jbe     image00400000+0x1489 (00401489)
004013f2 8b0dc0534400     mov     ecx,[image00400000+0x453c0 (004453c0)]
004013f8 8b5d88           mov     ebx,[ebp-0x78]
004013fb 8b79f4           mov     edi,[ecx-0xc]
004013fe 8b149a           mov     edx,[edx+ebx*4]
00401401 81c7c0534400     add     edi,0x4453c0
00401407 8b470c           mov     eax,[edi+0xc]
0040140a a840             test    al,0x40
0040140c 7504             jnz     image00400000+0x1412 (00401412)
0040140e a808             test    al,0x8
00401410 745e             jz      image00400000+0x1470 (00401470)
00401412 89542404         mov     [esp+0x4],edx
00401416 c70424c0534400   mov     dword ptr [esp],0x4453c0
0040141d c7459801000000   mov     dword ptr [ebp-0x68],0x1
00401424 e8b7ce0200       call    image00400000+0x2e2e0 (0042e2e0)
00401429 890424           mov     [esp],eax
0040142c c7459801000000   mov     dword ptr [ebp-0x68],0x1
00401433 e8c8bf0300       call    image00400000+0x3d400 (0043d400)
00401438 ff4588           inc     dword ptr [ebp-0x78]
0040143b eba1             jmp     image00400000+0x13de (004013de)
0040143d 8d7600           lea     esi,[esi]
00401440 83c518           add     ebp,0x18
00401443 837d9801         cmp     dword ptr [ebp-0x68],0x1
00401447 8b559c           mov     edx,[ebp-0x64]
0040144a 89558c           mov     [ebp-0x74],edx
0040144d 740f             jz      image00400000+0x145e (0040145e)
0040144f 8b45d8           mov     eax,[ebp-0x28]
00401452 85c0             test    eax,eax
00401454 7408             jz      image00400000+0x145e (0040145e)
00401456 890424           mov     [esp],eax
00401459 e8721a0000       call    image00400000+0x2ed0 (00402ed0)
0040145e c74598ffffffff   mov     dword ptr [ebp-0x68],0xffffffff
00401465 8b458c           mov     eax,[ebp-0x74]
00401468 890424           mov     [esp],eax
0040146b e800c50000       call    image00400000+0xd970 (0040d970)
00401470 89542404         mov     [esp+0x4],edx
00401474 c70424c0534400   mov     dword ptr [esp],0x4453c0
0040147b c7459801000000   mov     dword ptr [ebp-0x68],0x1
00401482 e8a9ca0200       call    image00400000+0x2df30 (0042df30)
00401487 eba0             jmp     image00400000+0x1429 (00401429)
00401489 85d2             test    edx,edx
0040148b 7408             jz      image00400000+0x1495 (00401495)
0040148d 891424           mov     [esp],edx
00401490 e83b1a0000       call    image00400000+0x2ed0 (00402ed0)
00401495 8d7d94           lea     edi,[ebp-0x6c]
00401498 893c24           mov     [esp],edi
0040149b e8f0be0000       call    image00400000+0xd390 (0040d390)
004014a0 8d65f4           lea     esp,[ebp-0xc]

Tu peux développer ? S'il est vrai que la décoration peut poser des problèmes, une fois que l'édition de lien a eu lieu, je ne vois pas en quoi ça se traduit à l'exécution. Je veux bien quelques sources qui appuient ton argument, ça m'intéresse (ce n'est pas ironique).

Pour un exemple, regarde du côté de ODE. ODE est écrit en C++, mais l'interface est (Bien sûr) en C, l'auteur détaille ses raisons qui sont d'ailleurs assez proches de ce que Linus explique.

A vu de nez, il a utilisé la méthode classique pour réaliser le wrapper C <-> C++.
Ça donnerait quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void moveBody(void* body, float x, float y, float z)
{
  ((Body)body)->move(x, y, z);
}

On a des méthodes statique genre "C" qui transmette les appels aux objets genre "C++" qui sont passés sous forme de handles. Bilan à l'exécution, on a une redirection qui a un cout, certes faible.

Je chipote aussi.

Ca n'a aucun sens : l'apport du C à l'ASM a révolutionné le monde de l'informatique car il a créé un nouveau niveau de codage. C++ est situé au même niveau que C.

On pourrait aussi penser que le C++ ne se situe pas du tout au même niveau que le C, tout est relatif. On peut voir le C comme une antiquité et le C++ comme un langage puissant (Objet, templates) et relativement moderne (On pourrait trouver java/C# plus modernes).
Le C++ serait alors vu comme une révolution du C (Orienté objet révolution de l'impératif).

Mais c'est justement ce que Linus conteste. Pour lui la soit disant révolution du C++ n'apporte rien si ce n'est des ennuis.

[Invité]

Petite remarque en passant :
On peut créer un vecteur sans initialiser son contenu. Par contre, il faut passer par le constructeur par défaut puis utiliser reserve :

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
16
17
18
19
 
#include <iostream>
#include <vector>
#include <algorithm>
 
using namespace std;
 
int main() 
{
  vector<int> myVector;
  myVector.reserve(2000);
 
  for (unsigned int i = 0; i < myVector.capacity(); i++)
  {
    myVector.push_back(i + 1);
  }
 
  std::copy( myVector.begin(), myVector.end(), std::ostream_iterator<int>());
}

EDIT: Et par rapport aux dépendanced, on peut se passer de la bibliothèque standard avec -nostdlib

[Luc Hermitte]

Aujourd'hui (ce mot est important, je ne parle pas de compilos d'il y a 14 ans comme VC6 ou gcc2.95) la conformité au standard C++03 de VC++ est bonne. Celles de GCC 4.7 et de clang 3.0 aussi.

Les compilos unix ? OK cela reste une plaie, mais dans l'ensemble on s'en sort.

VC11 ne sera pas entièrement conforme (déjà il ne peut pas produire du code qui tourne sous XP ...) au standard qui vient de sortir c'est vrai. Crois-tu vraiment qu'il sera un jour conforme au C99, ne parlons même pas du C2011 ?
Ils ont un objectif de date de livraison fixé, des fonctionnalités retenues pour cette date, et des cycles de validations qui font qu'il faudra attendre VC12, GCC5.0 et probablement clang 4.0 pour que tout le C++2011 soit supporté.
Pour le C++11 on ne parle pas des 4 nouvelles fonctionnalités du C11 qui se battent en duel (dont les redondantes, mais deétemplatisées sur les atomics les modèles de mémoire, etc qui sont déjà grandement implémentées grâce au standard C++ qui est sorti avant et qui a mobilisé quantités d'experts du domaine MT), mais de bien plus. Qu'il faille 2 ans pour se mettre en conformité avec un document de spec ne me surprend pas.


Bref. Et ? Les points problématiques, contemporains (synonyme d'aujourd'hui), sont totalement anecdotiques et liés à des points très arcaniques du langage que l'utilisateur lambda ne rencontrera jamais. Si on ne sort pas de la métaprog poussée, ou des hacks qui s'appuient sur des trucs non spécifiés (dans le standard), on ne s'en rendra jamais compte.

Il y a des vérités, nombreuses, dans ce que tu dis, mais ta dialectique me titille aussi. Quand jblecanard parle du respect de la norme, il parle des outils contemporains, et tu ignores ce fait pour ressasser le vieux temps ou parler d'un logiciel qui pour des raisons (industrielles) évidentes ne peut pas tout faire en 6 jours. Quoique tu fournis un lien, mais je n'y ai pas lu de volonté exprimée de ne jamais supporter le standard.
T'eus parlé de Sun/Oracle, c'eut-été vrai à AMA. De même Sutter qui avait souhaité que VC11 soit le nouveau VC6 est un argument facile. Mais là ... j'ai l'impression d'assister à une manipulation de faits. Sincèrement.


PS: je trouve 100 fois plus de facilités à implémenter du C++ portable (ce que je fais régulièrement) que du C portable car POSIX (et ses multiples implémentations) est agréablement encapsulé dans quantité de libs portables en C++ (boost, ACE, Qt, POCO, etc)
[cf aussi les autotools qui vérifient les 150 variations autour des implémentations de *printf, et j'en passe]

PPS: oui std::vector fait une default-init, au final j'arrive quand même à plus de perfs avec resize() et plus facilement qu'avec p=realloc(p,.....) [oui il y a une erreur dans ce bout de code, c'est volontaire, elle est du même niveau idiomatique que l'appel à size() dans le for, sauf que là c'est un bug].
Au pire, il est facile d'écrire un équivalent qui ne la fasse pas. Cela doit même déjà exister dans boost, et aussi dans tous les libs matricielles C++.
Franchement, c'est un non-argument pour moi (a contrario des problèmes d'ABI, de la lourdeur des flux, ...)


PPPS: le premier qui a parlé d'assembleur faisait de l'humour (démonstration par l'absurde, ironie, tout ça), je ne sais pas pourquoi vous vous prenez sérieusement le choux là dessus.

[jblecanard]

Merci pour cette réponse détaillée rt15.

Pour les vectors, je persiste à dire qu'on compare des choux et des carottes par rapport aux tableaux : les tableaux sont fixes là ou le vector est dynamique. A la limite, on pourrait comparer les tableaux C et le tr1::array de C++11. Là, ça a du sens.

Je me suis en effet lourdé sur l'initialisation : mea culpa.

Pour un exemple, regarde du côté de ODE. ODE est écrit en C++, mais l'interface est (Bien sûr) en C, l'auteur détaille ses raisons qui sont d'ailleurs assez proches de ce que Linus explique.

Merci pour l'exemple. Mais il ne convainc pas :
- Si tout est en C++, où est le surcoût ?
- le choix de l'auteur d'ODE de forcer l'interface en C est à mes yeux très discutable : il aurait très bien pu fournir les deux en se débrouillant correctement.
- Il faut savoir ce qu'on veut : si on veut une lib inter-opérable C et C++, le choix de C++ est lui aussi discutable.

Au final, on est d'accord : tu chipotes .

[Ekleog]

[...]

On respècte plus facilement une norme de 683 pages qui a plus de 20 ans qu'une norme de "683" + XXXXX pages (Je ne connais pas la taille totale du standard C++, mais ça doit être assez impressionant j'imagine).

[...]

Pour un exemple, regarde du côté de ODE. ODE est écrit en C++, mais l'interface est (Bien sûr) en C, l'auteur détaille ses raisons qui sont d'ailleurs assez proches de ce que Linus explique.

A vu de nez, il a utilisé la méthode classique pour réaliser le wrapper C <-> C++.
Ça donnerait quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void moveBody(void* body, float x, float y, float z)
{
  ((Body)body)->move(x, y, z);
}

On a des méthodes statique genre "C" qui transmette les appels aux objets genre "C++" qui sont passés sous forme de handles. Bilan à l'exécution, on a une redirection qui a un cout, certes faible.

Je chipote aussi.

[...]

La norme fait 1334 pages. (enfin, pour le dernier draft public du C++11 - il y en a 3 de plus dans le final, j'espère !)

Pour ODE, si la méthode utilisée est celle-ci, elle me semble parfaitement normale !
En effet, il n'y a pas de surcout. Parce que, dans tous les cas, l'appel à body.move(x, y, z) va appeller une fonction C-like comme _Body_move(&body, x, y, z).
Et un compilateur pourra donc inliner body->move pour la remplacer par la _Body_move.
Du coup, le code deviendrait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void moveBody(void* body, float x, float y, float z)
{
  Body * this = static_cast<Body*>(body);
  // Le code de Body::move directement
}

Et n'aurait plus la moindre redirection.
Au passage, il y a une faute de frappe : ce devrait être ((Body*)body)->move(x, y, z);

[koala01]

Salut

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

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

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...

-> 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 - Visualiser dans une fenêtre à part

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

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

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 )

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

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

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++.

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

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é )

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

[rt15]

Concernant le coût des exceptions, cf la vidéo . Diaporama là.

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 ?).

[Klaim]

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.

[Flob90]

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).

[koala01]

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

[oodini]

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 ?

[Joel F]

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é.

[screetch]

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.

[jblecanard]

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é.

[GeantVert13]

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...