Passage VC6-> VS2008: erreur dans les fichiers internes à Visual lors de la compilation

Version imprimable

15/12/2009, 15h01
Flore22

Passage VC6-> VS2008: erreur dans les fichiers internes à Visual lors de la compilation

Bonjour,

Dans le cadre de mon travail, on m'a demandé de passer une solution de Visual C++6 vers Visual Studio 2008. Sous visual 6, la solution compile sans problème.

Après avoir pris en compte un certain nombre de modifications dans les 6 projets qui composent la solution (du type ajouter des déclarations de variables entières dans les boucles "for", ou faire des modifications pour passer les bons types en entrée), la compilation se passe bien pour 5 d'entre eux.

J'ai toutefois été forcé d'ajouter aux projets les chemins des "include" de VC, certains fichiers ".h" ne se trouvant pas dans ceux de Visual studio 2008. Ce point déjà me semble surprenant... mais ça marche...

En revanche, lors de la compilation du 6ème projet, qui dépend des 5 autres et doit conduire à la création d'un fichier exécutable, la compilation s'arrête -le nombre d'erreur dépasse les 100 par fichier-...

Ce qui est surprenant et pose problème, c'est que toutes ces erreurs ce situent dans des fichiers propres à Visual Studio 2008! les fichiers en question se trouvent dans:
c:\program files\microsoft visual studio 9.0\vc\atlmfc\include\ ou dans c:\program files\microsoft visual studio 9.0\vc\include...

et les erreurs sont de type:

Citation:

- error C2065: 'DWORD_PTR' : identificateur non déclaré
- error C2143: erreur de syntaxe : absence de ';' avant 'GetWindowThreadProcessId'
- error C2065: 'LLONG_MIN' : identificateur non déclaré
- error C3861: 'memcpy_s' : identificateur introuvable

... [je passe, il y en a 7650, toutes du même genre]

Or, ces fichiers n'ont pas été modifiés dans le cadre du projet!!
Les erreurs étant du même type, sur des fichiers dans le même dossier, j'ai tendance à supposer qu'il s'agit d'une question de configuration de visual, mais sans certitude...

Quelqu'un aurait-il déjà rencontré le même type d'erreur et pourrait-il m'éclairer? Merci d'avance.
15/12/2009, 16h22
Mac LAK
Citation:

Envoyé par Flore22

Quelqu'un aurait-il déjà rencontré le même type d'erreur et pourrait-il m'éclairer? Merci d'avance.

C'est l'interface de certaines fonctions MFC qui a été changé, le plus flagrant étant les CString.

Tu auras une partie de la réponse sur cette page. Comme tu as fait un gros saut de version (j'ai fait le même d'ailleurs), tu vas devoir concaténer manuellement toutes les modifications avec rupture (Breaking Changes) de chaque version intermédiaire.
Pour ma part, sur un problème similaire, j'ai dû réécrire la callback intégralement pour la faire coller aux nouveaux paramètres (cf. aide MFC VS2008 pour savoir quoi faire/mettre).

Quelques tuyaux :
- Macro _USE_32BIT_TIME_T pour les problèmes sur time_t.
- Pour les versions sécurisées des fonctions CRT/STL : _CRT_SECURE_NO_WARNINGS et _SCL_SECURE_NO_WARNINGS.
- Vérifier attentivement les CString dans le code MFC.
En espérant t'avoir aidé.
15/12/2009, 16h44
Flore22
Merci pour le lien! Il me sera probablement utile, mais malheureusement pas dans l'immédiat... (je note toutefois le raisonnement, je vais me plonger dans ces sauts pour voir s'ils ne résolvent pas d'autres erreurs) :

La première erreur que j'obtiens lors de la compilation, récurrente, est la suivante:

Citation:

c:\program files\microsoft visual studio 9.0\vc\atlmfc\include\atlalloc.h(80) : error C2065: 'LLONG_MIN'*: identificateur non déclaré

Dans le lien que tu me donnes, on indique que la version antérieure de visual acceptait que les paramètres d'une fonctions soient entre guillemets alors qu'il ne s'agissait pas de chaine de caractères, ou l'inverse (que le paramètre n'ait pas de guillemets alors qu'il s'agissait d'une chaine). Ceci donne une erreur C2065 (comme la mienne!:)).

Si ce n'est que dans le code de ma machine, le code est le suivant:
Code:

1 2 3 4 public: static const long long _Min=LLONG_MIN; static const long long _Max=LLONG_MAX; };
et LLONG_MIN n'est -d'après la console d'erreur- pas déclaré...
Je veux bien le déclarer, mais le fichier est un fichier Visual... (voir chemin d'accès). Et je suppose que Visual fournit des fichiers corrects...

Les autres erreurs y ressemblent... La deuxième, qui porte sur la même ligne que la première, est la suivante:

Citation:

c:\program files\microsoft visual studio 9.0\vc\atlmfc\include\atlalloc.h(80) : error C2057: expression constante attendue

Bref, ça ressemble à des erreurs de débutant (oubli de déclaration, mettre une variable à la place d'une constante,...), sauf que c'est du code visual... ce qui me surprend...
15/12/2009, 23h25
bacelar

Faite particulièrement attention aux "#ifdef" qui encadrent les déclarations que le pre-processeur ne trouve pas. Je pense qu'un petit nombre de constantes de compilation permettraient de rendre le vieux code plus acceptable pour le jeune compilateur.
16/12/2009, 10h01
Mac LAK

Citation:

Envoyé par bacelar

Faite particulièrement attention aux "#ifdef" qui encadrent les déclarations que le pre-processeur ne trouve pas. Je pense qu'un petit nombre de constantes de compilation permettraient de rendre le vieux code plus acceptable pour le jeune compilateur.

C'est typiquement le cas de _USE_32BIT_TIME_T, par exemple...
21/12/2009, 09h01
Flore22

J'ai fini par trouver une solution, mais dont les implications m'échappent...

Le projet fait référence à des bibliothèques qui se trouvent sur un lecteur externe (lecteur N:\ pour info). Le chemin de ce lecteur était indiqué dans les propriétés d'un projet qui refusait de compiler (dans Propriétés de configuration/ C C++/ Général/ autres fichiers Include).
J'avais précédemment résolu cette erreur de compilation en supprimant ce chemin des pages de propriétés du projet, et en le mettant dans Outils/Options puis Projets et Solutions/ répertoires de VC++ puis sélectionner dans le menu déroulant de gauche "Fichiers Include".

Le projet en question compilait alors, mais pas le projet global, dépendant des 5 autres. Après multiples essais et recherches en tout genre, je me suis rendu compte que ce dernier projet faisait référence, dans ses propriétés, au chemin du lecteur N:\. La solution pour faire compiler la solution complète a alors consisté en la suppression de la référence à N:\ dans les propriétés du dernier projet (N:\ étant néanmoins recensé dans les fichiers Include globaux). Ou comment passer de 7650 erreurs à 160 (résolvables).

C'est pas très très propre... Heureusement, il s'agit de la seule solution sur laquelle je travaille avec Visual studio.

En résumé, j'ai supprimé la référence à un dossier d'include des propriétés des projets, pour le mettre une unique fois dans Outils/options. La double référence à ce dossier d'include ne convenait pas au compilateur. Chose étrange, l'inclusion dans les propriétés de chaque projet ne convenait pas non plus, et il a fallu le mettre une seule et unique fois dans les options globales de compilation.

A ce jour, la solution compile! (ne linke pas encore, mais c'est une autre histoire...:))
Merci pour votre aide!