cin.get(string,int,OEF) et cin.getline(strng,int,EOF) : errreur
17 réponses
heinquoi
bjr,
j'ai un petit prog qui ne fonctionne pas et je ne comprend pas bien
l'erreur:
// Variables
#include <string>
#include <iostream>
#include <map>
#include <fstream>
//#include <stdcomp>
#include <strstream>
#include "client.hpp"
<........>
Avec le message d'erreur suivant:
:\X Mes Documents X\Mes Programmes\VisualC++ 6\map2\mapmartinez.cpp(163):
error: no instance of overloaded function "std::basic_istream<_E, _Tr>::get
[with _E=char, _Tr=std::char_traits<char>]" matches the argument list
argument types are: (std::string, int)
object type is: std::istream
cin.get(nom, 25);
^
D:\X Mes Documents X\Mes Programmes\VisualC++ 6\map2\mapmartinez.cpp(168):
error: no instance of overloaded function "std::basic_istream<_E,
_Tr>::getline [with _E=char, _Tr=std::char_traits<char>]" matches the
argument list
argument types are: (std::string, int, int)
object type is: std::istream
cin.getline(adr, 50, EOF);
^
Or cin.get et cin.getline sont 2 fonctions qui existe et qui prennent bien
les arguments (char*, int, int)...
Un truc m'echappe....probablememnt un petit truc !
Merci d'avance de votre aide
Cordialement
H
j'ai vu que tu as ecrit 2 livres et un troisieme est en preparation. Le 3eme m'interesse particulièrement. Structures de données et algothmes en iso c++. l'as tu terminé ?
En fait, j'en ai écrit et fini deux, que j'ai refondus et retravaillés pour en faire un nouveau que je suis en train de terminer ainsi que le troisième (quatrième ?) qui est déjà distribué de façon limitée. J'espère finir les deux dans les semaines qui viennent, pour qu'ils soient disponibles à la fin de l'été, au Québec à tout le moins (je ne sais plus comment se fait la distribution ailleurs).
de plus sache que, d'apres ton sommaire cela correspond tout a fait, a une unite de valeur du diplome BAC+2 informatique d'entreprise du CNAM orleans (que je passe cette année)
Tant mieux si ça apporte des ventes :-) C'est sûr que c'est un contenu classique, mais mon livre est très différent de ce que je connais sur le sujet, visant plus la pratique que la théorie en étant aussi très spécifique sur les possibilités de ISO C++.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:40c8adad$0$13812$626a14ce@news.free.fr,
j'ai vu que tu as ecrit 2 livres et un troisieme est en
preparation. Le 3eme m'interesse particulièrement.
Structures de données et algothmes en iso c++.
l'as tu terminé ?
En fait, j'en ai écrit et fini deux, que j'ai refondus et
retravaillés pour en faire un nouveau que je suis en train de
terminer ainsi que le troisième (quatrième ?) qui est déjà
distribué de façon limitée. J'espère finir les deux dans les
semaines qui viennent, pour qu'ils soient disponibles à la fin
de l'été, au Québec à tout le moins (je ne sais plus comment se
fait la distribution ailleurs).
de plus sache que, d'apres ton sommaire cela correspond tout a
fait, a une unite de valeur du diplome BAC+2 informatique
d'entreprise du CNAM orleans (que je passe cette année)
Tant mieux si ça apporte des ventes :-) C'est sûr que c'est un
contenu classique, mais mon livre est très différent de ce que
je connais sur le sujet, visant plus la pratique que la théorie
en étant aussi très spécifique sur les possibilités de ISO C++.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
j'ai vu que tu as ecrit 2 livres et un troisieme est en preparation. Le 3eme m'interesse particulièrement. Structures de données et algothmes en iso c++. l'as tu terminé ?
En fait, j'en ai écrit et fini deux, que j'ai refondus et retravaillés pour en faire un nouveau que je suis en train de terminer ainsi que le troisième (quatrième ?) qui est déjà distribué de façon limitée. J'espère finir les deux dans les semaines qui viennent, pour qu'ils soient disponibles à la fin de l'été, au Québec à tout le moins (je ne sais plus comment se fait la distribution ailleurs).
de plus sache que, d'apres ton sommaire cela correspond tout a fait, a une unite de valeur du diplome BAC+2 informatique d'entreprise du CNAM orleans (que je passe cette année)
Tant mieux si ça apporte des ventes :-) C'est sûr que c'est un contenu classique, mais mon livre est très différent de ce que je connais sur le sujet, visant plus la pratique que la théorie en étant aussi très spécifique sur les possibilités de ISO C++.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
"Michel Michaud" wrote in message news:<uY0yc.43735$...
Dans news:40c898ee$0$13821$,
"Luc Hermitte" a écrit dans le message de news:
std::cin.ignore(std::numeric_limits<int>::max(),'n'); avant le getline. Oui ca règle ...mais ca amène un autre probleme: je met un
cin.ignore (80) avant et apres chaque getline (cin.....)
La logique de base qui fonctionne si tu veux être consistant et lire directement les valeurs numériques avec >> (ce qui n'est pas très solide) est de faire un ignore APRÈS chaque lecture avec >> et pas après getline. En fait, l'idée est de ne jamais laisser le délimiteur dans la zone tampon (>> le laisse, getline non).
Donc si tu lis avec >>, tu fais ensuite un ignore pour lire le délimiteur. En fait, si tu ne veux pas valider les lectures sérieusement, donc si tu supposes que les données sont bonnes, tu peux faire un simple flux.ignore() (qui saute un seul caractère) pour lire le délimiteur. Faire un ignore jusqu'à n, en pensant qu'il y aura d'autres choses avant mais qu'on ne veut pas s'en préoccuper, ce n'est pas vraiment une solution « supérieure » !
En général, je le trouve préférable à ne pas mélanger les lectures orientées ligne et les lectures orientées champs. Si la syntaxe de ce qu'on lit, c'est orientée ligne, je préfère ne lire que des lignes, quitte à utiliser un istringstream pour les analyser par la suite.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<uY0yc.43735$sS2.1562611@news20.bellglobal.com>...
Dans news:40c898ee$0$13821$626a14ce@news.free.fr,
"Luc Hermitte" <hermitte@free.fr.invalid> a écrit dans le
message de news:Xns9504B03E2927Bisyfur@127.0.0.1...
std::cin.ignore(std::numeric_limits<int>::max(),'n');
avant le getline.
Oui ca règle ...mais ca amène un autre probleme: je met un
cin.ignore (80) avant et apres chaque getline (cin.....)
La logique de base qui fonctionne si tu veux être consistant et lire
directement les valeurs numériques avec >> (ce qui n'est pas très
solide) est de faire un ignore APRÈS chaque lecture avec >> et pas
après getline. En fait, l'idée est de ne jamais laisser le délimiteur
dans la zone tampon (>> le laisse, getline non).
Donc si tu lis avec >>, tu fais ensuite un ignore pour lire le
délimiteur. En fait, si tu ne veux pas valider les lectures
sérieusement, donc si tu supposes que les données sont bonnes, tu peux
faire un simple flux.ignore() (qui saute un seul caractère) pour lire
le délimiteur. Faire un ignore jusqu'à n, en pensant qu'il y aura
d'autres choses avant mais qu'on ne veut pas s'en préoccuper, ce n'est
pas vraiment une solution « supérieure » !
En général, je le trouve préférable à ne pas mélanger les lectures
orientées ligne et les lectures orientées champs. Si la syntaxe de ce
qu'on lit, c'est orientée ligne, je préfère ne lire que des lignes,
quitte à utiliser un istringstream pour les analyser par la suite.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"Michel Michaud" wrote in message news:<uY0yc.43735$...
Dans news:40c898ee$0$13821$,
"Luc Hermitte" a écrit dans le message de news:
std::cin.ignore(std::numeric_limits<int>::max(),'n'); avant le getline. Oui ca règle ...mais ca amène un autre probleme: je met un
cin.ignore (80) avant et apres chaque getline (cin.....)
La logique de base qui fonctionne si tu veux être consistant et lire directement les valeurs numériques avec >> (ce qui n'est pas très solide) est de faire un ignore APRÈS chaque lecture avec >> et pas après getline. En fait, l'idée est de ne jamais laisser le délimiteur dans la zone tampon (>> le laisse, getline non).
Donc si tu lis avec >>, tu fais ensuite un ignore pour lire le délimiteur. En fait, si tu ne veux pas valider les lectures sérieusement, donc si tu supposes que les données sont bonnes, tu peux faire un simple flux.ignore() (qui saute un seul caractère) pour lire le délimiteur. Faire un ignore jusqu'à n, en pensant qu'il y aura d'autres choses avant mais qu'on ne veut pas s'en préoccuper, ce n'est pas vraiment une solution « supérieure » !
En général, je le trouve préférable à ne pas mélanger les lectures orientées ligne et les lectures orientées champs. Si la syntaxe de ce qu'on lit, c'est orientée ligne, je préfère ne lire que des lignes, quitte à utiliser un istringstream pour les analyser par la suite.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
drkm
writes:
En général, je le trouve préférable à ne pas mélanger les lectures orientées ligne et les lectures orientées champs.
Tu veux dire champs de longueur fixe ? Parceque, sinon, je ne vois pas vraiment la différence. Les lignes sont des champs de longueur variable, et de dilimiteur 'n'. Non ?
--drkm
kanze@gabi-soft.fr writes:
En général, je le trouve préférable à ne pas mélanger les lectures
orientées ligne et les lectures orientées champs.
Tu veux dire champs de longueur fixe ? Parceque, sinon, je ne vois
pas vraiment la différence. Les lignes sont des champs de longueur
variable, et de dilimiteur 'n'. Non ?
En général, je le trouve préférable à ne pas mélanger les lectures orientées ligne et les lectures orientées champs.
Tu veux dire champs de longueur fixe ? Parceque, sinon, je ne vois pas vraiment la différence. Les lignes sont des champs de longueur variable, et de dilimiteur 'n'. Non ?
--drkm
Michel Michaud
Dans news:,
"Michel Michaud" wrote in message news:<uY0yc.43735$... En général, je le trouve préférable à ne pas mélanger les lectures orientées ligne et les lectures orientées champs. Si la syntaxe de ce qu'on lit, c'est orientée ligne, je préfère ne lire que des lignes, quitte à utiliser un istringstream pour les analyser par la suite.
En fait, même (ou surtout) si la ligne contient plusieurs champs, la façon la plus sûre est de lire la ligne au complet et de l'analyser ensuite. Mais si l'on suppose qu'il n'y a pas d'erreurs ou qu'on ne veut pas les vérifier, on peut voir getline comme un version particulière de >>...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:d6652001.0406102359.40c19ae2@posting.google.com,
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<uY0yc.43735$sS2.1562611@news20.bellglobal.com>...
En général, je le trouve préférable à ne pas mélanger les
lectures orientées ligne et les lectures orientées champs. Si
la syntaxe de ce qu'on lit, c'est orientée ligne, je préfère ne
lire que des lignes, quitte à utiliser un istringstream pour
les analyser par la suite.
En fait, même (ou surtout) si la ligne contient plusieurs champs,
la façon la plus sûre est de lire la ligne au complet et de
l'analyser ensuite. Mais si l'on suppose qu'il n'y a pas d'erreurs
ou qu'on ne veut pas les vérifier, on peut voir getline comme un
version particulière de >>...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Michel Michaud" wrote in message news:<uY0yc.43735$... En général, je le trouve préférable à ne pas mélanger les lectures orientées ligne et les lectures orientées champs. Si la syntaxe de ce qu'on lit, c'est orientée ligne, je préfère ne lire que des lignes, quitte à utiliser un istringstream pour les analyser par la suite.
En fait, même (ou surtout) si la ligne contient plusieurs champs, la façon la plus sûre est de lire la ligne au complet et de l'analyser ensuite. Mais si l'on suppose qu'il n'y a pas d'erreurs ou qu'on ne veut pas les vérifier, on peut voir getline comme un version particulière de >>...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
James Kanze
drkm writes:
|> writes:
|> > En général, je le trouve préférable à ne pas mélanger les lectures |> > orientées ligne et les lectures orientées champs.
|> Tu veux dire champs de longueur fixe ? Parceque, sinon, je ne vois |> pas vraiment la différence. Les lignes sont des champs de longueur |> variable, et de dilimiteur 'n'. Non ?
Non. Orienté champs, ce n'est peut-être pas le mot qui convient. Mais j'imaginais, par exemple, un fichier avec une suite de nombres, les tous séparés par des blancs, mais avec des sauts de lignes sans importance. (Il y a eu une question à cet égard dans de.comp.lang.iso-c++ dernièrement ; c'est pour ça que j'y ai pensé.)
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
drkm <usenet.fclcxx@fgeorges.org> writes:
|> kanze@gabi-soft.fr writes:
|> > En général, je le trouve préférable à ne pas mélanger les lectures
|> > orientées ligne et les lectures orientées champs.
|> Tu veux dire champs de longueur fixe ? Parceque, sinon, je ne vois
|> pas vraiment la différence. Les lignes sont des champs de longueur
|> variable, et de dilimiteur 'n'. Non ?
Non. Orienté champs, ce n'est peut-être pas le mot qui convient. Mais
j'imaginais, par exemple, un fichier avec une suite de nombres, les tous
séparés par des blancs, mais avec des sauts de lignes sans importance.
(Il y a eu une question à cet égard dans de.comp.lang.iso-c++
dernièrement ; c'est pour ça que j'y ai pensé.)
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
|> > En général, je le trouve préférable à ne pas mélanger les lectures |> > orientées ligne et les lectures orientées champs.
|> Tu veux dire champs de longueur fixe ? Parceque, sinon, je ne vois |> pas vraiment la différence. Les lignes sont des champs de longueur |> variable, et de dilimiteur 'n'. Non ?
Non. Orienté champs, ce n'est peut-être pas le mot qui convient. Mais j'imaginais, par exemple, un fichier avec une suite de nombres, les tous séparés par des blancs, mais avec des sauts de lignes sans importance. (Il y a eu une question à cet égard dans de.comp.lang.iso-c++ dernièrement ; c'est pour ça que j'y ai pensé.)
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
heinquoi
bjr, en fait le comportement bizarre de getline malgres l'utilisation de cin.ignore est du a un bug de microsoft, dans visual studio 6 c++ et, il propose de corriger le fichier string pour que cela fonctionne normalement voir ici http://support.microsoft.com/default.aspx?scid=kb;EN-US;q240015
morbleu, dudieu ... j'en est chier pour rien... merci micro$oft, de ne pas suivre les normes du langages ! H
-- Cordialement, Heinquoi "Michel Michaud" a écrit dans le message de news:Pbiyc.52158$
Dans news:,
"Michel Michaud" wrote in message news:<uY0yc.43735$... En général, je le trouve préférable à ne pas mélanger les lectures orientées ligne et les lectures orientées champs. Si la syntaxe de ce qu'on lit, c'est orientée ligne, je préfère ne lire que des lignes, quitte à utiliser un istringstream pour les analyser par la suite.
En fait, même (ou surtout) si la ligne contient plusieurs champs, la façon la plus sûre est de lire la ligne au complet et de l'analyser ensuite. Mais si l'on suppose qu'il n'y a pas d'erreurs ou qu'on ne veut pas les vérifier, on peut voir getline comme un version particulière de >>...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
bjr,
en fait le comportement bizarre de getline malgres l'utilisation de
cin.ignore est du a un bug de microsoft, dans visual studio 6 c++ et, il
propose de corriger le fichier string pour que cela fonctionne normalement
voir ici
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q240015
morbleu, dudieu ... j'en est chier pour rien...
merci micro$oft, de ne pas suivre les normes du langages !
H
--
Cordialement,
Heinquoi
"Michel Michaud" <mm@gdzid.com> a écrit dans le message de
news:Pbiyc.52158$sS2.1875000@news20.bellglobal.com...
Dans news:d6652001.0406102359.40c19ae2@posting.google.com,
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<uY0yc.43735$sS2.1562611@news20.bellglobal.com>...
En général, je le trouve préférable à ne pas mélanger les
lectures orientées ligne et les lectures orientées champs. Si
la syntaxe de ce qu'on lit, c'est orientée ligne, je préfère ne
lire que des lignes, quitte à utiliser un istringstream pour
les analyser par la suite.
En fait, même (ou surtout) si la ligne contient plusieurs champs,
la façon la plus sûre est de lire la ligne au complet et de
l'analyser ensuite. Mais si l'on suppose qu'il n'y a pas d'erreurs
ou qu'on ne veut pas les vérifier, on peut voir getline comme un
version particulière de >>...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
bjr, en fait le comportement bizarre de getline malgres l'utilisation de cin.ignore est du a un bug de microsoft, dans visual studio 6 c++ et, il propose de corriger le fichier string pour que cela fonctionne normalement voir ici http://support.microsoft.com/default.aspx?scid=kb;EN-US;q240015
morbleu, dudieu ... j'en est chier pour rien... merci micro$oft, de ne pas suivre les normes du langages ! H
-- Cordialement, Heinquoi "Michel Michaud" a écrit dans le message de news:Pbiyc.52158$
Dans news:,
"Michel Michaud" wrote in message news:<uY0yc.43735$... En général, je le trouve préférable à ne pas mélanger les lectures orientées ligne et les lectures orientées champs. Si la syntaxe de ce qu'on lit, c'est orientée ligne, je préfère ne lire que des lignes, quitte à utiliser un istringstream pour les analyser par la suite.
En fait, même (ou surtout) si la ligne contient plusieurs champs, la façon la plus sûre est de lire la ligne au complet et de l'analyser ensuite. Mais si l'on suppose qu'il n'y a pas d'erreurs ou qu'on ne veut pas les vérifier, on peut voir getline comme un version particulière de >>...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
"Michel Michaud" wrote in message news:<Pbiyc.52158$...
Dans news:,
"Michel Michaud" wrote in message news:<uY0yc.43735$... En général, je le trouve préférable à ne pas mélanger les lectures orientées ligne et les lectures orientées champs. Si la syntaxe de ce qu'on lit, c'est orientée ligne, je préfère ne lire que des lignes, quitte à utiliser un istringstream pour les analyser par la suite.
En fait, même (ou surtout) si la ligne contient plusieurs champs, la façon la plus sûre est de lire la ligne au complet et de l'analyser ensuite. Mais si l'on suppose qu'il n'y a pas d'erreurs ou qu'on ne veut pas les vérifier, on peut voir getline comme un version particulière de >>...
Tout dépend de la contexte. Si les sauts à la ligne n'ont aucune signification dans le fichier, et la syntaxe est assez simple, on pourrait très bien se passer de getline. Le seul avantage qu'il pourrait apporter alors, c'est de pouvoir afficher le numéro de ligne en cas d'erreur (mais un streambuf filtrant pourrait aussi en faire l'affaire).
Mais j'avoue que de tels formats sont rares. Alors, tout dépend du syntaxe. Si j'écrivais un parseur C++, par exemple, je ne me servirai presque certainement pas de getline.
En somme, je me servirais pas de getline aux deux extrèmes (ultra-simple, ou ultra-compliqué), à moins que la grammaire soit orientée ligne.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<Pbiyc.52158$sS2.1875000@news20.bellglobal.com>...
Dans news:d6652001.0406102359.40c19ae2@posting.google.com,
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<uY0yc.43735$sS2.1562611@news20.bellglobal.com>...
En général, je le trouve préférable à ne pas mélanger les lectures
orientées ligne et les lectures orientées champs. Si la syntaxe de
ce qu'on lit, c'est orientée ligne, je préfère ne lire que des
lignes, quitte à utiliser un istringstream pour les analyser par la
suite.
En fait, même (ou surtout) si la ligne contient plusieurs champs, la
façon la plus sûre est de lire la ligne au complet et de l'analyser
ensuite. Mais si l'on suppose qu'il n'y a pas d'erreurs ou qu'on ne
veut pas les vérifier, on peut voir getline comme un version
particulière de >>...
Tout dépend de la contexte. Si les sauts à la ligne n'ont aucune
signification dans le fichier, et la syntaxe est assez simple, on
pourrait très bien se passer de getline. Le seul avantage qu'il pourrait
apporter alors, c'est de pouvoir afficher le numéro de ligne en cas
d'erreur (mais un streambuf filtrant pourrait aussi en faire l'affaire).
Mais j'avoue que de tels formats sont rares. Alors, tout dépend du
syntaxe. Si j'écrivais un parseur C++, par exemple, je ne me servirai
presque certainement pas de getline.
En somme, je me servirais pas de getline aux deux extrèmes
(ultra-simple, ou ultra-compliqué), à moins que la grammaire soit
orientée ligne.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"Michel Michaud" wrote in message news:<Pbiyc.52158$...
Dans news:,
"Michel Michaud" wrote in message news:<uY0yc.43735$... En général, je le trouve préférable à ne pas mélanger les lectures orientées ligne et les lectures orientées champs. Si la syntaxe de ce qu'on lit, c'est orientée ligne, je préfère ne lire que des lignes, quitte à utiliser un istringstream pour les analyser par la suite.
En fait, même (ou surtout) si la ligne contient plusieurs champs, la façon la plus sûre est de lire la ligne au complet et de l'analyser ensuite. Mais si l'on suppose qu'il n'y a pas d'erreurs ou qu'on ne veut pas les vérifier, on peut voir getline comme un version particulière de >>...
Tout dépend de la contexte. Si les sauts à la ligne n'ont aucune signification dans le fichier, et la syntaxe est assez simple, on pourrait très bien se passer de getline. Le seul avantage qu'il pourrait apporter alors, c'est de pouvoir afficher le numéro de ligne en cas d'erreur (mais un streambuf filtrant pourrait aussi en faire l'affaire).
Mais j'avoue que de tels formats sont rares. Alors, tout dépend du syntaxe. Si j'écrivais un parseur C++, par exemple, je ne me servirai presque certainement pas de getline.
En somme, je me servirais pas de getline aux deux extrèmes (ultra-simple, ou ultra-compliqué), à moins que la grammaire soit orientée ligne.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
