[XML]Utilisation de xerces-c sous Visual Studio 2005[résolu]

mer, 14/02/2007 - 17:37
#1
K-lo
[XML]Utilisation de xerces-c sous Visual Studio 2005[résolu]

J'ai récupéré xerces-c afin de faire des traitements sur fichier XML (logique :P)
Cependant après plusieurs liaisons (Outils->Option->Projet&Solution)
Notamment Lib, Include... Je n'arrive pas a compiler.
J'ai même utiliser une variable d'environnement et toujour des pb de liaisons
(le programme que j'ai tenté de compiler correspond à l'initialisation de xerces-c donner dans la doc fournit avec la librairie)

J'ai vraiment du mal à rajouter des librairies pour VStudio et je fini par m'y perdre.

Quelqu'un peut m'aider pour installer (TUTO précise) cette librairie ?

Haut
mer, 14/02/2007 - 19:01
fredericmazue

Salut k-lo :)

Quote:
J'ai même utiliser une variable d'environnement et toujour des pb de liaisons

Je suppsoe que tu as une floppée de messages qui émanent de l'éditeur de liens. Est-ce que tu peux donner un ou deux messages ici ?

Sinon pour ajouter des libs en Visual c'est tout simple. Ajouter dans la liste des répertoires de libs le répertoire qui contient ta lib et ajouter le fichier .lib lui même dans la ligne de commande de l'éditeur de liens

Ou sinon directement au début du code:

#pragma comment(lib, ".la_librairie_a_ajouter.lib")

Haut
jeu, 15/02/2007 - 09:54
K-lo

fredericmazue wrote:

Je suppsoe que tu as une floppée de messages qui émanent de l'éditeur de liens. Est-ce que tu peux donner un ou deux messages ici ?

Oui c'est vrai :D

fredericmazue wrote:
Sinon pour ajouter des libs en Visual c'est tout simple. Ajouter dans la liste des répertoires de libs le répertoire qui contient ta lib

Jusque là ça va !
fredericmazue wrote:

et ajouter le fichier .lib lui même dans la ligne de commande de l'éditeur de liens

Ou sinon directement au début du code:

#pragma comment(lib, ".la_librairie_a_ajouter.lib")

Et bien c'est là qu'est mon oubli ou plutôt la ligne que j'ignorais qu'il fallait mettre.

Maintenant ça marche impécable.
Merci fredericmazue!

Haut
jeu, 15/02/2007 - 18:18
K-lo

Je ne sais pas si ça vient de l'installation (pourtant j'ai réussi à compiler mon programme de conversion de chaine XMLString en chaine std::string via boost sans problème...) mais je n'arrive pas à définir une classe dérivée de DefaultHandler, qui est primordiale lorsque l'on veut parser un document.

J'ai bien inclue mes librairies (via VC++ et via pragma comment(lib, "nom2LaLib))
mais je me retrouve avec une 20ène de lignes d'erreurs de linkage de ce types:

1>MaClasse.obj : error LNK2001: symbole externe non résolu "public: virtual class xercesc_2_7::InputSource * __thiscall xercesc_2_7::DefaultHandler::resolveEntity(wchar_t const * const,wchar_t const * const)" (?resolveEntity@DefaultHandler@xercesc_2_7@@UAEPAVInputSource@2@QB_W0@Z)).

1>MaClasse.obj : error LNK2001: symbole externe non résolu "public: virtual void __thiscall xercesc_2_7::DefaultHandler::notationDecl(wchar_t const * const,wchar_t const * const,wchar_t const * const)" (?notationDecl@DefaultHandler@xercesc_2_7@@UAEXQB_W00@Z)

1>MaClasse.obj : error LNK2001: symbole externe non résolu "public: virtual void __thiscall xercesc_2_7::DefaultHandler::unparsedEntityDecl(wchar_t const * const,wchar_t const * const,wchar_t const * const,wchar_t const * const)" (?unparsedEntityDecl@DefaultHandler@xercesc_2_7@@UAEXQB_W000@Z)

1>MaClasse.obj : error LNK2001: symbole externe non résolu "public: virtual void __thiscall xercesc_2_7::DefaultHandler::characters(wchar_t const * const,unsigned int)" (?characters@DefaultHandler@xercesc_2_7@@UAEXQB_WI@Z)
Haut
jeu, 15/02/2007 - 18:47
fredericmazue

Quote:
J'ai bien inclue mes librairies (via VC++ et via pragma comment(lib, "nom2LaLib))

On dirait pourtant qu'il en manque une.
ou peut être que c'est une macro UNICODE qui gêne ou qui manque

Haut
jeu, 15/02/2007 - 23:16
K-lo

Et bien non j'ai mm teste avec #define UNICODE et non mm problème

Haut
ven, 16/02/2007 - 10:19
fredericmazue

Quote:
Et bien non j'ai mm teste avec #define UNICODE et non mm problème

Justement... dans Visual faudrait l'enlever si elle gêne. UNICODE est définie par défaut dans les projets de toutes façons. Donc c'est dans Visual que UNICODE peut gêner.

