Un peu d'aide sur la class string

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