Convertion pointeur tableau de char EN string

Bonsoir,

la FAQ n'a pas la réponse à mon problème.
Il s'agirais de faire ceci :

Code:

---

1 2 3 4 5 6 7 8

// Init. string chaine; char* pc = new char[35];   flux.read(pc, 35); // Lecture de 35 octet d'un fichier chaine = string(*reinterpret_cast<string*>(pc)); // Conversion pc en string

---

Evidement ça ne marche pas... Mais l'idée est là. ça fonctionne pour des int, des double... mais pas pour des string.
J'ai pu voir sur un site :

Code:

---

1 2	chaine = string str(pc);

---

Fonctionne ? Merci pour vos réponses !

Bonsoir,

les constructeurs de la classe std::string sont clairs =>click<=

Code:

---

1 2 3

string (const char* s); string (const char* s, size_t n);

---

Pour la lecture dans un fichier, n'oublie pas d'utiliser le standard C++ (et pas C), si jamais ce n'est pas déjà ce que tu fais : click (ifstream)

Et utiliser reinterpret_cast est un dernier recours, que tu devrais utiliser très peu de fois dans ta vie de programmeur, à éviter absolument tant que c'est possible, car dangereux.

Le "const" n'est pas problématique? Car la fonction "read" accept un char* et non un const char*.
Concernant le "reinterpret_cast" je n'ai pas trouvé d'autre moyen pour traduire des octets en entier, double...

Non ce n'est pas problématique, cela veut juste dire que le pointeur n'est pas modifiable. Mais il y a moyen de faire de toute façon plus simple, sans manipuler des types primitifs comme le char*

Code:

---

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

#include <iostream> #include <fstream> #include <string>   using namespace std;   int main() { ifstream inputFileStream; inputFileStream.open("test.txt"); string name; getline(inputFileStream,name); cout << name;   return 0; }

---

Avec un fichier text.txt, contenant du texte, ceci fonctionne (attention pas testé, mais à mon avis cela manque de tests pour éviter tout plantage).

Par rapport au code initial, il y a aussi un autre problème, c’est que la chaîne n’est pas nécessairement terminée par un \0, donc il faut bien utiliser le constructeur qui prend un size_t.

Pour ce qui est du reinterpret_cast, c’est à éviter de manière générale. Convertir un tableau de char[4] en entier nécessite de savoir l’endianness qu’on utilise. Et si on est au sein d’un tableau plus grand (par exemle, à l’index 2 d’un tableau de 8) c’est pire car il y a potentiellement des problèmes d’alignement qui font que le reinterpret_cast va planter sur certaines architectures (et sur les autres, ce sera lent).

Citation:

---

Envoyé par radlabo94

Le "const" n'est pas problématique? Car la fonction "read" accept un char* et non un const char*.

---

Non, au contraire:

• Il est normal que la fonction read exige un char* et non un const char*, car elle MODIFIE le contenu pointé
• Une fonction qui prend un paramètre const acceptera parfaitement un paramètre de type non const, car le const signifie simplement qu'elle s'engage (vérifié par le compilateur) à ne pas modifier le contenu du paramètre
• La seule chose qui poserait problème ce serait de déclarer un const char* et le passer à read. Dans ce cas tu aurais une erreur de compilation, car on ne peut passer une référence constante à une fonction qui souhaite modifier se valeur

Citation:

---

Envoyé par radlabo94

Concernant le "reinterpret_cast" je n'ai pas trouvé d'autre moyen pour traduire des octets en entier, double...

---

Pour ajouter ma couche à la très juste réaction de white_tentacle, tu es à la merci du moindre détail d'implémentation qui peut différer entre le producteur et le consommateur du fichier, parce que le reinterpret_cast ordonne au compilateur "ferme les yeux et considére que les octets à partir de l'adresse pointée sont les données internes, privées, de la variable". Donc sauf si tu es sûr que les octets en question sont un dump brut de l'état interne d'une variable fait par le même runtime, ton code cesse d'être valide à cette ligne. Au mieux tu vas avoir une valeur aberrante dans ta nouvelle variable, mais tu peux même te retrouver à créer deux variables ou plus qui se chevauchent en mémoire avec des effets de bord incompréhensibles...bref...
On enfonce peut-être des portes ouvertes mais ta façon de remplacer l'appel au constructeur de string par un reinterpret_cast me fait plutôt penser qu tu ne maîtrise pas ces notions...