Envoyé par
kaymak
Je ne suis pas un spécialiste barbu du c++, juste un nouvel utilisateur depuis peu, quelques heures à mon actif.
Et je dois bien dire que les include sont infâmes. D'ailleurs je ne comprend pas pourquoi il faut que j'indique l'usage de la classe <machin>, c'est écris dans le code, le compilo n'à qu'à lire pour le déterminer, rien de bien sorcier.
Les seules raisons qui devraient me pousser à faire cette définition explicite seraient de vouloir forcer une version, mais d'autres mécanismes doivent déjà exister.
d'utiliser des types "dynamique", mais est ce qu'on s'en sert si souvent ? Et est ce que lorsqu'on s'en sert ce n'est pas au développeur de l'indiquer explicitement.
Par ailleurs, au sein d'un même projet genre gui, pas trop gros cela va de soit, on pourrait avoir un seul include sa éviterait les duplications...
De la même manière le compilateur n'émet pas de message lorsque une librairie est chargée inutilement.
Enfin je ne comprend pas pourquoi ce genre d'update devrait attendre une dizaine d'années.... C'est pas une tâche du compilateur sa ? Suffit pas de faire un patch?....
De mon oeil de novice qui n'y connait pas grand chose, tout cela me laisse un goût de jm'en foutisme, particulièrement lorsque je lis ceci :
a plus
C'est original comme message.
Bon, point par point :
Envoyé par
kaymak
Je ne suis pas un spécialiste barbu du c++, juste un nouvel utilisateur depuis peu, quelques heures à mon actif.
Du coup, moins qualifié que d'autre pour parler des forces et faiblesses du langage. Le système de compilation du C++ est lent, on ne peut pas le nier, mais cette lenteur est en grande partie due aux forces intrinsèques du langage - template, etc. Du coup, ne pas connaître le langage rends l'appréciation de ses limites et des conséquences sur le modèle de compilation hasardeuse. Mais oublions ce point, car il n'a que peu d'intérêt.
Et je dois bien dire que les include sont infâmes. D'ailleurs je ne comprend pas pourquoi il faut que j'indique l'usage de la classe <machin>, c'est écris dans le code, le compilo n'à qu'à lire pour le déterminer, rien de bien sorcier.
Impossible au vu du modèle de compilation. Un élément qui n'est pas déclarer avant d'être utilisé est impossible à identifier correctement avant la phase de lien, ce qui n'est pas une bonne chose (ça reviendrais à compiler systématiquement tout le projet avant de pouvoir détecter 90% des erreurs). Ce n'est pas acceptable - d'où la présence des headers (qui ne contiennent pas que des classes, et qui peuvent contenir plusieurs classes si nécessaire ; de plus, la classe machin n'est pas nécessairement définie dans <machin>
.
Les seules raisons qui devraient me pousser à faire cette définition explicite seraient de vouloir forcer une version, mais d'autres mécanismes doivent déjà exister.
Nope. La raison est la validation syntaxique du code. Deux problèmes sont à résoudre : la grammaire ambigüe du C++ fait que des expressions semblables peuvent avoir un traitement fort différent selon le type des symboles utilisé, ou que certaines expressions n'ont pas de sens.
identifier1 identifier2;
est une déclaration de variable si identifier1 est un type, sinon une erreur de syntaxe doit être générée. Et comment savoir si identifier1 est un type ou non sans connaître le symbole ?
Le second problème est lié à la surcharge des fonctions (et des opérateurs).
c = a + b;
Peut faire intervenir deux surcharges (operator=, operator+) ainsi que des conversions implicite de type qui peuvent elles aussi être surchargées.
Par exemple :
1
2
3
4
5
| std::string s1, s2("yy");
const char* s2 = "xx";
s1 = s2 + s3;
// s1 == "yyxx" |
Comment le compilateur peut-il savoir s'il doit générer du code pour une addition (opcode assembleur ADD ou assimilé) ou s'il doit appeler une fonction (CALL) ? S'il veut pouvoir faire le choix, il lui faut connaître le détail des types utilisé. Sans header, cela reviendrait à réécrire le header de manière systématique dans tous les fichiers qui l'utilise.
d'utiliser des types "dynamique", mais est ce qu'on s'en sert si souvent ? Et est ce que lorsqu'on s'en sert ce n'est pas au développeur de l'indiquer explicitement.
Par ailleurs, au sein d'un même projet genre gui, pas trop gros cela va de soit, on pourrait avoir un seul include sa éviterait les duplications...
Je ne comprends pas ce que tu veux dire.
De la même manière le compilateur n'émet pas de message lorsque une librairie est chargée inutilement.
Pour la simple et bonne raison que c'est au linker de le faire, et pas au compilateur. Ca ne fait pas partie du langage. Le compilateur a simplement pour but d'interpréter correctement le programme, et de générer une sortie qui sera comprise par le linker. Le reste est du ressort d'autres outils de la chaine qui n'ont rien à voir avec le C++ (le linker GNU (ld) est utilisé par d'autres toolchain : C, fortran, pascal,...).
Enfin je ne comprend pas pourquoi ce genre d'update devrait attendre une dizaine d'années.... C'est pas une tâche du compilateur sa ? Suffit pas de faire un patch?....
Euh... J'ai du mal à comprendre ce passage. La mise à jour de la norme C++ est suffisamment importante pour avoir nécessité des années de travail. Sans cette norme, aucun compilateur ne fonctionnerait de la même manière et les programmes C++ ne seraient pas portables d'un compilateur à l'autre. Ce n'est pas à un vendeur de compilateur de dicter sa loi sur le marché, surtout lorsque le langage ne lui appartient pas (il peut le faire s'il veut, mais il va développer son produit en pure perte : personne de censé ne l’achètera).
Et faire un patch à quoi ? Au compilateur ? Lequel ? Celui d'Intel, celui de GNU, celui de Microsoft, le front end de EGC, celui de Commeau, celui de Digital Mars, celui de Codeplay, etc... ?
Ca va faire un gros patch, avec beaucoup de binaire dedans...
De mon oeil de novice qui n'y connait pas grand chose, tout cela me laisse un goût de jm'en foutisme, particulièrement lorsque je lis ceci :
Le fait que les plus grand experts du monde se soient penchés pendant 10 ans sur le problème de le mise à jour du standard du C++ te laisse un goût de "jm'en foutisme"? Il faudrait peut être que tu ailles les aider alors, parce que ça, ça me laisse sans voix.
8 |
0 |
La compilaton du C++ est elle véritablement aussi lente que ce que laisse entendre Walter Bright ?
Ben en C++ on fait même "pire", interface dans les .h et implémentation dans le .cpp.
, mais beaucoup de lignes vides) et sous VS 2010 663 Ko (74 899 lignes).
...
