Est-ce que cela vous arrive
de separer l'implementation d'une meme classe en plusieurs .cpp ?
J'en suis venu a cette idee car les classes
de la bibliotheque sur laquelle je travaille,
sont tellement imbriquees
que si je veux developper un projet
qui fait appel a tres peu de classes et de methodes,
je suis quasiment oblige de recompiler toutes les methodes.
Sans aller jusqu'a : une methode par fichier .cpp,
est-ce que vous avez une politique sur la specialisation des .cpp ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christophe Lephay
Cyril Gruau wrote:
En fait, je cherche un moyen de dire a l'editeur de lien : ne resoud que les symboles dont tu as besoin, et non pas tous ceux que tu vois afin de ne pas m'obliger a tout compiler.
Il y a un peu contradiction dans les termes...
en général, l'éditeur de lien ne prend que ce dont il a besoin. Le cas échéant, tu peux l'aider en lui fournissant certaines options (la manière est propre à chaque éditeur de lien). Concernant la compilation, il n'y a pas de raison que le compilateur compile du code inutilisé, à moins que tu n'es tout mis dans des fichiers entêtes. Par ailleurs, si les entêtes sont de taille conséquente, beaucoup de compilateurs permettent de les précompiler si elles ne sont pas modifiées (là encore, spécifique à chaque compilateur).
Chris
Cyril Gruau wrote:
En fait, je cherche un moyen de dire a l'editeur de lien :
ne resoud que les symboles dont tu as besoin,
et non pas tous ceux que tu vois
afin de ne pas m'obliger a tout compiler.
Il y a un peu contradiction dans les termes...
en général, l'éditeur de lien ne prend que ce dont il a besoin. Le cas
échéant, tu peux l'aider en lui fournissant certaines options (la manière
est propre à chaque éditeur de lien). Concernant la compilation, il n'y a
pas de raison que le compilateur compile du code inutilisé, à moins que tu
n'es tout mis dans des fichiers entêtes. Par ailleurs, si les entêtes sont
de taille conséquente, beaucoup de compilateurs permettent de les
précompiler si elles ne sont pas modifiées (là encore, spécifique à chaque
compilateur).
En fait, je cherche un moyen de dire a l'editeur de lien : ne resoud que les symboles dont tu as besoin, et non pas tous ceux que tu vois afin de ne pas m'obliger a tout compiler.
Il y a un peu contradiction dans les termes...
en général, l'éditeur de lien ne prend que ce dont il a besoin. Le cas échéant, tu peux l'aider en lui fournissant certaines options (la manière est propre à chaque éditeur de lien). Concernant la compilation, il n'y a pas de raison que le compilateur compile du code inutilisé, à moins que tu n'es tout mis dans des fichiers entêtes. Par ailleurs, si les entêtes sont de taille conséquente, beaucoup de compilateurs permettent de les précompiler si elles ne sont pas modifiées (là encore, spécifique à chaque compilateur).
Chris
Jacti
Est-ce que cela vous arrive de separer l'implementation d'une meme classe en plusieurs .cpp ?
C'est plutôt un problème de conception. Ce n'est pas du tout recommandé car ça complique les dépendances et bonjour la maintenance... Personnellement, ça ne m'est jamais arrivé.
J'en suis venu a cette idee car les classes de la bibliotheque sur laquelle je travaille, sont tellement imbriquees que si je veux developper un projet qui fait appel a tres peu de classes et de methodes, je suis quasiment oblige de recompiler toutes les methodes.
Je ne suis pas sûr de comprendre ce que tu dis. Veux-tu dire que la bibliothèque que tu utilises est mal fichue ?
Sans aller jusqu'a : une methode par fichier .cpp, est-ce que vous avez une politique sur la specialisation des .cpp ?
Pour les classes qu'on développe : à un fichier .h doit correspondre un fichier .ccp. Dans le cas de l'héritage, si les classes dérivées sont petites, on peut les regrouper dans un seul .h. Ma politique c'est que les classes abstraites sont toujours seules dans un .h car elles représentent l'interface (donc le contrat avec les classes "clientes").
La règle c'est de modulariser au maximum. J'ai fait un simulateur de processeur dont la plus grosse méthode faisait 6 lignes (oui six !) d'instructions (je ne compte pas l'en-tête ni les déclarations).
Jacti
Est-ce que cela vous arrive
de separer l'implementation d'une meme classe en plusieurs .cpp ?
C'est plutôt un problème de conception.
Ce n'est pas du tout recommandé car ça complique les dépendances
et bonjour la maintenance...
Personnellement, ça ne m'est jamais arrivé.
J'en suis venu a cette idee car les classes
de la bibliotheque sur laquelle je travaille,
sont tellement imbriquees
que si je veux developper un projet
qui fait appel a tres peu de classes et de methodes,
je suis quasiment oblige de recompiler toutes les methodes.
Je ne suis pas sûr de comprendre ce que tu dis.
Veux-tu dire que la bibliothèque que tu utilises est mal fichue ?
Sans aller jusqu'a : une methode par fichier .cpp,
est-ce que vous avez une politique sur la specialisation des .cpp ?
Pour les classes qu'on développe : à un fichier .h doit correspondre
un fichier .ccp.
Dans le cas de l'héritage, si les classes dérivées sont petites, on peut
les regrouper
dans un seul .h.
Ma politique c'est que les classes abstraites sont toujours seules dans
un .h
car elles représentent l'interface (donc le contrat avec les classes
"clientes").
La règle c'est de modulariser au maximum.
J'ai fait un simulateur de processeur dont la plus grosse méthode
faisait 6 lignes (oui six !) d'instructions (je ne compte pas l'en-tête
ni les déclarations).
Est-ce que cela vous arrive de separer l'implementation d'une meme classe en plusieurs .cpp ?
C'est plutôt un problème de conception. Ce n'est pas du tout recommandé car ça complique les dépendances et bonjour la maintenance... Personnellement, ça ne m'est jamais arrivé.
J'en suis venu a cette idee car les classes de la bibliotheque sur laquelle je travaille, sont tellement imbriquees que si je veux developper un projet qui fait appel a tres peu de classes et de methodes, je suis quasiment oblige de recompiler toutes les methodes.
Je ne suis pas sûr de comprendre ce que tu dis. Veux-tu dire que la bibliothèque que tu utilises est mal fichue ?
Sans aller jusqu'a : une methode par fichier .cpp, est-ce que vous avez une politique sur la specialisation des .cpp ?
Pour les classes qu'on développe : à un fichier .h doit correspondre un fichier .ccp. Dans le cas de l'héritage, si les classes dérivées sont petites, on peut les regrouper dans un seul .h. Ma politique c'est que les classes abstraites sont toujours seules dans un .h car elles représentent l'interface (donc le contrat avec les classes "clientes").
La règle c'est de modulariser au maximum. J'ai fait un simulateur de processeur dont la plus grosse méthode faisait 6 lignes (oui six !) d'instructions (je ne compte pas l'en-tête ni les déclarations).
Jacti
Cyril.Gruau
On Wed, 29 Oct 2003 17:27:14 +0100, Jacti wrote:
Je ne suis pas sûr de comprendre ce que tu dis.
En fait, je cherche un moyen de dire a l'editeur de lien : ne resoud que les symboles dont tu as besoin, et non pas tous ceux que tu vois afin de ne pas m'obliger a tout compiler.
Cyril
On Wed, 29 Oct 2003 17:27:14 +0100, Jacti <jacti@jacti-antispam.com>
wrote:
Je ne suis pas sûr de comprendre ce que tu dis.
En fait, je cherche un moyen de dire a l'editeur de lien :
ne resoud que les symboles dont tu as besoin,
et non pas tous ceux que tu vois
afin de ne pas m'obliger a tout compiler.
En fait, je cherche un moyen de dire a l'editeur de lien : ne resoud que les symboles dont tu as besoin, et non pas tous ceux que tu vois afin de ne pas m'obliger a tout compiler.
Cyril
Luc Hermitte
(Cyril Gruau) wrote in news:3f9fd807.80483158 @news.cma.fr:
Est-ce que cela vous arrive de separer l'implementation d'une meme classe en plusieurs .cpp ?
Une fois. Dans le cas d'un gros composant COM qui implémentait plusieurs interfaces.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Cyril.Gruau@cemef.cma.fr (Cyril Gruau) wrote in news:3f9fd807.80483158
@news.cma.fr:
Est-ce que cela vous arrive de separer l'implementation d'une meme classe
en plusieurs .cpp ?
Une fois. Dans le cas d'un gros composant COM qui implémentait plusieurs
interfaces.
--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>
(Cyril Gruau) wrote in news:3f9fd807.80483158 @news.cma.fr:
Est-ce que cela vous arrive de separer l'implementation d'une meme classe en plusieurs .cpp ?
Une fois. Dans le cas d'un gros composant COM qui implémentait plusieurs interfaces.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Jean-Marc Molina
Bonjour Cyril,
1 classe = 1 .h et 1.cpp Après tu peux organiser tes classes en paquets/modules en utilisant les namespaces. Niveau compilation en utilisant des outils pros comme Visual C++ tu n'auras pas de problèmes de compilation, c'est incrémental et seuls les fichiers modifiés et les dépendances sont recompilés. Gain de temps :). Sinon il existe aussi des design patterns pour te faciliter la vie, en utilisant les facades et Visual C++ on peut arriver à quelque chose de pas mal, moi je préfère en rester aux systèmes des includes à inclure pour compiler un .cpp en particulier. Au moins on garde le contrôle et on sait ce qu'on utilise. Par contre niveau maintenance ça peut être laborieux.
JM
-- Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
Bonjour Cyril,
1 classe = 1 .h et 1.cpp
Après tu peux organiser tes classes en paquets/modules en utilisant les
namespaces.
Niveau compilation en utilisant des outils pros comme Visual C++ tu n'auras
pas de problèmes de compilation, c'est incrémental et seuls les fichiers
modifiés et les dépendances sont recompilés. Gain de temps :).
Sinon il existe aussi des design patterns pour te faciliter la vie, en
utilisant les facades et Visual C++ on peut arriver à quelque chose de pas
mal, moi je préfère en rester aux systèmes des includes à inclure pour
compiler un .cpp en particulier. Au moins on garde le contrôle et on sait ce
qu'on utilise. Par contre niveau maintenance ça peut être laborieux.
JM
--
Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
1 classe = 1 .h et 1.cpp Après tu peux organiser tes classes en paquets/modules en utilisant les namespaces. Niveau compilation en utilisant des outils pros comme Visual C++ tu n'auras pas de problèmes de compilation, c'est incrémental et seuls les fichiers modifiés et les dépendances sont recompilés. Gain de temps :). Sinon il existe aussi des design patterns pour te faciliter la vie, en utilisant les facades et Visual C++ on peut arriver à quelque chose de pas mal, moi je préfère en rester aux systèmes des includes à inclure pour compiler un .cpp en particulier. Au moins on garde le contrôle et on sait ce qu'on utilise. Par contre niveau maintenance ça peut être laborieux.
JM
-- Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
Cyril.Gruau
On Wed, 29 Oct 2003 17:10:29 +0100, "Christophe Lephay" wrote:
en général, l'éditeur de lien ne prend que ce dont il a besoin.
Et pourtant : j'ai un editeur de lien qui veut resoudre tous les symboles qu'il trouve dans le fichier objet (.o ou .obj), ce qui m'oblige a lui fournir d'autres fichiers objet, pour lesquels il essaie a nouveau de resoudre tous les symboles.
Finalement, je sui oblige de lui fournir tous les fichiers objets ou presque, ce qui m'oblige a compiler tous les fichiers sources (ou presque).
Le cas échéant, tu peux l'aider en lui fournissant certaines options (la manière est propre à chaque éditeur de lien).
Pour l'editeur de lien de gcc, quelles sont ces options par exemple ? Pour l'editeur de lien de VC++ ? Pour celui de Portland group ?
Ca m'interesse beaucoup !
Cyril
On Wed, 29 Oct 2003 17:10:29 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr> wrote:
en général, l'éditeur de lien ne prend que ce dont il a besoin.
Et pourtant : j'ai un editeur de lien qui veut resoudre tous les
symboles qu'il trouve dans le fichier objet (.o ou .obj),
ce qui m'oblige a lui fournir d'autres fichiers objet,
pour lesquels il essaie a nouveau de resoudre tous les symboles.
Finalement, je sui oblige de lui fournir tous les fichiers objets ou
presque, ce qui m'oblige a compiler tous les fichiers sources
(ou presque).
Le cas échéant, tu peux l'aider en lui fournissant certaines options (la manière
est propre à chaque éditeur de lien).
Pour l'editeur de lien de gcc, quelles sont ces options par exemple ?
Pour l'editeur de lien de VC++ ?
Pour celui de Portland group ?
On Wed, 29 Oct 2003 17:10:29 +0100, "Christophe Lephay" wrote:
en général, l'éditeur de lien ne prend que ce dont il a besoin.
Et pourtant : j'ai un editeur de lien qui veut resoudre tous les symboles qu'il trouve dans le fichier objet (.o ou .obj), ce qui m'oblige a lui fournir d'autres fichiers objet, pour lesquels il essaie a nouveau de resoudre tous les symboles.
Finalement, je sui oblige de lui fournir tous les fichiers objets ou presque, ce qui m'oblige a compiler tous les fichiers sources (ou presque).
Le cas échéant, tu peux l'aider en lui fournissant certaines options (la manière est propre à chaque éditeur de lien).
Pour l'editeur de lien de gcc, quelles sont ces options par exemple ? Pour l'editeur de lien de VC++ ? Pour celui de Portland group ?
Ca m'interesse beaucoup !
Cyril
Cyril.Gruau
On Thu, 30 Oct 2003 11:20:57 +0100, "Jean-Marc Molina" wrote:
Bonjour Cyril,
1 classe = 1 .h et 1.cpp
Oui, on m'a aussi appris cette regle. Je suis en train de me demander si elle n'est pas idiote.
Cyril
On Thu, 30 Oct 2003 11:20:57 +0100, "Jean-Marc Molina"
<goa_pasdepourriel_@ifrance.com> wrote:
Bonjour Cyril,
1 classe = 1 .h et 1.cpp
Oui, on m'a aussi appris cette regle.
Je suis en train de me demander si elle n'est pas idiote.
On Thu, 30 Oct 2003 11:20:57 +0100, "Jean-Marc Molina" wrote:
Bonjour Cyril,
1 classe = 1 .h et 1.cpp
Oui, on m'a aussi appris cette regle. Je suis en train de me demander si elle n'est pas idiote.
Cyril
Zouplaz
Cyril Gruau - :
On Thu, 30 Oct 2003 11:20:57 +0100, "Jean-Marc Molina" wrote:
Bonjour Cyril,
1 classe = 1 .h et 1.cpp
Oui, on m'a aussi appris cette regle. Je suis en train de me demander si elle n'est pas idiote.
Cyril
Bin moi je suis confronté à ce problème : j'ai une série de classes Action_X, Action_Y et ainsi de suite. Chaque classe est une spécialisation de Action et la définition est relativement légère (redefinition d'une méthode Init pour chaque classe). Quant au code il est court aussi, j'ai donc groupé toutes mes classes Action_ dans un .h et le code dans un .cpp sinon j'aurais 30 fichiers fois 2... Un peu lourdingue quand même !!
Cyril Gruau - Cyril.Gruau@cemef.cma.fr :
On Thu, 30 Oct 2003 11:20:57 +0100, "Jean-Marc Molina"
<goa_pasdepourriel_@ifrance.com> wrote:
Bonjour Cyril,
1 classe = 1 .h et 1.cpp
Oui, on m'a aussi appris cette regle.
Je suis en train de me demander si elle n'est pas idiote.
Cyril
Bin moi je suis confronté à ce problème : j'ai une série de classes
Action_X, Action_Y et ainsi de suite. Chaque classe est une spécialisation
de Action et la définition est relativement légère (redefinition d'une
méthode Init pour chaque classe). Quant au code il est court aussi, j'ai
donc groupé toutes mes classes Action_ dans un .h et le code dans un .cpp
sinon j'aurais 30 fichiers fois 2... Un peu lourdingue quand même !!
On Thu, 30 Oct 2003 11:20:57 +0100, "Jean-Marc Molina" wrote:
Bonjour Cyril,
1 classe = 1 .h et 1.cpp
Oui, on m'a aussi appris cette regle. Je suis en train de me demander si elle n'est pas idiote.
Cyril
Bin moi je suis confronté à ce problème : j'ai une série de classes Action_X, Action_Y et ainsi de suite. Chaque classe est une spécialisation de Action et la définition est relativement légère (redefinition d'une méthode Init pour chaque classe). Quant au code il est court aussi, j'ai donc groupé toutes mes classes Action_ dans un .h et le code dans un .cpp sinon j'aurais 30 fichiers fois 2... Un peu lourdingue quand même !!
kanze
(Cyril Gruau) wrote in message news:...
On Thu, 30 Oct 2003 11:20:57 +0100, "Jean-Marc Molina" wrote:
1 classe = 1 .h et 1.cpp
(En passant, ce sont des .hh et des .cc.)
Oui, on m'a aussi appris cette regle. Je suis en train de me demander si elle n'est pas idiote.
Comme toute règle, elle est bien ou elle convient, et idiote où elle ne convient pas. Pour les classes de base, comme ma GB_String pré-norme, c'est bien une fonction pro .cc ; c'est un peu fastidieux pour l'écriture, mais quand l'interface est large, l'utilisateur ne doit être obligé à n'incorporer que le minimum dont il a besoin. Dès qu'il y a des fonctions virtuelles, en revance, c'est bien un .cc pour la classe entière.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Cyril.Gruau@cemef.cma.fr (Cyril Gruau) wrote in message
news:<3fa21b23.228733150@news.cma.fr>...
On Thu, 30 Oct 2003 11:20:57 +0100, "Jean-Marc Molina"
<goa_pasdepourriel_@ifrance.com> wrote:
1 classe = 1 .h et 1.cpp
(En passant, ce sont des .hh et des .cc.)
Oui, on m'a aussi appris cette regle. Je suis en train de me demander
si elle n'est pas idiote.
Comme toute règle, elle est bien ou elle convient, et idiote où elle ne
convient pas. Pour les classes de base, comme ma GB_String pré-norme,
c'est bien une fonction pro .cc ; c'est un peu fastidieux pour
l'écriture, mais quand l'interface est large, l'utilisateur ne doit être
obligé à n'incorporer que le minimum dont il a besoin. Dès qu'il y a des
fonctions virtuelles, en revance, c'est bien un .cc pour la classe
entière.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
On Thu, 30 Oct 2003 11:20:57 +0100, "Jean-Marc Molina" wrote:
1 classe = 1 .h et 1.cpp
(En passant, ce sont des .hh et des .cc.)
Oui, on m'a aussi appris cette regle. Je suis en train de me demander si elle n'est pas idiote.
Comme toute règle, elle est bien ou elle convient, et idiote où elle ne convient pas. Pour les classes de base, comme ma GB_String pré-norme, c'est bien une fonction pro .cc ; c'est un peu fastidieux pour l'écriture, mais quand l'interface est large, l'utilisateur ne doit être obligé à n'incorporer que le minimum dont il a besoin. Dès qu'il y a des fonctions virtuelles, en revance, c'est bien un .cc pour la classe entière.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Jean-Marc Molina
En effet ça dépend du contexte. Pour les projets sur lesquels j'ai travaillés, on a toujours opté pour 1 .cpp et 1 .h par classe. Dans le cas d'héritage on peut préfixer ses noms de fichier par le nom de la classe de base. On peut aussi utiliser des répertoires pour classer ces classes par catégories, de même pour gérer ses modules/espaces de noms.
JM
-- Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
En effet ça dépend du contexte. Pour les projets sur lesquels j'ai
travaillés, on a toujours opté pour 1 .cpp et 1 .h par classe.
Dans le cas d'héritage on peut préfixer ses noms de fichier par le nom de la
classe de base. On peut aussi utiliser des répertoires pour classer ces
classes par catégories, de même pour gérer ses modules/espaces de noms.
JM
--
Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
En effet ça dépend du contexte. Pour les projets sur lesquels j'ai travaillés, on a toujours opté pour 1 .cpp et 1 .h par classe. Dans le cas d'héritage on peut préfixer ses noms de fichier par le nom de la classe de base. On peut aussi utiliser des répertoires pour classer ces classes par catégories, de même pour gérer ses modules/espaces de noms.
JM
-- Clé AntiPourriel : PASUNPOURRIEL (ne pas retirer)
