Déclaration et définition dans un .cpp

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:

---

#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 :D

Merci :D

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 ?

Citation:

---

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 :?

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.

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.

Citation:

---

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 :?

Citation:

---

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 ?

Citation:

---

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.

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...

Mettons que ton CPP aie cette structure :

Code:

---

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:

---

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:

---

#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.

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

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

Désolé pour le hors sujet.

Citation:

---

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 8O

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

Code:

---

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:

---

#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).

Citation:

---

Envoyé par Loulou24

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.

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é.

Citation:

---

Envoyé par Loulou24

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é...

Citation:

---

Envoyé par Loulou24

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 ?