Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Les lignes suivantes sont-elles nécessaires pour créer une DLL?

20 réponses
Avatar
Raymond H.
Bonjour,
J'ai DevC++ pour faire du C. Les lignes suivantes sont elles
nécessaires pour créer une DLL?
r.h.

>>>>>>>>>>>>>>>>>>>>>
BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle. */ ,
DWORD reason /* Reason this function is being
called. */ ,
LPVOID reserved /* Not used. */ )
{
switch (reason)
{
case DLL_PROCESS_ATTACH:
break;

case DLL_PROCESS_DETACH:
break;

case DLL_THREAD_ATTACH:
break;

case DLL_THREAD_DETACH:
break;
}
/* Returns TRUE on success, FALSE on failure */
return TRUE;
}
<<<<<<<<<<<<<<<<<<<<<<<<

10 réponses

1 2
Avatar
Raymond H.
Bonjour,
J'essaie de créer une DLL et j'ai une erreur à la compilation (en C).
(Existe-t-il un site expliquant par un exemple comment créer un simple DLL
avec DevC++ en C ?).
Voici les seules lignes que j'ai dans 'fichier.c':
-----------------------
int Addition(int Val1,int Val2)
{
return((int)(Val1 + Val2));
}
------------------------


Voici ce qui est indiqué au bas de DevC++ après compilation de ma DLL:
-------------------------
Compilateur: Default compiler
Exécution de gcc.exe...
gcc.exe "C:RHCodesCodes Visual BasicProjet vb RHAllCrypterEn
francaisExtra AllCrypterClef modifiéeDLLAllCrypter.c" -o
"C:RHCodesCodes Visual BasicProjet vb RHAllCrypterEn francaisExtra
AllCrypterClef modifiéeDLLAllCrypter.exe" -I"C:Program
FilesDev-Cppinclude" -L"C:Program FilesDev-Cpplib"
C:/RH/Codes/Codes Visual Basic/Projet vb RH/AllCrypter/En francais/Extra
AllCrypter/Clef modifiée/DLL/AllCrypter.c:21:3: warning: no newline at end
of file

C:Program FilesDev-Cpplib/libmingw32.a(main.o)(.text+0x106):main.c:
undefined reference to `'

Exécution terminée
------------------------

a+
r.h.
Avatar
Pierre Maurette
Bonjour,
J'ai DevC++ pour faire du C. Les lignes suivantes sont elles
nécessaires pour créer une DLL?
r.h.


BOOL APIENTRY DllMain (HINSTANCE hInst /* Library instance handle. */ ,
DWORD reason /* Reason this function is being
called. */ ,
LPVOID reserved /* Not used. */ )
{
switch (reason)
{
case DLL_PROCESS_ATTACH:
break;

case DLL_PROCESS_DETACH:
break;

case DLL_THREAD_ATTACH:
break;

case DLL_THREAD_DETACH:
break;
}
/* Returns TRUE on success, FALSE on failure */
return TRUE;
}
Vous pourriez vous cintenter de :

BOOL APIENTRY DllMain (HINSTANCE hInst
, DWORD reason
, LPVOID reserved)
{
return 1;
}

Mais franchement, pourquoi ? L'important, c'est le "return 1" lors de
l'enregisrement de la DLL.
Mais quand vous maîtriserez le mécanisme, ce sera pratique de pouvoir
placer du code dans les deux premiers case. Pour les deux derniers, leur
utilisation attendra certainement encore quelques temps.
Laissez le code tel qu'il est, le compilateur fera le ménage. Si vous
pensez que ce code inutile va ralentir ou engraisser votre appli (ce qui
est faux), commentez /* tout le bloc sauf le return */.

--
Pierre

Avatar
Pierre Maurette
Bonjour,
J'essaie de créer une DLL et j'ai une erreur à la compilation (en C).
(Existe-t-il un site expliquant par un exemple comment créer un simple DLL
avec DevC++ en C ?).
Voici les seules lignes que j'ai dans 'fichier.c':
-----------------------
int Addition(int Val1,int Val2)
{
return((int)(Val1 + Val2));
}
------------------------
Si Addition() est une fonction exportée par la DLL, elle doit s'écrire :

-----------------------
DLLIMPORT int Addition(int Val1,int Val2)
{
return(Val1 + Val2);
}
------------------------



Voici ce qui est indiqué au bas de DevC++ après compilation de ma DLL:
-------------------------
Compilateur: Default compiler
Exécution de gcc.exe...
gcc.exe "C:RHCodesCodes Visual BasicProjet vb RHAllCrypterEn
francaisExtra AllCrypterClef modifiéeDLLAllCrypter.c" -o
"C:RHCodesCodes Visual BasicProjet vb RHAllCrypterEn francaisExtra
AllCrypterClef modifiéeDLLAllCrypter.exe" -I"C:Program
FilesDev-Cppinclude" -L"C:Program FilesDev-Cpplib"
C:/RH/Codes/Codes Visual Basic/Projet vb RH/AllCrypter/En francais/Extra
AllCrypter/Clef modifiée/DLL/AllCrypter.c:21:3: warning: no newline at end
of file
Clair apparemment. Il faut passer à la ligne "à vide" à la fin de la

dernière ligne.


C:Program FilesDev-Cpplib/libmingw32.a(main.o)(.text+0x106):main.c:
undefined reference to `'
Là, je n'en sais pas assez. Il est important que vous compiliez (ou