Si tu regardes les erreurs de l'éditeur de liens, ce sont des fonctions qui prennent du wchar_t en veux tu en voilà qui font défaut. Alors je me dis que la librairie a peut être été compilée sans UNICODE et c'est là qu'elle manquerait.
Tu l'as compilée toi même la lib ou tu as seulement téléchargé les binaires ?

Je pense que c'est dans cette direction qu'il faut chercher, si tu es sûr que tu n'as pas omis une lib dans la liste à intégrer au projet.

Au problème possible, un problème de décoration de noms de fonctions. mais je n'y crois pas trop là, je dois dire.

Haut
ven, 16/02/2007 - 13:48
K-lo

J'ai du la compiler !
Ouverture du projet VC++ (c'était un projet en faite avec le version 6 ou 7 et j'ai validé le faite de la porter avec la version 8 donc je me demande si justement l'unicode a été défini ou non)
Et apres j'ai fait les liaisons.

Bref je vais partir vers cette piste

Merci fredericmazue.

En parlant d'unicode j'ai un code de ce type :

wstring ws = L"infini => \u221E";
wcout<<ws;

m'affiche en sortie : "infini => "

J'ai fait de même via l'écriture de flux mais lorsque j'ouvre un fichier via un éditeur hexa je n'ai pas de trace des 16bits représentant le caractere infini et pourtant l'espion du debug de VC++ le traduit bien...
Es-ce encore du à la définition ou non de UNICODE qui me supprime les caractères unicode ?

Haut
sam, 17/02/2007 - 11:24
fredericmazue

Quote:
wstring ws = L"infini => \u221E";

ouha.. de l'unicode en dur... faut avoir le courage d'oser, bravo. :)

Seulement voilà, il y a des os...

Quote:
je n'ai pas de trace des 16bits représentant le caractere infini

Halte là, contraiement à une idée reçu, Unicode n'est pas toujours ne 16 bits, loin s'en faut.
D'un autre côté, l'unicode Windows est un unicode particulier, UTF-16. Là d'accord pour les 16 bits MAIS dans *le monde Windows*
Quand tu prends une wstring tu n'est pas dans le monde de Windows mais dans le monde du stardard C++ et là rien ne te dis que les caractères unicode sont traités pareil.
Ca peut être ok pour les 16 bits puisque le standard C++ ne prend pas en charge les unicode de longueur variable (il me semble je dis de mémoire, à vérifier) MAIS la traction des caractères va dépendre de la locale et comme tu ne dis pas avoir définie une locale, il y a à parier que la traduction ne se fasse pas comme tu l'attends.

C'est cool unicode ... :)

Haut
mar, 20/02/2007 - 11:02
K-lo

fredericmazue wrote:
Quote:
wstring ws = L"infini => \u221E";

ouha.. de l'unicode en dur... faut avoir le courage d'oser, bravo. :)

Huhu oui bon je l'avoue...

fredericmazue wrote:

Seulement voilà, il y a des os...

Halte là, contraiement à une idée reçu, Unicode n'est pas toujours ne 16 bits, loin s'en faut.
D'un autre côté, l'unicode Windows est un unicode particulier, UTF-16. Là d'accord pour les 16 bits MAIS dans *le monde Windows*
Quand tu prends une wstring tu n'est pas dans le monde de Windows mais dans le monde du stardard C++ et là rien ne te dis que les caractères unicode sont traités pareil.
Ca peut être ok pour les 16 bits puisque le standard C++ ne prend pas en charge les unicode de longueur variable (il me semble je dis de mémoire, à vérifier) MAIS la traction des caractères va dépendre de la locale et comme tu ne dis pas avoir définie une locale, il y a à parier que la traduction ne se fasse pas comme tu l'attends.

C'est cool unicode ... :)

En gros je dois utiliser la biblothèque locale 

local loc(""); 
loc.name();

Me retournant sous quelle locale standardisée je travail.

C'est donc un problèmed'internationnalisation ?
:D.

Autant pour moi.

Pour ce qui est du XML j'ai abandonner Xerces pour TinyXML étant donner la complexité du programme (simple parsage)

Haut
mar, 20/02/2007 - 11:17
fredericmazue

Quote:
C'est donc un problème d'internationnalisation ?

Internationalisation, le mot est peut être trop fort. Tout dépend que ce que tu veux faire. Tant que tu travailles une application en français seulement sous Windows tu as intérêt à faire au plus simple.
A ta place je me limiterais à travailler avec des chaînes std:string avec la locale par défaut (la locale "C" donc) et seulement au moment de les passer à des API Windows, un appel à MultiByteToWideChar. Et dans l'autre sens, un appel à WideCharToMultiByte avant de ranger dans une std::string.

Quote:
Pour ce qui est du XML j'ai abandonner Xerces pour TinyXML étant donner la complexité du programme

Oui je comprends ta décision :)

Au plaisir :)

Haut
Post reply