Discussion :

[SteelBox]

Dans un fichier maClass.cpp, on a la déclaration et la définition d'une classe.
Dans un autre fichier .cpp, on voudrait utiliser cette classe. Comment faut-il faire sachant que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#include "maClass.h"

ne va bien sûr pas fonctionner puisque la déclaration de la classe n'est pas présente dans le .h

J'ai donc pensé à ajouter la déclaration de la classe dans mon .c qui doit
utiliser la classe de maClass.cpp, mais lorsque plusieurs fichiers utilisent
maClass.cpp il y'a des erreurs de link.
J'ai testé en utilisant les préconditions (ifdef...) comme pour les .h mais ca
ne fonctionne pas. Comment faire ?

PS : je sais que modifier maClass.cpp (pour mettre la déclaration dans maClass.h) serait plus simple, mais j'aimerais éviter car il s'agit d'un programme qui n'a pas été fait par moi et qui est utilisé par d'autres personnes, il faut donc resté compatible, même si je ne comprends pas ce type de construction...si vous avez des idées sur l'utilité de cette construction, je suis preneur

Merci

[Laurent Gomila]

Ca paraît assez moche comme façon de coder, effectivement.

Je ne vois pas de solution, au pire si tu peux modifier le .cpp tu peux en faire un .h déguisé : directives anti-réinclusions et fonctions toutes inline (puis tu inclues "classe.cpp" au lieu d'un "classe.h").

Est-ce que tu es sûr que si cette classe est confinée dans une unité de traduction, ce n'est pas pour ne pas être utilisée ailleurs ?

[SteelBox]

Est-ce que tu es sûr que si cette classe est confinée dans une unité de traduction, ce n'est pas pour ne pas être utilisée ailleurs ?

Effectivement, c'est ce à quoi j'ai pensé au départ, mais y'a pas de facon plus propre de faire ca ?

En ajoutant les directives anti-inclusion, les erreurs de link ne disparaissent pas

[Laurent Gomila]

Pour les erreurs de link, comme je te l'ai dit il faut traiter ton fichier comme un en-tête, à savoir mettre toutes les fonctions inline et l'inclure au lieu de le compiler.

[Mac LAK]

Perso, je ferais un .H "privé" en séparant proprement le .CPP déclaré "à la chacal" : ça ne changera pas l'interface publique du programme/module, mais ça résoudra ton problème. Et comme le .HPP est privé, non connu et non référencé sauf par toi, ça ne posera aucun problème de rétrocompatibilité.
Mais ça demande à pouvoir ajouter un fichier au référentiel, c'es le seul et unique point bloquant.

[SteelBox]

Mais ça demande à pouvoir ajouter un fichier au référentiel, c'es le seul et unique point bloquant.

Effecivement, c'est un point bloquant même si ca me semble une bonne solution

Pour les erreurs de link, comme je te l'ai dit il faut traiter ton fichier comme un en-tête, à savoir mettre toutes les fonctions inline et l'inclure au lieu de le compiler.

Comment je fais pour ne pas le compiler. un .c ou .cpp est toujours compiler par un compilateur, non ?

[Laurent Gomila]

Comment je fais pour ne pas le compiler. un .c ou .cpp est toujours compiler par un compilateur, non ?

Si tu ne lui dis pas de le compiler, il ne le compilera pas... Si tu bosses avec un IDE quelconque, il suffit de ne pas ajouter le fichier au projet. Avec VC++ tu peux l'ajouter et indiquer dans les options de ne pas le compiler.

[SteelBox]

En fait, il faudrait que je compile quand même le Cpp quand il y a les définitions de classes. J'aurais une erreur de link quand même...

[Mac LAK]

Mettons que ton CPP aie cette structure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
// Uniquement des déclarations/inclusions
#include .....
 
class maClass {
....
} ;
 
// A partir d'ici, uniquement des implémentations.
maClass::maClass() {
...
}
...

Tu peux t'en sortir en le modifiant de la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Uniquement des déclarations/inclusions
#include .....
 
class maClass {
....
} ;
 
#ifndef _MACLASS_ALREADY_IMPLEMENTED_
#define _MACLASS_ALREADY_IMPLEMENTED_
 
// A partir d'ici, uniquement des implémentations.
maClass::maClass() {
...
}
...
#endif  //_MACLASS_ALREADY_IMPLEMENTED_

et utiliser le CPP en inclusion de cette manière :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#include "maclass.cpp"

C'est super-hyper crade, mais quand même moins que le travail sagouinesque de ton collègue... ;-) Je pense que c'est cette solution que voulait t'indiquer Loulou24.

[SteelBox]

D'accord, je vois.
Je vais essayer cette solution. merci

[Azharis]

J'ai l'impression d'avoir trouvé un ancien compagnon de jeu n'est-ce pas?

Désolé pour le hors sujet.

[SteelBox]

J'ai l'impression d'avoir trouvé un ancien compagnon de jeu n'est-ce pas?

Désolé pour le hors sujet.

Hein ??? tu peux expliquer

[Laurent Gomila]

C'était pas vraiment ce que je voulais dire. Je voyais un truc plus classique (genre ce qu'on fait avec des templates) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#ifndef MACLASSE_H
#define MACLASSE_H
 
