home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11825 < prev    next >
Encoding:
Text File  |  1992-07-30  |  1.5 KB  |  46 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!stanford.edu!lucid.com!lucid.com!jss
  3. From: jss@lucid.com (Jerry Schwarz)
  4. Subject: Re: Bizarre Borland stream bug
  5. Message-ID: <1992Jul30.234906.17943@lucid.com>
  6. Sender: usenet@lucid.com
  7. Reply-To: jss@lucid.com (Jerry Schwarz)
  8. Organization: Lucid, Inc.
  9. References: <1992Jul30.185327.662@news2.cis.umn.edu> <1992Jul30.193832.2535@noose.ecn.purdue.edu>
  10. Date: Thu, 30 Jul 92 23:49:06 GMT
  11. Lines: 33
  12.  
  13. In article <1992Jul30.193832.2535@noose.ecn.purdue.edu>, psmith@iies.ecn.purdue.edu (Paul Smith) writes:
  14. ||> 
  15. |> Looks kinda like it is reading 0009 as an octal constant because of 
  16. |> the leading zeros, except that 9 isn't a valid octal digit so it gets 
  17. |> bumped to the next read.
  18. |> 
  19. |> Is this correct behavior?  I dunno.
  20. |> 
  21.  
  22.  
  23. This is correct behavior if the ios::basefield of a stream
  24. has no bits set by default.  For input that condition means
  25. use C lexical conventions.  
  26.  
  27. So the answer to the original problem is to set that field
  28. explicitly.
  29.     
  30.     in.setf(ios::dec,ios::basefield) ;
  31.  
  32.  
  33. The tricky part of the question is whether Borland is
  34. properly initializing flags hen an istream is constructed. 
  35. The original AT&T documentation (which I wrote) doesn't say.
  36. Although the code (which I also wrote) initialized to
  37. ios::skipws|ios::dec.  Not documenting that was a 
  38. bad oversight. The latest working paper from X3J16 (which I 
  39. have also had a hand in) says initialize to zero, but I've
  40. just made a note to review that decision.  
  41.  
  42.   -- Jerry Schwarz
  43.  
  44.  
  45.  
  46.