Discussion :

[ceugniet]

D�butant en Visual C++, je souhaite recr�er les biblioth�ques xxx.lib que j'avais cr��es sous Borland C++. Je ne trouve pas de mod�le dans la documentation en ligne. On me propose un mod�le de "biblioth�ques de classes", mais, comme je suis d�butant, je ne comprends pas encore grand chose aux classes et je veux juste, pour l'instant, cr�er des fonctions C une fois pour toutes pour �viter d'avoir � en recopier le code dans tous mes programmes.

Ensuite, j'imagine qu'il suffira d'inclure une r�f�rence au fichier .h (#include "xxx.h") et � la librairie (USELIB("c;\...\xxx.lib")) pour avoir acc�s � ces fonctions dans n'importe quel programme. Ai-je raison ? O� est-ce plus compliqu� ?

Merci d'avance pour tout conseil !

[Mac LAK]

Tu peux par exemple faire un projet Win32, et dans l'onglet g�n�ral, tu mettras la propri�t� "Type de configuration" sur "Librairie statique (.LIB)".

Apr�s, je n'utilise pas VS Express mais la version compl�te, qui poss�de un wizard de cr�ation de librairie statique :

• Panneau de gauche : Projet Visual C++, choix "Win32".
• Panneau de droite : Projet Win32.
• Valider le nom et le r�pertoire, cliquer sur "OK", puis "Next".
• Cocher "Librairie statique" au lieu de "Application Windows", cliquer sur "OK".

A voir s'il y a le m�me pour VS Express, ce qui devrait �tre le cas.

[ceugniet]

Merci de ta r�ponse !

J'ai fait exactement ce que tu m'as dit. Le nom de mon projet est test13. Visual C++ a cr�� trois fichiers :
stdafx.h, targetver.h, et stdafx.cpp

Au pifom�tre, j'ai choisi stdafx.cpp pour coder ma fonction "mafonction" (oui, c'est un test...). Puis, j'ai cliqu� sur "g�n�rer->g�n�rer la solution" et ont �t� cr��s plusieurs fichiers dont un fichier test13.lib dans test13\debug. "test13.h" pour sa part n'a pas �t� cr��, je suppose que c'est � moi de le faire, ce n'est pas un probl�me, bien s�r.

A pr�sent, si j'ai fait ce qu'il fallait faire, comment coder un programme appelant ? Je vais cr�er un programme qui dans son code va faire r�f�rence � mafonction(10) par exemple. Je devrais probablement inclure une ligne #include "c:\.....\test13.h" (que j'aurais cr�� pr�alablement), mais comment vais-je faire savoir au linker que la fonction manquante (mafonction) se trouve dans test13.lib ? Sous Borland C++, il fallait inclure une ligne USELIB("test13.lib") dans le code, et pr�ciser au linker dans quel dossier se trouvaient les librairies auxquelles je faisait r�f�rence. Comment faire sous Visual C++ ? Apparemment, Visual C++ n'utilise pas ce mot "USELIB". La syntaxe est donc diff�rente.

Merci de me renseigner.

[Mac LAK]

Bon, quelques points importants :

• VS cr�e quelques fichiers "de base", mais ils ont un r�le tr�s particulier qu'il te faut conna�tre.
• Targetver.hpp est un fichier destin� � param�trer la version minimale de Windows requise par ton programme. Cela aura une importance si tu veux que ton programme tourne aussi bien sur Windows 2000 que Windows 7.
  Pour l'instant, laisse-le tel quel.
• StdAfx.h est l'ent�te primaire pour les ent�tes pr�compil�s. Cela sert � acc�l�rer la REcompilation de ton projet, ou la compilation utilisant BEAUCOUP de librairies. Sur un projet "simple", c'est parfois plus probl�matique qu'autre chose d'utiliser les ent�tes pr�compil�s.
  Pour l'instant, je te conseille de ne pas t'en servir, du moins tant que tu n'as pas bien compris le concept de compilation s�par�e et de modules.
• StdAfx.cpp est le fichier permettant, justement, de construire les ent�tes pr�compil�s. Par d�faut, il est vide, et il doit le rester. Ce n'est PAS un fichier pour y mettre ton code !
• Un fichier .H n'est jamais compil�, ce ne sont QUE les fichiers .C ou .CPP qui le sont. Donc, c'est normal que ton fichier "test13.h" ne soit pas compil�, il ne le sera qu'au travers des fichiers C/CPP qui l'utilisent.
• Donc : essaie plut�t de partir d'un projet vide pour d�marrer, cela t'�vitera quelques n�uds au cerveau pour rien. Tu as le temps d'apprendre les subtilit�s propres � Visual Studio un peu plus tard, concentres-toi sur le langage lui-m�me pour l'instant.

