A propos de std::streambuf

Bonsoir,

j'ai un probl�me avec l'utilisation de std::streambuf. Apparemment, il travaille avec des char*, mais visiblement, j'ai du mal � g�rer la m�moire dans mon projet.

Admettons le code suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

template <typename T> inline std::string read(std::ifstream& ifs, const T& offset, const T& size) { std::streambuf *pbuf = ifs.rdbuf(); char* contents = new char[size + 1]; pbuf->pubseekoff(offset, ifs.beg); pbuf->sgetn(contents, size); contents[size] = '\0'; std::string datas(contents); delete[] contents; delete pbuf; return datas; }

---

Cette fonction est appel�e des millions de fois , la d�sallocation ne se semble pas se d�rouler correctement, ma m�moire RAM finit par saturer.. J'ai du oublier un d�tail. :?

Merci d'avance pour vos r�ponses.

Je ne suis pas expert de std::streambuf mais essayes d'�viter les allocations et les desallocations.

Pour

• La variable contents passe l� en static ou en global et fixe sa taille avec la plus grande taille possible (tu dois la conna�tre)
• La variable pbuf l� c'est in�vitable, � moins d'avoir une seule variable ifs (puisqu'on prend son pointeur sur son objet interne)
• Pour ta valeur de retour, il me semble qu'un const std::string& �vite des recopies inutiles. Mais je pense qu'un const est trop limitant.

Par contre, il semble te manquer un ifs.close(); juste avant la ligne 10 :mrgreen:

C'est dommage que l'application ne plante pas (elle devrait). Mais un outil d'analyse (asan, valgrind, ...) aurait probablement relev� l'erreur.
La ligne 11 est de trop. Le pbuf est d�truit et ifs n'en est m�me pas inform� !

Tu peux aussi te passer compl�tement du buffer interm�diaire.
Depuis C++11, la m�moire d'un std::string est garantit continue, ce qui permet de remplacer content par &datas[0] (apr�s application de std::string::resize).
Par contre, il y a toujours le memset d� au resize.

J'ai une fonction de lecture de fichier un peu sioux. Comme aucune donn�e n'est pr�sente dans le buffer du streambuf, tout le contenu est directement �crit dans le buffer donn� � sgetn (pas d'interm�diaire). Remplacer le buffer interne du streambuf permet aussi de l'emp�cher d'en allouer un.

@foetus: pourquoi vouloir fermer le fichier ? La fonction ne s'appelle pas read_and_close ;)

Citation:

---

Envoy� par jo_link_noir

@foetus: pourquoi vouloir fermer le fichier ? La fonction ne s'appelle pas read_and_close ;)

---

En regardant les exemples sur cplusplus.com :mrgreen: ici (qui est tr�s proche du code de bowow) et l�

foetus, contrairement � ce que tu peux penser, je ne peux pas pr�dire la taille du buffer � l'avance, les donn�es sont tr�s tr�s denses, je ne peux donc pas les lire, d'ou mon allocation dynamique. Comme cette fonction est appel�e des milliards de fois, le fichier reste ouvert jusqu'� la lecture compl�te du fichier � partir des offsets sauvegard�s dans un vecteur de structure.

jo_link_noir, merci bien, comme toujours! Bon j'ai remplac� mon code par celui-ci:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

template <typename T> std::string read(std::ifstream& ifs, const T& offset, const T& size) { std::string datas; datas.resize(size); std::streambuf *pbuf = ifs.rdbuf(); pbuf->pubseekoff(offset, ifs.beg); pbuf->sgetn(&datas[0], size);   return datas; }

---

je r�cup�re bien mes chaines de caract�res et la RAM me dit merci. 8-)

Par contre, je recherche � supprimer des '\n' en plein milieu de la chaine de caract�res, existe-t-il un m�thode adapt�e pour �a? j'avais pens� faire une fonction un peu d�riv�e de celle du dessus:

Code:

---

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

template <typename T> std::string read_char(std::ifstream& ifs, const T& offset, const T& size) { std::string datas; std::streambuf *pbuf = ifs.rdbuf(); pbuf->pubseekoff(offset, ifs.beg); do { char c = pbuf->sgetc(); if (c != '\n') datas.push_back(c);   } while (pbuf->snextc() != '>');   return datas; }

---

Citation:

---

Envoy� par bowow

Par contre, je recherche � supprimer des '\n' en plein milieu de la chaine de caract�res, existe-t-il un m�thode adapt�e pour �a?

---

Pas � ma connaissance. Si les sauts de lignes sont peu nombreux, peut-�tre une boucle sur sgetn() et std::remove(..., '\n') ?

Attention avec read_char. Avec resize, il ne faut pas ins�rer en fin, mais modifier les valeurs du tableaux (ou utiliser std::string::reserve + insert/push_back).
La ligne 15 n'a pas d'effet en l'�tat: resize() joue sur la valeur de size(). Si on lui donne la valeur de size(), alors il n'y a rien � faire.
Concernant la boucle, je ne comprends pas ce que vient faire la comparaison sur '>' ? Un parser html ?

Aussi, tu ne fais pas de v�rification d'erreur de lecture ?

Ouais en fait, j'avais post� le code � 3h du mat', sans vraiment tester, alors qu'un simple push_back est plus adapt� et redimensionne automatiquement. J'ai r��dit� mon poste initial.

je testerais bien ta m�thode avec sgetn et std::remove, pour voir et comparer. (je bench pas mal, je recherche toujours les moindres petites optimisations).

Pour les erreurs de lecture, je ne vois pas trop ou tu veux en venir, v�rifier que c != null ?

Citation:

---

Envoy� par bowow

Pour les erreurs de lecture, je ne vois pas trop ou tu veux en venir, v�rifier que c != null ?

---

V�rifier par exemple qu'il n'y a plus rien � lire ou qu'il n'est plus possible de lire (il n'y a pas de distinction entre la fin de fichier et une erreur, il faut regarder errno pour �a).

Code:

---

1 2 3 4 5 6 7 8

using traits = stream_buf::traits_type; const auto eof = traits::eof(); auto c = sb->sgetc();   while (!traits::eq_int_type(c, eof)) { ... c = sb->snextc(); }

---

Comme j'y pense, que devient la cha�ne retourn�e par read et read_char ? Si elle peut �tre r�utilis�e, il est pr�f�rable de la fournir en r�f�rence aux fonctions pour ne pas allouer syst�matiquement la m�moire quand resize/reserve est appel�.

Citation:

---

Comme j'y pense, que devient la cha�ne retourn�e par read et read_char ? Si elle peut �tre r�utilis�e, il est pr�f�rable de la fournir en r�f�rence aux fonctions pour ne pas allouer syst�matiquement la m�moire quand resize/reserve est appel�.

---

A chaque it�ration, les offsets changent et la cha�ne retourn�e est toujours diff�rente. Par contre, dans certains cas, la taille peut stagner sur plusieurs it�rations, mais impossible � pr�dire.

Mais bon les performances de mon code ne sont pas terrible, au niveau du d�placement dans le fichier.

comment r�agit pubseekoff ? Si je lui dis tu te d�places � l'offset 1.000.000, il se d�place imm�diatement � cette position, ou il est oblig� de d�placer l'offset char par char ?
Actuellement je sauvegarde l'offset depuis le d�but du fichier, puis je d�marre � std::ios_base::beg � chaque fois.
S'il se d�place char par char, autant calculer l'offset � partir de l'offset pr�c�dent et utiliser std::ios_base::cur ?

Citation:

---

Envoy� par bowow

A chaque it�ration, les offsets changent et la cha�ne retourn�e est toujours diff�rente. Par contre, dans certains cas, la taille peut stagner sur plusieurs it�rations, mais impossible � pr�dire.

---

Je vais donner un exemple pour mieux me faire comprendre.

Code:

---

1 2 3 4

std::string s; while (!(s = read(...).empty()) { std::cout << s; }

---

Dans cette exemple, read fait syst�matiquement une allocation alors que si s �tait pass� en param�tre, il n'y en aurait uniquement quand la taille demand�e est plus grande que la capacit� de la cha�ne.

Citation:

---

Envoy� par bowow

Mais bon les performances de mon code ne sont pas terrible, au niveau du d�placement dans le fichier. comment r�agit pubseekoff ?

Si je lui dis tu te d�places � l'offset 1.000.000, il se d�place imm�diatement � cette position, ou il est oblig� de d�placer l'offset char par char ?

---

Heureusement que nom. Derri�re se cache un appel � lseek, qui fait appel au driver disque pour d�placer le pointeur. � moins de travailler sur des p�riph�riques particuliers, le saut est "imm�diat". Mais le disque n'est pas r�put� rapide ; comme toutes les io en fait.

Je ne sais pas si c'est possible ou s'il y aura un v�ritable impact, mais, peux-tu lire par offset croissant ?
C'est peut-�tre m�me plus rapide de lire par gros morceau dans un buffer et travailler un maximum avec celui-ci ? Voir carr�ment avec le buffer interne de streambuf (streambuf::showmanyc et streambuf::pubsetbuf)
Je n'ai jamais test�, mais c'est peut-�tre plus efficace avec std::ios::cur ?

Il faudrait plus d'infos.

En fait d�sol�, je me suis pr�cipit� dans ces affirmations hasardeuses, en comparant avec mon ancienne solution, la recherche de motif est beaucoup plus rapide car elle ne m'oblige plus � tout relire le fichier � chaque fois, mais � pointer sur les offsets, donc on y gagne en faisant les sauts d'offsets. Tu n'as fait que confirmer mon point de vue � propos de pubseekof, le contraire aurait �t� �tonnant, donc ouf je garde mon algorithm actuel. ;)

Par contre, ton optimisation est plut�t bonne � prendre et non n�gligeable, surtout si la taille des donn�es est importante. 8-)

Citation:

---

Je ne sais pas si c'est possible ou s'il y aura un v�ritable impact, mais, peux-tu lire par offset croissant ?

---

Les offsets sont d�j� enregistr�s en m�moire par ordre croissant.

Citation:

---

C'est peut-�tre m�me plus rapide de lire par gros morceau dans un buffer et travailler un maximum avec celui-ci ? Voir carr�ment avec le buffer interne de streambuf (streambuf::showmanyc et streambuf::pubsetbuf)

---

Cette approche pourrait �tre int�ressante � exploiter.

Citation:

---

Je n'ai jamais test�, mais c'est peut-�tre plus efficace avec std::ios::cur ?

---

Aucune id�e, mais �a m'obligerait � faire beaucoup de changements dans les algorithmes et pas sur que le b�n�fice soit flagrant.