Un peu d'aide sur la class string

Bonjour

J'aimerais avoir quelques précisions sur la classe std::string de C++. En fait j'utilise une macro qui retourne une string. Pour récupérer la string dans une variable j'ecris std::string *str = new string(MACRO(parametres)) en utilisant le constructeur par copie. Quand j'ecris simplement std::string = MACRO(parametres) j'ai une violation mémoire (fichiers dbgheap.c et dbgdel.c pour ceux qui ont deja vu ca). Malheureusement je sais pas comment est ecrite la fonction MACRO. Si vous avez une idée de pourquoi la deuxieme solution marche pas?
Autre chose j'aimerais pouvoir reattribuer ma variable str. J'ai tenté
str = &(MACRO(nouveaux parametres)) mais ca plante aussi (mais pas tout le temps :s). Je suis assez nul en C++ comme vous vous en doutez en lisant ces lignes alors ne me moquez pas trop vite, merci ;)

un petit mot avant d'aller en pause :mouarf:
pose des bouts de code avec les balises...c'est plus facile a lire car ton post est assez condensé et ca donne pas envie de lire :king:

MACRO te renvoie une std::string ou un char*?

Bon je reformate un peu mon message. Donc je souhaite récupérer une instance de std::string via une marco qui retourne une string (et pas un char* pour repondre au message précédent). J'écris:

Code:

---

std::string *str = new string(MACRO(parametres))

---

en utilisant le constructeur par copie. Ca ca marche. En revanche, si j'écris

Code:

---

std::string = MACRO(parametres)

---

ca plante, une alloc qui a pas été faite je présume mais en principe l'alloc a lieu dans la fonction MACRO. Peut-etre dois je déclarer ma variable comme étant une référence sur le retour de la fonction?
J'aimerais également pouvoir reattribuer ma variable str. J'ai testé

Code:

---

str = &(MACRO(nouveaux parametres))

---

mais ca plante aussi (mais pas tout le temps :s). Voila si vous avez qq idées et précisions à me fournir sur le fonctionnement précis de la classe String (je préfère la classe String de java ;)).

ta MACRO elle renvoie un std::string, pas un std::string* ?

alors:

Code:

---

1 2	std::string str = MACRO( param );

---

ça ça ne marche pas?

les string C++ ne sont pas compliqués. Ce qui est compliqué c'est que tu utilises une MACRO qui a l'air bien pourrie et que tu te mélanges les pinceaux avec les pointeurs ( alors qu'en C++ ils ne sont pas fait pour être utilisés tout le temps ).

la classe string s'utilise très bien comme ça:

Code:

---

1 2 3 4 5 6

std::string str = "toto"; std::string str2 = str; std::string str3 = str + str2;   std::cout << str3 << std::endl;

---

quand j'ai ecrit

Code:

---

std::string = MACRO(parametres)

---

il fallait bien sur lire

Code:

---

std::string str = MACRO(parametres)

---

c'est ce que j'avais d'abord écris dans mon code mais comme ca plantait je me suis résolu a faire une allocation dynamique qui elle a fonctionné. Ouai la macro doit etre bien pourrie et elle retourne bien un string pas un string* (d'ou l'emploi du constructeur par copie pour l'alloc dynamique). Mais jcomprends toujours pas pourquoi la première déclaration sans passer par un pointeur marche pas. Et pour réattribuer ma string je suis obligé d'écrire à chaque fois

Code:

---

str = new string(MACRO(nouveaux parametres))

---

ce qui est bien laid je trouve. Je précise que tt ça s'exécute au sein d'une JNI ca joue peut-être un rôle.. Enfin pour l'instant je comprends pas bien.

t'as aucun moyen d'avoir le code de ta MACRO?

elle est dans une dll. Et c'est pas le premier truc chelou que j'ai avec cette dll d'ailleurs. J'my connais pas très bien en programmation mais plein de trucs ont l'air bizarrement écrit dedans. Bon ben jcrois que jvais rester avec ma solution pourrie à base de pointeurs. Comme quoi du code sale engendre du code sale...

pour tes remarques

Une macro ne peut pas être dans une DLL, puisqu'elle est résolue par le préprocesseur et non le compilateur ni l'éditeur de liens.
Tu devrais donc trouver la macro en question dans le fichier d'en-tête associé à la DLL...

je pense que tu dois avoir moyen de retrouver ce code, ton compilateur y arrive.
( demande lui? )

Difficile à deviner ce qu'il se passe exactement sans avoir le code de la macro.
Mais je suppute l'existence de structure conditionnelle (if) dans cette macro, ce qui peut entrainer des comportements indéfinis.

Un exemple de ce qui peut arriver:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

struct Param{ Param(/*parametres constructeur*/){/* constructeur */}; bool constructStrings(){ /* fonction qui va construire les strings str1 et str2 */ }; string str1, str2;};   #define MACRO ( Param params ) ( ( params.ConstructStrings() ) ? params.str1 : params.str2 ; )   // plus tard dans le code: string str = MACRO( Param(/*parametres du constructeur*/) );   // regardons ce qu'il se passe: le #define remplace le code, on aura donc: string str = ( Param(/*parametres du constructeur*/).ConstructStrings() ) ? Param(/*parametres du constructeur*/).str1 : Param(/*parametres du constructeur*/).str2;