Pour utiliser une librairie (statique ou dynamique) sous Visual, tu as deux solutions :

• R�f�rencer explicitement la librairie dans ton ex�cutable. On peut faire �a de deux fa�ons :
  • L'ajouter dans le champ "Librairies additionnelles" de la partie "Edition de liens" des propri�t�s de ton projet.
  • Utiliser un "#pragma comment(lib,"MaLibrairie")" dans le code, qui correspond au USELIB de BC++ (voire cette discussion et cette FAQ).
• Utiliser les d�pendances au sein de la solution : bouton droit sur ton ex�cutable, "D�pendances", et coche la librairie � utiliser.
• Dans les deux cas, il te faudra ajouter les chemins vers les includes de ta librairie dans ton projet de toutes fa�ons (voir cette FAQ).

Pour rejoindre l'autre discussion : avec les DLL, c'est pareil, car c'est un probl�me de compilation dans un premier temps. Pour les d�pendances de projet, VS g�re tr�s bien le fait que ce soit une DLL ou une LIB : en effet, pour les DLL, il g�n�re une librairie d'importation qui t'�vite d'avoir � linker manuellement les fonctions de la DLL.

[ceugniet]

Achhhh ! Je ne comprends pas ! D�sol�, j'ai la t�te dure !

Targetver.hpp est un fichier destin� ...Pour l'instant, laisse-le tel quel.

Tu n'auras pas besoin de me dire �a deux fois ! Je n'y touche pas !

StdAfx.h est l'ent�te primaire pour les ent�tes pr�compil�s...Pour l'instant, je te conseille de ne pas t'en servir

Je n'y toucherai pas non pus !

StdAfx.cpp est le fichier permettant, justement, de construire les ent�tes pr�compil�s. Par d�faut, il est vide, et il doit le rester. Ce n'est PAS un fichier pour y mettre ton code !

Bon, d'accord ! Mais, comme je te l'ai dit, c'est pourtant ce que j'ai fait ! J'ai cliqu� sur "g�n�rer" et VS m'a effectivement cr�� un fichier test13.lib !!!!
Qu'est-ce que peut bien contenir test13.lib � pr�sent ???

Un fichier .H n'est jamais compil�, ce ne sont QUE les fichiers .C ou .CPP qui le sont. Donc, c'est normal que ton fichier "test13.h" ne soit pas compil�, il ne le sera qu'au travers des fichiers C/CPP qui l'utilisent.

Je n'ai pas dit que mon fichier test13.h n'�tait pas compil� ; j'ai dit qu'il n'existait pas. A fortiori ne peut-il pas �tre compil� ! Dans ma na�vet�, j'ai pens� que VS allait me cr�er un fichier test13.cpp et me demander d'y loger mon code pour les fonctions que j'avais envie de mettre dans la LIB, et qu'il allait cr�er et remplir automatiquement un test13.h. J'ai justement remarqu� qu'il n'avait rien fait de tel.
Mon interpr�tation des fichiers .h est la suivante :

Lorsqu'un code fait r�f�rence � une fonction qui n'existe pas dans ce code, le compilateur a besoin de conna�tre la syntaxe d'appel de la fonction pour indiquer � l'utilisateur si la fonction r�f�renc�e est correctement appel�e ou pas. Il laisse au linker le soin d'aller chercher o� il pourra les fonctions pr�compil�es dans des librairies (.lib) pour la cr�ation d'un ex�cutable complet, ou dans des librairies .dll lors de l'ex�cution. A mon avis, les fichiers .h ne sont pas compil�s, car pas compilables ; elles ne contiennent que les prototypes des fonctions et pas leur code.
Au demeurant, je trouve que cette expression "fichiers d'ent�te pr�compil�s" est malheureuse. Le fichiers ne sont pas "pr�compil�s" et ils ne seront pas davantage compil�s ult�rieurement. Ce sont les fonctions r�f�renc�es dans ces fichiers qui ont �t� pr�alablement compil�es, pas les fichiers, pas les ent�tes ! Mais peut-�tre ai-je mal interpr�t� encore...
Merci de me dire si j'ai au moins correctement compris �a !

Donc : essaie plut�t de partir d'un projet vide pour d�marrer

