convertir char* en r�f�rence sur string

Bonjour. Je cherche � convertir un char* en r�f�rence sur un string. En gros faire quelque chose comme �a...

Code:

---

1 2 3

char* c = "church"; string &s = c;

---

Mais le compilateur veux pas. Existe-t-il un autre moyen?

Le but de l'op�ration est le suivant:

• je re�ois une base de donn�es sous la forme d'un char*
• une entr�e correspond � une cl� de 16 charact�res plus 32 charact�res de donn�es.
• du coup la base est un char* vers des entr�es de 48 chars qui se suivent

J'ai un algo qui trie ma base sur la cl�. Sauf que j'ai �crit l'algo avec des cl�s qui sont des string...
Du coup, je veux cr�e des string � partir des cl�... Pour �tre plus pr�cis, je veux des r�f�rences vers des string.
La base va contenir un million d'entr�e du coup, je veux pas tout recopi�... Existe-t-il une solution pour mon probl�me?

Salut,

L�, tu essaye en fait de cr�er une r�f�rence sur une std::sting qui devrait faire r�f�rence � un pointeur sur char...

Or, une r�f�rence doit faire r�f�rence � un objet (du type ad�quat) existant, et un char* n'est pas un std::string :aie:

Par contre, tu peux cr�er une std::string (non r�f�rence :D) au d�part d'un char*, soit en utilisant l'une des surcharges du constructeur, soit en utilisant l'op�rateur = :

Code:

---

1 2 3

char * c="coucou"; std::string ok1(c); std::string ok2=c;

---

A partir de l�, rien ne t'emp�che de cr�er une r�f�rence sur ta std::string, si tu le souhaites:

Code:

---

1 2 3

std::string & ref1 =ok1; std::string & ref2 =ok2;

---

Ceci dit: lorsqu'il s'agit de d�clarer une variable en vue de l'utiliser dans la fonction, il ne sert pas � grand chose d'en cr�er une r�f�rence par la suite, pour la simple raison que l'on risque d'appliquer des modifications � la r�f�rence sans se rendre compte que l'on modifie en r�alit� la chaine originale (ou invers�ment), et que, la distraction aidant, on peut facilement en arriver � se demander pourquoi l'une a �t� modifi�e alors que l'on modifiait l'autre :aie:

Il est g�n�ralement "de bon ton" de r�server l'usage des r�f�rences (constantes ou non) au passage d'arguments, � quelques exceptions pr�s ;)

Hmmm. Merci pour la r�ponse mais je crois pas que �a ne r�soud pas mon probl�me. Le truc c'est que je vais recevoir un char* pointant sur plus de 48 000 000 de chars... Ca fait dans les 90mega...

Je dois trier tout �a. Grosso modo, la chaine comporte des entr�es les unes � la suite de l'autre, les 16 premiers chars sont une cl� pour le tri, les 32 une adresse web...

Mais j'ai �crit mon algo pour traiter les cl�s comme stock�es dans un
objet: std::vector <string> &s...
Du coup, j'ai pens� utiliser mon vector pour contenir des r�f�rences vers les strings qui sont contenu dans 1 grand char... j'espere que tu me suis...

Est-ce que c'est possible?
Mon autre alternative est de modifi� mon algo pour trier sur des char* au lieu de string mais bon....

Bonjour,


Si et seulement si tes cl�s sont immutables (pas de modification sur les cl�s) alors il existe une solution tr�s pratique qui consiste � cr�er une classe repr�sentant un wrapper extr�mement l�ger sur une chaine en m�moire (un char* + une taille) mais qui propose l'interface famili�re de std::string

Sauf qu'il n'y a pas besoin de le coder soit-m�me, vu que des gros projets C++ open-source l'ont d�j� fait :mrgreen: (mais bizarrement pas boost. Pourtant ce genre de classe extr�mement utile me semble pile-poil dans le scope de boost mais bon...)

Par exemple :

StringPiece du projet google Chrome :
http://code.google.com/p/re2/source/.../stringpiece.h

ou StringRef du projet LLVM :
http://llvm.org/svn/llvm-project/llv...DT/StringRef.h
http://llvm.org/svn/llvm-project/llv.../StringRef.cpp