---

Dans cet exemple, ça ne plantera pas à l'execution, mais on n'obtiendra pas le résultat escompté.

Mais je le répète, sans connaitre le contenu de la MACRO, il me parait impossible de comprendre ce qu'il se passe.

Dans la librairie je dispose d'une autre macro pour récupérer une string: AsString comme son nom l'indique. Cette fois la déclaration statique fonctionne:

Code:

---

std::string str = AsString(parametre); //OK

---

Mais quand je veux vérifier ce que contient str:

Code:

---

cout << "affichage de str: " << str->c_str() << endl;

---

n'affiche que "affichage de str: " :s, alors que je sais tres bien ce que str est censé contenir (pas une chaine vide comme ca semble etre le cas). D'ailleurs avec l'autre macro et l'alloc dynamique jaffiche bien qq chose...
Je crois que jvais écrire un mail au programmeur de la librairie pour récupérer le code. Jcomprends riennnnnnnn

Réfléchis un peu aussi avant de poser des questions... tu déclare un objet et tu l'utilises comme un pointeur :?

j'ai bien ecris [CODE]cout << "affichage: "<< str2.data() << endl;/CODE] dans mon code. J'aurais eu un problème à la compilation sinon. Je suis nul mais pas à ce point la quand même. Je confirme ce que j'ai dit avant donc..

je n'avais pas vu ta remarque. En fait aprés vérification c'est pas une macro au sens C/C++ mais au sens général du terme donc ce n'est en fait qu'une fonction dont j'ai uniquement le prototype dans le .h

Bon, je sais, il semble qu'on se répète, mais peut-on voir le code de MACRO stp ? Sans cette information, il est impossible de savoir ce qui se passe.

Pour ma part, je penche pour un problème de modèle de mémoire. Le standard C++ ne définit pas d'ABI (abstract binary interface). De fait, les compilateurs sont libres de gérer la mémoire comme ils le souhaite dans les différents modules. Si une DLL utilise un modèle de mémoire différent du programme appelant, alors il est impossible de garantir le fonctionnement d'un programme qui va détruire ce qui aura été créé par la DLL.

Ce qui pose problème pour les templates, car dans la plupart des cas le code du template est directement inséré là ou il est utilisé (il est "inliné"). De fait, si ta MACRO est (contrairement à son nom) une fonction qui crée une std::string, il ne faut pas que cette chaine soit détruite dans le programme appelant, car le destructeur sera directement inséré dans le code de l'appelant (et non pas dans la DLL). Si il y a ne serait-ce qu'une petite différence dans le modèle de mémoire, la pile ou le tas risquent fortement d'être corrompu.

Cependant, tout ceci ne reste que pure spéculation: tant que nous ne savons pas exactement ce que fait MACRO (c'est à dire tant que nous ne voyons pas son code), il nous est impossible de trouver une solution à ton problème.

Donc cherche dans les .h et livre nous les informations nécessaires - tu verras, nous allons être un brin plus efficace après ça :)

Salut,

Il ne faut pas passer de std::string en entrée ou en sortie d'une DLL, c'est au mieux très dangereux et au pire ça fait n'importe quoi (un peu comme là quoi 8-))...
Cf. C++, the real world, and link and binary compatibility.

MAT.

qui commencent à m'éclairer un peu. Si je peux pas passer std::string en sortie d'une fonction d'une DLL comment puis-je récupérer l'objet renvoyé par cette fonction? Jvais voir si jtrouve une réponse dans le lien que tu as donné. Le code de la fonction je l'ai pas pour l'instant malheureusement

Citation:

---

Envoyé par KindPlayer

Le code de la fonction je l'ai pas pour l'instant malheureusement

---

Tu dois avoir au moins la signature de cette fonction, dans un des .h fourni avec la DLL, elle ressemble à quoi ?

MAT.

Code:

---

IASAPI_API std::string _HB(CBlob const & blob);

---

jsais pas si ca va beaucoup t'éclairer. CBlob est une classe qui sert de wrapper pour un buffer binaire. Dailleurs _HB a deux signatures différentes puisqu'elle permet de passer de CBlob à string et inversement:

Code:

---

IASAPI_API CBlob _HB(std::string hex);

---

Salut,