�a je ne comprends pas ! Je viens de demander � VS de cr�er une librairie qui s'appelle test13.lib ! Je m'attends par cons�quent � trouver un fichier (genre test13.cpp) o� je vais taper le code des fonctions que je vais mettre dans ma librairie. Je ne le trouve pas : VS ne l'a pas cr��. Tu me dis de "partir d'un projet vide". Comment ? J'ai cliqu� sur Nouveau->projet->CLR->Projet vide CLR ; j'ai donn� le nom "bidon". A pr�sent, la "solution" test13, contient deux "projets" : test13 et bidon ! L'explorateur Windows me dit que dans le dossier "test13", a �t� cr�� un sous-dossier bidon, qui contient un fichier bidon.vcproj et c'est tout. Par contre, dans la fen�tre de VS est apparu, de mani�re l�g�rement diff�rente un "projet" bidon avec trois petits rectangles jaunes (qui �voquent des sous-dossiers) intitul�s "fichiers d'entete", fichiers ressources" et "fichiers sources". Mais toujours pas de test13.cpp ! Et cliquer sur ces trois petits rectangles n'a absolument aucun effet !
Je ne sais toujours pas o� je vais placer les trois lignes du code de ma fonction "mafonction" !!!

Entre parenth�ses, je n'ai pas compris ce qu'est une "solution", un "projet", pas plus que ce que signifie de cliquer sur "g�n�rer"

Je te remercie beaucoup du temps que tu as pass� � me r�pondre de mani�re extensive. Pour �tre moi-m�me conseilleur sur d'autres forums d'aide dans ma sp�cialit� (qui n'est pas C++ - ce n'est pas un scoop !), je sais que cela prend beaucoup de temps. Je t'en suis par cons�quent tr�s reconnaissant. Je crains malheureusement que je n'aie pas encore fini de t'emb�ter avec mes questions...

Merci mille fois !

[Mac LAK]

Je n'ai pas dit que mon fichier test13.h n'�tait pas compil� ; j'ai dit qu'il n'existait pas.

Oui, c'est � toi de les rajouter. Sur certains wizards VS, ces fichiers "vides" sont cr��s (notamment avec les DLL), mais pas toujours. De toutes fa�ons, ce n'est qu'un cadre : rien ne t'emp�che d'ajouter tous les fichiers (.H ou .CPP) que tu veux.

Au demeurant, je trouve que cette expression "fichiers d'ent�te pr�compil�s" est malheureuse. Le fichiers ne sont pas "pr�compil�s" et ils ne seront pas davantage compil�s ult�rieurement. Ce sont les fonctions r�f�renc�es dans ces fichiers qui ont �t� pr�alablement compil�es, pas les fichiers, pas les ent�tes ! Mais peut-�tre ai-je mal interpr�t� encore...