Tr�s pratique car :
- License BSD
- Pas de d�pendance (pour StringRef il faut quand m�me virer deux trois fonctions qui induisent des d�pendances vers d'autres parties de LLVM)

Donc si tout se passe bien, dans ton cas, il devrait suffire de rajouter un constructeur StringPiece(char*, size_t) pour limiter aux 16 premiers char de la cl�, puis dans ton algo de tri faire un chercher/remplacer de std::string par StringPiece/StringRef, et �a devrait suffire.

Citation:

---

Envoy� par Arzar

puis dans ton algo de tri faire un chercher/remplacer de std::string par StringPiece/StringRef, et �a devrait suffire.

---

Voire de templatiser l'algorithme de tri pour qu'il marche avec des std::string, des StringPiece, des StringRef...

Citation:

---

Envoy� par JolyLoic

Voire de templatiser l'algorithme de tri pour qu'il marche avec des std::string, des StringPiece, des StringRef...

---

Voire m�me aller jusqu'� prendre une paire d'it�rateurs en param�tres (pour pouvoir prendre char *, std::string, des StringPiece, des StringRef ... :P).


Mais l'int�r�t de ces classes (StringPiece, StringRef) semble justement �tre d'encapsuler cette paire d'it�rateurs (en conservant la taille en plut�t qu'un iterateur "past to end") pour une utilisation plus intuitive.

Toutes ces solutions supposent n�anmoins d'avoir acc�s � la taille / fin de la cha�ne. Si tu ne la poss�des pas, cela peut aussi avoir un coup de la calculer.

Citation:

---

Envoy� par Arzar

Bonjour,


Si et seulement si tes cl�s sont immutables (pas de modification sur les cl�s) alors il existe une solution tr�s pratique qui consiste � cr�er une classe repr�sentant un wrapper extr�mement l�ger sur une chaine en m�moire (un char* + une taille) mais qui propose l'interface famili�re de std::string

Sauf qu'il n'y a pas besoin de le coder soit-m�me, vu que des gros projets C++ open-source l'ont d�j� fait :mrgreen: (mais bizarrement pas boost. Pourtant ce genre de classe extr�mement utile me semble pile-poil dans le scope de boost mais bon...)

Par exemple :

StringPiece du projet google Chrome :
http://code.google.com/p/re2/source/.../stringpiece.h

ou StringRef du projet LLVM :
http://llvm.org/svn/llvm-project/llv...DT/StringRef.h
http://llvm.org/svn/llvm-project/llv.../StringRef.cpp

