Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C Les lignes suivantes sont-elles nécessaires pour créer une DLL?

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;
}
<<<<<<<<<<<<<<<<<<<<<<<<
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Emmanuel Delahaye
Raymond H. wrote on 17/02/05 :
Bonjour,
J'ai DevC++ pour faire du C. Les lignes suivantes sont elles nécessaires
pour créer une DLL?


c'est quoi une DLL ?

news:fr.comp.os.ms-windows.programmation

là, ils savent...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.

Avatar
Emmanuel Delahaye
Mister Jack wrote on 17/02/05 :
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.


Un fichier texte est formé de lignes. Si la dernière ligne est
incomplète, elle pourrait très bien être ignorée. Je ne sais pas ce que
dit la norme à ce sujet (probablement rien) mais le bon sens dicte de
terminer ses lignes correctement...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Avatar
Raymond H.
Bonjour,

"Pierre Maurette" a écrit dans le message de
news:

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);
}
------------------------


La DLL serait utilisée par un projet VB. J'ai ajouté DLLIMPORT int...
comme vous l'avez écrit et l'erreur suivante est listée:
18 C:RHCodesCodes Visual BasicProjet vb RHAllCrypterEn francaisExtra
AllCrypterClef modifiéeDLLAllCrypter.c syntax error before "int"

a+
r.h.


Avatar
Raymond H.
Bonjour Mister Jack,
une vieille connaissance :-)

"Mister Jack" a écrit dans le message de news:
421475f9$0$363$
Salut Raymond !

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


Disons que j'ai déjà étudié un cours au complet en C que je viens de
terminer avant hier. J'en débute un nouveau car j'en ai perdu beaucoup et
je n'ai pas tout compris. C'est trop dans peu de jours, et la fatigue
là-dedans. Alors je continue.

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.


J'avais une ligne. Je l'ai supprimée et je l'ai remis. Mais en
supprimant j'ai remarqué qu'il y avait un espace au début qui me causait
cette erreur.
Merci et bonne journée
Raymond H.


Avatar
manu l.
"Antoine Leca" a écrit dans le message de
news:cv297p$ano$
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.

[snip]


Désolé de vous contredire. La norme ISO 1990, au point 7.9.2, §2, dit :

"C'est l'implémentation qui décide si la dernière ligne doit se terminer par
le caractère saut de ligne."

Elle a peut-être changé sur ce point. J'utilise toujours cette version-là.

Au passage je conseille à tous ceux qui veulent en savoir plus sur la norme
de lire et de relire l'excellent : "La bibliothèque C standard" de M. P.J.
Plauger, éd. Masson. (Mentionné dans la FAQ). Et en
français s.v.p. Ca vaut le détour.

Meilleures salutations.

--
Manu L.



Avatar
Erwann ABALEA
Bonjour,

On Thu, 17 Feb 2005, manu l. wrote:

"Antoine Leca" a écrit dans le message de
news:cv297p$ano$
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.


Désolé de vous contredire. La norme ISO 1990, au point 7.9.2, §2, dit :

"C'est l'implémentation qui décide si la dernière ligne doit se terminer par
le caractère saut de ligne."


Et la norme de 1999, § 5.1.1.2 dit:
"A source file that is not empty shall end in a new-line character, which
shall not be immediately preceded by a backslash character before any such
splicing takes place." (le splicing en question, c'est de supprimer la
suite "n" pour joindre 2 lignes de source).

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Je n'ai pas envie de perdre mon temps à leur APD à la con. Mais j'ai
besoin du certificat qu'y est délivré, pour passer le permis. J'ai
entendu qu'on le trouvait sur Internet. Quelqu'un aurait-il des infos?
-+- DC in GNU : Neuneu s'achète une conduite -+-




Avatar
Antoine Leca
Désolé pour la dérive sur un sujet différent.

En 42151ac4$0$3408$, manu l. va escriure:
"Antoine Leca" a écrit dans le message de
news:cv297p$ano$
warning: no newline at end
La raison officielle c'est que la norme dit qu'il faut le faire.




Désolé de vous contredire.


Je ne vois pas de contradiction.


La norme ISO 1990, au point 7.9.2, §2,


La clause 7.9.2 se dénomme "Streams" (flux), et se réfère aux objets FILE
manipulés par <stdio.h>. À moins d'exiger que le compilateur C soit écrit en
C (ce qui serait une nouveauté pour moi), cette restriction n'est pas
transposable.


Mais ce n'est pas tout.

"C'est l'implémentation qui décide si la dernière ligne doit se
terminer par le caractère saut de ligne."


Mmmm. J'aime bien le bouquin de Plaugher, mais je me méfie de la traduction
en français. On dirait qu'une fois de plus on est devant un problème.

La version anglaise dit
" Whether the last line requires a terminating new-line
character is implementation-defined. "
(texte inchangé dans la norme ANSI de 1989 ou la norme ISO de 1999).

Traduit du langage abscon de la norme en français, cela oblige
l'implémentation à expliciter (dans la documentation l'accompagnant) si la
contrainte est effective ou pas (sens de l'expression
"implementation-defined", cf. article 4, Conformité, dernier paragraphe).