Et pourtant, si, ils sont bel et bien pr�compil�s... C'est � dire que le compilateur va pr�processer et pr�compiler le maximum de donn�es possible depuis un "point d'entr�e" (StdAfx.h en g�n�ral), c'est � dire le fichier racine de pr�compilation (ce point d'entr�e) et TOUS les ent�tes qu'il r�f�rence.
Le temps gagn� l'est principalement sur la phase de lecture des fichiers .H unitaires (on ne lit qu'un seul fichier, le .PCH [PreCompiled Headers]), de pr�process (c'est d�j� fait), d'analyse lexicale / s�mantique (c'est du binaire d�j� "valide" et non plus du texte � v�rifier), et sur les d�pendances (elles sont incluses dans le PCH).

J'ai cliqu� sur Nouveau->projet->CLR->Projet vide CLR ; j'ai donn� le nom "bidon".

Houl�, attention !!! Je t'ai dit de prendre un projet Win32, pas CLR !! CLR, c'est autre chose, c'est du C++ � la sauce .NET.

Je ne sais toujours pas o� je vais placer les trois lignes du code de ma fonction "mafonction" !!!

Dans des fichiers .H / .CPP que tu vas cr��er, et ajouter (par drag & drop notamment) � ton projet. Ils vont se classer automatiquement dans les filtres de projet (les "pseudo-r�pertoires" que tu vois, comme "Fichiers d'ent�te").

Entre parenth�ses, je n'ai pas compris ce qu'est une "solution", un "projet", pas plus que ce que signifie de cliquer sur "g�n�rer"

Projet (extension .vcproj) : �l�ments permettant de compiler UN �l�ment binaire. Un EXE, une DLL, une LIB, etc. Un projet ne peut pas (en situation normale) permettre de g�n�rer plus d'un objet de sortie "final" (EXE, DLL, LIB, ...). Donc, tu devras avoir un projet pour ton EXE, et un autre pour ta librairie.
Solution (extension .sln) : Ensemble de projets reli�s ensemble, notamment via les d�pendances.
G�n�rer : compiler une solution ou un projet. Tu as une entr�e de menu "G�n�rer", justement.

[ceugniet]

Merci de toutes ces informations compl�mentaires.

J'ai enfin r�ussi � cr�er une librairie statique, et � l'utiliser dans un programme test ! Ca marche au poil !

Mais, comme tu m'as convaincu qu'une DLL �tait bien mieux...j'ai essay� dans la foul�e de faire de m�me pour une DLL. Et l�, je ne sais pas quel pragma je dois ins�rer pour indiquer au linker que je vais utiliser cette dll l� et pas une autre : il faut bien que je lui dise o� chercher ses externes non r�sulus non ? Apparemment, le pragma comment (lib,...) ne fonctionne pas avec les dll ! Et je ne trouve pas :

le champ "Librairies additionnelles" de la partie "Edition de liens" des propri�t�s de ton projet.

En outre, tu dis que je peux cliquer sur l'ex�cutable et lui indiquer la dll qu'il faut utiliser, mais encore faudrait-il que l'ex�cutable existe, et justement, VS refuse de me cr�er mon ex�cutable qui teste la dll disant qu'il y a des externes non r�solus !

Merci encore !

[Mac LAK]

Et l�, je ne sais pas quel pragma je dois ins�rer pour indiquer au linker que je vais utiliser cette dll l� et pas une autre : il faut bien que je lui dise o� chercher ses externes non r�sulus non ? Apparemment, le pragma comment (lib,...) ne fonctionne pas avec les dll !

V�rifie que tu g�n�res bien une librairie d'importation (il doit y avoir un fichier .LIB de m�me nom g�n�r� � c�t� de la DLL), pour commencer.
Ensuite, n'oublie pas que dans une DLL, tu dois imp�rativement d�clarer ce qui est export� de fa�on EXPLICITE. C'est le but des macros "NOMDELALIB_API" d�clar�e automatiquement par Visual lors de la cr�ation d'un projet DLL. Pour v�rifier �a, utilise Dependancy Walker, et ouvre ta DLL. Dans le cadre au milieu, � droite, tu verras la liste des fonctions export�es par la DLL. Si c'est vide... Pas bon !

Une fois que tu as une DLL qui exporte quelque chose, et que la librairie d'importation est g�n�r�e, �a s'utilise comme une librairie statique (ou presque, mais ne t'en pr�occupe pas pour l'instant). En tout cas, les #pragma fonctionneront.

En outre, tu dis que je peux cliquer sur l'ex�cutable et lui indiquer la dll qu'il faut utiliser, mais encore faudrait-il que l'ex�cutable existe, et justement, VS refuse de me cr�er mon ex�cutable qui teste la dll disant qu'il y a des externes non r�solus !

V�rifie les points ci-dessus, et une fois qu'ils seront r�gl�s, ton ex�cutable linkera.
On verra plus tard comment charger une DLL de fa�on r�ellement dynamique, pour l'instant, utilises-les de fa�on primaire le temps de d�m�ler les pi�ges courants.

[ceugniet]

V�rifie que tu g�n�res bien une librairie d'importation (il doit y avoir un fichier .LIB de m�me nom g�n�r� � c�t� de la DLL), pour commencer.

Ben non ! Il n'y a pas de fichier .LIB. Et je ne sais pas comment g�n�rer une "librairie d'importation" !!! (P.S. Bon, je viens de trouver : j'ai mis "oui" � la question "Biblioth�que d'importation ignor�e" (Readme.txt : "...vous pouvez d�finir la propri�t� Ignore Input Library � la valeur Yes dans la page de propri�t�s G�n�ral du dossier �diteur de liens de la bo�te de dialogue Pages de propri�t�s du projet..."), mais cela ne me g�n�re toujours pas de calendll.lib !

n'oublie pas que dans une DLL, tu dois imp�rativement d�clarer ce qui est export� de fa�on EXPLICITE. C'est le but des macros "NOMDELALIB_API" d�clar�e automatiquement par Visual lors de la cr�ation d'un projet DLL.

Je risque pas de l'oublier : je ne l'ai jamais su ! Et je ne sais pas ce qu'est une macro, ni comment l'utiliser...

(� la lumi�re de tes commentaires, j'ai finalement compris ce qui �tait �crit dans readme.txt ; j'ai bien compris que je dois "ajouter du code" dans le fichier mais comment ? )

Je ne sais pas ce que c'est que "ce qui est export�" ! S'agit-il des variables globales de la librairie ? Si oui, je me suis content�, comme dans le cas de la LIB, de mentionner comme "extern" les variables globales mentionn�es dans le .h. Quant aux macros "NOMDELALIB_API" ??? Je suppose qu'il s'agit d'un fichier calendll.api (ma librairie s'appelle calendll.dll) ? Mais point de calendll.api nulle part !!!

Pour v�rifier �a, utilise Dependancy Walker, et ouvre ta DLL.

C'est quoi "Dependancy Walker" ??? Je suppose que c'est un utilitaire qui devrait faire partie de VS ! Mais je n'ai rien de tel, en tous cas je ne sais pas o� le chercher !

Une fois que tu as une DLL qui exporte quelque chose, et que la librairie d'importation est g�n�r�e, �a s'utilise comme une librairie statique (ou presque, mais ne t'en pr�occupe pas pour l'instant). En tout cas, les #pragma fonctionneront.

Cela veut dire qu'il faut �crire :
#pragma comment(lib,calendll.dll")
ou bien
#pragma comment(dll,calendll.dll")
?

A moins que ce soit :
#pragma comment(lib,calendll.lib")
puisque VS devrait m'en cr�er une !!!


D�sol� pour ces centaines de questions ! Mais tout cela est enti�rement nouveau pour moi ! Le moindre de tes mots me fait me gratter la t�te :
" librairie d'importation" ? C'est quoi �a ?
"tu dois imp�rativement d�clarer" ? Je veux bien d�clarer mais comment ?
"C'est le but des macros "NOMDELALIB_API" d�clar�e automatiquement" ? Ca consiste en quoi "d�clarer" quand c'est VS qui d�clare ? Il cr�e un fichier ? Du code ? O� �a ?

Et merci de ta patience !

[Mac LAK]

Ben non ! Il n'y a pas de fichier .LIB. Et je ne sais pas comment g�n�rer une "librairie d'importation" !!! (P.S. Bon, je viens de trouver : j'ai mis "oui" � la question "Biblioth�que d'importation ignor�e" (Readme.txt : "...vous pouvez d�finir la propri�t� Ignore Input Library � la valeur Yes dans la page de propri�t�s G�n�ral du dossier �diteur de liens de la bo�te de dialogue Pages de propri�t�s du projet..."), mais cela ne me g�n�re toujours pas de calendll.lib !

Justement : il n'en g�n�re pas s'il n'y a pas de symboles export�s.
La directive d'exportation ressemble � �a :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
#ifdef MYLIB_EXPORTS
    #define MYLIB_API __declspec(dllexport)
#else
    #define MYLIB_API __declspec(dllimport)
#endif

Lorsque tu compiles ta DLL, tu dois d�finir la macro MYLIB_EXPORTS pour le projet. Par d�faut, VS le fait pour toi lorsque tu cr�e un nouveau projet DLL.
Il te faut ensuite d�clarer tes variables / fonctions / classes ainsi :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
extern MYLIB_API int AGlobalVariable ;
 
MYLIB_API int AnExportedFunction ( int param1, void* param2 ) ;
 
class MYLIB_API AnExportedClass {
 ....
} ;

Je ne sais pas ce que c'est que "ce qui est export�" ! S'agit-il des variables globales de la librairie ? Si oui, je me suis content�, comme dans le cas de la LIB, de mentionner comme "extern" les variables globales mentionn�es dans le .h. Quant aux macros "NOMDELALIB_API" ??? Je suppose qu'il s'agit d'un fichier calendll.api (ma librairie s'appelle calendll.dll) ? Mais point de calendll.api nulle part !!!

