home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 31,843 of 33,346   
   =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to Daryle Walker   
   Re: When should a UDT activate "badbit"    
   24 Jan 12 13:59:43   
   
   40d3a699   
   From: daniel.kruegler@googlemail.com   
      
   On 2012-01-21 00:07, Daryle Walker wrote:   
   > Let's say I'm reading a list of numbers:   
   >   
   > template<  typename T, typename Ch, class Tr>   
   > std::list   
   > read_my_udt( std::basic_istream  &is )   
   > {   
   >      Ch const  lp = is.widen('('), ca = is.widen(','), rp = is.widen(')');   
   >      Ch        c;   
   >      std::list   result;   
   >   
   >      if ( !(is>>  c) )   
   >          return std::list();   
   >      if ( !Tr::eq(c, lp) )   
   >      {   
   >          T  sole_element;   
   >   
   >          is.unget();   
   >          is>>  sole_element;   
   >          result.push_back( sole_element );   
   >      }   
   >      else   
   >      {   
   >          //...   
   >      }   
   >      return result;   
   > }   
   >   
   > I didn't get into reading a comma-separated, parentheses-bounded list   
   because the single-element case is sufficient.  If there's a format error,   
   from a read setting "eof" or "failbit", I can just return an empty list and   
   use the stream's state to pass    
   on   
   > the error.  But what if there's some sort of exception thrown from list   
   operations?  Should "badbit" be set, or should exceptions not having anything   
   to do with stream operations get passed up without affecting the stream's   
   state?  After all, the stream   
   > is still technically usable, although it has all the elements that weren't   
   read yet at the time of the throw.   
      
   IMO you already answered your question: I also see no reason, why the   
   stream should be considered in a "bad state" just because of a failing   
   operation. There is no contract that requires you to modify the stream   
   state in any way here. But if you use this template to implement some IO   
   extractor and if you want to mimic the behaviour of the standard library   
   in this regard, you should indeed catch the exception within this   
   extractor, set the badbit state, and rethrow the exception unless the   
   stream's exception() flag bit-and-combined with badbit is not zero. If   
   you look at the discussion of LWG issue 309,   
      
   http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#309   
      
   you can get an idea how this can be done.   
      
   HTH & Greetings from Bremen,   
      
   Daniel Krügler   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca