Reprise du message précédent :
Quelques questions/suggestions
 
Se dire qu'en utilisant la STL ou un buffer de la taille du fichier on aura pas de probleme de buffer trop petit lors du get_line est AMHA pas très acceptable.
Le problème n'est que reporté, pas éliminé.
Un tableau a une limite. Celle-ci peut etre atteinte.
Augmenter la taille du tableau ne change en rien le fait que sa limite peut toujours être atteinte.
Du coup : que se passe-t-il avec la version *all STL* si le fichier est trop gros/la ligne trop longue/pas assez de mémoire (au choix ) ?
Tu n'as pas à te soucier de l'alloc de place, mais tu dois tout de même te soucier du cas ou y'a pas assez de place.
 
Pour le modele producteur/conso, je pense que ca peut etre benefique. Notament si ton programme n'est pas le seul à acceder au disque (genre une copie de gros fichier est en cours).
Le fichier mappé ... perso je suis pas cho (c'est pas destiné à un autre usage ?)
Le fait d'avoir un buffer d'une taille donnée (taille que tu décide en fonction du temps que ca prend à parser ... histoire de tenir 10 secondes par exemple tout en restant dans les limites de l'acceptable nivo memoire, genre 1 Mo) que le premier thread s'occupe de maintenir plein et que le second s'acharne à vider ne doit pas être sorcier à coder.
En utilisation classique je ne pense pas que ca apporte grand chose.
Mais ton programme resistera mieux a un acces disque perturbé et autre avantage que je trouve a utiliser des thread pour les acces disque : ton programme est plus réactif.
Perso je deteste qu'un programme se fige quand il accede au lecteur de disquette ou qu'il soit lent a la detente quand il sollicite fortement le disque. (genre Word quand on enregistre un gros doc... plus rien ne répond ).
La, seul ton thread d'acces disque sera bloque et pas ton programme principal.
 
Au fait, c'est un parser de quoi ? (ca m'a echapé)

Le problème reste le même que tu utilises la STL ou les fonctions classiques.
fstream ne donne pas de taille de fichier, mais une indication d'épuisement puisque c'est un flot. Et un failbit mis pour identifier le problème.
 
Je précise que le mappage de fichier ne réserve pas de la mémoire, mais de l'espace d'adressage.
D'où une limite quelque part sous 2 Go (espace d'adressage d'une application).
 
Pour l'histoire des threads qui se bloquent tu as raison.
Ça vaudrait peut-être le coup de faire un thread dédié à la lecture anticipée du fichier.