Non, justement, on n'exporte pas une fonction d'une DLL via un simple extern, cf. la premi�re r�ponse.

C'est quoi "Dependancy Walker" ??? Je suppose que c'est un utilitaire qui devrait faire partie de VS ! Mais je n'ai rien de tel, en tous cas je ne sais pas o� le chercher !

Ici : http://www.dependencywalker.com/
C'est un outil "� part", franchement indispensable si tu d�veloppes des DLL.

A moins que ce soit :
#pragma comment(lib,calendll.lib")
puisque VS devrait m'en cr�er une !!!

Oui, ce sera le .LIB qu'il faudra importer, ou rendre le projet de l'ex�cutable d�pendant du projet de la DLL via les d�pendances de solution (bouton droit sur le projet de l'ex�cutable => "D�pendances" => cocher le projet de la DLL).

" librairie d'importation" ? C'est quoi �a ?

La librairie (statique) qui permet d'importer les fonctions de la DLL. Sans elle, tu serais oblig� d'utiliser les fonctions de chargement dynamique de Windows (LoadLibrary / GetProcAddress / FreeLibrary) pour CHAQUE fonction export�e, et tu ne pourrais pas importer ni variables globales, ni classes C++.

"C'est le but des macros "NOMDELALIB_API" d�clar�e automatiquement" ? Ca consiste en quoi "d�clarer" quand c'est VS qui d�clare ? Il cr�e un fichier ? Du code ? O� �a ?

Il cr�e du code dans l'ent�te principal du projet DLL, lorsque tu g�n�res un projet "DLL" via les assistants. Je te conseille de cr�er un nouveau projet de test en lui demandant de cr�er un projet DLL NON VIDE, de fa�on � voir ce qu'il met dedans.
N'oublie pas de bien lire la : DLL en m�me temps.

[ceugniet]

Bonjour,

Me revoil� avec mes questions sans fin...

J'ai bien essay� de cr�er une DLL mais jusqu'� pr�sent sans succ�s. J'y reviendrai plus tard.

En attendant, j'ai constat� que le cas que j'avais r�ussi sur une librairie statique �tait un cas tr�s particulier : il n'y a avait pas de variables globales dans la librairie.

J'ai essay� de cr�er une librairie statique parmi celles que j'ai d�j�, et elle ne marche pas � cause des variables globales, pr�cis�ment.

Le fichier C:\0\1\p\vc\inc\codedfiles.h est le suivant :

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
20
21
22
23
24
25
26
27
28
29
30
 
#ifdef creelib
#ifndef codedh
#define codedh
#define bufsize 65536
unsigned char ascbuf[bufsize];
int ascnotread,ascfindefichier,asclus,ascnblig,ascadfichbuf,ascadundef;
FILE *input_file;
void feedbuf();
void initread();
int readlin(char *line);
int readline(char *line);
int readlin2(char *line,int *adfi);
int readline2(char *line,int *adfi);
#endif
#else
#ifndef codedh
#define codedh
#define bufsize 65536
extern unsigned char ascbuf[bufsize];
extern int ascnotread,ascfindefichier,asclus,ascnblig,ascadfichbuf,ascadundef;
extern FILE *input_file;
void feedbuf();
void initread();
int readlin(char *line);
int readline(char *line);
int readlin2(char *line,int *adfi);
int readline2(char *line,int *adfi);
#endif
#endif

Dans le "projet" "codedfiles", le fichier codedfiles.cpp contient quelque chose comme :

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
 
#define creelib
#include "stdafx.h"
 
void feedbuf()
{
...
}
void initread()
{
...
}
... etc
int readline2(char *line,int *adfi)
{
...
}

et le fichier stdafx.h contient :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
 
#pragma once
 
#include "targetver.h"
 
#define WIN32_LEAN_AND_MEAN             // Exclure les en-têtes Windows rarement utilisés
#include <stdio.h>
#include <conio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include "C:\0\1\p\vc\inc\codedfiles.h"

Comme j'ai d�fini creelib dans codedfiles.cpp le fichier codedfiles.cpp interpr�te les variables ascnotread, ascfindefichier, etc... comme des variables internes.

La cr�ation de la librairie ne pose apparemment pas de probl�me !

Dependency walker (qui est cens� marcher pour windows jusqu'� Vista - alors que mon syst�me est Windows 7 - ) ne reconna�t cependant rien dans la librairie cr��e : il me dit

No DOS or PE signature found. This is not a valid 32-bit or 64-bit Windows module.

Peut-�tre ce logiciel n'est-il utilis� que pour les dll ! Mais bon !

Je cr�e ensuite un "projet" testcoded. Dedans, le fichier stdafx.h contient :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
 
#pragma once
 
#include "targetver.h"
 
#include <stdio.h>
#include <tchar.h>
#include "C:\0\1\p\vc\inc\codedfiles.h"

et le fichier testcoded.cpp contient :

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
 
#include "stdafx.h"
 
 
#pragma comment(lib,"C:\\0\\1\\p\\vc\\lib\\crelibs\\codedfiles\\Debug\\codedfiles.lib")
int _tmain(int argc, _TCHAR* argv[])
{
	   initread();
	   input_file=fopen("\\0\\0\\garb\\bidon.txt","rb");
	   int t;
	   char myline[200];
	   t=readline(myline);
	   while (t==0)
	   {
		   printf("%s\n",myline);
		   t=readline(myline);
	   }
	return 0;
}

A la g�n�ration, la r�ponse est :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
1>codedfiles.lib(codedfile.obj) : error LNK2019: symbole externe non résolu "struct _iobuf * input_file" (?input_file@@3PAU_iobuf@@A) référencé dans la fonction "void __cdecl feedbuf(void)" (?feedbuf@@YAXXZ)
1>codedfiles.lib(codedfile.obj) : error LNK2001: symbole externe non résolu "int ascfindefichier" (?ascfindefichier@@3HA)
1>codedfiles.lib(codedfile.obj) : error LNK2001: symbole externe non résolu "int asclus" (?asclus@@3HA)
... etc
au total sept symboles externes non résolus

Alors, voil� ! Apparemment, je n'ai pas compris !

Merci de m'aider encore un peu !

[Mac LAK]

Le fichier C:\0\1\p\vc\inc\codedfiles.h est le suivant :

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
20
21
22
23
24
25
26
27
28
29
30
 
#ifdef creelib
#ifndef codedh
#define codedh
#define bufsize 65536
unsigned char ascbuf[bufsize];
int ascnotread,ascfindefichier,asclus,ascnblig,ascadfichbuf,ascadundef;
FILE *input_file;
void feedbuf();
void initread();
int readlin(char *line);
int readline(char *line);
int readlin2(char *line,int *adfi);
int readline2(char *line,int *adfi);
#endif
#else
#ifndef codedh
#define codedh
#define bufsize 65536
extern unsigned char ascbuf[bufsize];
extern int ascnotread,ascfindefichier,asclus,ascnblig,ascadfichbuf,ascadundef;
extern FILE *input_file;
void feedbuf();
void initread();
int readlin(char *line);
int readline(char *line);
int readlin2(char *line,int *adfi);
int readline2(char *line,int *adfi);
#endif
#endif

Cet ent�te n'a pas de sens : tu d�finis en compilation conditionnelle deux fois la m�me chose, tu n'utilises pas les directives d'exportation normales des DLL.

Je t'�crivais que VS allait g�n�rer un code similaire � celui-ci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
#ifdef MYLIB_EXPORTS
    #define MYLIB_API __declspec(dllexport)
#else
    #define MYLIB_API __declspec(dllimport)
#endif

Ce n'est PAS un oubli de ma part de ne pas avoir mis de code "utile" dans ce #ifdef : il ne contient bien QUE des #define, et rien d'autre !
Le code que je citais ensuite te montrait o� (et comment !) utiliser la macro MYLIB_API dans tes d�clarations de variables globales / fonctions / classes.

Cr�e un projet DLL tout neuf, SANS cocher la case "Projet vide" de l'assistant, et regarde bien ce que g�n�re Visual Studio comme code.



Note : Dependancy Walker ne fonctionne PAS sur les librairies statiques. Il ne peut analyser que les ex�cutables et les librairies dynamiques.

[ceugniet]

Merci de ta r�ponse, une fois de plus tr�s rapide.

Mais je crois que l'on ne s'est pas compris. J'ai dit en t�te que je laissais de c�t�, pour l'instant, les DLL. Je veux juste comprendre compl�tement comment on cr�e une librairie statique (j'ai bien compris que Dependency Walker ne me sera alors d'aucune utilit�).

Cet ent�te n'a pas de sens : tu d�finis en compilation conditionnelle deux fois la m�me chose, tu n'utilises pas les directives d'exportation normales des DLL.

(pour les directives des DLL, c'est donc normal, puisqu'ici, c'est une librairie statique)

Les deux ifs imbriqu� ont pour moi la signification suivante :

Si le parametre creelib existe, alors, je veux compiler seulement la premi�re partie, celle qui d�finit les variables comme internes, et sinon, je veux compiler seulement la deuxi�me partie, celle qui d�finit les variables comme externes. Comme j'ai d�fini creelib dans le programme qui cr�e la librairie, je pensais que les variables seraient internes. Et comme je ne d�finis pas creelib dans le programme test (qui UTILISE cette librairie), ces variables doivent �tre consid�r�es comme externes, non ? C'est ce que je voulais en tous cas.
Ensuite, le deuxi�me if (#ifdef codedh) �tait l� parce que je voulais �viter que l'on passe deux fois sur le m�me code si jamais le fichier codedfiles.h �tait lu deux fois (j'avais eu cette impression...).

Ce n'est PAS un oubli de ma part de ne pas avoir mis de code "utile" dans ce #ifdef : il ne contient bien QUE des #define, et rien d'autre !

Veux-tu dire que c'est interdit de mettre du code "utile" dans un if ?

[Mac LAK]

Les deux ifs imbriqu� ont pour moi la signification suivante :

Si le parametre creelib existe, alors, je veux compiler seulement la premi�re partie, celle qui d�finit les variables comme internes, et sinon, je veux compiler seulement la deuxi�me partie, celle qui d�finit les variables comme externes. Comme j'ai d�fini creelib dans le programme qui cr�e la librairie, je pensais que les variables seraient internes. Et comme je ne d�finis pas creelib dans le programme test (qui UTILISE cette librairie), ces variables doivent �tre consid�r�es comme externes, non ? C'est ce que je voulais en tous cas.

Non. Pour d�finir une VARIABLE comme "export�e" de ta librairie, tu mets la directive extern devant, c'est tout, et c'est le M�ME ent�te utilis� "en interne" et "en externe".
Pour une exporter une fonction, tu n'as RIEN � d�finir de particulier dans le cas d'une librairie statique.

Ensuite, le deuxi�me if (#ifdef codedh) �tait l� parce que je voulais �viter que l'on passe deux fois sur le m�me code si jamais le fichier codedfiles.h �tait lu deux fois (j'avais eu cette impression...).

C'est ce que l'on appelle commun�ment la "directive anti-double inclusion". Elle se met au niveau le plus externe, quoi qu'il arrive.

Ton ent�te doit donc s'�crire ainsi (pense aux indentations / lignes de s�paration pour rendre tout �a plus lisible) :

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
#ifndef __codedh__
#define  __codedh__
 
#define bufsize 65536
 
extern unsigned char ascbuf[bufsize];
extern int ascnotread,ascfindefichier,asclus,ascnblig,ascadfichbuf,ascadundef;
extern FILE *input_file;
 
void feedbuf();
void initread();
int readlin(char *line);
int readline(char *line);
int readlin2(char *line,int *adfi);
int readline2(char *line,int *adfi);
 
#endif //  __codedh__

Normalement, c'est bon avec �a.

Veux-tu dire que c'est interdit de mettre du code "utile" dans un if ?

Bien s�r que non ! Mais pour les directives d'exportation d'une DLL, le cas par d�faut est de ne PAS le faire. C'est la directive "MYLIB_API" qui sera d�finie diff�remment suivant que tu exportes (compilation de la DLL) ou que tu importes (utilisation de la DLL), mais les prototypes des fonctions / variables / classes ne changent pas, et n'ont donc pas besoin d'�tre d�finis "diff�remment" d'un mode � l'autre.

Pour une librairie statique, il n'y a aucune diff�rence entre les deux modes.

[ceugniet]

Merci, j'essaye !

[ceugniet]

Ben mes variables sont toujours non d�finies .

1>�dition des liens en cours...
1>testcoded.obj : error LNK2001: symbole externe non r�solu "struct _iobuf * input_file" (?input_file@@3PAU_iobuf@@A)
1>codedfiles.lib(codedfile.obj) : error LNK2019: symbole externe non r�solu "struct _iobuf * input_file" (?input_file@@3PAU_iobuf@@A) r�f�renc� dans la fonction "void __cdecl feedbuf(void)" (?feedbuf@@YAXXZ)
1>codedfiles.lib(codedfile.obj) : error LNK2001: symbole externe non r�solu "int ascfindefichier" (?ascfindefichier@@3HA)
1>codedfiles.lib(codedfile.obj) : error LNK2001: symbole externe non r�solu "int asclus" (?asclus@@3HA)
1>codedfiles.lib(codedfile.obj) : error LNK2001: symbole externe non r�solu "int ascadfichbuf" (?ascadfichbuf@@3HA)
1>codedfiles.lib(codedfile.obj) : error LNK2001: symbole externe non r�solu "unsigned char * ascbuf" (?ascbuf@@3PAEA)
1>codedfiles.lib(codedfile.obj) : error LNK2001: symbole externe non r�solu "int ascadundef" (?ascadundef@@3HA)
1>codedfiles.lib(codedfile.obj) : error LNK2001: symbole externe non r�solu "int ascnotread" (?ascnotread@@3HA)
1>C:\0\1\p\visual\vc\testcoded\Debug\testcoded.exe : fatal error LNK1120: 7 externes non r�solus
1>Le journal de g�n�ration a �t� enregistr� � l'emplacement "file://c:\0\1\p\visual\vc\testcoded\testcoded\Debug\BuildLog.htm"
1>testcoded - 9 erreur(s), 1 avertissement(s)
========== G�n�ration*: 0 a r�ussi, 1 a �chou�, 0 mis � jour, 0 a �t� ignor� ==========

Je suppose que j'ai encore oubli� quelque chose !