Discussion :

[masterx_goldman]

Bonjour,

Je travaille sous Visual Stduio 2005 et je suis entrain de développer une application console en c++ avec des Classes MFC.
Alors je veux savoir est ce que mon application va générer des problèmes de versions pour les dll MFC sur les machines cibles et comment faire pour pouvoir utiliser des classes MFC et ne pas tomber dans le problème de versions ?
Autre chose, j'aimerai bien comprendre (dans l'onglet Use Of MFC)la différence entre :

1)Use Standard Windows Libraries
2)Use MFC in a Static Library
3)Use MFC in a Shared DLL

et la différence (dans l'onglet Code Generation) entre:
1) Multi-threaded (/MT)
2) Multi-threaded Debug (/MTd)
3) Multi-threaded DLL (/MD)
4) Multi-threaded Debug DLL (/MDd)

Merci pour tout type d'aide

[TheGzD]

Autre chose, j'aimerai bien comprendre (dans l'onglet Use Of MFC)la différence entre :

1)Use Standard Windows Libraries
2)Use MFC in a Static Library
3)Use MFC in a Shared DLL

C'est justement ce qui est sensé te permettre de répondre à ta question "Comment utiliser des classes MFC sans générer des dépendances vers des dll ?". Utiliser les MFC en Static te permettra d'inclure celles que tu utilises à ton exécutable : ce dernier sera plus volumineux, mais te garantira la présence et la bonne version des MFC utilisées.

[masterx_goldman]

Utiliser les MFC en Static te permettra d'inclure celles que tu utilises à ton exécutable : ce dernier sera plus volumineux, mais te garantira la présence et la bonne version des MFC utilisées.

merci, j'ai compri ça
mais pour le choix de la "RunTime Library" la seule option qui va avec "Use MFC in a Static Library" est :

Multi-threaded Debug (/MTd)

les autres options génèrent des problèmes de Link (voir plus bas ) et la génération échou , donc est ce que l'utilisation de cette option ne va pas me mettre dans un autre problème qui est " l'absence de ces dll de debugage " sur les machines cibles ?

****************************
erreurs et avertissement avec l'option "Multi-threaded (/MT)"
****************************

Erreur 1 error LNK2005: _calloc already defined in libcmtd.lib(dbgheap.obj) LIBCMT.lib

Avertissement 2 warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library dirTest


Erreur 3 fatal error LNK1169: one or more multiply defined symbols found C:\Users\....\dirTest\Debug\dirTest.exe

****************************
erreurs et avertissement avec l'option "Multi-threaded DLL (/MD)"
****************************

Erreur 1 fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d] c:\program files\microsoft visual studio 8\vc\atlmfc\include\afx.h 24

****************************
erreurs et avertissement avec l'option "Multi-threaded Debug DLL (/MDd)"
****************************

Erreur 1 fatal error C1189: #error : Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d] c:\program files\microsoft visual studio 8\vc\atlmfc\include\afx.h 24

[bacelar]

Les MFC dans une application console, autant essaye d'écrasé une mouche avec un marteau-pilon.

Vérifiez bien que vous avez besoin des MFC, si c'est la cas, vous avez déjà une méga-erreur de conception quelque part.

Quand vous utilisez les MFC en librairies (MFC en Static), celles-ci ont elles-mêmes été compilées avec des options pour spécifier une version de la C-Runtime (les options /MT ....).
Sauf exceptions, il est nécessaire que toutes les librairies et le corps du programme utilisent la même version de la C-Runtime.

Comme vous en êtes à mettre les MFC dans une application console, je ne pense pas que vous ayez le niveau nécessaire pour se libérer de cette contrainte.

Avant tous, n'utilisez les MFC QUE pour des applications MFC.

[masterx_goldman]

Vérifiez bien que vous avez besoin des MFC, si c'est la cas, vous avez déjà une méga-erreur de conception quelque part.

je veux seulement profiter des fonctionalité des classes MFC ( CString, CWinThread, ...) ce n'est pas une raison de conception qui m'a poussé à les utiliser.

Quand vous utilisez les MFC en librairies (MFC en Static), celles-ci ont elles-mêmes été compilées avec des options pour spécifier une version de la C-Runtime (les options /MT ....).
Sauf exceptions, il est nécessaire que toutes les librairies et le corps du programme utilisent la même version de la C-Runtime.

Plus de détail stp, si c'est possible ..

Comme vous en êtes à mettre les MFC dans une application console, je ne pense pas que vous ayez le niveau nécessaire pour se libérer de cette contrainte.

est ce qu'il y a un moyen pour s'en libérer ? je suis prêt à apparendre et tout le monde commence par être débutant dans un domaine et puis on évolue

Avant tous, n'utilisez les MFC QUE pour des applications MFC.

tu as tout à fait raison, je prendrai ce conseil dorénavant.

[bacelar]

je veux seulement profiter des fonctionnalité des classes MFC ( CString, CWinThread, ...) ce n'est pas une raison de conception qui m'a poussé à les utiliser.

Les CString sont utilisable sans les MFC depuis VS2003 ou VS2005 (minimum)
il suffit d'inclure "<atlstr.h>", pas besoin de "<cstringt.h>" ou autres "<Afx....h>".
CWinThread est une classe qui simplifie la gestion des Thread MFC et qu'MFC. Elle est impossible à utiliser sans les MFC et ne présente aucun intérêt dans une application console. Pourquoi avez vous besoin de CWinThread ?
Un handle et les fonctions Win32 (plus quelques macro et fonctions utilitaires) devraient largement suffire à une gestion de Thread du "niveau" de CWinThread.

Pensez aussi à la lib standard C++ avec la classe std::string.

Plus de détail stp, si c'est possible ..

C-Runtime est la librarie qui contient le code des fonctions de base de l'API C du système d'exploitation comme "malloc" ou "free".
- Il y des implémentations Release et Debug de ces fonctions (avec ou sans vérifications des paramètres en entré et des structures internes de la librairie.
- Il y aussi des implémentations dit multi-thread safe et d'autre non. Les thread-safe peuvent être utilisées dans un programme contenant plusieurs Thread, pas les autres.
- Il y aussi des implémentations qui utilisent une dll pour contenir le véritable code exécutable (C-Runtime en dll) et d'autres qui contiennent le code dans la librairie elle-même (C-Runtime static).

Cela nous fait déjà 2*2*2 (8) implémentation possible de la C-Runtime. Chacune définissant la fonction malloc et la fonction free (entre autres).
Chacune de ces fonctions synonymes sont incompatibles. Et le "free" doit correspondre au malloc de la même implémentation.
Le linker construire l'appel à la fonction par une instruction contenant l'adresse de la fonction. S'il y a plusieurs fonctions avec le même nom, comment choisit-il ? A la courte paille ?
Or en utilisant plusieurs C-Runtime, vous avez plusieurs "malloc" etc...

est ce qu'il y a un moyen pour s'en libérer ? je suis prêt à apparendre et tout le monde commence par être débutant dans un domaine et puis on évolue

Cela déborderais largement le cadre de la question. Google est ton ami et j'ai du déjà répondre plusieurs fois à ce type de question.

tu as tout à fait raison, je prendrai ce conseil dorénavant.

Essayez donc de ne pas utiliser les MFC, et d'utiliser une et une seule C-Runtime.