vector subscript out of range: qu'est-ce ?

Bonjour
voilà j'ai un problème et j'espère bien que vous pouviez m'aider.
le problème c'est que je développe une librairie qui lie des DTED(digital terrain elevation data ) et l'un de ses fonctions est la fonction findlist qui cherche dans un chemin donnée (_path) toutes les extention (.dt0) et les sauvegarde dans une liste(paths)
crée avec des vecteurs.comme vous voyer ci-dessous.

Code:

---

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

bool LoaderDTED0::findList(const boost::filesystem::path & _path, std::vector<boost::filesystem::path>& paths, int& nbLevel) { if ( !exists( _path )||(nbLevel<0) ) return false; directory_iterator end_itr; paths.resize(500); for ( directory_iterator itr(_path );(itr != end_itr);++itr ) { if ( is_directory(itr->status()) ) { nbLevel--; if ( findList( itr->path(), paths, nbLevel ) ) return true; }   else if ( extension(itr->leaf()) == ".dt0") { paths.push_back(itr->path()); } } return false; }

---

le problème c'est que tt se compile tres bien mais lors de l'exécution il m'affiche l'erreur suivante : "vector su bscript out of range".
je sais pas d'ou vient l'erreur je suis vraiment besoin de votre aide.merci d'avance de votre réponse

Bonjour et bienvenue sur developpez.com :)

Cette erreur est levée par la classe vector de la STL(*) lorsqu'on tente d'accéder à un élément du vecteur qui est en dehors de l'intervalle de ce dernier.

Par exemple:

Code:

---

1 2 3 4

std::vector<int> v(2); // crée un vecteur de 2 éléments v[0] = 1; //ok v[1] = 2; // ok v[3] = 3; // <-- plantage: vector subscript out of range

---

Hope it helps.

*: je ne suis pas certain que toutes les implémentations de la STL respèctent cela. Je ne suis pas non plus certain que ce soit précisé dans la norme.

Code:

---

directory_iterator end_itr;

---

ne semble pas initialisé avant le debut de la boucle.
C'est pourtant la condition d'arret.

Half HS :
Selon des souvenirs, c'est at qui lance une exception, pas operator[].

Edit: Je confirme

Citation:

---

23.1.1:12§: The member function at() provides bounds-checked access to container elements. at() throws out_of_range if n >= a.size().

---

@Luther13: bien vu!

@Davibrcz: Je ne trouve pas que tu sois HS du tout, bien au contraire, tu apporte une précision importante. Je crois d'ailleurs qu'il y a une raison importante qui explique pourquoi l'operateur [] ne lève pas d'exception, contrairement au at() . Peut-être une histoire de vitesse d'exécution?

Exactement, en théorie at est poil plus lente que operator[] car elle doit vérifier la pré-condition concernant n (n<v.size() et normalement n >=0 bien que cette dernière ne soit pas mentioné dans la norme).

Par contre, la vrai question est de savoir si cette contre performance a un réel coût ? J'avoue que je n'en sais, n'ayant jamais fait de bench.

Salut,

Citation:

---

Envoyé par Davidbrcz

Exactement, en théorie at est poil plus lente que operator[] car elle doit vérifier la pré-condition concernant n (n<v.size() et normalement n >=0 bien que cette dernière ne soit pas mentioné dans la norme).

Par contre, la vrai question est de savoir si cette contre performance a un réel coût ? J'avoue que je n'en sais, n'ayant jamais fait de bench.

---

Par définition, tout test a un cout, fusse-t-il de quelque cycles d'horloge, et même si le test en question revient à faire une égalité entre deux variables mises dans des registres.

Or, il n'y a rien à faire, étant donné le test de la pré condition, il faut s'attendre à ce que la méthode at() soit implémentée sous une forme proche de

Code:

---

1 2 3 4 5 6

