Discussion :

[Emmanuel Deloget]

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 :

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 :

Code :

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

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.

[PhilIvey]

C'est original comme message.

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.

Il faut pas exagérer et justifier un archaïsme hérité ( le système de compilation) par un ajout "récent" du langage.

Le système de compilation du C++ et la syntaxe ambiguë sont les deux faiblesses du langage. Ils rendent moins attractifs certaines forces du langage, comme les templates. Quant je vois que certains de nos projets c# font massivement appel aux generics, alors que l'utilisation des templates est toujours fortement encadrée sur les projets C++, que certains bibliothèques de Boost (MPL,etc...) sont interdites, alors qu'elles serait la solution localement sur certains composants.

Il ne faut pas chercher bien loin le coupable.

[koala01]

Il faut pas exagérer et justifier un archaïsme hérité ( le système de compilation) par un ajout "récent" du langage.

Le système de compilation du C++ et la syntaxe ambiguë sont les deux faiblesses du langage. Ils rendent moins attractifs certaines forces du langage, comme les templates. Quant je vois que certains de nos projets c# font massivement appel aux generics, alors que l'utilisation des templates est toujours fortement encadrée sur les projets C++, que certains bibliothèques de Boost (MPL,etc...) sont interdites, alors qu'elles serait la solution localement sur certains composants.

Il ne faut pas chercher bien loin le coupable.

Là, c'est toi qui exagère en rendant le langage responsable des faiblesses de certains utilisateurs en termes de conception...

Je suis tout à fait d'accord que C++ est lent à la compilation et que c'est un langage qui, revers des libertés qu'il offre, nécessite un respect plus stricte des principes de programmation, d'encapsulation et de POO...

Je travaille personnellement sur un projet important, on ne peut plus pro, mais dans une équipe (un minimum en tout cas) compétante, et on bouffe massivement des template et du boost à foison!!!

Avant d'en arriver à rendre le langage ou les bibliothèques responsables de certaines restrictions imposées dans un projet particulier, commence peut être par t'interroger sur les faiblesses et la (l'in) compétence des responsables de projet et / ou des développeurs de l'équipe

[agrosjea]

Je me demandais si Make ne pouvais pas lancer la compilation des fichier .o en parallèle, avec le multicoeur on gagnerait pas mal de temps !

Edit : magnifique -j permet de spécifier le nombre de tâches à lancer en parallèle !!!!

[Aurelien.Regat-Barrel]

Edit : magnifique -j permet de spécifier le nombre de tâches à lancer en parallèle !!!!

Il suffit de lire l'article de l'auteur pour l'apprendre Il parle aussi des entêtes précompilées.

Personnellement je vois pas trop le but du tsoin tsoin. Avec les templates et la metaprogrammation, le compilateur peut être utilisé comme générateur de code. Forcément, cela a un cout au moment de la compilation.

Comparer avec Delphi c'est comparer des choux avec des chemises. Le Pascal Delphi a été conçu dès l'origine pour être compilable en une seule passe. Ca fait partie de son design et c'est entre autre ce qui a fait son succès. Malgré ça, Delphi c'est mort et quasiment enterré. Cherchez l'erreur!

Jusqu'ici les solutions aux temps élevés de compilation ont été techniques, et tout montre que ça va encore continuer à l'être. Les linkers et compilateurs deviennent multi-threadés. Et y'a des projets comme ccache et IncrediBuild (build distribuées) qui permettent d'obtenir des temps très corrects.

Mais comme toujours avec le C++, toute cette artillerie lourdre montre son intérêt sur de gros projets. C'est sur que pour faire un simple hello world, le C++ apparait vite comme archaïque.

Suffit pas de faire un patch?....

Et bien il suffit que tu le fasses, ce patch! :p

[Florian Goo]

« J'espère que des efforts seront faits pour résoudre le problème », même si cela devrait prendre « au moins 10 ans » et poser des problèmes de rétrocompatibilité.

Des efforts sont faits pour résoudre le problème. Il s'agit des modules (et de la directive « import »), une proposition faite à la base pour C++0x mais pas assez mûre pour y être intégrée. Heureusement, on ne devra probablement pas avoir à attendre C++2x pour les voir arriver :

Heading for a separate TR
These topics are deemed too important to wait for another standard after C++0x before being published, but too experimental to be finalised in time for the next Standard. Therefore, these features will be delivered by a technical report at the earliest opportunity.

Source : http://www.open-std.org/jtc1/sc22/wg...009/n2869.html

Voici le PDF de la proposition : http://www.open-std.org/jtc1/sc22/wg...2007/n2316.pdf

Un jour, on pourra écrire ça :

Code :

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

1
2
3
4
import std; // Module import directive.
int main() {
    std::cout << “Hello World\n”;
}

[bioinfornatics]

C'est drôle comme la syntaxe du c++ évolue pour ressembler au D. Sauf qu'en D ça y est déjà

[Klaim]

D'après le bouquin de D que je lis en ce moment, je dirais plutot que D a intégré des concepts basiques qui sont dans le nouveau standard C++. Mais ensuite l'essentiel des features reste assez différent (de ce que j'ai lu jusqu'ici).

[Florian Goo]

@bioinfornatics
Il y a quelque temps, j'ai ouvert un sujet concernant la légitimité de D à être un digne successeur du C++ : http://www.developpez.net/forums/d78...ute/langage-d/
On pourrait peut-être continuer le débat sur cet autre topic ?