Discussion :

[flamme34]

Pour les histoires "d'économie" de RAM, vous allez pas l'user, et on est maintenant avec des machine 64bits et avec des OS qui gèrent tous la mémoire virtuelle.
On n'est plus sur des systèmes de 64Ko sans MMU, nom d'un chien.

Justement nous avons à traiter des gros gros gros fichiers de plusieurs millions d’éléments il arrive parfois que la RAM atteigne facilement le plafond et que l'appli parte en "out of memory". rarement sur mon PC de develioppement qui possède 12Go de RAM mais sur les Pcs client qui n'ont la plupart du temps que 4Go de RAM cela peut arriver.
D'où cette tentative d'économie même si elle est maladroite semble-t-il.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
P.S.: j'ai vu des "catch(...)" à la con, vous me virez ces conneries qui vous empêche de correctement déboguer et mettre au point votre programme.
On ne catch que ce que l'on traite, c'est tout.

C'est noté je l'ai est enlevé.

N'hésitez pas à vérifier avec le code assembleur que les sources et le binaire sont bien "aligné".

Désolé de poser la question mais comment fait-on ceci ?

J'ai l'impression que vous avez des réticences à utiliser le débogueur.

En général je l'utilise, c'est juste que là j'ai du mal a savoir vraiment quoi chercher , ne connaissant pas très bien la structure interne de la classe ofstream.

[bacelar]

Avec la mémoire virtuelle et le 64 bits, ce n'est pas dû à la taille de la RAM que vos clients se tapent des "out of memory", c'est juste qu'ils n'ont pas gérer correctement la taille de leur swap.
(Ok, le swap ça plombe les perf. mais ce n'est pas le même problème).
Ce n'est donc pas un problème de "RAM" mais de configuration de la plateforme d'exécution.

Ne gérer des problèmes de performance qu'au moment où vous y êtes confronté (on passant à la scalabilité de votre solution quand même à l'avance).

Vous avez donc 2 approches, soit vous allez du coté d'une plateforme configurée pour la bonne taille et des perf. pas terrible => plus besoin de multiples écritures qui plombent encore plus les perf. .
Soit vous savez déjà que les performances doivent "scalées" avec la plateforme. Mais vous devez choisir sur quel type de plateforme vous devez avoir les meilleurs performances.
12Go ou 4Go de RAM, cela peut changer complètement les stratégies d'optimisations.

Si votre approche est viable, autant découper votre programme en plusieurs autres programmes. Cela rendrait votre architecture bien plus scalable et les programmes serait encore plus simples.

En bref, votre approche est toujours étrange vue de l'extérieur.

Désolé de poser la question mais comment fait-on ceci ?

Juste voir que le code assembleur correspond bien au code source (ce n'est vraiment jouable qu'avec des codes peu optimisés par l'optimiseur).
Le débogueur affiche le code assembleur correspondant au source, dans votre IDE, non ?

ne connaissant pas très bien la structure interne de la classe ofstream.

Ne cherchez pas à savoir comment marche par le menu les classes qui ne sont pas les vôtres. Il est très peu probable que le problème viennent d'elles mais plus de comment vous les utilisez dans votre code.
Donc, regardez ce qui déconne, le champ/ la variable qui vous fait faire une General Protection Fault et traquez comment il/elle évolue et pourquoi il/elle se met dans un état qui fait tout planté.

Il se peut que l'erreur ne soit pas trivial, encore plus fréquent quand on fait du multithreading "à l'arrache".
Mais peut-être qu'il serait plus efficace de refactorer votre architecture.