Discussion :

[djflex68]

Salut à tous,
J'ai un gros souci ...
En fait j'ai crée une librairie statique avec DevC++ (bizarrement sous Visual C++ ça compile pas correctement).
Cette librairie contient des classes
Maintenant je souhaiterais intégrer cette librairie dans un projet MFC pour utiliser ses fonctionnalités dans une interface graphique.
La question est, comment faire pour que dans visual studio il comprenne que ce sont des classes de ma bibliothque externe que je veux utiliser ?
J'ai fait ceci :
- Ajouter ma librairie aux librairies d'entrée du projet
- Ajouter le fichier Include de ma librairie dans le projet
Cependant il me sort des erreurs de link quand je compile ..
Qu'ai-je oublié ? des exportations ? comment faire ?
Help !!!
Merci

[Laurent Gomila]

Une bibliothèque statique générée avec Dev-C++ ne sera pas compatible avec VC++. Il faut la compiler avec ce dernier.

[djflex68]

Ca ne change rien avec VC++ lui même..
Lorsque je crée un projet de librairie statique dans la même solution que le projet MFC, et que je réalise la même manip :
- Ajouter la librairie aux librairies d'entrée du projet MFC
- Ajouter le fichier Include de ma librairie dans le projet MFC
si je fais ceci avec une fonction toute simple ça marche
si je fais ceci avec une classe il me sort des erreurs de link :

IPIPOura error LNK2019: symbole externe non résolu "public: __thiscall SocketConnexion::SocketConnexion(void)" (??0SocketConnexion@@QAE@XZ) référencé dans la fonction "public: void __thiscall CIPIPOuraDlg::OnBnClickedButton1(void)" (?OnBnClickedButton1@CIPIPOuraDlg@@QAEXXZ)
IPIPOura error LNK2019: symbole externe non résolu "public: __thiscall SocketConnexion::SocketConnexion(void)" (??0SocketConnexion@@QAE@XZ) référencé dans la fonction "bool __cdecl grow_lf70(unsigned int,unsigned int)" (?grow_lf70@@YA_NII@Z)

Comprends pas ..

[Madeiras]

Une bibliothèque statique générée avec Dev-C++ ne sera pas compatible avec VC++. Il faut la compiler avec ce dernier.

En effet, lorsque tu crées une fonction simple au prototype C

Code :

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

1
2
 
extern "C" void MaFonction(void);

Normalement tous les compilateurs C compile ta fonction en lui donnant le nom interne (symbole)

Code :

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

1
2
 
_MaFonction

avec un underscore devant le nom de ta fonction, c'est pour çà que çà marche.

Par contre, en C++ (et peut-être plus particulièrement en VC++), lorsque tu crées une fonction C++ ou une classe, les nom symboliques des fonctions/méthodes ne respectent une dénomination standard
Donc une classe compilée en Dev-C++ peut donner :

Code :

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

1
2
3
4
5
6
 
class MaClasse
{
   public:
   void UneMethode();
}

En Dev-C++ (j'invente ici des noms)

Code :

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

1
2
 
?MaClasse_UneMethode_DevC

et en Visual C

Code :

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

1
2
 
??MaClasse_UneMethode_VC

Donc ta classe compilée porte le nom ?MaClasse_UneMethode_DevC en DevC++ par contre le VC va s'attendre à lire un nom symbolique ??MaClasse_UneMethode_VC qui n'existe pas dans ta librairie.

Voilà pourquoi le Dev-C++ n'est pas compatible avec le VC++[/b]

[djflex68]

Oui je connaissais le point de détail dont tu parles que l'on appelle aussi "decorated name"... le souci est le même quand on crée une DLL il faut utiliser un fichier def pour spécifier nos propres noms ...
Mais bon ce qui est bizarre c'est que le même fichier source utilisé dans Visual C++ et compilé en tant que librairie statique ne fonctionne plus une fois lié ... (Link error) ...

[djflex68]

Bon je vais clarifier un peu les choses quand même :
Voilà exactement ce que j'essaye de faire :
Au départ je voulais créer un projet avec wxWidgets pour faire une appli multi plateforme... Et puis je me suis rendu compte que le rendu graphique est moyen avec cette librairie...
Mais j'avais déjà fait toutes les classes techniques internes avec wxWidgets et ça fonctionnait très bien...
Alors je me suis dit : bon ben je vais garder ces classes faites avec wxWidgets et faire une interface graphique avec Visual Studio en liant statiquement l'appli MFC à ma bibliothèque de classes. (quitte à refaire l'interface graphique uniquement sur chaque plateforme, pas de problème)
Or problème, si la librairie compile très bien en elle même, dès lors qu'on rajoute le fichier d'include de cette même bibliothèque dans le projet MFC les ennuis commencent.
Alors je m'amuse à configurer tout le projet jusqu'à ce qu'il soit adapté à wxWidgets et apte à pouvoir compiler ... Je croyais enfin toucher au but, mais dernière erreur :
Un certain fichier de socket de wx ne compile pas... j'en trouve la cause après 2 jours de recherche : winsock.h doit être inclus avant lui ...
Résolu ? Pas encore, parce qu'en faisant ça, ça me sort une nouvelle erreur : LoadIcon not referenced in TheApp ...
Enfin bon vous voyez le bordel que c'est pour finalement lier un pauvre truc qui contient des classes faites en wxWidgets avec un projet MFC ...
C la mouise totale, je pense que je vais carrément essayer de passer par Borland C Builder ...

[Gabrielly]

Pour exporter des classes entières il faut générer une DLL MFC d'extension et utiliser la macro AFX_EXT_CLASS devant le nom de tes classes