Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
problème de tableau
je suis en train de réaliser un programme qui nécessite une très grande quantité de données extraites à partir d'un fichier et que je dois traiter. pour cela j'ai déclaré un tableau de string [1000] mais je ne peux pas dépasser cette limite de taille. Y'a-t-il un moyen qui me permet de dépasser cette limite car à chaque fois que j'essaie d'agrandir la taille du tableau le programme cesse de fonctionner et si je garde cette limite le programme retourne de faux résultats??
Tu peux utiliser un std::vector<string> et sa méthode push_back.
http://www.cplusplus.com/reference/v...tor/push_back/
Bonjour,
Ne pas oublier d'appeler std::reserve quand on veut insérer plusieurs éléments.Envoyé par Ehonn
Oui mais je voulais pas "complexifier" le truc maintenant.
En pus std::reserve ne permet d'«insérer» plusieurs éléments (:o) c'est mal dit. std::reserve permet de "réserver" l'espace afin que le push_back ne fasse pas de réallocation.
Il ne connaît pas la taille ici (sinon, le tableau aurait suffit (selon la taille de la pile) / on aurait donner la taille à std::vector) (il faudrait parcourir deux fois le fichier). Laissons std::vector avoir un comportement "pas trop débile" lorsqu'il fait les réallocations.
Pourtant je trouve ma phrase assez claire :
"ne pas oublier d'appeler" => ne sous-entends pas de remplacer l'appel de push_back mais de rajouter un appel.
"quand on veut" pas "pour" => on ne l'utilise pas dans un but d'insérer plusieurs éléments (donc ne remplace pas push_back) mais lorsqu'on le fait, sous-entends donc à côté des opérations d'insertions d'éléments.
Après, la doc est là pour donner tous les renseignements nécessaire, je donne un nom de méthode, mais après c'est à lui d'aller faire le minimum de recherche par la suite (surtout que ce n'est pas dur à trouver).
Sinon, il y a aussi std::resize qui peut être intéressant.
Je voulais juste dire que tu aurais pu être plus explicite
Lorsqu'on lit un fichier, c'est pas évidement d'estimer la taille (sauf s'il y a des informations de ce genre dans le fichier).
Dans le cas général (enregistrement des lignes) le push_back reste le plus simple et utiliser reserve ou resize est une optimisation prématurée (sauf si on a ce genre d'information dans le fichier).
En revanche(edit) Dans le même style un shrink_to_fit (en C++11, ou un code équivalent pour la norme d'avant) à la fin des push_back peut être intéressant si on veut dupliquer plusieurs fois le vector résultat (il me semble que la copie d'un vector garde la capacité, à vérifier).
Si tu connais la taille maximum d'une ligne, ou que tu es en mesure de l'estimer, tu calcules la taille du fichier avec un "tell", puis tu réserves la taille du tell/longueur de ligne.
Ça devrait être pas si pire..., non ?
Dans mon exemple "cas général" la taille du std::vector correspond aux nombres de lignes (pas la longueur, getline de #include <string> le fait pour toi).Si tu connais la taille maximum d'une ligne, ou que tu es en mesure de l'estimer, tu calcules la taille du fichier avec un "tell", puis tu réserves la taille du tell/longueur de ligne.
Ça devrait être pas si pire...
Oui on pourrait essayer d'estimer la taille / le nombre de lignes du fichier. Je me répète, je n'ai rien contre mais c'est une «optimisation prématurée» pour moi.
Pour moi, c'est tout le contraire, c'est l'un des réflexes qu'un bon programmeur doit avoir.
Dès qu'on sait qu'on va insérer plusieurs éléments, on utilise un reserve ou un resize.
Après on a plusieurs possibilités :
- On connait la taille finale -> aucun problème
- On ne connait pas la taille finale
---> on sait qu'on insère X éléments à la fois -> on reserve un Y*X éléments supplémentaires.
---> on connait une taille moyenne, minimale ou maximale -> on s'en sert pour choisir une valeur de réservation arbitraire et on réalloue Y éléments quand on a plus de places.
---> on ne sait juste qu'on a plusieurs éléments -> on choisit une valeur arbitraire et on réalloue Y éléments si on a plus de places.
Après, mieux vaut réserver plus de places que nécessaire (mais pas trop quand même) puis redimensionner une fois qu'on a la taille finale que de faire des series de push_back sans reserve
C'est comme essayer de passer tous les arguments par copies (surtout quand ce sont de très gros objets) au lieu d'utiliser des références constates, des pointeurs ou autre. C'est une optimisation, certes, mais en aucun cas prématuré.
C'est comme charger un fichier dans un buffer (sans traitement spécifique), on ne va pas s'amuser à redimensionner le buffer de 1 octet à chaque lecture d'octet, c'est vraiment sale
Petite précision tout de même.
Vector ne réalloue pas avec un incrément d'un élément à chaque push_back.
Sa taille augmente d'environ la moitiée (valeur jugée "optimale")
donc, si le vector est de capacité 10 par défaut, ses capacités successives sont 10, 15, 22, 33, 48, 72 etc.
donc, sur 72 push_back, tu auras seulement 1 allocation + 5 réallocations.
réserve permet d'économiser tout de suite les 4 premières réallocations, le constructeur peut, lui, aider à supprimer la dernière (en fait, la première...)
Cela va aussi dépendre de l'OS (il reserve toujours un peu plus de mémoire que nécessaire), d'ailleurs es-tu sûr qu'il augmente sa taille de 150% à chaque fois ? Si l'OS peut "étendre" l'espace mémoire réservé au std::vector afin qu'il ai suffisement d'espace pour les éléments demandés (et donc pas la peine de refaire les copie), est-ce que le vecteur va vraiment faire augmenter sa taille de 150% qui dans ce cas là pourrait nécessiter une réallocation complète ?
ie : si on a un vecteur plein et on veut insérer un élément, si l'OS lui dit qu'il a un peu de place "préreservé" après la zone mémoire réservée au vecteur, est-ce que le vecteur va vraiment demander à réserver 150% de sa taille ou va-t-il simplement prendre le petit bout donné par l'OS ?
Sinon un appel à reserve ne coûte rien (ou presque), et sur de gros tableaux, la copie des données à effectuer après une nouvelle allocation peut être très coûteux.
Si réserve provoque une réallocation, les données sont copiées, sauf si justement l'OS avait de la marge suffisante.
Théoriquement parlant, les implémentations de push_back() ressemble à
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Après, la question c'est de savoir ce que fait le reserve derrière^^
Mais je suppose que faire un reserve d'un élément en plus, permettrait de demander à l'OS un seul élément si on a pas besoin de réallocation sinon demande à l'OS une réallocation avec une augmentation de 150% (ce n'est qu'un exemple) de la mémoire.
Tandis que le push_back fera qu'on demandera directement l'augmentation de 150% de la taille ?
Donc si on ne veut qu'augmenter la taille de 4 éléments, on peut, peut être, éviter une réallocation en utilisant reserve qui ne demandera que 4 éléments à la place d'utiliser push_back qui risque de provoquer une nouvelle allocation ainsi qu'une copie de données ?
Ce facteur de 1.5 dépend de l'implémentation, il me semble.
Oui, c'est juste la valeur classique.
J'avais trouvé toute une explication sur le pourquoi du comment, mais ca n'est pas la discussion.
reserve() devient dès que l'on dépasse la vingtaine d'éléments sans avoir spécifié la capacité du vector à la construction.
Répondre avec citation
Partager