construisiez) soit un projet DLL tel que le propose
Fichier/Nouveau/Projet, pour fabriquer la DLL, soit un projet Console
Application (c'est le plus simple) pour faire un programme de test (mais
je crois que vous testez en VB).
--
Pierre

Avatar
Mister Jack
Salut Raymond !

Je vois que ça progresse sur l'écriture en C.

Raymond H. wrote:
Bonjour,
J'essaie de créer une DLL et j'ai une erreur à la compilation (en C).
Voici les seules lignes que j'ai dans 'fichier.c':
-----------------------
int Addition(int Val1,int Val2)
{
return((int)(Val1 + Val2));
}
------------------------


Il faut toujours penser à ajouter une ligne vide à la fin de ton
programme C. Si quelqu'un savait le pourquoi de ceci, peut-il nous en
faire part ? Je me pose la question sans savoir me répondre :p

warning: no newline at end


Pourtant je le trouve très clair ce message.

Amicalement,
--
Mister Jack (MJ)
"- M'sieur ! Il me met no newline at end of file !
- Hé bien, il doit y avoir une règle qui dit qu'il faut un newline.
- Alors je mets newline point virgule ?
- Non..."

Avatar
Pierre Maurette
[...]
Il faut toujours penser à ajouter une ligne vide à la fin de ton
programme C. Si quelqu'un savait le pourquoi de ceci, peut-il nous en
faire part ? Je me pose la question sans savoir me répondre :p
Parce que c'est dans la norme ;-).

En fait, je suppose que comme souvent les raisons sont à la fois
historiques et dans l'universalité des plateformes sur lesquelles le
compilateur doit pouvoir être implémenté.
Il ne faut pas "ajouter une ligne vide" en fin de programme, mais chaque
ligne doit être terminée par un "fin de ligne". Les fichiers sources
sont lus ligne à ligne, et il faut que la dernière soit lue. Sans
rentrer dans les délices des 0x0D, 0x0A et autres (j'en serais
incapable), il se trouve que nos éditeurs, en tous cas une partie
d'entre eux, ne savent terminer une ligne sans passer à la suivante.
Remarquez que gcc 3.2 ne se laisse pas prendre. Il identifie
parfaitement cette dernière ligne. Simplement il nous warne gentiment
pour pas qu'on ait de pépins si on passe le petit à la concurrence, et à
la concurrence étrangère en particulier.


warning: no newline at end


Pourtant je le trouve très clair ce message.
Non, pas tant que ça. Est-ce "Attention, malheureux, pas de newline à la

fin", ou "Attention, il n'y a pas de newline à la fin" ?
Comment traduisez-vous "No woman no cry" (Bob) ?
--
Pierre


Avatar
Mister Jack
Salut !

Pierre Maurette wrote:
Il faut toujours penser à ajouter une ligne vide à la fin de ton
programme C. Si quelqu'un savait le pourquoi de ceci, peut-il nous en
faire part ?


Parce que c'est dans la norme ;-).


Ah, bah vala... ça explique tout ;-)

Il ne faut pas "ajouter une ligne vide" en fin de programme, mais chaque
ligne doit être terminée par un "fin de ligne". Les fichiers sources
sont lus ligne à ligne, et il faut que la dernière soit lue. Sans
rentrer dans les délices des 0x0D, 0x0A et autres (j'en serais
incapable), il se trouve que nos éditeurs, en tous cas une partie
d'entre eux, ne savent terminer une ligne sans passer à la suivante.


Disons que certains compilateurs s'en sont tenus à la norme, et savent
qu'une ligne de code est peut-être terminée lorsqu'ils rencontrent un fn
de ligne. (encore faut-il tester pour en être sûr).
Et s'ils ont une fin de fichier avant, alors ils sont paumés...

Ce que j'ai toujours eu du mal à comprendre c'est le pourquoi de ce saut
de ligne. Je pense que la norme ne devrait pas interférer avec la façon
de faire du compilateur, mais bon... faut s'y résigner.

warning: no newline at end
Pourtant je le trouve très clair ce message.



Non, pas tant que ça. Est-ce "Attention, malheureux, pas de newline à la
fin", ou "Attention, il n'y a pas de newline à la fin" ?


Bon, malgré le fait que je trouve le message clair, je peux concevoir
qu'il puisse paraitre incompréhensible à d'autres. (c'est déjà arrivé :
voir la signature)
Je ne pensais sincèrement pas qu'un canadien y verrait une difficulté.

