determiner la dimention en kb d'un vector<string>

Salut
Comment efficasement determiner la taille en bit's d'un buffer de type
vector<string>

Quel est ton problème ? (->que veux-tu exactement faire ?)

(L'espace mémoire occupé par chaines, vecteurs et autres trucs standards varie d'une implémentation à l'autre, et qui plus est sont répartis entre tas (le buffer) et pile ou tas (les élements de la classe dont la taille est obtenue avec un sizeof)

un de nos nouvelle equipement genere de trop gros fichier pour la compatibiliter avec certain de nos sotware on ma demmender de tronquer ces fichier je me suis arranger avec l'inverce ingenerei pour l'entete des fichier maintenent je doit tronquer le contenue. Bien que je n'ait pas de besion d'une precission au bit pres j'en profite pour esseiller d'apronfondire mes connaissance dans ce dommaine

le principe est simple

je lit le fichier ligne par ligne puis place le contenue dans un buffer <<vector>>
si je dececte que je peut tronquer le fichier a la dernierre ligne lue
je compare la taille du buffer a une taille minimal;
si le buffer est plus grand que la taille minimal;
je cree un nouveau fichier et le peuple avec le contenue du buffer
je vide le buffer
je continue la lecture


ainsi
sizeof(vector)=le total des membre de vector //ici ca pas rapport

j'aurais crue que l'addition des
buffer+=vector[i].size()*sizeof(char)
pour un buffer de 3320960 bit's le fichier = 3,669 kb

ces pas encore ca, a moin que un fichier prene plus de place sur un disque que en memoire mais j'ai rien trouver pour le confirmer

merci

C'est pas très clair.
Juste quelques remarques:
sizeof(vector), c'était une façon de parler j'espère, car l'opérateur sizeof ne te renvoie pas la taille d'un tableau.
attention à ne pas utiliser la taille réelle sur disque mais la taille du fichier lui même. Si le fichier est compressé sa taille réelle sera plus petite, sinon elle sera plus grande car le système de fichier n'alloue pas de l'espace à l'octet près mais par petits morceaux entiers.

desoler pour sizeof<vector> j'ai pas pensser avant d'ecrire je ne voulait pas etre mesquin

en effait tu ma faits realiser que ta table d'allocation des fichier alloue(ces pas vraiment la table d'allocation qui aloue masi bon) l'espace disque pour les fichier par block (4 cluster il me semble) a moin que le disque n'ait ete doubler (sous windows);

ne en moin mes interogation demmeure

Code:

---

1 2 3 4 5 6 7 8

vector<string>m_vector; ... int buffersize=0; for(int i=0;i<m_vector.size() i++) { buffersize+=m_vector[i].size()*sizeof(char); }

---

ici est-ce que buffersize sera = a l'espace memoire utiliser
probablement pas ????
il devrait etre plus petit car il ne repersente que l'espace occupe par les caractere a l'interieur des string qui sont a l'interieur de mon tableau

donc quelle est l'espace accuper par mon vector ????

si j'ecrit un fichier avec ce buffer pourquoi est-ce que j'ai une difference de pres de 7% ?????

buffersize =3320960
filesize =3756876 bits

ces pas tres important et ces meme pas un probleme et ce ne m'empeche pas de rien comprendre

merci a tous;

je devrait peut etre ecrire un livre sur:: comment ne pas poser la question sur ce que l'on pas de besoin savoir !!!

A priori ton code de calcul de la taille occupée par les caractères des string est bon (sauf que l'occupation en RAM est supérieure : voir différence size() / capacity() dans la FAQ, + sur-coût de l'allocation dynamique + espace sur la pile etc...)
Ce qui peut expliquer cette différence c'est si t'es sous Windows et que c'est un fichier texte, a chaque saut de ligne la séquence \r\n est transformée en \n (donc en gros tous les carcatères \r sautent). Reste à compter dans un éditeur hexa combien tu as de \r pour savoir si c'est bien la différence constatée...

Ha oui je croie que tu mas donnee une bonne piste

etant donner que std::string ne retourne pas le caractere de fin de ligne
ca pourait expliquer pourquoi la taille de fichier est plus grande que mon buffer
ainsi (vertor[i].size+1)*sizeof(char) serait plus pret de la realiter

je ne veut pas me faire d'idee mais je croi que ca commence a rentere

Merci

L'ouverture en mode non binaire permet de traiter de façon transparente les divers sauts de lignes (\r\n, \n, \r). D'un système à l'autre cela peut changer. Sans compter les fichiers qui mélangent allègrement deux styles -- limite fréquent quand on commence à mélanger divers éditeurs de texte et/ou samba mal configurés j'ai l'impression.

Ce compte est-il vraiment important ?