Discussion :

[Clément_R]

Bonjour à tous,

Dans le cadre d'un projet OpenSource multiplateforme, je dois porter mon code sous windows ( j'utilise Visual C++ 6.0 et Qt-3.3.5 pour Win ). Tout ce compilait très bien sous Linux et ( sous windows ), mais là, suite à un :

#include <windows.h>

J'en ai besoin pour un appel à "shellExecute" afin de pouvoir ouvrir un explorer ou lecteur de médias ou un module de mail.
mon programme ne veut plus compiler. J'obtiens les 2 erreurs suivantes dans un fichier header de Visual :

C:\Visual\VC98\INCLUDE\objidl.h(6624) : error C2143: syntax error : missing ';' before 'string'
C:\Visual\VC98\INCLUDE\objidl.h(6624) : fatal error C1004: unexpected end of file found

Les lignes correspondantes sont fournies avec Microsoft Visual studio... Donc je pense ( peut-etre à tord, mais j'en aurais entendu parler ) que ces lignes sont plus "sûr" que les miennes.
Il ne manque pas à mon code ';' ni de '(' ou ')' . Ca fait maintenant + de 3 jours à temps plein que je suis la-dessus... Si quelqu'un avait une idée ce serait super super gentil...
Parce que là moi je CRRAAAQUE ...

D'avance, merci beaucoup.

Clément

PS : C'est mon premier message sur un forum, alors excusez moi si je ne l'ai pas mis dans la bonne thread...

[Jan Rendek]

Est-tu sûr que 'string' est correctement défini ?
Le "missing ';' before 'string' " sent fort la déclaration de type manquante.

[Clément_R]

Est-tu sûr que 'string' est correctement défini ?
Le "missing ';' before 'string' " sent fort la déclaration de type manquante.

Bien non, je n'en suis pas sûr, mais je ne m'en serts pas; à aucun endroit de l'appli. J'utilise exclusivement : des QString et des char[] (encore qu'assez peu pour ces derniers).
De même je ne fais appel ( hormis peut être indirectement à cause de Libxml et Libxslt que j'inclus ) à aucune methode ou classe des stdlib .

[Laurent Gomila]

Et à tout hasard, il y a quoi à la ligne 6624 de ce fichier ?

[Jan Rendek]

Difficile de t'aider à distance sur un coup comme ça.
Je pense que le plus simple, c'est d'isoler la partie de ton code qui nécessite les en-têtes de
window.h. Au pire, commenter les fonctions en question. Le but est de voir quel fichier
d'entête provoque l'erreur, ou quelle succession de fichiers d'entête provoque l'erreur.

Ensuite, si tu n'as besoin que de très peu de fonctionnalité de windows, essaie de retrouver
les fichers strictement nécessaire à tes besoins. Quand tu inclues windows.h, tu inclues
en cascade un ensemble assez conséquent de fichiers, dont tu n'as sûrement pas besoin
(notamment objidl.h, je pense).

Sinon, au petit bonheur la chance, j'essaierais un #include <string> avant d'inclure windows.h

L'erreur "fatal error C1004: unexpected end of file found " est génante tout de même. Est-tu
sûr que tu n'as pas oublié de point-virgule après la déclaration d'une classe ou d'une structure ?

Voilà mes 2 cents d'euros. Je laisse les spécialistes windows te répondre plus avant.

[Clément_R]

Et à tout hasard, il y a quoi à la ligne 6624 de ce fichier ?

Alors à la ligne 6624 du fichier objidl.h, il y a ça :

/****************************************
* Generated header for interface: IDataObject
* at Thu Sep 11 10:57:04 1997
* using MIDL 3.03.0110
****************************************/
/* [unique][uuid][object] */
typedef /* [unique] */ IDataObject __RPC_FAR *LPDATAOBJECT;
typedef
enum tagDATADIR
{ DATADIR_GET = 1,
DATADIR_SET = 2
} DATADIR; // ligne 6624
EXTERN_C const IID IID_IDataObject;
#if defined(__cplusplus) && !defined(CINTERFACE)
.
.
.

Le fichier est installé nativement avec MS Visual, je dois avouer qu'hormis la définition d'une structure, je n'y comprends pas grand chose...
Je suppose (très fortement) que les erreur viennent de mon code ou de la configuration VC++ de mon projet et pas de ces lignes qui après tout doivent être bonnes.

Le fait étrange est que si je retire l'appel à shellExecute, j'ai toujours les 2 erreurs, elles sont générées à cause de ce #include. Je soupsonne donc un problème de conflit de lib, mais je ne maitrise pas assez ( ni visual, ni la prog sous win ) pour pouvoir le déterminer autrement que de façon empirique ( c a d : dégager les lib les unes après les autres en croisant les doigts pour que ça marche )...

Merci de m'aider

[Jan Rendek]

Ce n'est pas un problème de lib, puisque le build échoue avant l'édition de liens.
Recherche dans quel fichier d'entête est déclaré la fonction 'shellExecute()' dont tu as besoin,
et inclue uniquement celui-ci.
Vérifie aussi tes propres fichier d'entête. Le plus simple c'est de faire un programme bidon

Code :

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

1
2
3
4
5
6
#include "le_fichier_a_tester.hh"
 
int main()
{
  //EMPTY
}

Tu les passes un par un, comme ça tu verras s'il manque un point-virgule, ou autre chose.

[Clément_R]

Ôh Gloire ! Ôh bonheur !

Ca y est je l'ai localisé !!! On dit quoi ? On dit :" merci Microsoft !"
Désolé pour les adorateurs de Bill ( je n'ai rien contre lui mais quand même )... J'ai encore jamais eut ce genre de trucs sous Linux.

Bref toujours est-il l'erreur de compilo venait de, attention les yeux :

#define DATADIR "/usr/share"

Donc c'est à savoir ce n'est la chaine de caractère qui fait référence à un chemin sous Linux qui faisait planter la compilo sous windows. Mais bien le nom de ma MACRO. C'est vrai, je le reconnais c'est un nom de macro pourri ( qui est surtout potentiellement utilisé partout ), mais bon c'est PAS UNE RAISON...
Donc, surtout si vous avez besoin d'un header découlant d'un :
#include <windows.h>
, prenez garde de ne pas avoir déclaré de macro
ayant le model suivant :
#define DATADIR "ma_macro_blablabla"

Sinon vous savez ce qu'il vous attend...
Donc voilà...

Clément

PS : merci VoidSeer pour ton idée ( c'est elle qui m'a sauvé ) et un peu de chance...
PS 2 : je crois que ça ne se fait pas de s'adresser directement comme ça à un gars ( ou une fille d'ailleurs ) dans les forums, mais quand même... Merci VoidSeer

[Laurent Gomila]

Effectivement Microsoft "pourrit" parfois l'espace global avec ses macros (compatibilité C oblige), mais toi rien ne t'empêche d'utiliser des espaces nommés et des constantes au lieu de ces horribles #define

[Médinoc]

Et puis, dans les cas où quelque chose perturbe windows.h, il reste également la possibilité de l'inclure AVANT le #define...

Là, le compilateur aurait surement marché correctement, puisque DATADIR est un typedef et que tu ne l'utilises pas. (si DATADIR était une définition, il y aurait eu une erreur de redéfinition de macro...)

[Aurelien.Regat-Barrel]

Donc c'est à savoir ce n'est la chaine de caractère qui fait référence à un chemin sous Linux qui faisait planter la compilo sous windows. Mais bien le nom de ma MACRO. C'est vrai, je le reconnais c'est un nom de macro pourri ( qui est surtout potentiellement utilisé partout ), mais bon c'est PAS UNE RAISON...

Ben si, c'est le comportement attendu. Le compilo n'a pas planté, il n'a fait qu'exécuter ce que tu lui a demandé, à savoir de remplacer partout dans le code le mot DATADIR par l'expression "/usr/share".

[Caine]

Avant de critiquer Windows à tout va, il faut savoir ce que signifie un portage d'un OS vers un autre.

Un portage réussi, ça ne s'invente pas et ça demande de maîtriser les deux OS.

[Matthieu Brucher]

Et c'est pas dû à Microsoft, c'est dû à ton code.

[Clément_R]

Avant de critiquer Windows à tout va, il faut savoir ce que signifie un portage d'un OS vers un autre.

Un portage réussi, ça ne s'invente pas et ça demande de maîtriser les deux OS.

Non effectivement, ça n s'invente pas. Mais quand t'es payé pour le faire, tu t'exécutes comme tu peux...