Bonjour,
 
Je suis à la recherche depuis un moment sur mon programme de la cause de l'augmentation de mémoire ram utilisée.
 
Dans ma boucle principale, je crée tout un tas d'objet à partir d'un flux, je les analyse, et un peu tout le long j'enregistre des infos dans un fichier log.
 
J'ai passé beaucoup de temps à vérifier la première partie de création d'objet et je suis quasi sur qu'il n'y plus de fuites, ou alors vraiment très faibles.
Le point qui m’intrigue le plus c'est que en dé-commentant ligne par ligne la suite du programme je me suis rendu compte que l'augmentation mémoire  se jouait au moment où je log les infos.
 
Je déclare ça :
 

 
EDIT :
Seule cette ligne la fait la différence finalement :

=> augmentation significative de la mémoire

=> pas d'augmentation significative de la mémoire
 
Quelque chose m'échappe dans tout ça j'espère que vous pourrez m'éclairer !
merci

A première vue, je ne vois pas le lien avec une fuite mémoire. Si tu travailles sous Linux, valgrind est ton ami pour ce genre de problème.

merci de t'intéresser à mon problème.
moi aussi cela m'intrigue pourtant j'ai fais le tests dans tous les sens, dès que je rajoute un "<< endl" à la place d'un << '\n', et en ne changeant que ça, la mémoire se met à grimper de manière assez importante.
 
et je travaille avec visual studio 2010

Tiens, il y a %i au lieu de %d.
Mais d'après la doc, c'est un remplacement possible, bien que très peu fréquent.
 
Tiens, il y a sprintf_s() au lieu de sprintf().
Voyons la doc, http://msdn.microsoft.com/fr-fr/li [...] s.80).aspx :

Or, dans le code, cette taille est manquante (de plus le code retour de sprintf_s() n'est pas testé, ce qui fait perdre tout son intérêt à sprintf_s()).
 
Cela me parait une piste intéressante à étudier, mais le problème n'est peut-être pas (uniquement) là.
 

merci oui je n'avais pas fais attention à ça, mais ce n'était qu'un test supplémentaire, pour voir si cette méthode faisait augmenter la mémoire, et ce n'est pas le cas
mais j'utilise "<< '\n'" au lieu de "<< endl" qui à l'air de fonctionner aussi, sans savoir trop pourquoi

Si tu permutes tes deux lignes, la première déclenche t'elle toujours une augmentation significative par rapport à la seconde?
Ou l'augmentation suit elle la ligne permutée?
 
A+,

Désolé, je ne comprends pas ta question
Quelles deux lignes ?
 
Précision : j'ai toujours testé qu'une seule des 3 manières (avec endl, avec '\n' et avec .write() ) à la fois  et seul "endl" fait augmenter la mémoire

Ce qui n'était pas clair au vu du bout de code posté.
A+,

Dans ce que tu dis, rien n'explique vraiement le comportement dont tu te plains. Et avec
 
    fichier << "var1 : " << var1 << '\n';
    fichier << "var1 : " << var1 << '\n' << flush;
    fichier << "var1 : " << var1 << "\n" << flush;
 
que se passe-t'il?

Salut j'ai édité le premier post en espérant qu'il soit plus clair
La question que je me posais, c'est pourquoi le endl fait augmenter la taille du programme en mémoire alors que les autres manières d'écrire dans le fichier ne la changent pas.
 
En modifiant encore pour tester ce que tu viens de proposer, j'ai trouvé la ligne exacte, c'est :

lorsqu'il ya du texte entre les deux toutes les méthodes fonctionnent correctement

Essaye de compiler en release    
 
Honnetement, quand j'ai vu le titre de ton sujet, direct j'ai reconnu VS  
J'ai eu le meme pb il y a quelques années sous le 2005 ou il y avait des bugs dans basic_iostream...  
Mon thread de l'epoque: http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 
 
bah 5 ans plus tard ça a l'air de pas être mieux

A mon avis ça veux juste dire que "cout " applique un "cout.flush ()" automatiquement quand tu lui envoies "\n".