A mon niveau je vois juste les namespaces un peut comme des "librairies"
pour pouvoir organiser les objets et éviter les collisions (bon terme?).
fondamentalement je ne vois pas trop la différence entre utiliser un
namespace qui contiendrait un objet déclaré static et utiliser une
classe de type singleton ayant leur instance globale ...
les namespaces sont t'il chargés/déchargés quand il y en a
besoin/plus besoin ?
Est-ce que ça coûte plus cher en CPU/RAM d'utiliser un objet à
déclaré à l'interieur d'un namespace plutôt qu'à un objet du même
type déclaré en dehors ?
Sinon comment fait-on pour importer, dans un namespace A des classes
(implémentées dans d'autres fichiers) et faire en sorte que ces classes
ne puissent pas être visibles/utilisés directement ailleurs dans le code
(sans passer par le namespace N) ?
faut t'il obligatoirement en faire une librairie ?
(j'ai tenté des trucs vite fait avec extern mais ça ne compilait pas)
Pareil pour les namespaces, faut t'il obligatoirement quelque chose
comme :
//.h :
namespace A {
int MA();
namespace B { int MB(); }
}
//.cpp(s)
int A::mA() { return 1; }
int A::B::MB() { return 2; }
Éventuellement, oui. Si chaque développeur travaille sur une copie locale (de n'importe quoi), tu as un sacré problème à s'assurer que tout le monde à la version qui lui convient. Tandis qu'avec une solution centralisée, genre Clearcase, il n'y a aucun problème.
Euh, il n'y a pas non plus que clearcase, dans la vie, comme gestionnaire de versions. Et a ma connaissance, clearcase est le seul a charger autant le serveur.
ClearCase est aussi le seul que je regrette. Il a un modele different des autres que j'ai vu et j'aimerais vraiment ne pas devoir l'emuler avec une foret de liens symboliques et en surveillant mes mails et en faisant des cvs update quand j'en recois un comme quoi des fichiers qui m'interessent ont ete modifie.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Éventuellement, oui. Si chaque développeur travaille sur une
copie locale (de n'importe quoi), tu as un sacré problème à
s'assurer que tout le monde à la version qui lui convient.
Tandis qu'avec une solution centralisée, genre Clearcase, il n'y
a aucun problème.
Euh, il n'y a pas non plus que clearcase, dans la vie, comme
gestionnaire de versions. Et a ma connaissance, clearcase est le
seul a charger autant le serveur.
ClearCase est aussi le seul que je regrette. Il a un modele different
des autres que j'ai vu et j'aimerais vraiment ne pas devoir l'emuler
avec une foret de liens symboliques et en surveillant mes mails et en
faisant des cvs update quand j'en recois un comme quoi des fichiers
qui m'interessent ont ete modifie.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Éventuellement, oui. Si chaque développeur travaille sur une copie locale (de n'importe quoi), tu as un sacré problème à s'assurer que tout le monde à la version qui lui convient. Tandis qu'avec une solution centralisée, genre Clearcase, il n'y a aucun problème.
Euh, il n'y a pas non plus que clearcase, dans la vie, comme gestionnaire de versions. Et a ma connaissance, clearcase est le seul a charger autant le serveur.
ClearCase est aussi le seul que je regrette. Il a un modele different des autres que j'ai vu et j'aimerais vraiment ne pas devoir l'emuler avec une foret de liens symboliques et en surveillant mes mails et en faisant des cvs update quand j'en recois un comme quoi des fichiers qui m'interessent ont ete modifie.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Matthieu Moy writes:
writes:
Matthieu Moy wrote:
Euh, il n'y a pas non plus que clearcase, dans la vie, comme gestionnaire de versions. Et a ma connaissance, clearcase est le seul a charger autant le serveur.
C'est aussi à peu près le seul qui marche pour des gros projets. Au moins parmi ce dont je me suis servi. (Mais tous les autres suivait plus ou moins le modèle CVS.)
En général, le développeur travaille sur une copie locale et n'accède au serveur que pour les commit/update/merge/...
Ça marche pour des petits projets. Ça finit vite par poser les problèmes sur les gros.
Tu considères bien entendu le noyau Linux, OpenOffice, Mozilla, GCC, ... comme des petits projets ...
Pour gcc, 133M de sources y compris les tests, c'est pas petit mais c'est il manque un ordre de grandeur pour que j'appelle ca gros.
Pour Linux, OpenOffice et Mozilla, j'ai pas les donnees sous la main.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Euh, il n'y a pas non plus que clearcase, dans la vie, comme
gestionnaire de versions. Et a ma connaissance, clearcase est
le seul a charger autant le serveur.
C'est aussi à peu près le seul qui marche pour des gros projets.
Au moins parmi ce dont je me suis servi. (Mais tous les autres
suivait plus ou moins le modèle CVS.)
En général, le développeur travaille sur une copie locale et
n'accède au serveur que pour les commit/update/merge/...
Ça marche pour des petits projets. Ça finit vite par poser les
problèmes sur les gros.
Tu considères bien entendu le noyau Linux, OpenOffice, Mozilla,
GCC, ... comme des petits projets ...
Pour gcc, 133M de sources y compris les tests, c'est pas petit mais
c'est il manque un ordre de grandeur pour que j'appelle ca gros.
Pour Linux, OpenOffice et Mozilla, j'ai pas les donnees sous la main.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Euh, il n'y a pas non plus que clearcase, dans la vie, comme gestionnaire de versions. Et a ma connaissance, clearcase est le seul a charger autant le serveur.
C'est aussi à peu près le seul qui marche pour des gros projets. Au moins parmi ce dont je me suis servi. (Mais tous les autres suivait plus ou moins le modèle CVS.)
En général, le développeur travaille sur une copie locale et n'accède au serveur que pour les commit/update/merge/...
Ça marche pour des petits projets. Ça finit vite par poser les problèmes sur les gros.
Tu considères bien entendu le noyau Linux, OpenOffice, Mozilla, GCC, ... comme des petits projets ...
Pour gcc, 133M de sources y compris les tests, c'est pas petit mais c'est il manque un ordre de grandeur pour que j'appelle ca gros.
Pour Linux, OpenOffice et Mozilla, j'ai pas les donnees sous la main.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Matthieu Moy
Jean-Marc Bourguet writes:
Pour Linux, OpenOffice et Mozilla, j'ai pas les donnees sous la main.
Pour Linux,
$ du -sh kernel-source-2.6.10.tar 191M kernel-source-2.6.10.tar
Le chiffre que je trouve le plus impressionnant, c'est qu'il y a à peu près 10Mo de patchs par mois intégres dans la branche principale (le tout, avec une seule personne autorisée a faire des commits sur cette branche -- pour ceux qui ne sont pas convaincus qu'une solution décentralisée est applicable a grande échelle).
De mémoire, Mozilla est un peu plus petit, et OpenOffice est encore nettement plus gros.
-- Matthieu
Jean-Marc Bourguet <jm@bourguet.org> writes:
Pour Linux, OpenOffice et Mozilla, j'ai pas les donnees sous la
main.
Pour Linux,
$ du -sh kernel-source-2.6.10.tar
191M kernel-source-2.6.10.tar
Le chiffre que je trouve le plus impressionnant, c'est qu'il y a à peu
près 10Mo de patchs par mois intégres dans la branche principale (le
tout, avec une seule personne autorisée a faire des commits sur cette
branche -- pour ceux qui ne sont pas convaincus qu'une solution
décentralisée est applicable a grande échelle).
De mémoire, Mozilla est un peu plus petit, et OpenOffice est encore
nettement plus gros.
Pour Linux, OpenOffice et Mozilla, j'ai pas les donnees sous la main.
Pour Linux,
$ du -sh kernel-source-2.6.10.tar 191M kernel-source-2.6.10.tar
Le chiffre que je trouve le plus impressionnant, c'est qu'il y a à peu près 10Mo de patchs par mois intégres dans la branche principale (le tout, avec une seule personne autorisée a faire des commits sur cette branche -- pour ceux qui ne sont pas convaincus qu'une solution décentralisée est applicable a grande échelle).
De mémoire, Mozilla est un peu plus petit, et OpenOffice est encore nettement plus gros.
-- Matthieu
kanze
Matthieu Moy wrote:
writes:
Matthieu Moy wrote:
Euh, il n'y a pas non plus que clearcase, dans la vie, comme gestionnaire de versions. Et a ma connaissance, clearcase est le seul a charger autant le serveur.
C'est aussi à peu près le seul qui marche pour des gros projets. Au moins parmi ce dont je me suis servi. (Mais tous les autres suivait plus ou moins le modèle CVS.)
En général, le développeur travaille sur une copie locale et n'accède au serveur que pour les commit/update/merge/...
Ça marche pour des petits projets. Ça finit vite par poser les problèmes sur les gros.
Tu considères bien entendu le noyau Linux, OpenOffice, Mozilla, GCC, ... comme des petits projets ...
Ça dépend. Le seul que je connais un peu, c'est gcc, et c'est effectivement un petit projet. Encore que ça dépend de comment on mésure -- en termes de nombre de collaborateurs, peut-être pas.
Mais lis bien ce que j'ai dit : on peut s'en servir, mais ça pose des problèmes. Non des problèmes irresolvables, mais des problèmes en plus qu'ils faut résoudre. Dans ces développements aussi, il y a le problème de la répartition géographique des développeurs. Qui posent encore plus de problèmes.
J'ajouterais aussi qu'on remarmque bien des faiblesses du côté qualité dans tous les produits que tu as cité. (Malheureusement, leurs concurrents commerciaux ne font pas toujours mieux. Même si Solaris ou MS-Office sont nettement plus robuste que Linux ou OpenOffice, je crois que c'est plutôt un effet d'âge que parce que Sun ou Microsoft utilisent de bons processus de développement.)
-- 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
Matthieu Moy wrote:
kanze@gabi-soft.fr writes:
Matthieu Moy wrote:
Euh, il n'y a pas non plus que clearcase, dans la vie,
comme gestionnaire de versions. Et a ma connaissance,
clearcase est le seul a charger autant le serveur.
C'est aussi à peu près le seul qui marche pour des gros
projets. Au moins parmi ce dont je me suis servi. (Mais tous
les autres suivait plus ou moins le modèle CVS.)
En général, le développeur travaille sur une copie locale
et n'accède au serveur que pour les commit/update/merge/...
Ça marche pour des petits projets. Ça finit vite par poser
les problèmes sur les gros.
Tu considères bien entendu le noyau Linux, OpenOffice,
Mozilla, GCC, ... comme des petits projets ...
Ça dépend. Le seul que je connais un peu, c'est gcc, et c'est
effectivement un petit projet. Encore que ça dépend de comment
on mésure -- en termes de nombre de collaborateurs, peut-être
pas.
Mais lis bien ce que j'ai dit : on peut s'en servir, mais ça
pose des problèmes. Non des problèmes irresolvables, mais des
problèmes en plus qu'ils faut résoudre. Dans ces développements
aussi, il y a le problème de la répartition géographique des
développeurs. Qui posent encore plus de problèmes.
J'ajouterais aussi qu'on remarmque bien des faiblesses du côté
qualité dans tous les produits que tu as cité. (Malheureusement,
leurs concurrents commerciaux ne font pas toujours mieux. Même
si Solaris ou MS-Office sont nettement plus robuste que Linux ou
OpenOffice, je crois que c'est plutôt un effet d'âge que parce
que Sun ou Microsoft utilisent de bons processus de
développement.)
--
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
Euh, il n'y a pas non plus que clearcase, dans la vie, comme gestionnaire de versions. Et a ma connaissance, clearcase est le seul a charger autant le serveur.
C'est aussi à peu près le seul qui marche pour des gros projets. Au moins parmi ce dont je me suis servi. (Mais tous les autres suivait plus ou moins le modèle CVS.)
En général, le développeur travaille sur une copie locale et n'accède au serveur que pour les commit/update/merge/...
Ça marche pour des petits projets. Ça finit vite par poser les problèmes sur les gros.
Tu considères bien entendu le noyau Linux, OpenOffice, Mozilla, GCC, ... comme des petits projets ...
Ça dépend. Le seul que je connais un peu, c'est gcc, et c'est effectivement un petit projet. Encore que ça dépend de comment on mésure -- en termes de nombre de collaborateurs, peut-être pas.
Mais lis bien ce que j'ai dit : on peut s'en servir, mais ça pose des problèmes. Non des problèmes irresolvables, mais des problèmes en plus qu'ils faut résoudre. Dans ces développements aussi, il y a le problème de la répartition géographique des développeurs. Qui posent encore plus de problèmes.
J'ajouterais aussi qu'on remarmque bien des faiblesses du côté qualité dans tous les produits que tu as cité. (Malheureusement, leurs concurrents commerciaux ne font pas toujours mieux. Même si Solaris ou MS-Office sont nettement plus robuste que Linux ou OpenOffice, je crois que c'est plutôt un effet d'âge que parce que Sun ou Microsoft utilisent de bons processus de développement.)
-- 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
Jean-Marc Bourguet wrote:
Marc Boyer writes:
Mais avant de demander aux développeurs d'aller modifier à la main tous les sources, je serais quand même tenté de commencer par ma version.
Ce qui est certain, c'est que c'est une optimisation. Et donc que ce n'est a mettre en place: - que si on a un probleme - qu'apres avoir verifie que ca ameliorait substantivement - qu'en ayant examine les alternatives (qui comportent aussi des en-tetes precompiles, l'amelioration des infrastructures reseau, ...)
Enfin un qui a compris.
Dans le cas que j'ai cité, on n'avait pas commencé avec les gardes extérieurs. Seulement, à un moment donné, il s'avérait qu'on ne pouvait pas faire un build complet des quatre versions dans un week-end. Alors, on a analysé où se passait le temps -- il s'avérait qu'il y avait deux goulot d'étranglement : le temps d'ouverture (non de lecture) des fichiers d'include, et le temps de transfert des libs sur le reseau. Du coup, on a installé les gardes externes, machinellement (on n'a jamais démandé à un développeur de les écrire), et on s'est arrangé pour faire les éditions de liens sur le serveur où se trouver les bibliothèques. (Par la suite, on s'est aussi arrangé pour faire des compilations en parallel, sur des machines libres sur le reseau. Et encore par la suite, on a passé à Clearcase, dont le clearmake fait la parallelisation automatiquement.)
Tout ça, en réponse à un problème qui s'est réelement présent é. Tant qu'il n'y a pas de problème, je ne vois pas de raison d'en chercher une solution.
-- 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
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Mais avant de demander aux développeurs d'aller modifier
à la main tous les sources, je serais quand même tenté de
commencer par ma version.
Ce qui est certain, c'est que c'est une optimisation. Et donc
que ce n'est a mettre en place:
- que si on a un probleme
- qu'apres avoir verifie que ca ameliorait substantivement
- qu'en ayant examine les alternatives (qui comportent aussi des
en-tetes precompiles, l'amelioration des infrastructures reseau,
...)
Enfin un qui a compris.
Dans le cas que j'ai cité, on n'avait pas commencé avec les
gardes extérieurs. Seulement, à un moment donné, il s'avérait
qu'on ne pouvait pas faire un build complet des quatre versions
dans un week-end. Alors, on a analysé où se passait le temps --
il s'avérait qu'il y avait deux goulot d'étranglement : le temps
d'ouverture (non de lecture) des fichiers d'include, et le temps
de transfert des libs sur le reseau. Du coup, on a installé les
gardes externes, machinellement (on n'a jamais démandé à un
développeur de les écrire), et on s'est arrangé pour faire les
éditions de liens sur le serveur où se trouver les
bibliothèques. (Par la suite, on s'est aussi arrangé pour faire
des compilations en parallel, sur des machines libres sur le
reseau. Et encore par la suite, on a passé à Clearcase, dont le
clearmake fait la parallelisation automatiquement.)
Tout ça, en réponse à un problème qui s'est réelement présent é.
Tant qu'il n'y a pas de problème, je ne vois pas de raison d'en
chercher une solution.
--
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
Mais avant de demander aux développeurs d'aller modifier à la main tous les sources, je serais quand même tenté de commencer par ma version.
Ce qui est certain, c'est que c'est une optimisation. Et donc que ce n'est a mettre en place: - que si on a un probleme - qu'apres avoir verifie que ca ameliorait substantivement - qu'en ayant examine les alternatives (qui comportent aussi des en-tetes precompiles, l'amelioration des infrastructures reseau, ...)
Enfin un qui a compris.
Dans le cas que j'ai cité, on n'avait pas commencé avec les gardes extérieurs. Seulement, à un moment donné, il s'avérait qu'on ne pouvait pas faire un build complet des quatre versions dans un week-end. Alors, on a analysé où se passait le temps -- il s'avérait qu'il y avait deux goulot d'étranglement : le temps d'ouverture (non de lecture) des fichiers d'include, et le temps de transfert des libs sur le reseau. Du coup, on a installé les gardes externes, machinellement (on n'a jamais démandé à un développeur de les écrire), et on s'est arrangé pour faire les éditions de liens sur le serveur où se trouver les bibliothèques. (Par la suite, on s'est aussi arrangé pour faire des compilations en parallel, sur des machines libres sur le reseau. Et encore par la suite, on a passé à Clearcase, dont le clearmake fait la parallelisation automatiquement.)
Tout ça, en réponse à un problème qui s'est réelement présent é. Tant qu'il n'y a pas de problème, je ne vois pas de raison d'en chercher une solution.
-- 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
Fabien LE LEZ
On 21 Mar 2005 23:46:45 -0800, :
Tout ça, en réponse à un problème qui s'est réelement présenté. Tant qu'il n'y a pas de problème, je ne vois pas de raison d'en chercher une solution.
Donc, pour revenir au début du thread, je ne suis pas convaincu que pour le projet de départ (deux .cpp, deux .h), les gardes externes soient indispensables pour garder un temps de compilation raisonnable.
Idel sur un petit projet sur lequel je travaille (entre trente et quarante mille lignes de code), pour lequel un build complet demande une centaine de secondes.
-- ;-)
On 21 Mar 2005 23:46:45 -0800, kanze@gabi-soft.fr:
Tout ça, en réponse à un problème qui s'est réelement présenté.
Tant qu'il n'y a pas de problème, je ne vois pas de raison d'en
chercher une solution.
Donc, pour revenir au début du thread, je ne suis pas convaincu que
pour le projet de départ (deux .cpp, deux .h), les gardes externes
soient indispensables pour garder un temps de compilation raisonnable.
Idel sur un petit projet sur lequel je travaille (entre trente et
quarante mille lignes de code), pour lequel un build complet demande
une centaine de secondes.
Tout ça, en réponse à un problème qui s'est réelement présenté. Tant qu'il n'y a pas de problème, je ne vois pas de raison d'en chercher une solution.
Donc, pour revenir au début du thread, je ne suis pas convaincu que pour le projet de départ (deux .cpp, deux .h), les gardes externes soient indispensables pour garder un temps de compilation raisonnable.
Idel sur un petit projet sur lequel je travaille (entre trente et quarante mille lignes de code), pour lequel un build complet demande une centaine de secondes.
-- ;-)
James Kanze
Fabien LE LEZ wrote:
On 20 Mar 2005 23:48:34 -0800, :
on pourrait facilement ajouter des gardes externes au moyen d'un script assez simple.
Tu sais, un script qui ouvre chaque .h, lit le nom de garde, et rajoute les gardes externes, n'est pas tellement plus compliqué ;-)
Tu crois ? Il faut déjà qu'il émule la démarche du compilateur pour trouver l'en-tête. Comprendre les options -I (qu'on lui donne), maitenir une liste de répertoires, etc., etc.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 20 Mar 2005 23:48:34 -0800, kanze@gabi-soft.fr:
on pourrait facilement ajouter des gardes externes au moyen
d'un script assez simple.
Tu sais, un script qui ouvre chaque .h, lit le nom de garde,
et rajoute les gardes externes, n'est pas tellement plus
compliqué ;-)
Tu crois ? Il faut déjà qu'il émule la démarche du compilateur
pour trouver l'en-tête. Comprendre les options -I (qu'on lui
donne), maitenir une liste de répertoires, etc., etc.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
on pourrait facilement ajouter des gardes externes au moyen d'un script assez simple.
Tu sais, un script qui ouvre chaque .h, lit le nom de garde, et rajoute les gardes externes, n'est pas tellement plus compliqué ;-)
Tu crois ? Il faut déjà qu'il émule la démarche du compilateur pour trouver l'en-tête. Comprendre les options -I (qu'on lui donne), maitenir une liste de répertoires, etc., etc.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
