Discussion :

[Emplyst]

Salut, je buttine de langages de programmations en langages de programmations et je me rappel plus ce que le standard de mettre "_" devant une procédure ou un structure signifie.

Je crain que ce soit tout simplement un problème de compilateur ou si c'est mes librairies qui on décider que tout ce qui était POSIX allait avoir "_" devant mais bon.

Les fait sont que lorsque j'essais de lister les fichiers présent dans un répertoire tel que montrer dans la faq (http://c.developpez.com/faq/c/?page=...dir_list_POSIX) je reçois ces erreures de compilation:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
~\Desktop\ls.c(8): error #2048: Undeclared identifier 'DIR'.
~\Desktop\ls.c(8): error #2048: Undeclared identifier 'rep'.
~\Desktop\ls.c(9): warning #2027: Missing prototype for 'opendir'.
~\Desktop\ls.c(10): warning #2027: Missing prototype for 'readdir'.
~\Desktop\ls.c(10): error #2168: Operands of = have incompatible types '[incomplete] struct dirent *' and 'int'.
~\Desktop\ls.c(11): warning #2030: = used in a conditional expression.
~\Desktop\ls.c(12): error #2113: Left operand of . has incompatible type '[incomplete] struct dirent *'.
~\Desktop\ls.c(14): warning #2027: Missing prototype for 'closedir'.
~\Desktop\ls.c(8): warning #2114: Local 'DIR' is not referenced.

Parcontre si je précède les opendir, DIR et co. de "_" le programme fonctionne.

Merci de prendre le temps de réponde.

<edit>
Ah au fait je suis aller sur le site de mon IDE (PellesC) et j'ai lu ceci «The compiler is based on LCC (by Chris Fraser and David Hanson), and the install builder for Windows is based on NSIS. Both are heavily modified.» J'imagine que ça pourrais être une explicaiton, ou du moins aider à expliquer la situation.

--Emplyst

[Emmanuel Delahaye]

Salut, je buttine de langages de programmations en langages de programmations et je me rappel plus ce que le standard de mettre "_" devant une procédure ou un structure signifie.

C'est réservé à l'implémentation. L'utilisateur ne doit pas définir d'identificateurs commençant par _.

http://emmanuel-delahaye.developpez....htm#id_reserve

Je crain que ce soit tout simplement un problème de compilateur ou si c'est mes librairies qui on décider que tout ce qui était POSIX allait avoir "_" devant mais bon.

Les fait sont que lorsque j'essais de lister les fichiers présent dans un répertoire tel que montrer dans la faq (http://c.developpez.com/faq/c/?page=...dir_list_POSIX) je reçois ces erreures de compilation:
[code]
~\Desktop\ls.c(8): error #2048: Undeclared identifier 'DIR'.

Les fonctions POSIX ne sont pas précédées d'un _. Est-tu sûr que l'inclusion du fichier <dirent.h> s'est faite correctement ? Pas de message ? Les fichiers sont bien présents et accessibles ?

[Emplyst]

L'inclusion <dir.h> n'est pas reconnue. À l'inverse de <dirent.h>, m'enfin voici le code du programme avec les barres de soulignement:

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
 
#include <stdio.h>
#include <sys/types.h>
#include <dirent.h>
 
int main(void)
{
	struct _dirent *reader;
	_DIR *dir;
 
	dir = _opendir("C:\\test");
 
	while ((reader = _readdir(dir)))
	{
		printf("-- %s\n", reader->d_name);
	}
	_closedir(dir);
 
	return 0;
}

En fait, j'en suis venu à utiliser _dirent par erreur et j'ai remarquer par la suite que _opendir existait également et c'est comme ça que j'ai réaliser que _opendir retournait un type _DIR etc etc.

C'est vraiment particulier comme erreur, je vais tenter de me renseinger sur les forums de Pelles C parallèlement.

[Emmanuel Delahaye]

L'inclusion <dir.h> n'est pas reconnue.

Erreur de ma part... Ca n'existe pas.

[Emplyst]

Bon j'ai régler le problème d'une façon un peut barbare ^_^ j'utilise un IDE qui prend MinGW comme compileur (Code::Block). Un peut moins bien mais bon, je finirais par m'y habituer.

[Emmanuel Delahaye]

Bon j'ai régler le problème d'une façon un peut barbare ^_^ j'utilise un IDE qui prend MinGW comme compileur (Code::Block). Un peut moins bien mais bon, je finirais par m'y habituer.

C'est à peu près ce qu'on fait tout ici (enfin en grande majorité...)