Reprise du message précédent :
Au boulot c'est ce que j'ai, je ne vois aucune concession.

 
Plus précisément c'est dans options/environnement/project & solution.
Décochez track active item in solution list
Décochez display task list when build is finished.
C'est quelque chose comme ça. Et je ne sais plus si ça existe dans .NET 2001.
 
Sinon tes temps de compilation me parraissent pas trop mal vu le nombre de fichiers. Les precompiled marchent très bien, il faut juste prendre soin d'y mettre des headers rarement modifiés. Tu peux aussi tester les directives d'inclusion avant de faire l'include. Cela dit, si incredibuild n'est plus bugué, pas de raison de s'en priver .
 
edit: ortho.

c.a.d ?

 
Xoreax est très réactif, et ils nous ont toujours aidé à régler tous nos problèmes (même en période d'éval). Donc je ne pense pas qu'il y ait de gros bugs rédhibitoires. Par contre il y a pas mal de trucs non documentés.  
 
On avait quand mêle un petit million de lignes, avec 8-10h de compil pour le tout...

 
T'économises le temps d'ouverture / fermeture du fichier si l'include a déjà été fait.

ridicule ...

testé et approuvé par un collègue sous VC 6. J'ai pas fait de tests avancés sous VC.NET.
 
[edit] c'était peut-être codewarrior et non vc6, je ne me rappelle plus et ça remonte à ~4 ans.

Et ton collègue, sa religion lui interdit aussi de faire des "#pragma once" ?

Aucune idée. C'est vrai que c'est plus lisible mais ce pragma n'est ou n'était pas supporté partout.

Le pragma once n'est pas encore supporté dans codewarrior. En tout cas, pas dans la version PS2 3.6 que l'on utilise.
Euh si... elle est peut etre supporté, mais il me semble qu'il y a un bug grossier (genre le compilo regarde que le nom du fichier et pas le chemin complet ou un truc dans le genre).
 
Sinon, pour faire des PCH, ça marche bien pour windows.h. Mais malheureusement, c'est majoritairement le code de nos .h qui ralentisse la compilation. Et comme on les modifie régulièrement... Des fois, je me demande si les commentaires dans les .h ne ralentissent pas la compil/preprocess (en gros chez nous, c'est 50% du poids des fichiers).
 
En tout cas, pour IncrediBuild je le trouve très bien à l'exception du "Update depedencies" qui est très long dans la version 1.31. Mais on va surement passer à la v2.20 qui à l'air plus rapide à ce niveau.
Par contre, c'est vrai qu'il est un peu cher.
 
Et sinon, pour Panini, dans la version 2001, j'ai trouvé uniquement "display task list when build is finished" (j'avais pas bien cherché apparement). Mais lorsque je fais F4, visual m'ouvre toujours la liste des taches pour indiquer les erreurs.

Tiens, ça me fait penser à un mec qui parlait de son expérience dans l'enseignement de la programmation à des débutants. Donc tjrs pareil il explique puis des doigts se lèvent "ça marche pas". Entre autre, il tombe sur un mec qui avait commenté tout son code. "Ben ça compile beaucoup plus vite comme ça!"
Sinon ca coute combien IncrediBuild ?

Nan, c'est toi qui a une mauvaise politique d'inclusion et de développement.
 
Perso j'ai pas de PCH, mais des outils comme ccache me file un bon coup de booster

 
300$. C'est peanuts quand tu considères le gain de productivité que tu as   sur des gros projets.

 
C'est juste une anecdote ou il y a une réponse cachée à ma discrete question méthaphysque sur l'influence des commentaires sur les temps de compil. Parce que si c'est une réponse, je n'ai pas compris (je préfère demander, plutot que de mal interpréter) ce que tu voulais dire.
 
Pour le cout, c'est 300$ pour chaque poste sur lequel il est installé. Une licence, c'est autant un poste qui t'aide à compiler, qu'un poste qui fait de la compil avec IndrediBuild (cf le site web : www.xoreax.com ).
 
Taz: Nan, c'est toi qui a une mauvaise politique d'inclusion et de développement.
 