class MaClasse
{
   // ...
};
 
inline MaClasse::MaClasse()
{
   // ...
}
 
inline MaClasse::XXX()
{
   // ...
}
 
#endif

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

#include "MaClasse.cpp"

Je ne sais pas si la solution de Mac LAK fonctionnerait (il y aurait tout de même des erreurs de link, vu que les fonctions seraient définies dans chaque unité de traduction qui inclue le fichier cpp -- les directives préprocesseurs n'y changent rien).

[Mac LAK]

Je ne sais pas si la solution de Mac LAK fonctionnerait (il y aurait tout de même des erreurs de link, vu que les fonctions seraient définies dans chaque unité de traduction qui inclue le fichier cpp -- les directives préprocesseurs n'y changent rien).

Hélas, si, ça marche... C'est même un peu le problème !

La redéfinition étant "à l'identique", ça ne pose pas de problèmes majeurs d'inclusion (à l'exception, peut-être, d'une directive anti-inclusion supplémentaire pour la partie "déclarative" qui peut s'avérer nécessaire), et le link est résolu à l'édition de lien : le module étant réellement compilé une fois (et une seule !) dans le projet, ça marche.

C'est une utilisation très crade du préprocesseur, mais du point de vue du résultat final, ça fait exactement la même chose qu'une inclusion d'entête... Et comme la partie du source "encadrée" par les #ifndef/#endif est purement et simplement éliminée par le préprocesseur, il n'y a pas de "doublons" de code.

[Laurent Gomila]

Je ne peux pas tester pour le moment, mais je ne suis pas si sûr que cela marche. En effet le code sera bien compilé plusieurs fois, les directives anti-réinclusions ne serviront que dans le cas où un même fichier incluerait plusieurs fois celui-ci.

Comme tu le dis très justement, ça revient exactement à une inclusion d'en-tête. Or on ne peut pas mettre de code comme ça dans un en-tête, celui-ci ne fera pas exception. Les fonctions doivent être inline et le fichier ne doit pas être compilé.

[Mac LAK]

Je ne peux pas tester pour le moment, mais je ne suis pas si sûr que cela marche. En effet le code sera bien compilé plusieurs fois, les directives anti-réinclusions ne serviront que dans le cas où un même fichier incluerait plusieurs fois celui-ci.

Ah oui, c'est vrai que si les fichiers sont totalement séparés, ça peut poser problème... Faudra peut-être regarder du côté des #pragma, mais ça flingue la portabilité...

Comme tu le dis très justement, ça revient exactement à une inclusion d'en-tête. Or on ne peut pas mettre de code comme ça dans un en-tête, celui-ci ne fera pas exception. Les fonctions doivent être inline et le fichier ne doit pas être compilé.

Ca peut passer quand même (le code produit est le même), mais va y avoir un méchant warning du linker !! Il devrait prendre la première version compilée, normalement, mais faudra peut-être le régler pour qu'il ne génère qu'un warning et non pas une erreur...

De toutes façons, quelle que soit la solution n'utilisant que le CPP, ça restera "crade" : créer un nouvel entête (éventuellement non public) reste la seule méthode propre...
Alors un warning de plus ou de moins, je pense sincèrement que ce n'est pas là le pire des problèmes du projet de SteelBox, non ?