Merci de cette réponse.
Amicalement,
--
Mister Jack (MJ)
"- M'sieur ! Il me met no newline at end of file !
- Hé bien, il doit y avoir une règle qui dit qu'il faut un newline.
- Alors je mets newline point virgule ?
- Non..."



Avatar
Pierre Maurette
[...]
Ce que j'ai toujours eu du mal à comprendre c'est le pourquoi de ce saut
de ligne. Je pense que la norme ne devrait pas interférer avec la façon
de faire du compilateur, mais bon... faut s'y résigner.
Là, gcc est très sain. Il considère que dans le contexte, une fin de

fichier est aussi une fin de ligne et fait son boulot. La norme de
l'interdit pas. Elle autorise les implémentations à exiger une fin de ligne.
Le warning n'est pas une contrainte. C'est une fonctionalité utile du
compilateur. gcc offre *en plus* la vérification de conformité. C'est
comme ça qu'il faut voir les choses.

[...]
Je ne pensais sincèrement pas qu'un canadien y verrait une difficulté.
Qui est canadien ?


Alors, "No woman no cry" ?
--
Pierre

Avatar
Mister Jack
Salut !

Pierre Maurette wrote:
Là, gcc est très sain. Il considère que dans le contexte, une fin de
fichier est aussi une fin de ligne et fait son boulot. La norme de
l'interdit pas. Elle autorise les implémentations à exiger une fin de
ligne.
Le warning n'est pas une contrainte. C'est une fonctionalité utile du
compilateur. gcc offre *en plus* la vérification de conformité. C'est
comme ça qu'il faut voir les choses.


Oui. GCC se borne à un avertissement. C'et ce qui me semble
effectivement le plus sain, comme comportement.
Si j'ai bien suivi, ce "fin de ligne" serait une /recommandation/ de la
norme, ou devrait être considéré comme tel ? Là, ça me semblerait plus
compréhensible.

Je ne pensais sincèrement pas qu'un canadien y verrait une difficulté.
Qui est canadien ?



Eh bien, je crois que Raymond, l'est. A moins qu'il soit Québequois ;-)
[Date: Thu, 17 Feb 2005 02:19:26 -0500
X-Complaints-To: ]

Alors, "No woman no cry" ?


Désolé, je ne pensais que vous attendiez une réponse :p
Effectivement ça peut prêter à confusion. La bonne traduction doit être
"Non femme, ne pleure pas", mais on pourrait l'interpréter par "Pas de
femme, [et] pas de pleurs" ou "Pas de femme, [donc] pas de pleurs".
Alors, la signification profonde des paroles de Lemon Tree, c'est quoi?
Non, non, je n'attends pas de réponse :D

Cordialement,
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !" <EOL>
<EOF>


Avatar
Antoine Leca
En 421475f9$0$363$, Mister Jack va escriure:
warning: no newline at end
Il faut toujours penser à ajouter une ligne vide à la fin de ton

programme C. Si quelqu'un savait le pourquoi de ceci, peut-il nous
en faire part ? Je me pose la question sans savoir me répondre :p


La raison officielle c'est que la norme dit qu'il faut le faire.

La raison réelle c'est qu'il y eut des systèmes qui ne traitaient que les
lignes entières; et que c'était la présence du n final de ligne qui
marquait une ligne comme complète. Alors si tu oublies la dernière fin de
ligne, il fut possible que certains compilateurs ne voient pas la dernière
ligne.

Une raison additionnelle (et alambiquée) est que si tu ne mets pas de fin de
ligne à un fichier #include, certains préprocesseurs vont faire la jonction
avec le caractère suivant (le premier caractère de la ligne qui suit le
#include), puisuque "fin de fichier" n'est pas un caractère valide en C.
Pendant que la plupart des autres font voir deux lexèmes, cela devient donc
une écriture ambiguë.


Antoine


Avatar
Mister Jack
Salut !

Antoine Leca wrote:
En 421475f9$0$363$, Mister Jack va escriure:
warning: no newline at end
Il faut toujours penser à ajouter une ligne vide à la fin de ton

programme C. Si quelqu'un savait le pourquoi de ceci, peut-il nous
en faire part ? Je me pose la question sans savoir me répondre :p


Une raison additionnelle (et alambiquée) est que si tu ne mets pas de fin de
ligne à un fichier #include, certains préprocesseurs vont faire la jonction
avec le caractère suivant (le premier caractère de la ligne qui suit le
#include), puisuque "fin de fichier" n'est pas un caractère valide en C.
Pendant que la plupart des autres font voir deux lexèmes, cela devient donc
une écriture ambiguë.


OK, le manque éventuel d'un séparateur quand on a plusieurs fichiers, ça
me plait comme explication.
Evidemment ça supprime un type d'erreur qu'il pourrait être difficile de
détecter autrement. Et ce n'est pas vraiment une incursion dans le
domaine de la compilation, donc sa présence dans la norme me semble
légitime.

Parfait ! Merci beaucoup.

Cordialement,
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"



1 2