Tr�s pratique car :
- License BSD
- Pas de d�pendance (pour StringRef il faut quand m�me virer deux trois fonctions qui induisent des d�pendances vers d'autres parties de LLVM)

Donc si tout se passe bien, dans ton cas, il devrait suffire de rajouter un constructeur StringPiece(char*, size_t) pour limiter aux 16 premiers char de la cl�, puis dans ton algo de tri faire un chercher/remplacer de std::string par StringPiece/StringRef, et �a devrait suffire.

---

Merci, je jette un coup d'oeil � tout �a et je vous tiens rapidement au courant. Par contre, je sais pas trop si je vais pouvoir me servir, mon prof est assez chiant l� dessus et il voulait qu'on utilise uniquement les librairies "classiques"... Le probl�me c'est qu'� la base, le devoir �tait pr�vu pour du C mais il a autoris� � ce qu'on utilise C++. Du coup, j'ai �crit mon algo en utilisant des strings... bref, je vais voir tout �a et au pire des cas, ben je changerai mes strings en char*...

Dans tous les cas, si j'utilise un wrapper, je vais quand m�me cr�er des objets en plus? Si je manipule les char* directement je prends moins de place non? Bien sur c'est plus gal�re � g�rer que les string mais bon...

Mon objectif avec les r�f�rences c'�tait de ne rien cr�er en plus....

Citation:

---

Envoy� par ncheboi

Mon objectif avec les r�f�rences c'�tait de ne rien cr�er en plus....

---

Si tu utilises un wrapper, que ce soint un std::string ou autre, tu auras effectivement de la cr�ation d'objets. On n'a rien sans rien en �change ! Par contre, cr�ation d'objet ne veut pas dire copie du stream de char. Un wrapper peut utiliser un pointeur sur une zone du tableau pour �viter la recopie comme tu le d�sires, ce qui limitera l'utilisation suppl�mentaire de m�moire. A priori, si tu en es d�j� � 90 Mo, tu n'es plus � quelques Mo pr�s non ?

Citation:

---

Envoy� par ncheboi

Dans tous les cas, si j'utilise un wrapper, je vais quand m�me cr�er des objets en plus?

---

En plus que si tu ne fais rien, oui.

Citation:

---

Envoy� par ncheboi

Si je manipule les char* directement je prends moins de place non?

---

Pas forc�ment. Si tu manipules des char*, tu cr�es aussi des objets, de type char*. Et il y a aussi des chances que tu cr�es des objets soit de type size_t, soit de type char* pour rep�rer la fin de la cha�ne.

L'id�e du wrapper est justement qu'il est compos� uniquement de ces deux informations, et ne prend pas plus de place que si tu faisais le boulot � la main.

Citation:

---

Envoy� par ncheboi

Si je manipule les char* directement je prends moins de place non? Bien sur c'est plus gal�re � g�rer que les string mais bon...

---

Peut �tre que j'ai mal compris le probl�me, mais a priori le code qui trie les cl�s devrait �tre tr�s proche que ce soit avec std::string ou char*, non ?
Avec StringPiece je suppose que �a ressemblerait � peu pr�s � �a :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

#include "StringPiece.h" #include <vector> #include <iostream> #include <algorithm>   char* data = "abcdef1234567890www.yahoo.fr 1234567890abcdefwww.google.fr "; int data_size = 64;   int main() { std::vector<StringPiece> keys; for(int i = 0 ; i < data_size ; i+= 48) { keys.push_back(StringPiece(data + i, 16)); } std::sort(keys.begin(), keys.end()); for(unsigned int i = 0 ; i < keys.size() ; i++) { StringPiece key = keys[i]; StringPiece url(key.end(), 32); std::cout << "key : " << key << "\n"; std::cout << "url : " << url << "\n"; } }

---

Dans ce cas on peut en effet gagner quelques m�gas en manipulant un std::vector<char*>. Il n'y a pas beaucoup de changement � faire, le plus gros �tant de passer � std::sort la fonction qui fait la comparaison des cl�s...

Ok. Merci pour l'exemple d'impl�mentation.
Sinon une question concernant les namespace. Je peux avoir

Code:

---

1 2 3

using namespace std; using namespace re2;

---

sans avoir de conflit?

Sinon, quand je tente de compil� il me dit qu'il y a un probl�me de symbole externe non r�solu.
J'ai vu que c'�tait du au fait que dans StringPiece.h, la red�finition de l'op�rateur << est:

Code:

---

1 2	extern std::ostream& operator<<(std::ostream& o, const re2::StringPiece& piece);

---

Que-faut il que je rajoute pour que �a fonctionne?
Merci encore

Bonjour,
Je pense que le mieux soit que tu utilises uniquement des char* si c'est pour un devoir un C avec C++ tol�r� mais limit� � la biblio standard.
Avec le bout de code montr� plus haut les changements sont minimes. Il suffit de :
- Remplir un std::vector de char* avec des pointeurs se d�calant de 48 octets en 48.
- Passer � la fonction std::sort une fonction binaire de comparaison (un pr�dicat voir la faq) qui prend en param�tre deux char* et renvoie un bool�en si une cl� est inf�rieure � une autre. (voir la fonction de la biblio C "memcmp").

Car j'imagine que le but de l�exercice est de manipuler des pointeurs quand m�me. Donc au boulot :mrgreen:

Citation:

---

Envoy� par Arzar

Bonjour,
- Passer � la fonction std::sort une fonction binaire de comparaison (un pr�dicat voir la faq) qui prend en param�tre deux char* et renvoie un bool�en si une cl� est inf�rieure � une autre. (voir la fonction de la biblio C "memcmp").

Car j'imagine que le but de l�exercice est de manipuler des pointeurs quand m�me. Donc au boulot :mrgreen:

---

Non non le but c'est pas de manipuler les pointeurs. Au fait, je dois impl�menter le tri radix en parall�le avec OpenMP:?... Le truc c'est que je suis parti sur des vector de string alors que je re�ois un char* en param�tre...
L'algo marche bien (apr�s plusieurs journ�es de reflexion, d�bogage(merci VS), et pertes de cheveux)... La je dois juste prendre le char*, le d�couper et remplir un vector sur lequel je fais mon tri... Du coup la class StringPiece est bien utile ;). Par contre, toujours pas possible de g�rer mon probl�me avec

Code:

---

1 2	extern std::ostream& operator<<(std::ostream& o, const re2::StringPiece& piece);

---

Citation:

---

Au fait, je dois impl�menter le tri radix en parall�le avec OpenMP...

---

Chouette exo !

Citation:

---

Par contre, toujours pas possible de g�rer mon probl�me avec :

Code:

---

extern std::ostream& operator<<(std::ostream& o, const re2::StringPiece& piece);

---

---

et bien en fait, je ne savais m�me pas qu'on pouvait d�clarer une fonction extern :mrgreen: (une variable oui, mais une fonction !?) Je ne comprends pas trop l'utilit� d'ailleurs, qu'en pense les autres participants ?

Bon sinon le but de cette fonction est simplement de pouvoir afficher une StringPiece gr�ce � un flux (voir faq)
Remplace par une fonction classique �a devrait suffire :
Dans le .h

Code:

---

std::ostream& operator<<(std::ostream& o, const re2::StringPiece& piece);

---

Et dans un .cpp

Code:

---

1 2 3 4 5

std::ostream& operator<<(std::ostream& o, const re2::StringPiece& piece) { o << piece.as_string(); return o; }

---

Bon finalement je me suis rendu compte que partir avec un vector de char* changeait pas beaucoup � mon algo...

Par contre, un nouveau probl�me...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

void pRadix_sort2(char *database) { vector <char*> keys; int db_length = strlen(database); //after his for loop, the keys vector will contain pointers to the beginning of each key for(int i = 0 ; i < db_length ; i+=48) { keys.push_back(database + i); }   //we sort the keys array starting from the end of the keys for(int i = KEY_LENGTH - 1; i >=0 ; i--) pCounting_sort2(keys,i);   /* for(std::vector<char*>::iterator i = keys.begin(); i != keys.end(); ++i) { database }*/ }

---

J'ai donc pris mon char* en entr�e, cr�er un vector <char*> contenant les pointeurs vers le d�but de chaque cl�... Apr�s le tri, je me retrouve avec un vector <char*> contenant les pointeurs vers les cl� dans l'ordre tri�.
Maintenant je dois reconstruire mon char* dans l'ordre.
Grosso modo, il s'agit de parcourir mon tableau et de faire un truc du genre:

Code:

---

1 2 3 4 5

//pseudocode char* sortedDB = null; for i= keys.begin to keys.end sortedDB += (48 chars starting from keys[i])

---

J'ai vu que la fonction strcat() pouvait m'aider � concat�ner des char* mais j'ai besoin qu'elle concat�ne juste un bout... Si je fait
strcat(sortedDB,keys[i]);
il rajoute la chaine situ� apr�s la cl�, si c'est la premi�re cl�, il rajoutera toute la database et non pas les 48 premiers char....

Citation:

---

Envoy� par Arzar

(mais bizarrement pas boost. Pourtant ce genre de classe extr�mement utile me semble pile-poil dans le scope de boost mais bon...)

---

Si, si, �a existe, ce sont les iterator_range qui font bien plus que les strings. Aucun int�r�t d'avoir plus que ces b�tes-l� ;)

Citation:

---

il rajoute la chaine situ� apr�s la cl�, si c'est la premi�re cl�, il rajoutera toute la database et non pas les 48 premiers char....

---

strncat ?

Citation:

---

Envoy� par Matthieu Brucher

strncat ?

---

Nikel. Voila ce que j'ai fait:

Code:

---

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

char* temp_db = (char*)malloc(sizeof(database)); *temp_db = '\0'; //initialiser à chaine vide, si je fais pas ça, la chaine contient des trucs bizarre avant cout << "length: " << strlen(temp_db) << endl; cout << "size of keys: " << keys.size() << endl; for(std::vector<char*>::iterator pKey = keys.begin(); pKey != keys.end(); ++pKey) { strncat(temp_db, *pKey, 48); } database = strdup(temp_db); cout << "after sort: " << endl << temp_db << endl; cout << "size of temp_db" << strlen(temp_db) << endl; free(temp_db);

---

J'execute en pas � pas sous VS et je vois que �a m'a mit les entr�es dans l'ordre voulu. Par contre, quand j'arrive � la fin de la fonction, VS me lance une belle erreur:

Windows a d�clench� un point d'arret dans abc.exe.
Cela peut etre due � une d�faillance du tas qui indique un bogue dans abc.exe ou l'une des DLL charg�es.
Cela peut �galement �tre du � l'appui sur F12...

Bref, un truc qui me dit pas grand chose sur d'o� vient l'erreur...
Si j'execute sans d�bogage (Ctrl+F5 sous VS), j'ai une autre erreur(en anglais cette fois):
HEAP CORRUPTION DETECTED: after Normal block (#356) at 0x002B78B8.
CRT detected that application wrote to memory after end of heap buffer.

Bon du coup, je me doute que j'ai un probl�me avec la m�moire... Le truc c'est que je sais pas lequel...
La fonction strncat �crit les charact�res voulus, plus '\0' (selon la doc)... Du coup, est-ce que c'est pas li� � �a? C'est bizarre parce que juste avant de faire le free j'arrive � imprimer database avec un

Code:

---

1 2	cout << database << endl;

---

bon en r�visant un peu l'allocation dynamique, j'ai vu qu'en c++, on devait plutot utilis� new et delete...
bref, mon probl�me est donc r�solue:

Code:

---

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

char* temp_db = new char; *temp_db = '\0'; cout << "length: " << strlen(temp_db) << endl; cout << "size of keys: " << keys.size() << endl;   for(std::vector<char*>::iterator pKey = keys.begin(); pKey != keys.end(); ++pKey) { strncat(temp_db, *pKey, 48); } database = strdup(temp_db); cout << "after sort: " << endl << database << endl; cout << "size of temp_db: " << strlen(temp_db) << endl; //delete temp_db; <- plante si je décommente ça...

---

par contre, quand je veux faire delete � la fin( ligne en commentaire), il me relance l'erreur de HEAP MEMORY etc...

Bonjour,

Je ne suis pas s�r (je n'utilise jamais de char*), mais qu'est-ce que �a donne si tu fais:

Code:

---

delete [] temp_db;

---