Toujours en suivant la logique de l'article 4, cette même phrase oblige les
programmes « strictement conformes » (le plus portable possible) à éviter de
dépendre de cette différence, donc les _oblige_ à
toujours terminer les écritures sur des flux texte par un n. Bien
évidemment, un programme non totalement portable n'a pas de telles
obligations (par exemple, avec MS-DOS, si on voulait effacer un fichier .BAT
en cours d'exécution il fallait écrire sur la dernière ligne "DEL %0.BAT"
_sans_ la fin de ligne, sinon erreur; on voit bien que ce n'est pas portable
!)


On voit donc ici que le texte anglais parle de "defined", comportement
défini, tandis que le texte français que vous citiez parle de « décide », ce
qui induit une possibilité d'alternative.

Évidemment il serait absurde de comprendre cela comme la possibilité que
certaines implémentations acceptent une fin de ligne et d'autres la
refuseraient ;-). Si donc on enlève cette possibilité, il ne reste plus que
la solution... de ne pas se fier au fait que certaines implémentations
puissent ne pas exiger ce fameux n, et donc... il faut toujours le mettre.

Donc en fait, le texte que vous citez dit la même chose que ce que
j'affirmai, à savoir qu'il faut toujours mettre une fin de ligne à la fin
d'un fichier texte, même lorsque celui-ci est généré par un programme C.


Elle a peut-être changé sur ce point. J'utilise toujours cette
version-là.


Non, elle n'a pas changé.
C'est très bien d'utiliser cette version-là, et à ma connaissance c'est la
meilleure version de la norme en français (pour la partie bibliothèque).
Malheureusement comme on peut le voir ici, il y a des différences de détail
qui peuvent induire en erreur, et donc rien ne remplace la consultation de
la vraie norme, malheureusement en anglais.

Traduire en français la norme pourrait être utile, mais:
1) c'est beaucoup de travail, surtout si on veut que ce soit bien fait; et
personne n'a vraiment envie de le faire;
2) les utilisateurs dans une importante proportion n'en ont cure, car ils
comprennent suffisament l'anglais pour « se débrouiller »;
3) et bien sûr il n'y aucun marché derrière, donc tout plein de problèmes
administratifs potentiels (par exemple, il faudrait mettre à disposition des
traducteurs potentiels et de leurs réviserus le texte en anglais, ce qui
constituerait une potentielle perte de revenus pour les agences de
normalisation si c'était fait par le grand public, méthode Open Source).

À l'AFNOR, à un moment on avait tenté de traduire les parties clés
(conformité et glossaire, en particulier, ce qui pourrait éviter les
problèmes comme celui-ci) des normes C et C++. Mais l'effort n'a pas abouti
pendant le --court-- temps où je participais, par manque de ressources.


Antoine




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.
Attention, ce détail n'est pas à l'apanage du fichier source. J'ai

remarqué la même chose dans les fichiers de config de Thunderbird 1.0
pour Windows (....NomServeur.rc par exemple, qui liste les groupes
abonnés). Si la dernière ligne utile n'est pas terminée par un passage à
la ligne, elle est ignorée. Une grande partie du code de TB est commune
aux versions Linux et Windows. Il faudrait voir le comportement des
fread() en mode texte sous gcc face à ce problème.
Je suppose qu'un éditeur peut ajouter cette fin de ligne en fin de
fichier, ou un compilateur considérer qu'elle y est. Faudrait que je
regarde dans les 200.000 optins d'UltraEdit32.
--
Pierre

Avatar
Emmanuel Delahaye
Pierre Maurette wrote on 19/02/05 :
Faudrait que je regarde dans les
200.000 optins d'UltraEdit32.
As-tu essayé la version 11 avec réduction/expansion des blocs ? L'idée

est bonne mais la réalisation est encore un peu hésitante..

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Avatar
Pierre Maurette
Pierre Maurette wrote on 19/02/05 :

Faudrait que je regarde dans les 200.000 optins d'UltraEdit32.


As-tu essayé la version 11 avec réduction/expansion des blocs ? L'idée
est bonne mais la réalisation est encore un peu hésitante..
Je viens de l'installer pour voir. Bon, on passe à 250.000 options ;-)

En fait, c'est pas le nombre que je reproche, c'est le manque
d'intuitivité pour les trouver. Apparemment, même en ne validant pas
l'affichage des numéros de lignes, on affiche la gouttière. C'est un peu
con, mais j'imagine que ça doit pouvoir se régler par une ... option.
La réduction/expansion de blocs, je l'attendais, en souvenir d'un vieil
EDI sous DOS. Et puis tous comptes faits, avec un bon explorateur de
classes/fonctions/variables, je m'en passe facilement.
Je commence à trouver qu'à 40¤ et 20¤ la mise à jour, pour un produit
monoplateforme, c'est un peu cher.
Pour faire du C et/ou du C++ sous Windows, il y a Visual C++ 2005
Express, qui sera à moins de 100¤ (gratuit en Béta).
Une fonctionalité serait intéressante sous UltraEdit, ce serait la
sauvegarde automatique des fichiers ouverts non à jour à la perte de focus.
--
Pierre


1 2