Temp quand tu nous tiens...

Rémy wrote:

<bruckner.olivier@tiscali.fr> a écrit dans le message de
news:40a8a977$0$13002$626a14ce@news.free.fr...

Bonjour !

Me balladant sur différents forums, site internet etc, j'ai remarqué
qu'un critère me semblait crucial au yeux des programmeurs qui préfere
le C au C++ (expecté un débat sur l'OO), Il s'agit du temp de compilation.

Je suis d'accord que le C est plus vite compilé que le C++, mais je me
demande pourquoi y attacher tant d'importance, le programmeur est-il
impatient de nature ? personnellement je pense que le temp de
compilation n'es pas un paramètre crucial, j'entends par là que ce qui
doit se compiler se compilera (pas mal hein ?) et je demande donc si
l'impact sur un grand projet est sensible ou bien est-ce purement
quelque chose que l'on chéri en programmation ?

De mon point de vu celà me semble etre un faux argument (débutant) mais
j'aimerais avoir l'avis d'experts tels que vous.

Merci de m'éclairer.

Bonjour,

Ayant beaucoup développé en C et en C++ sur de gros projets, je peux dire
que c'est effectivement à mes yeux un mauvais argument.

Néanmoins, le temps de compilation peut devenir un problème pour la
productivité d'une équipe. J'ai travaillé sur un projet où la recompilation
de la totalité du code source prenait plus de huit heures sur un serveur
quadri-processeur. Eh bien, on évite d'avoir à modifier certains includes...

Rémy

Je connais un logiciel qui peux compenser le temp de compilation, celà
utilise le principe de calcul partagé.

http://www.xoreax.com/main.htm

Je vais le tester car j'ai la chance de posséder plusieurs ordinateurs
et d'un réseau. peut etre est-ce une bonne solution alternative pour les
entreprise ?

<bruckner.olivier@tiscali.fr> a écrit dans le message de
news:40a8a977$0$13002$626a14ce@news.free.fr...

Bonjour !

Me balladant sur différents forums, site internet etc, j'ai remarqué
qu'un critère me semblait crucial au yeux des programmeurs qui préfere
le C au C++ (expecté un débat sur l'OO), Il s'agit du temp de compilation.

Je suis d'accord que le C est plus vite compilé que le C++, mais je me
demande pourquoi y attacher tant d'importance, le programmeur est-il
impatient de nature ? personnellement je pense que le temp de
compilation n'es pas un paramètre crucial, j'entends par là que ce qui
doit se compiler se compilera (pas mal hein ?) et je demande donc si
l'impact sur un grand projet est sensible ou bien est-ce purement
quelque chose que l'on chéri en programmation ?

De mon point de vu celà me semble etre un faux argument (débutant) mais
j'aimerais avoir l'avis d'experts tels que vous.

Merci de m'éclairer.

Bonjour,

Ayant beaucoup développé en C et en C++ sur de gros projets, je peux dire
que c'est effectivement à mes yeux un mauvais argument.

Néanmoins, le temps de compilation peut devenir un problème pour la
productivité d'une équipe. J'ai travaillé sur un projet où la recompilation
de la totalité du code source prenait plus de huit heures sur un serveur
quadri-processeur. Eh bien, on évite d'avoir à modifier certains includes...

Rémy

<bruckner.olivier@tiscali.fr> a écrit dans le message de
news:40a8c5c3$0$13006$626a14ce@news.free.fr...

Rémy wrote:

<bruckner.olivier@tiscali.fr> a écrit dans le message de
news:40a8a977$0$13002$626a14ce@news.free.fr...

Bonjour !

Me balladant sur différents forums, site internet etc, j'ai remarqué
qu'un critère me semblait crucial au yeux des programmeurs qui préfere
le C au C++ (expecté un débat sur l'OO), Il s'agit du temp de
compilation.

Je suis d'accord que le C est plus vite compilé que le C++, mais je me
demande pourquoi y attacher tant d'importance, le programmeur est-il
impatient de nature ? personnellement je pense que le temp de
compilation n'es pas un paramètre crucial, j'entends par là que ce qui
doit se compiler se compilera (pas mal hein ?) et je demande donc si
l'impact sur un grand projet est sensible ou bien est-ce purement
quelque chose que l'on chéri en programmation ?

De mon point de vu celà me semble etre un faux argument (débutant) mais
j'aimerais avoir l'avis d'experts tels que vous.

Merci de m'éclairer.

Bonjour,

Ayant beaucoup développé en C et en C++ sur de gros projets, je peux
dire

que c'est effectivement à mes yeux un mauvais argument.

Néanmoins, le temps de compilation peut devenir un problème pour la
productivité d'une équipe. J'ai travaillé sur un projet où la
recompilation

de la totalité du code source prenait plus de huit heures sur un serveur
quadri-processeur. Eh bien, on évite d'avoir à modifier certains
includes...

Rémy

Je connais un logiciel qui peux compenser le temp de compilation, celà
utilise le principe de calcul partagé.

http://www.xoreax.com/main.htm

Je vais le tester car j'ai la chance de posséder plusieurs ordinateurs
et d'un réseau. peut etre est-ce une bonne solution alternative pour les
entreprise ?

A condition de développer sous Windows ;-(

Rémy

Rémy wrote:

<bruckner.olivier@tiscali.fr> a écrit dans le message de
news:40a8a977$0$13002$626a14ce@news.free.fr...

Bonjour !

Me balladant sur différents forums, site internet etc, j'ai remarqué
qu'un critère me semblait crucial au yeux des programmeurs qui préfere
le C au C++ (expecté un débat sur l'OO), Il s'agit du temp de compilation.

Je suis d'accord que le C est plus vite compilé que le C++, mais je me
demande pourquoi y attacher tant d'importance, le programmeur est-il
impatient de nature ? personnellement je pense que le temp de
compilation n'es pas un paramètre crucial, j'entends par là que ce qui
doit se compiler se compilera (pas mal hein ?) et je demande donc si
l'impact sur un grand projet est sensible ou bien est-ce purement
quelque chose que l'on chéri en programmation ?

De mon point de vu celà me semble etre un faux argument (débutant) mais
j'aimerais avoir l'avis d'experts tels que vous.

Merci de m'éclairer.

Bonjour,

Ayant beaucoup développé en C et en C++ sur de gros projets, je peux dire
que c'est effectivement à mes yeux un mauvais argument.

Néanmoins, le temps de compilation peut devenir un problème pour la
productivité d'une équipe. J'ai travaillé sur un projet où la recompilation
de la totalité du code source prenait plus de huit heures sur un serveur
quadri-processeur. Eh bien, on évite d'avoir à modifier certains includes...

Si cela est vraiment un probleme, lire

Large-Scale C++ Software Design
http://www.awprofessional.com/titles/0-201-63362-0/

peu apporter de nombreux conseils interessant si le design n'est pas fige.

a+, ld.

Rémy wrote:

<bruckner.olivier@tiscali.fr> a écrit dans le message de
news:40a8c5c3$0$13006$626a14ce@news.free.fr...

Je connais un logiciel qui peux compenser le temp de compilation, celà
utilise le principe de calcul partagé.

http://www.xoreax.com/main.htm

Je vais le tester car j'ai la chance de posséder plusieurs ordinateurs
et d'un réseau. peut etre est-ce une bonne solution alternative pour les
entreprise ?

A condition de développer sous Windows ;-(

En solution libre sous unix il y a distcc.
Il existe aussi ccache qui le complète très bien.
Perso j'utilise les deux et je gagne des heures et des heures de compilo
chaque semaine...


--
Christophe

On Sun, 16 May 2004 14:01:14 +0200, "bruckner.olivier@tiscali.fr"
<bruckner.olivier@tiscali.fr> wrote:

Me balladant sur différents forums, site internet etc, j'ai remarqué
qu'un critère me semblait crucial au yeux des programmeurs qui préfere
le C au C++ (expecté un débat sur l'OO), Il s'agit du temp de compilation.

Ça me paraît passablement douteux, comme critère. Si c'est ça que les
afficionados du C prennent comme argument, le C++ a de beaux jours
devant lui :-)

Le temps de compilation est important sur de gros projets ; aussi
existe-t-il des méthodes pour le réduire, notamment un découpage
judicieux des .cpp et des .h, et un choix des headers à #inclure (si
on peut éviter un #include, on l'évite, par exemple par des
"forward-déclaration" -- du style,
class A;
au lieu de
#include "a.h"
)

Mais de là à modifier totalement le code (voire changer de langage) à
cause d'un temps de compilation trop élevé, il y a un sacré pas.

--
;-)
FLL, Epagneul Breton

On Sun, 16 May 2004 14:01:14 +0200, "bruckner.olivier@tiscali.fr"
<bruckner.olivier@tiscali.fr> wrote:

Me balladant sur différents forums, site internet etc, j'ai remarqué

En me baladant sur différents sites web, j'ai remarqué que la majorité
des cours sur le C++ sont de très bas niveau (du style, le gars qui
croit qu'il maîtrise le C++ parce qu'il a écrit "class" au lieu de
"struct"). D'une manière générale, les conseils et infos qu'on trouve
sur le web sont à prendre avec des pincettes.

Bon réflexe, donc, de venir poser la question ici -- si tu racontes
une connerie, tu trouveras toujours quelqu'un pour démentir :-)

--
;-)
FLL, Epagneul Breton

Christophe de VIENNE <cdevienne@alphacent.com> wrote in message
news:<newscache$oo4vxh$084$1@guronzan.alphacent.com>...

Rémy wrote:

<bruckner.olivier@tiscali.fr> a écrit dans le message de
news:40a8c5c3$0$13006$626a14ce@news.free.fr...

Je connais un logiciel qui peux compenser le temp de compilation,
celà utilise le principe de calcul partagé.

http://www.xoreax.com/main.htm

Je vais le tester car j'ai la chance de posséder plusieurs
ordinateurs et d'un réseau. peut etre est-ce une bonne solution
alternative pour les entreprise ?

A condition de développer sous Windows ;-(

En solution libre sous unix il y a distcc. Il existe aussi ccache qui
le complète très bien. Perso j'utilise les deux et je gagne des
heures et des heures de compilo chaque semaine...

En général, Unix offre les outils nécessaires pour l'implémenter
soi-même d'une façon assez simple ; je m'en suis servi déjà en 1993,
environ. Et certains autres « make » le font automatiquement --
clearmake, par exemple, si tu travailles sous Clearcase.

Le GNU make actuel lancerait plusieurs tâches en parallel, mais tous sur
la même machine. Il ne doit pas être trop difficile à précéder chaque
tâche par un préfixe qui le fait exécuter sur une autre machine.

D'après mon expérience, souvent, c'est aussi le temps du reseau qui
importe, et non seulement le temps CPU. À un client, on a constater une
différence entre plus de deux heures, et vingt minutes, pour une édition
de lien, selon que l'édition de lien s'exécutait sur le serveur, ou sur
une machine quelconque. On utilisait un système à prefixe, comme
ci-dessus, pour faire executer toutes les éditions de liens sur le
serveur. Une à la fois, pour ne pas surcharger le serveur. Aussi, on
maintenait une copie locale sur chaque machine de tous les en-têtes
commun (et qui n'évoluaient pas).

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze@gabi-soft.fr wrote:

Christophe de VIENNE <cdevienne@alphacent.com> wrote in message
news:<newscache$oo4vxh$084$1@guronzan.alphacent.com>...

En solution libre sous unix il y a distcc. Il existe aussi ccache qui
le complète très bien. Perso j'utilise les deux et je gagne des
heures et des heures de compilo chaque semaine...

[...]

Le GNU make actuel lancerait plusieurs tâches en parallel, mais tous sur
la même machine. Il ne doit pas être trop difficile à précéder chaque
tâche par un préfixe qui le fait exécuter sur une autre machine.

Et le préfixe le + simple c'est 'distcc', qui envoit le fichier une fois
passé par le préprocesseur vers une des machines du pool.

[...]

Aussi, on
maintenait une copie locale sur chaque machine de tous les en-têtes
commun (et qui n'évoluaient pas).

Le gros avantage de distcc est qu'il ne necessite pas la recopie des
entêtes sur toutes les machines de la "ferme". Et sa mise en place est
d'une simplicité enfantine, d'autant plus qu'il est présent dans la
plupart des distributions de linux.
On peut même faire relativement facilement du cross-compiling, par
exemple utiliser des machines sous linux pour compiler des programmes
windows (avec mingw), ou bien l'inverse.


--
Christophe

Christophe de VIENNE <cdevienne@alphacent.com> wrote in message
news:<newscache$kakwxh$bom$1@guronzan.alphacent.com>...

kanze@gabi-soft.fr wrote:

Christophe de VIENNE <cdevienne@alphacent.com> wrote in message
news:<newscache$oo4vxh$084$1@guronzan.alphacent.com>...

En solution libre sous unix il y a distcc. Il existe aussi ccache
qui le complète très bien. Perso j'utilise les deux et je gagne des
heures et des heures de compilo chaque semaine...

[...]

Le GNU make actuel lancerait plusieurs tâches en parallel, mais tous
sur la même machine. Il ne doit pas être trop difficile à précéder
chaque tâche par un préfixe qui le fait exécuter sur une autre
machine.

Et le préfixe le + simple c'est 'distcc', qui envoit le fichier une
fois passé par le préprocesseur vers une des machines du pool.

Mais quel est alors l'intérêt ? C'est souvent la lecture des fichiers
d'en-têtes qui prend le plus de temps. Et la sortie du préprocesseur, ça
fait des fichiers d'une certaine taille, qu'on balance en plus sur le
reseau.

Je suppose que ça dépend de la configuration, mais chaque fois que j'ai
eu des problèmes des temps de compilation, le problème était le reseau,
et non le compilateur. (Mais c'était avant l'époque de tout est un
template ; avec les templates, je crois que le compilateur a bien plus à
faire aussi.)

[...]

Aussi, on maintenait une copie locale sur chaque machine de tous les
en-têtes commun (et qui n'évoluaient pas).

Le gros avantage de distcc est qu'il ne necessite pas la recopie des
entêtes sur toutes les machines de la "ferme".

Mais puisque toutes les machines de la ferme sont aussi des machines de
dévelopement, ou bien on récopie, ou bien la majorité des gens font le
préprocessesseur sur une autre machine qu'où il y a des en-têtes, ou
bien toutes les machines ont leur copie des en-têtes.

Je suppose qu'il y a des cas où c'est intéressant, mais c'est toujours
assez limité par rapport à ce que fait par exemple ClearMake.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34