IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Le C++ se compile-t-il trop lentement ? Oui répond Walter Bright, un développeur de compilateur


Sujet :

C++

  1. #1
    Expert éminent sénior
    Avatar de Idelways
    Homme Profil pro
    Développeur Ruby on Rails / iOS
    Inscrit en
    juin 2010
    Messages
    1 374
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur Ruby on Rails / iOS

    Informations forums :
    Inscription : juin 2010
    Messages : 1 374
    Points : 68 507
    Points
    68 507
    Par défaut Le C++ se compile-t-il trop lentement ? Oui répond Walter Bright, un développeur de compilateur
    Le C++ se compile-t-il trop lentement ?
    Oui répond Walter Bright, un développeur de compilateur qui expose les raisons de cette lenteur supposée


    Walter Bright travaille dans le développement de compilateurs de C++ depuis plus de 20 ans. Et selon lui c'est un fait : la compilation du C++ est lente, trop lente. Vraiment trop lente même puisqu'elle peut aller jusqu'à durer des nuits entières.

    Dans un billet, il expose les raisons qui lui semblent expliquer ce problème, un problème souvent cité comme l'une des raisons qui ont motivé le développement par Google du langage de programmation « GO ».

    Walter Bright expose en tout 7 raisons, autant que le nombre (important) de phases de compilations, complètement indépendantes les unes des autres.

    Il explique en substance que l'appel a #include étant textuel - et non symbolique - les appels répétés aux même sources provoqueraient leur analyse complète à plusieurs reprises, même quand #include est protégé par #ifndef.

    Ce mécanisme serait d'autant plus aggravé que les développeurs auraient de plus en plus tendance à « #inclure » tout (et donc aussi n'importe quoi) surtout en programmation générique et pour l'usage des templates.

    Ces critiques n'empêche pas d'aimer le langage. Au contraire, il place de nombreux espoirs dans C++1x, la nouvelle norme pour le langage C++ sur laquelle planche depuis plusieurs années maintenant, un comité de normalisation ISO (et qui pourrait s'appeler C++11).

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

    Mais quand on aime on ne compte pas... et on sait être patient.

    Non ?


    La compilaton du C++ est elle véritablement aussi lente que ce que laisse entendre Walter Bright ?

    Quelles sont selon vous les raisons de cette lenteur ? Comment la gérez-vous ?
    Est-elle préjudiciable à votre productivité ?
    Avez-vous déjà envisagé de passer à Go ou un autre langage à cause de cette lenteur ?



    Source : Blog Dr.Bobb's

    Lire aussi :

    Quel est pour vous le défaut le plus gênant du C++ ? Un développeur chevronné fait la liste des faiblesses de son langage préféré

    C ou C++ ? Quel langage choisir pour un projet sur une cible embarquée ?

    Le moc (meta-object compiler) a-t-il toujours une raison d'exister, maintenant que les compilateurs ont évolué ?

    Les rubriques (actu, forums, tutos) de Développez :

    C++
    Langages


    En collaboration avec Gordon Fowler

  2. #2
    Membre confirmé

    Profil pro
    Inscrit en
    mars 2009
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : mars 2009
    Messages : 349
    Points : 538
    Points
    538
    Par défaut
    Je trouve bizarre que walter bright parle du GO étant un développeur D / C++ ! Mais bon il parle bien du Go dans son blog

  3. #3
    Membre expérimenté Avatar de chaplin
    Profil pro
    Inscrit en
    août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2006
    Messages : 1 215
    Points : 1 674
    Points
    1 674
    Par défaut
    Je travaille sur un projet en delphi de + 100 000 lignes, 10 s à la compilation.

  4. #4
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 611
    Points
    7 611
    Par défaut
    Oui c'est un problème lors de la compilation mais pas seulement. Côté IDE, l'analyse de code pour l'auto-complétion est aussi très difficile tout comme le sont les fonctions de refactoring.

    Il est malheureux que si peu de gens s'intéressent à D.

  5. #5
    Membre habitué
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    134
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2009
    Messages : 134
    Points : 129
    Points
    129
    Par défaut
    @ chaplin : la longueur de code ne fait pas tout... 100 000 lignes dont l'objectif est d'afficher la valeur 1 au moniteur c'est pas la même que 100 000 lignes qui calibrent, modélisent et simulent des modèles mathématiques.
    Au taf : Quad Core/8Go de RAM sous Win Seven 64 - Matlab 2009b 64bit.
    Perso : Core 2 Duo/8Go de RAM Mac OS X 10.6 - Matlab 2009b 64bit

  6. #6
    Membre éclairé Avatar de HanLee
    Profil pro
    Inscrit en
    mai 2004
    Messages
    738
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2004
    Messages : 738
    Points : 854
    Points
    854
    Par défaut
    Citation Envoyé par HAL-9000 Voir le message
    @ chaplin : la longueur de code ne fait pas tout... 100 000 lignes dont l'objectif est d'afficher la valeur 1 au moniteur c'est pas la même que 100 000 lignes qui calibrent, modélisent et simulent des modèles mathématiques.
    Mais ce n'est pas parce qu'un 100 000 lignes de code prend du temps à exécuter que ça prend du temps à être compilé.

    Une boucle infinie...
    Une boucle d'une ligne de calcul très lourde...
    C'est peanuts à compiler!

  7. #7
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    7 489
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 489
    Points : 17 549
    Points
    17 549
    Par défaut
    Ce mécanisme serait d'autant plus aggravé que les développeurs auraient de plus en plus tendance à « #inclure » tout (et donc aussi n'importe quoi) surtout en programmation générique et pour l'usage des templates.
    ce problème est contourné sous Visual Studio avec les en-têtes précompilés ( precompiled headers)

  8. #8
    Membre actif Avatar de amaury pouly
    Profil pro
    Inscrit en
    décembre 2002
    Messages
    157
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France

    Informations forums :
    Inscription : décembre 2002
    Messages : 157
    Points : 219
    Points
    219
    Par défaut
    ce problème est contourné sous Visual Studio avec les en-têtes précompilés ( precompiled headers)
    Les en-têtes précompilées accélère le temps nécessaire à parser le code, c'est indéniable. Toutefois, les problèmes du C++ se situe a bien des niveau. Le plus gros des problème est sa grammaire ambiguë. Certaines expressions doivent être lu jusqu'au dernier caractère pour en déterminer ne serait-ce que le type (déclaration, affectation, ...). Et c'est sans parler du fait qu'il faut "lire" le code plusieurs fois sinon on ne peut pas connaître le type d'une expression.
    Il y a ensuite le problème d'instanciation des templates puisque le compilateur ne vérifie presque rien avant l'instanciation et qu'il doit recommencer pour chaque instanciation différente.
    En bref, le C++1x ne va rien changer à ce problème, c'est le langage lui-même qu'il faudrait changer

    Par exemple, le D dont il est l'auteur résout ces problèmes grâce à une grammaire plus simple et une inclusion non textuelle, mais le D n'est pas parfait non plus.

  9. #9
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par amaury pouly Voir le message
    Les en-têtes précompilées accélère le temps nécessaire à parser le code, c'est indéniable. Toutefois, les problèmes du C++ se situe a bien des niveau. Le plus gros des problème est sa grammaire ambiguë. Certaines expressions doivent être lu jusqu'au dernier caractère pour en déterminer ne serait-ce que le type (déclaration, affectation, ...). Et c'est sans parler du fait qu'il faut "lire" le code plusieurs fois sinon on ne peut pas connaître le type d'une expression.
    GLR, ça change sur LL(1) de Pascal, mais ce n'est pas forcement imbuvable pour autant ^^


    Citation Envoyé par amaury pouly Voir le message
    Il y a ensuite le problème d'instanciation des templates puisque le compilateur ne vérifie presque rien avant l'instanciation et qu'il doit recommencer pour chaque instanciation différente.
    En bref, le C++1x ne va rien changer à ce problème, c'est le langage lui-même qu'il faudrait changer
    qu'est-ce qu'il ne faut pas entendre ?
    1. il est possible de simplifier BEAUCOUP les messages d'erreurs émis malgré les imbrications de templates... les concepts l'ont prouvé,
    2. il existe des outils de création d'interface minimale pour la programmation par contrat dans certains analyseurs qui réaliseraient cette tâche également... et simplifierait la gestion de templates en général



    donc avant de vouloir changer de langage, il faudrait essayer de le comprendre, et surtout de comprendre ce qui ralentit tant toutes évolutions de sa part
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  10. #10
    Membre expérimenté Avatar de chaplin
    Profil pro
    Inscrit en
    août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2006
    Messages : 1 215
    Points : 1 674
    Points
    1 674
    Par défaut
    Citation Envoyé par HAL-9000 Voir le message
    @ chaplin : la longueur de code ne fait pas tout... 100 000 lignes dont l'objectif est d'afficher la valeur 1 au moniteur c'est pas la même que 100 000 lignes qui calibrent, modélisent et simulent des modèles mathématiques.
    Certe, il est vrai que la compilation se fait sur une machine du même calibre que celle qui est dans tes références, cependant, j'ai pas le souvenir d'avoir compilé une librairie (KSDev, glscene, etc ..) qui prenait plus d'une minute, sauf du temps des pentium à 32Mo .

  11. #11
    Membre confirmé

    Profil pro
    Inscrit en
    mars 2009
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : mars 2009
    Messages : 349
    Points : 538
    Points
    538
    Par défaut
    @gorgonite c'est juste que le D facilite grandement ce travail car géré nativement

  12. #12
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par bioinfornatics Voir le message
    @gorgonite c'est juste que le D facilite grandement ce travail car géré nativement
    va falloir revoir votre sens de "nativement"... parce que "intégrable dans le compilo" c'est quand même pas loin du natif

    après D profite de l'absence de guerres de standards et d'éditeurs "avant-gardistes"
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  13. #13
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 290
    Points
    3 290
    Par défaut
    Je trouve bizarre que walter bright parle du GO étant un développeur D / C++ ! Mais bon il parle bien du Go dans son blog
    Ces trois languages sont censé viser les développement système. Fondamentalement ils jouent dans la même cours, mais n'ont pas la même maturité.

    après D profite de l'absence de guerres de standards et d'éditeurs "avant-gardistes"
    Et perds sa crédibilité par manque de standardisation du language et de ses bibliothèque. Les deux cotés d'une même pièce.

    Cela dit, ça s'améliore dans le temps des deux cotés.

    Certe, il est vrai que la compilation se fait sur une machine du même calibre que celle qui est dans tes références, cependant, j'ai pas le souvenir d'avoir compilé une librairie (KSDev, glscene, etc ..) qui prenait plus d'une minute, sauf du temps des pentium à 32Mo
    Essaie de compiler OGRE. A part si tu est dans des conditions optimales (machine plus que 4 coeurs, 4Gh, compilation distribuée sur une ferme de serveurs...) je vois pas comment tu peux compiler cette lib en moins d'une minute.


    C'est evident que le C++ est lent a compilé, on le sait depuis longtemps. Ca m'irrite qu'on se concentre autant sur le probleme sans réfléchir a des solutions (autres que celles connues). Par exemple, le fameux commité a au moins abordé il y a quelques années la possibilité d'avoir un système de module. C'est déjà un bon pas parceque ça réglerai le problème de la compilation en ajouter des instructions (supposant un partage des symboles de l'application entière) et non des commande de pré-compilateur.

  14. #14
    Membre habitué
    Profil pro
    Inscrit en
    novembre 2009
    Messages
    134
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : novembre 2009
    Messages : 134
    Points : 129
    Points
    129
    Par défaut
    Certe, il est vrai que la compilation se fait sur une machine du même calibre que celle qui est dans tes références, cependant, j'ai pas le souvenir d'avoir compilé une librairie (KSDev, glscene, etc ..) qui prenait plus d'une minute, sauf du temps des pentium à 32Mo
    Elles n'ont pas toutes ma cylindrée
    Sinon j'ai effectivement mélangé Compilation avec Execution, mea culpa...
    Au taf : Quad Core/8Go de RAM sous Win Seven 64 - Matlab 2009b 64bit.
    Perso : Core 2 Duo/8Go de RAM Mac OS X 10.6 - Matlab 2009b 64bit

  15. #15
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 448
    Points : 2 199
    Points
    2 199
    Par défaut
    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 :
    Il explique en substance que l'appel a #include étant textuel - et non symbolique - les appels répétés aux même sources provoqueraient leur analyse complète à plusieurs reprises
    a plus

  16. #16
    Membre expérimenté

    Profil pro
    Chef de Projet / Développeur
    Inscrit en
    juin 2002
    Messages
    499
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Chef de Projet / Développeur
    Secteur : Santé

    Informations forums :
    Inscription : juin 2002
    Messages : 499
    Points : 1 414
    Points
    1 414
    Par défaut
    Bonjour,

    Citation Envoyé par chaplin Voir le message
    Je travaille sur un projet en delphi de + 100 000 lignes, 10 s à la compilation.
    C'est aussi parce qu'en Delphi, le développeur se cogne une grosse part du boulot, fait par le compilateur dans les autres langages.

    Je ne dit pas que c'est mal (je trouve le Delphi très lisible), mais Delphi est très verbeux.
    Une partie de tes 100.000 ne sont QUE de la déclaration et n'effectue aucun traitement.

    Cela permet à Delphi de réduire le nombre de passes, mais oblige, lors de la saisie du code, à de nombreux aller/retour entre les sections interface/implémentation - ce qui, comme des temps de compilation longs, n'est pas génial en terme de productivité (même si l'IDE aide).

    Les références circulaires, sont interdite, ce qui oblige à passer par des type ancêtres générique (la VCL est plein de TObject qui dans les fait désignent des objets de bien plus haut niveau), ce qui n'est pas génial non plus.

    Bref, le compilateur est rapide, mais il y a une contre-partie pour le développeur.
    --
    vanquish

  17. #17
    Membre du Club
    Profil pro
    Inscrit en
    mars 2007
    Messages
    91
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 91
    Points : 56
    Points
    56
    Par défaut
    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 !!!!

  18. #18
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    décembre 2005
    Messages
    10 321
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : décembre 2005
    Messages : 10 321
    Points : 18 477
    Points
    18 477
    Par défaut
    Citation Envoyé par kaymak Voir le message
    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.

    ...

    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 :

    tu ne comprends pas... ça se voit au premier coup d'oeil. malgré cela, tu émets des jugements (l'informatique étant le seul domaine où le premier individu passant plus d'une heure sur un ordinateur se permet d'expliquer son métier à ceux qui bossent dessus depuis des années, quoi de plus normal )

    revenons à nos moutons... avant de vouloir déterminer ce qui incombe au compilateur, et ce qui doit être explicitement effectué par l'utilisateur, il faudrait déjà comprendre ce que le langage souhaite faire, vers quel public il se destine, et surtout ce que ça coûterait "d'alléger certaines étapes si ingrates aux yeux d'un novice"

    déjà C++ est un langage utilisé à grande échelle, et ne dépendant pas exclusivement d'un éditeur... il y a donc un comité de "standardisation" & cie, qui empêche en théorie que tout le monde fasse n'importe quoi dans son coin, mais rien n'empêche un éditeur de s'adapter en fonction de contraintes/politiques internes dans la pratique (cf g++ 3.* , VC++ 6, etc)
    les normes prennent du temps à être établies, et des guerres d'influence / de lobby / de personnes sont parfois primordiales sur l'aspect technique des "études".
    donc inutile de comparer à Delphi, Java, Go & cie de ce côté... revenez à la "guerre des Pascal" à l'époque où Borland/Corel/Embarcadero (comme le KGB j'ai un peu de mal à me souvenir de son appellation du jour) ne contrôlait ce marché


    après clairement, il y a des opérations purement syntaxiques à première vue inutiles... mais un bon IDE le fera pour vous
    certains détails barbants subsistent, et les choses avancent à leur rythme... style auto dans C++0/1/2X (on sait jamais je prends mes précautions ), l'idée des concepts qui a fini en guerre de logiciens pour un lambda-prolog dans le moteur de templates (je caricature à peine )


    Citation Envoyé par kaymak Voir le message
    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.
    ok dans l'idée pour cette partie
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  19. #19
    Expert éminent sénior

    Homme Profil pro
    pdg
    Inscrit en
    juin 2003
    Messages
    5 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : juin 2003
    Messages : 5 732
    Points : 10 546
    Points
    10 546
    Billets dans le blog
    3
    Par défaut
    Citation Envoyé par agrosjea Voir le message
    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.

    Citation Envoyé par kaymak Voir le message
    Suffit pas de faire un patch?....
    Et bien il suffit que tu le fasses, ce patch! :p

  20. #20
    Expert éminent sénior
    Avatar de Paul TOTH
    Homme Profil pro
    Freelance
    Inscrit en
    novembre 2002
    Messages
    8 223
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Freelance
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2002
    Messages : 8 223
    Points : 26 627
    Points
    26 627
    Par défaut
    Citation Envoyé par vanquish Voir le message
    Bonjour,

    C'est aussi parce qu'en Delphi, le développeur se cogne une grosse part du boulot, fait par le compilateur dans les autres langages.
    je ne vois pas bien de quoi tu veux parler...en C++ comme en Delphi on déclare les classes on les crées et les détruit (sauf à utiliser des classes statiques en C++), mais au lieu de déclarer, initialiser et invoquer dans une même instruction, le Pascal (et donc Delphi) oblige à déclarer d'un côté, initialiser et ensuite invoquer...il est donc plus verbeux certes, mais il n'y a rien de plus ou de moins qu'en C++. D'ailleurs les propriétés dans Delphi peuvent directement faire référence à un champ privé sans avoir à déclarer des get/set

    Je ne dit pas que c'est mal (je trouve le Delphi très lisible), mais Delphi est très verbeux.
    Une partie de tes 100.000 ne sont QUE de la déclaration et n'effectue aucun traitement.
    que ce soit de la déclaration ou du code, se serra toujours plus rapide à compiler sous Delphi que le même code C++ car le compilateur sait toujours à quoi il a affaire...en c++ on pourra toujours tomber sur une référence externe ambiguë ou non résolue au moment de l'édition de liens.

    Cela permet à Delphi de réduire le nombre de passes, mais oblige, lors de la saisie du code, à de nombreux aller/retour entre les sections interface/implémentation - ce qui, comme des temps de compilation longs, n'est pas génial en terme de productivité (même si l'IDE aide).
    l'IDE offre en effet bon nombre de raccourcis pour ce point (Ctrl + Alt + C et hop ! l'interface est reportée en implementation)

    Les références circulaires, sont interdite, ce qui oblige à passer par des type ancêtres générique (la VCL est plein de TObject qui dans les fait désignent des objets de bien plus haut niveau), ce qui n'est pas génial non plus.
    c'est un prix que j'accepte pour une compilation ultra rapide, et c'est un point qui me pose très rarement problème

    Bref, le compilateur est rapide, mais il y a une contre-partie pour le développeur.
    Il n'est pas "que" rapide : une compilation de plusieurs heures sous Delphi ça n'existe pas ! Et c'est ce rapport gain de compilation/perte en déclaration qui me fait préférer de loin le Pascal aux autres langages compilés.
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

Discussions similaires

  1. [VB.NET]Mes controles graphiques se redessinent trop lentement
    Par noogatix dans le forum Windows Forms
    Réponses: 34
    Dernier message: 04/10/2012, 20h11
  2. Réponses: 60
    Dernier message: 15/04/2011, 06h44
  3. Erreur compilation: fichiers Include trop nombreux
    Par Pierrick584 dans le forum C++
    Réponses: 5
    Dernier message: 21/10/2006, 00h24
  4. [DOS] le texte s'affiche trop lentement
    Par maxonman dans le forum Autres Logiciels
    Réponses: 3
    Dernier message: 09/12/2005, 14h53
  5. Réponses: 8
    Dernier message: 20/05/2005, 20h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo