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; }
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, ...)
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
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,
...)
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
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, ...)
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
Fabien LE LEZ
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é ;-)
Ce qui n'empêche qu'il faut effectivement des règles rigoureuses, ne serait-ce que pour éviter que deux headers aient le même nom de garde...
-- ;-)
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é ;-)
Ce qui n'empêche qu'il faut effectivement des règles rigoureuses, ne
serait-ce que pour éviter que deux headers aient le même nom de
garde...
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é ;-)
Ce qui n'empêche qu'il faut effectivement des règles rigoureuses, ne serait-ce que pour éviter que deux headers aient le même nom de garde...
-- ;-)
Fabien LE LEZ
On 20 Mar 2005 23:40:35 -0800, :
Ceci dit, il faut se rappelait qu'à l'époque, la plupart des machines sur le reseau n'avaientt pas de disque local.
À une époque où un PC avec un disque dur énorme et assez de RAM pour y faire tenir un gros projet en entier coûte moins de 500 EUR, tout ça a-t-il encore vraiment un sens ?
-- ;-)
On 20 Mar 2005 23:40:35 -0800, kanze@gabi-soft.fr:
Ceci dit, il faut se rappelait qu'à l'époque, la plupart des
machines sur le reseau n'avaientt pas de disque local.
À une époque où un PC avec un disque dur énorme et assez de RAM pour y
faire tenir un gros projet en entier coûte moins de 500 EUR, tout ça
a-t-il encore vraiment un sens ?
Ceci dit, il faut se rappelait qu'à l'époque, la plupart des machines sur le reseau n'avaientt pas de disque local.
À une époque où un PC avec un disque dur énorme et assez de RAM pour y faire tenir un gros projet en entier coûte moins de 500 EUR, tout ça a-t-il encore vraiment un sens ?
-- ;-)
Fabien LE LEZ
On 21 Mar 2005 11:35:59 +0100, Jean-Marc Bourguet :
Je me demande si un facteur important n'etait pas l'ouverture d'un fichier sur le reseau plus que la taille du fichier
Il me semble que c'est bien le cas. Et qu'un réseau à 1 Gbps n'est pas forcément beaucoup plus efficace qu'un réseau à 10 Mbps sur ce coup-là. D'où l'idée que la première étape doit être de ramener tous les fichiers sur la machine de compilation.
-- ;-)
On 21 Mar 2005 11:35:59 +0100, Jean-Marc Bourguet <jm@bourguet.org>:
Je me demande si un facteur important n'etait pas l'ouverture d'un
fichier sur le reseau plus que la taille du fichier
Il me semble que c'est bien le cas. Et qu'un réseau à 1 Gbps n'est pas
forcément beaucoup plus efficace qu'un réseau à 10 Mbps sur ce
coup-là.
D'où l'idée que la première étape doit être de ramener tous les
fichiers sur la machine de compilation.
On 21 Mar 2005 11:35:59 +0100, Jean-Marc Bourguet :
Je me demande si un facteur important n'etait pas l'ouverture d'un fichier sur le reseau plus que la taille du fichier
Il me semble que c'est bien le cas. Et qu'un réseau à 1 Gbps n'est pas forcément beaucoup plus efficace qu'un réseau à 10 Mbps sur ce coup-là. D'où l'idée que la première étape doit être de ramener tous les fichiers sur la machine de compilation.
-- ;-)
Matthieu Moy
Fabien LE LEZ writes:
Il me semble que c'est bien le cas. Et qu'un réseau à 1 Gbps n'est pas forcément beaucoup plus efficace qu'un réseau à 10 Mbps sur ce coup-là. D'où l'idée que la première étape doit être de ramener tous les fichiers sur la machine de compilation.
Ou d'utiliser un système de cache efficace.
-- Matthieu
Fabien LE LEZ <gramster@gramster.com> writes:
Il me semble que c'est bien le cas. Et qu'un réseau à 1 Gbps n'est pas
forcément beaucoup plus efficace qu'un réseau à 10 Mbps sur ce
coup-là.
D'où l'idée que la première étape doit être de ramener tous les
fichiers sur la machine de compilation.
Il me semble que c'est bien le cas. Et qu'un réseau à 1 Gbps n'est pas forcément beaucoup plus efficace qu'un réseau à 10 Mbps sur ce coup-là. D'où l'idée que la première étape doit être de ramener tous les fichiers sur la machine de compilation.
Ou d'utiliser un système de cache efficace.
-- Matthieu
Fabien LE LEZ
On Mon, 21 Mar 2005 14:32:13 +0100, Matthieu Moy :
D'où l'idée que la première étape doit être de ramener tous les fichiers sur la machine de compilation.
Ou d'utiliser un système de cache efficace.
Ce qui revient à télécharger chaque fichier un seule fois, la première fois qu'on en a besoin. S'il y a beaucoup de petits fichiers, ça peut être moins efficace que les télécharger en bloc.
-- ;-)
On Mon, 21 Mar 2005 14:32:13 +0100, Matthieu Moy
<MatthieuNOSPAM.Moy@imag.fr.invalid>:
D'où l'idée que la première étape doit être de ramener tous les
fichiers sur la machine de compilation.
Ou d'utiliser un système de cache efficace.
Ce qui revient à télécharger chaque fichier un seule fois, la première
fois qu'on en a besoin. S'il y a beaucoup de petits fichiers, ça peut
être moins efficace que les télécharger en bloc.
On Mon, 21 Mar 2005 14:32:13 +0100, Matthieu Moy :
D'où l'idée que la première étape doit être de ramener tous les fichiers sur la machine de compilation.
Ou d'utiliser un système de cache efficace.
Ce qui revient à télécharger chaque fichier un seule fois, la première fois qu'on en a besoin. S'il y a beaucoup de petits fichiers, ça peut être moins efficace que les télécharger en bloc.
-- ;-)
kanze
Fabien LE LEZ wrote:
On 20 Mar 2005 23:40:35 -0800, :
Ceci dit, il faut se rappelait qu'à l'époque, la plupart des machines sur le reseau n'avaientt pas de disque local.
À une époque où un PC avec un disque dur énorme et assez de RAM pour y faire tenir un gros projet en entier coûte moins de 500 EUR, tout ça a-t-il encore vraiment un sens ?
É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.
Ceci dit, avec les machines modernes (avec beaucoup de mémoire pour caches les secteurs), et un reseau plus rapide... Qui sait ?
-- 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 wrote:
On 20 Mar 2005 23:40:35 -0800, kanze@gabi-soft.fr:
Ceci dit, il faut se rappelait qu'à l'époque, la plupart des
machines sur le reseau n'avaientt pas de disque local.
À une époque où un PC avec un disque dur énorme et assez de
RAM pour y faire tenir un gros projet en entier coûte moins de
500 EUR, tout ça a-t-il encore vraiment un sens ?
É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.
Ceci dit, avec les machines modernes (avec beaucoup de mémoire
pour caches les secteurs), et un reseau plus rapide... Qui sait ?
--
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
Ceci dit, il faut se rappelait qu'à l'époque, la plupart des machines sur le reseau n'avaientt pas de disque local.
À une époque où un PC avec un disque dur énorme et assez de RAM pour y faire tenir un gros projet en entier coûte moins de 500 EUR, tout ça a-t-il encore vraiment un sens ?
É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.
Ceci dit, avec les machines modernes (avec beaucoup de mémoire pour caches les secteurs), et un reseau plus rapide... Qui sait ?
-- 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
writes:
É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.
En général, le développeur travaille sur une copie locale et n'accède au serveur que pour les commit/update/merge/...
-- Matthieu
kanze@gabi-soft.fr writes:
É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.
En général, le développeur travaille sur une copie locale et n'accède
au serveur que pour les commit/update/merge/...
É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.
En général, le développeur travaille sur une copie locale et n'accède au serveur que pour les commit/update/merge/...
-- Matthieu
kanze
Matthieu Moy wrote:
writes:
É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.
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.
-- 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:
É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.
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.
--
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
É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.
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.
-- 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
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 ...
-- Matthieu
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 ...
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 ...