Ben peut etre. Je me suis souvent poser la question de comment gagner du temps. J'ai essayer plusieurs pistes, mais j'ai pas trouvé de pistes géniales qui change significativement le temps de compil.
En tout cas, si tu veux expliquer la bonne politique d'inclusion je suis très très très interessé (et surement pas le seul).
 
Taz: Perso j'ai pas de PCH, mais des outils comme ccache me file un bon coup de booster
 
Ca fait gagner bcp de temps ? Ca marche comment cet outil ? Il s'intégre dans Visual ?
 
Edit: mise en page

ben y a plein de techniques pour minimiser les dépendances de compilation. Les deux plus connues :  
- chesire cat / pimpl
- forward declration

 
Je ne connaissais pas les deux techniques de nom. En faisant une recherche sur le web, j'ai trouvé la définition des 2 méthodes, qui ne m'était pas inconnue en fait.
Toutes les deux sont basées sur la réduction des dépendances afin de réduire les temps de compilations (fichier à compiler plus petit) et tout aussi important, le nombre de fichier à recompiler en moyenne lorsque l'on modifie du code.
 
La 2ème technique est en effet très bien, et on l'utilise depuis très longtemps (sans savoir qu'elle avait un nom). Elle n'a que très peu d'inconvénient lorsque l'on peut l'utiliser. Le plus gros à mes yeux est peut être celui qui empêche de faire des fonctions inlines qui accèdent aux classes uniquement déclarées.
Voici un petit exemple pour ceux, qui comme moi, ne connaissait pas le nom de la technique cachée derrière "forward declaration" :

 
Pour la 1ère méthode, "pimpl" pour Protected Implementation, je ne connaissais pas le nom. Mais par contre, je connaissais le principe sans jamais l'avoir vraiment essayé.
Voici un petit exemple très simple pour illustrer la technique :

Je trouve que l'idée est vraiment très interessante et très bien pour faire réduire le temps de compilation et les dépendances.
Mais globalement je trouve que les inconvénients sont trop forts : Lisibilité du code moindre, duplication de la déclaration des fonctions, multiplication du nombre de classe (et donc de .h et .cpp), etc...
Bref, j'ai l'impression de faire une usine à gaz (le terme est surement un peu trop fort) pour réduire mes temps de compilation. Hors, ce qui m'importe avant tout, c'est la facilité de lecture, maintenance et d'organisation du code.
 
Mais peut etre que quelqu'un qui utilise cette technique tous les jours me donnera des arguments contraires. En tout cas, je suis preneur.
 
Leander

le pimpl m'a pas l'air terrible. les forward decl j'en fais un usage massif, mais j'ai pas l'impression que l'on puisse "forward déclaré" une inner class ? (genre class prout::toto) ?

tu dupliques rien du tout : le cheshire cat, c'est avant tout une méthode pour planquer des choses. Ça t'as jamais troué le cul que les membres privé soit déclarés publiquement ?

Surtout quand t'as plein de machines de secrétaires idle 95% du temps à ta dispo, hein lam's

Incredibuild,  

il y a plus de 10 ans, on avait concocté un truc dans le genre a coup de batchs, pour partager nos compilos sous windows 95 dans ma boite (des compilos C/C++ metaware). Ca avait pris qques heures a un des devellopeurs a concocter. c'etait assez bousin (on utilisait un disque unix partage par toute les becanes par pc-nfs il me semble comme zone de passage de message si mes souvenirs sont bons). C'etait assez efficace.
Mais bon, ca demandait d'avoir exactement le meme environnement de compil entre tous les postes. Si un compilo etait patché, il fallait qu'il en soit de meme des autres sinon pb...
A+,

sinon y a distcc qui est enfantin à utiliser et gratos

Par experience j'ai constate que la compilation sur un monoposte est largement boostée si ca tourne sur un bi-proc. Mais c'est plus cher...
A+,

ben c'est normal, la compilation, c'est assez lié aux E/S
déjà si tu lances la compilation de plusieurs unités simultanément, tu augmentes fortement l'utilisation de ton CPU

 
En effet, ça a l'air bien. Par contre, ça ne s'intègre pas Visual C++ ...