"Bad ptr" : impossible d'accéder à une donnée membre

Bonjour,
J'ai les classes suivantes :

Code:

---

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

struct Data { string name ; };   class Loader { public: Data obj[100] ; }   void main() { Loader * loader = new Loader(); loader->obj[0].name ; //Et bien cette ligne plante et me donne un "bad ptr" !! }

---

la variable "name" est initialisée correctement dans le constructeur de Loader,
mais à la ligne suivante c'est une donnée invalide et ça plante, savez vous pourquoi et comment puis je faire ?

PS : j'ai déjà essayé de remplacer le type string de "name" par char * ou vector <char> mais rien y fait...

Il ne faudrait pas mettre obj et name en public ?

Oui désolé mais je viens de corriger :
name est dans une struct (donc tout est public) et obj est en public et le problème a bien lieu dans ce cas de figure là.

Aux faits près que main doit retourner un int et un ; oublié, ce code est valide (pense néanmoins à libérer la mémoire avec delete, ou mieux, ne pas utiliser new).

Quel est le vrai code qui plante ?

Je vient de compiler ton code (avec Code::BLocks), je n'ai pas d'erreurs autres que :

- "string", tu a bien fait tous les includes et toutes les définitions nécessaires ? (#include <string>, using..)
- class Loader{...} ;
- int main(){ ... return 0;}

En faisant ces corrections, ça ne marche toujours pas ?

Tu utilise quel IDE/Compilateur ?

j'utilise visual studio 2008, ce qu'il me manquait dans ce que tu as mis c'était le include <string> (mais ça compilait quand même bizarrement) mais j'ai toujours le même problème.

Je n'ai pas mis tout le code car c'est un peu long. Et je suis d'accord pour dire que c'est bizarre...

Je viens de test avec VS2008, et bin ça marche :aie:

Essaye peut-être de créer un nouveau projet, et test le code minimal. Si ça marche, essaye d'importer tes fichiers dans ton nouveau projet...
Si ça ne marche pas après l'importation, c'est qu'il manque des choses dans ton code minimal...

Le problème est-il vraiment un crash à l'exécution ou alors simplement que tu n'arrives pas à voir la valeur de la variable en mode Debug?

Bonjour,
Si il y a juste une string dans ta structure la struct ne sert a rien.
Ensuite ton ptr sur ton loader ce n'est pas nécessaire les références c'est plus cool ensuite ton tableau en dur est peut être le problème (pb de porter)
Tu peut utiliser la class vector pour sa qui appartient a la lib stl et est donc portable.
Et comme tu est dans le main avec des références tu n'auras pas de pb de porter

Ça me rappelle: Est-ce qu'une std::string peut être NULL?
Ou bien contient-elle toujours quelque chose, au minimum une chaîne vide?

Essaie donc d'initialiser ou d'affecter un std::string à « NULL », tu vas t'amuser… :P
Contrairement à un char*, un std::string doit toujours être valide.
Donc au minimum, ça contient le caractère nul.

Pour information, Qt fait la différence entre les chaînes « vides » et les chaînes « nulles ».

Citation:

---

Envoyé par doc.qt.nokia.com

bool QString::isEmpty () const

Returns true if the string has no characters; otherwise returns false.

Example:

Code:

---

1 2 3 4

QString().isEmpty(); // returns true QString("").isEmpty(); // returns true QString("x").isEmpty(); // returns false QString("abc").isEmpty(); // returns false

---

bool QString::isNull () const

Returns true if this string is null; otherwise returns false.

Example:

Code:

---

1 2 3

QString().isNull(); // returns true QString("").isNull(); // returns false QString("abc").isNull(); // returns false

---

Qt makes a distinction between null strings and empty strings for historical reasons. For most applications, what matters is whether or not a string contains any data, and this can be determined using the isEmpty() function.

---

la string en elle même ne peut pas êtrtre NULL un pointer de string peu l’être ou une référence peut ne pas être initialiser

Citation:

---

Envoyé par jouana

la string en elle même ne peut pas êtrtre NULL un pointer de string peu l’être ou une référence peut ne pas être initialiser

---

Meh ? Tu veux dire que

Code:

---

std::string s;

---

oblige l'objet s à contenir quelque chose ?

La string elle même peut contenir n'importe quoi, y compris un (ou deux; ou trois) pointeurs NULL. L'interface de string, par contre, impose que les données auxquelles on accède depuis l'extérieur soient tout le temps valide (ni .data(), ni .c_str() ne peuvent renvoyer NULL. Mais comme ces fonctions renvoient des const char*, elles peuvent tout à fait renvoyer la chaine "" si les pointeurs internes de std::string sont à NULL) et contiguës en mémoire (ce qui est le cas pour la chaîne constante vide ""). De même, on ne peut pas créer une chaîne à partir de NULL (cette valeur est censée être checkée par les constructeurs prenant un const char* en paramètre; en cas de valeur NULL, le constructeur a de grandes chances de planter (mais comme la norme ne dit pas qu'il doit générer une exception, on va dire que c'est un comportement indéfini).

Et bon courage pour faire une référence non initialisée :) Selon le standard, une telle chose n'existe pas (comportement indéfini en cas de création ou d'utilisation).

On ne peut pas faire de référence invalide ou non-initialisée sans jouer avec les pointeurs.

Mais on peut initialiser une référence avec un pointeur non-initialisé.

Citation:

---

Envoyé par Emmanuel Deloget

Meh ? Tu veux dire que

Code:

---

std::string s;

---

oblige l'objet s à contenir quelque chose ?

---

Oui.
En tout cas pour g++.
Le pointeur interne n'est jamais NULL, et donc pointe toujours sur quelque chose.
Le constructeur par défaut le fait pointer sur des bits nuls, stockés statiquement par la classe.

Le problème ne peut pas venir de std::string quel que soit l'implémentation parceque le test présent est trop simple et le bug aurait été corrigé il y a des lustres.

Par contre, clairement il manque le reste du contexte. Donc soit on nous propose un exemple qui effectivement reproduit le problème (sachant que monter cet example peut permettre à celui qui pose la question de trouver la réponse en dépouillant son cas spécifique des "décorations"), soit on nous fournit tout le code qui reproduit le problème.

Soit on prends les paris. Je paris sur un buffer overrun.

Citation:

---

Envoyé par Médinoc

On ne peut pas faire de référence invalide ou non-initialisée sans jouer avec les pointeurs.

Mais on peut initialiser une référence avec un pointeur non-initialisé.

---

Ca veut pas dire que c'est une bonne idée :)

Le standard n'admet pas les références invalides. Toutes les références sont invalides, et s'il rencontre une référence invalide, le comportement du programme devient indéfini (donc hors du contexte de la norme). Bref, ce n'est plus du C++ :)

Citation:

---

Oui.
En tout cas pour g++.

---

Ce n'est qu'une implémentation parmi tant d'autres. Le standard se borne à donner l'interface de std::basic_string<> et d'expliciter certaines de ses obligations. Il n'impose pas une implémentation particulière.

(Pour info, c'est aussi le cas dans la version la plus récente de la librairie standard fournie avec VC++, et c'est du à SMO (small string optimization) qui fait que toute chaine de caractère de moins de X bytes n'est pas allouée mais pointe en fait sur un buffer de X bytes. Cette optimisation implique aussi que sizeof(std::string) >= X).