T& Contener::at(size_t ind) { if(ind>=size()) //pourrait aussi utiliser un membre de la classe ;) */ throw out_of_range(); /* recherche de l'élément à renvoyer et renvoi de celui-ci */ }

---

La question à se poser n'est donc pas "cette méthode a-t-elle un cout", mais bien "le cout de cette méthode est il en rapport avec la sécurité qu'elle apporte :question:" ou encore "le cout de cette méthode n'est il pas, selon le contexte, prohibitif du point de vue des performances" (pour ceux qui tiennent absolument à chasser le moindre cycle d'horloge inutilement utilisé ;))

merci pour vos réponses mais jusqu'à maintenant je vois pas où est l'erreur,c'est le bout de code qui me génére l'erreur.merci de préciser

Citation:

---

Envoyé par Davidbrcz

Half HS :
Selon des souvenirs, c'est at qui lance une exception, pas operator[].

---

Quand on est en dehors du range, at lance une exception, d'accord sur ce point.
Quand on est en dehors du range avec [], c'est un comportement indéfini. Donc le compilateur a le droit de faire ce qu'il veut, y compris la chose intelligente qui consiste à lancer une exception. En pratique, les bons compilateur auront en mode non optimisé un comportement identique entre [] et at, et en mode optimisé le code le plus rapide pour [] et le plus sur pour at.

Pour info, Luther13, le code du tutorial de boost::filesystem utilise aussi un directory_iterator "non initialisé" car la constructeur par défaut de directory_iterator le met automatiquement à la fin du répertoire.
(La phrase exacte est "default construction yields past-the-end", mais je ne suis pas sur à 100% de ma traduction :oops:)

Edit: ton débbugeur te donne quoi comme erreur/info/... ?

merci pour tt les réponses mais je vois pas comment résoudre ce problème d 'erreur déclanché "vector subscript out of range".merci pour vos aide

Vu que tu n'accèdes pas aux éléments du vecteur paths ici, l'erreur doit être ailleurs que dans ce code.

Par contre, deux points me semblent louches dans ton code :

- Le paths.resize[500] : Il ne sert à rien (puisque tu fais des push_back), va créer des objets vides au début, et à chaque appel récursif tu va tronquer ta liste, supprimant les vrais données pour ne garder que les 500 vides crées.

- Le passage par référence du niveau

Code:

---

1 2 3 4 5 6 7

Vu que tu n'accèdes pas aux éléments du vecteur paths ici, l'erreur doit être ailleurs que dans ce code.   Par contre, deux points me semblent louches dans ton code :   - Le paths.resize[500] : Il ne sert à rien (puisque tu fais des push_back), va créer des objets vides au début, et à chaque appel récursif tu va tronquer ta liste, supprimant les vrais données pour ne garder que les 500 vides crées.   - Le passage par référence du niveau

---

pour paths.resize[500] on l'a pas utilisé au début mais on a essayé de l'utilsé pusique l'erreur générée est dû au taille du vecteur mais ça genere tjrs le mem probleme

pour le passage par référence parcque on voulias utilsé que des pointeurs pour réduire l'espace memoire.
sinon vous savez pas quelle déclaration pourra générer cette erreur

Attention, car en passant ton nbLevel par référence, il pourra être modifié par les fonctions appelées, notamment par

Code:

---

nbLevel--;

---

La valeur de nbLevel dans les fonctions appelantes sera également affecté par cette décrémentation.
D'autre part, la taille d'un int n'est pas si grosse que ça comparé à une adresse, tu peux donc à mon avis le passer par valeur sans t'inquiéter pour la mémoire. Si tu veux absolument le passer par référence, fais-le par référence constante :

Code:

---

void maFonction(const int & i)

---

N'as-tu pas un debuggeur qui te permettrait de savoir exactement où cette erreur est déclenchée ?

non merci j'ai trouvé où est le probleme c'est comme vs avez dit c'est en dehors de code.merci infiniment pour vos aide