Discussion :

[myred]

Bonjour,
J'ai déclarer une structure et une fonction dans mon .h :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#include "D:\banque\Client.h"
#ifndef __CLIENT__
#define __CLIENT__
#define CAPACITE 20000
 
typedef struct
{
    Client liste[CAPACITE];
    int taille;
}listeClient;
 
listeClient* creerlisteClient(void);
#endif

Puis dans le .c

Code :

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

1
2
3
4
5
6
7
8
 
#include "D:\banque\listeClient.h"
listeClient* creerlisteClient()
{
    listeClient *c;
   ...
    return c;
}

Dès la seconde ligne j'ai une erreur de compilation : D:\Banque\listeClient.c|2|error: expected declaration specifiers or '...' before 'listeClient'|
Je ne vois vraiment pas ou se trouve le problème, j'ai essayer d'enlever (void) ou de le rajouter rien. Voila maintenant 1h que je tourne en rond.
Merci de votre aide.

[bpy1401]

Bonjour myred

Code :

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

#include "D:\banque\Client.h"

fait attention au "\" , c'est un code de contrôle dans les chaines de caractères, le chemin que tu donne n'est pas celui que tu crois donner.

De plus on ne met jamais un chemin absolu pour un include, c'est moche, même très très moche. Si ton include n'est pas dans le répertoire courant, ton compilateur te permet de redéfinir des path supplémentaires pour les includes.

A+

[myred]

Merci de ta réponse rapide. J'utilise la bibliothèque GTK+, ce qui me force a mettre des chemins absolus -_- ce n'est pas propre, cependant il trouve bien mon header vu qu'il reconnaît ma structure. Je vais essayer de redéfinir des PATH.
J'ai essayé de changer le chemin du fichier header pour le mettre directement au bon endroit, cependant le problème reste le même.
"D:\Banque\listeClient.c|2|error: expected declaration specifiers or '...' before 'listeClient'|"

[kwariz]

Salut,

ce que t'explique bpy1401 c'est qu'au lieu de

Code :

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

#include "D:\banque\Client.h"

il faudrait écrire

Code :

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

#include "D:\\banque\\Client.h"

car sinon \b et \C peuvent se faire interpréter autrement. Enfin je pense que c'en est un cause, car je ne connais pas bien les spécificité des compilo sur Windows ... il y a peut-être une exception pour les chaînes des includes ?

Pour éviter d'utiliser des chemins en dur dans les includes, tu peux te référer à la doc de ton compilo, il doit permettre via une option IDE ou CLI (généralement -I ou /I) de donner une liste de chemins à parcourir pour trouver les includes.

[LittleWhite]

Bonjour,

Comme dit précédemment, je conseille de rajouter un dossier d'inclusion, dans les propriétés de votre projet (ou comme paramètre à votre compilateur). Ainsi, plus besoin d'écrire le chemin absolu du fichier et donc, votre code source devient plus libre (exportable / copiable / réutilisable).

De plus, je conseille une écriture avec les '/'. Car même s'il fut un temps ou Microsoft obligé les '\', ce temps est résolu. Ainsi, pour qu'il y ai moins de problème avec d'autres compilateurs / systèmes, le '/' est conseillé.

[myred]

Bonjour,
J'ai réussi à faire reconnaitre au compilateur le fichier header rien qu'en mettant Client.h.
Cependant j'ai toujours la même erreur -_-

[bpy1401]

Bonjour

Tu peux nous mettre aussi Client.h

merci

[myred]

J'ai résolu le problème. Je ne sais pas trop comment.
Merci de votre aide !
Bonne journée

[denispir]

Salut,

ce que t'explique bpy1401 c'est qu'au lieu de

Code :

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

#include "D:\banque\Client.h"

il faudrait écrire

Code :

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

#include "D:\\banque\\Client.h"

car sinon \b et \C peuvent se faire interpréter autrement. Enfin je pense que c'en est un cause, car je ne connais pas bien les spécificité des compilo sur Windows ... il y a peut-être une exception pour les chaînes des includes ?
.

Il me semble avoir lu dans la doc du préprocesseur C (cpp) que les noms/chemins de fichiers à inclure ne sont pas interprétés (d'ailleurs c'est logique, l'include se passe avant le décodage "linguistique" proprement dit ; même si cpp fait la tokenisation, il doit s'arrêter là).

PS:
@myred : ce serait bien de savoir pourquoi (ton problème est résolu), non? Pour toi et pour les autres, d'ailleurs.


Denis

[kwariz]

Il me semble avoir lu dans la doc du préprocesseur C (cpp) que les noms/chemins de fichiers à inclure ne sont pas interprétés (d'ailleurs c'est logiqe, l'include se passe avant le décodage "linguistique" proprement dit ; même si cpp fait la tokenisation, il doit s'arrêter là).

Denis

Ah oui, tu as raison. Je viens de consulter la doc cpp (version GNU) et il est stipulé :

However, if backslashes occur within file, they are considered ordinary text characters, not escape characters. None of the character escape sequences appropriate to string constants in C are processed. Thus, #include "x\n\\y" specifies a filename containing three backslashes. (Some systems interpret ‘\’ as a pathname separator. All of these also interpret ‘/’ the same way. It is most portable to use only ‘/’.)

Maintenant il faudrait connaître le comportement du compilo utilisé par le PO.

[denispir]

Ah oui, tu as raison. Je viens de consulter la doc cpp (version GNU) et il est stipulé :

However, if backslashes occur within file, they are considered ordinary text characters, not escape characters. None of the character escape sequences appropriate to string constants in C are processed. Thus, #include "x\n\\y" specifies a filename containing three backslashes. (Some systems interpret ‘\’ as a pathname separator. All of these also interpret ‘/’ the same way. It is most portable to use only ‘/’.)

Maintenant il faudrait connaître le comportement du compilo utilisé par le PO.

La question est aussi de savoir quelle part, dans le comportement de cpp sur ce point et d'autres, est juste application de la norme C ou décision de leur part (qui me semble correcte dans ce cas).

denis

[kwariz]

La question est aussi de savoir quelle part, dans le comportement de cpp sur ce point et d'autres, est juste application de la norme C ou décision de leur part (qui me semble correcte dans ce cas).

denis

En fait la norme c99 précise en 6.4.7, à partir du verset 2:

2 The sequences in both forms of header names are mapped in an implementation-defined manner to headers or external source file names as specified in 6.10.2

3 If the characters ', \, ", //, or /* occur in the sequence between the < and > delimiters, the behavior is undefined. Similarly, if the characters ', \, //, or /* occur in the sequence between the " delimiters, the behavior is undefined.(69) A header name preprocessing token is recognized only within a #include preprocessing directive.

....

(69 Thus, sequences of characters that resemble escape sequences cause undefined behavior.