Salut
 
Je travaille sous Visual Studio C++ 2008 et je dois faire le portage de code c++ compilé avec GCC.
 
Dans mes sources, j'ai typiquement le code suivant:

.
 
Cependant à compilation, j'ai :

 
J'ai essayé de mettre le répertoire C:\Program Files\Microsoft Visual Studio 9.0\VC\include\ dans différents propriétés du projet :

• C/C++ / Général / Autres répertoires include
• C/C++ / Général / Résolution des références #using

 
Mais ca compile toujours pas.
 
SVP, pourriez-vous m'aider ?
Y a-t-il une propriété du projet pour indiquer le chemin vers la lib std ???
 
Merci de votre aide

Inverse les deux lignes...

 
Tout con.... ca marche.
Mais y a-t-il une explication a

 
Tout con.... ca marche.
Mais y a-t-il une explication au fait que ca passe avec gcc et pas avec le compilo VS ???
J'aimerai bien comprendre car j'ai pas envi de me taper tous les headers à modifier
 
merci du coup de main

 
PArce qu'en plus, tu mets des using namespace dans tes headers ?  

A mon avis, c'est un bug de gcc.  Une directive using a un nom de namespace comme "argument" et donc il faut que ce nom soit connu comme un nom de namespace.  (En passant gcc donne une erreur pour un autre namespace que std).
 
Toujours en passant, moi j'eviterais les directives using, et je suis activement contre leur usage dans les en-tetes.

Ben, je fais que reprendre du code qu'on me file.
Dans les classes déclarées dans les headers, il y a des fonctions qui retournent des string par exemple...

Les namespaces sont des entités définies comme les autres, ils n'existent pas ex nihilo.
 
   
 * on n'utilise jamais un using global dans un .h vu qu'il va contaminer toutes les TUs dans lequel il va etre inclus.

 
Et bien même si ce n'est pas de ton fait, c'est une très mauvaise pratique. Ta fonction peut tout à fait retourner une std::string sans faire de using. Les using dans les headers vont just dans le sens contraire de ce pour quoi les namespaces sont faits et tu vas te retrouver avec des collisions de noms ... Bref, ca mériterait une passe de nettoyage

Bon en gros tout le monde est en train de me dire que je dois me palucher tous les headers qu'on me file pour virer les using namespace std; ....
     

pas cool... et c'est juste le début du portage (537 erreurs / 2107 avertissements)

M'enfin je suis d'accord avec vous et je comprends pas pourquoi c'est comme ca dans le code... en plus le mec qui a codé n'est pourtant pas manchot en codage C++
.. à moins que lui aussi est repris ces bouts de code de qq'un d'autre...

 
Pour préciser et être plus juste tout de même, je peux déactiver les using namespace car il est à l'intérfieur d'une directive conditionnelle de compilation:

Suffit que je mette HAVE_NAMESPACES à 0 mais dans ce cas là, les types string ne seront plus reconnus...donc le problème est le même... faut mettre des std::string partout

c'est le genre de remplacement qui se fait assez simplement à coup de regexp sur tes headers.
 
Ensuite, tu mets tes using namespace dans tes fichiers cpp si ca te chante.
 
J'ai du mal à voir dans quel cas une telle directive peut-être utile. Ce serait pour un compilateur C++ qui ne supporterait pas les namespaces ?

 
Ouep ! C'est en cours.... plus que 323 erreurs ...

Pareil pour moi ... comprends pas ...
 
merci bcp pour votre aide et vos conseils
 
a très bientôt  
(avec 300 erreurs et 2000 warning, vous allez surement me revoir sur le fofo    

les vieux comeau, les vieux compilateurs sun et gcc avant 2.95 en les supportaient pas. Mais bon si on doit maintenir ces archaismes pr des compilosaures, on est pas sorti ...

 
C'est le genre de choses qu'on rencontre parce qu'elles ont été utiles il y a un certain nombres de transitions.  Elles ne le sont plus maintenant et je parie que le code ne compile de toute façon plus sur aucun compilateur ou elles ont été utiles.  On essaie normalement de nettoyer petit a petit, mais on en hérite parfois... C'est ton cas mais tu m'as l'air de récupérer cela dans une excellente contexte pour faire le nettoyage de suite.
 
Je sais, c'est le genre de nettoyage qui est assez difficile a vendre a partir d'un certain niveau -- et en prime pas très gai a faire -- mais ça rends la vie tellement plus facile par âpres que ça vaut la peine de se le palucher, quitte a l'agglomérer avec des choses qui passent mieux (chose qu'un bon manager d'un niveau en dessous de celui qui n'en comprends pas l'utilité fait naturellement).
 

 
je conseil l'option "stop on first error" dans des cas comme ça.

 
Merci du conseil , je vais regarder pour cette option.