Alex Martelli (martelli@cadlab.it) wrote:
: Trying to explain to a newbie how to do input by whole lines in C++,
: the way they easily used to do it with fgets in bad ol' C, I got bit
: (besides a bug in the libg++ implementation of getline(), which just
: points to some obscurity between the standard libraries' usages of
: length/size/capacity for strings -- obscurity enough to confuse the
: implementor) by a gotcha in the standard itself:
[snip]
: Why the gratuitous spec to setstate(failbit), even possibly to throw!,
: for something as innocuous as an empty line (i.e., just the terminating
While brousing the draft standard/working papers I found a
footnote (This is in the WWW/HTML version, lib-iostreams....)
  29) This implies an empty input line will not cause failbit to be set.

--
 dick@csci.csusb.edu=rbotting@wiley.csusb.edu.
Find out what's new at http://www.csci.csusb.edu/doc/www.sites.html
Disclaimer:`CSUSB may or may not agree with this message`.
Copyright(1995):Copy this freely but include the following link to the
<a href="http://www.csci.csusb.edu/dick/signature.html">author's signature</a>
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

dick@silicon.csci.csusb.edu (Dr. Richard Botting) writes:
 ...
>While brousing the draft standard/working papers I found a
>footnote (This is in the WWW/HTML version, lib-iostreams....)
>  29) This implies an empty input line will not cause failbit to be set.

Which unfortunately only applies to the overload of getline() that is
there described, the one taking an array of chars, not to others such
as the one taking a string -- Mr Kanze pointed out the discrepancy
between the "extracts no chars" and "appends no chars" wordings used
in the two places.  Let's indeed hope it's just a minor editorial
oversight (perfectly understandable, as Mr Kanze says, given the huge
amount of work the editors have been doing!) that's going to be fixed
at some point... with the public comment period closed, is there any
way to submit such concerns to the committee...?


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120

---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

Trying to explain to a newbie how to do input by whole lines in C++,
the way they easily used to do it with fgets in bad ol' C, I got bit
(besides a bug in the libg++ implementation of getline(), which just
points to some obscurity between the standard libraries' usages of
length/size/capacity for strings -- obscurity enough to confuse the
implementor) by a gotcha in the standard itself:

per paragraph 21.1.1.10.8, "Inserters and extractors", getline()...:

    If    the    function    appends    no    characters,    it    calls
    is.setstate(failbit),    which    may    throw     ios_base::failure

Eep.  So, instead of a smooth, simple and elegant style like...:

 while(getline(cin,mystr)) {
     // process mystr
 }

one has to adopt a convoluted...:

 while(1) {
     getline(cin,mystr);
     if(cin.eof() || cin.bad()) break;
     if(cin.fail()) { // just an empty line -- darn 21.1.1.10.8!-(
  cin.clear();
     }
     // process mystr -- at long last!
 }

Why the gratuitous spec to setstate(failbit), even possibly to throw!,
for something as innocuous as an empty line (i.e., just the terminating
'\n'), which the user could so easily test themselves if it had any
special significance for them...?  I found myself unable to explain
the rationale for this to the newbie -- because I can't see any
myself.  Any chance for a change...?  Or, what am I missing...?


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <martelli.815502013@cadlab> martelli@cadlab.it (Alex
Martelli) writes:

|> Trying to explain to a newbie how to do input by whole lines in C++,
|> the way they easily used to do it with fgets in bad ol' C, I got bit
|> (besides a bug in the libg++ implementation of getline(), which just
|> points to some obscurity between the standard libraries' usages of
|> length/size/capacity for strings -- obscurity enough to confuse the
|> implementor) by a gotcha in the standard itself:

|> per paragraph 21.1.1.10.8, "Inserters and extractors", getline()...:

|>     If    the    function    appends    no    characters,    it    calls
|>     is.setstate(failbit),    which    may    throw     ios_base::failure

In the public draft, the statement in 27.6.1.3 (where the target is a
char[]) is: "If the function *extracts* no characters...".  A quick
check with an old cfront based compiler (Sun CC 2.1) shows that this
was the case for the original AT&T implementation, too (unless Sun
changed something, which I very much doubt).  Thus, I expect that the
above is just a typographical error, and that `extracts' is what is
meant there, too.

The library working group did an amazing amount of work just before
the draft was made public, and the editor (and his assistants) had to
work like crazy to get it in in time.  Under these conditions, I don't
find it particularly surprising that there are a number of these sort
of errors.
--

James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung



---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]