La question va peut-être te paraître stupide (mais je m'en fout: si le ridicule tuais, je serais mort depuis longtemps :D ), mais, si j'ai bien compris, le but de cette fonction est... d'obtenir sous forme de chaines utilisant la notation hexadécimale, les valeurs d'un buffer et inversément :question:

Dés lors, ne pourrais tu, tout simplement, pas obtenir un résultat similaire sans passer par la fonction de la DLL :question:

Je me rend bien compte que cela relativise l'intérêt de la DLL, étant donné que cela signifie réinventer la roue pour quelque chose d'existant (et de théoriquement testé), mais cela te permettrait de contourner le problème d'ABI différentes ;)

en fait j'utilise massivement une fonction de l'API qui prend en parametre, entre autres, une référence à un CBlob et je veux récupérer la chaine hexa correspondant à ce CBlob. Me passer de la classe définie dans l'API m'obligerait à me passer de la seule fonction de l'API que j'utilise réellement.

A vrai dire, je te proposais de te passer de la fonction, et non de la classe... Quoi que, le problème est bel et bien similaire: idéalement, CBlob étant - sauf avis contraire - une classe avec tout ce qui en découle, la DLL ne devrait pas renvoyer d'élément de ce type vers l'application qui l'utilise (cf tous les messages précédents)...

Mais ceci dit, j'ai personnellement la conviction (même si cela n'engage que moi) qu'il vaut parfois mieux "réinventer la roue" (dans ton cas, il s'agirait de recréer une classe CBlob et les différentes fonctions que tu utilise) que de persister à vouloir utiliser quelque chose d'existant dont il apparaît à l'usage que ce n'est pas adapté du fait des restrictions que cela impose...

En effet, ce que tu écrivais plus haut est tout à fait juste: un code de départ "crade" impliquera une manière "crade" de coder ce qui en dépend.

Dans cette optique, et parce qu'un bon ouvrier utilise normalement de bons outils, la meilleur décision à prendre - pour difficile qu'elle puisse paraître - me semble être de virer les "mauvais" outils ;):D

Simplement si je réécris une classe CBlob à ma façon (c'est pas dit que ce soit moins crade :) ), il faudrait également que je réécrive par exemple cette fonction

Code:

---

1 2 3 4

void sendAPDU ( unsigned char cla, unsigned char ins, unsigned char p1, unsigned char p2, CBlob const & data, unsigned long le, CBlob &response, unsigned short &sw12);

---

qui envoie des commandes à une smartcard. Je n'ai pas les compétences pour écrire ca. Et d'une manière générale la quasi totalité des objets de l'API utilise CBlob qui en est presque une brique de base. Donc de ce coté la je suis coincé. Merci quand même pour tes recommandations, j'aurais quand même appris des choses aujourd'hui c déjà ça.

Tu parlais de la fonction et pas de la classe :$. Ben peut-être que c'est possible jvais regarder mais je ne sais pas comment est représenté le buffer au sein de cette classe, c'est assez opaque et je risque de générer plus de bugs que d'en résoudre :(

Citation:

---

Envoyé par KindPlayer

Simplement si je réécris une classe CBlob à ma façon (c'est pas dit que ce soit moins crade :) ), il faudrait également que je réécrive par exemple cette fonction

Code:

---

1 2 3 4

void sendAPDU ( unsigned char cla, unsigned char ins, unsigned char p1, unsigned char p2, CBlob const & data, unsigned long le, CBlob &response, unsigned short &sw12);

---

qui envoie des commandes à une smartcard. Je n'ai pas les compétences pour écrire ca. Et d'une manière générale la quasi totalité des objets de l'API utilise CBlob qui en est presque une brique de base. Donc de ce coté la je suis coincé. Merci quand même pour tes recommandations, j'aurais quand même appris des choses aujourd'hui c déjà ça.

---

Pas très compliqué - l'API smart card de Windows est relativement simple.

Bon, d'ou elle vient cette DLL ? a la voir comme ça, il s'agit de quelque chose qui a été développé en interne. N'y a t-il pas moyen d'éviter l'utilisation de _HB, ou de redéfinir cette fonction ?

Ceci dit, L'interface de CBlob ne doit pas être très compliquée. Un petit:

Code:

---

1 2 3 4 5 6 7 8 9

std::string to_hex(const CBlob& blob) { std::stringstream ss; for (std::size_t i=0; i<blob.length(); ++i) { ss << std::hex << std::setw(2) << std::setfill('0') << blob.get_byte(i); } return ss.str(); }

---

Je pré-suppose l'existence d'une fonction qui donne la taille du blob (CBlob::length() dans mon exemple) ainsi qu'un moyen pour récupérer le ième byte du blob (CBlob::get_byte(std::size_t) dans mon exemple). Mais de toute façon, il faut bien que CBlob ait une interface permettant de récupérer les informations coté client, non ?

(Note: les identifiants dont le nom commence par un _ et une majuscule sont reservés par le standard C++ pour l'implémentation. Il n'est pas garanti qu'il n'existe pas un identifiant _HB défini par ton compilateur pour une raison quelconque. Raison de plus pour demander des modifications de la librairie).

En effet la classe CBlob dispose d'une méthode size() ainsi que d'une surcharge de [] permettant d'accéder au ième byte. En revanche pas de méthode du type data() permettant de récupérer la chaine hexa. Mais en m'inspirant de ton exemple jpeux essayer de bricoler un truc qui remplace _HB
Merci