From: jklowden@speakeasy.net   
      
   On Thu, 24 Jan 2013 23:59:38 -0800 (PST)   
   fmatthew5876  wrote:   
      
   > Have there ever been any proposals are serious talks about a   
   > replacement for the iostreams library?   
      
   I've never seen an alternative proposed.  OTOH none of your claims   
   hold water.   
      
   > Among other things, its painfully slow,   
      
   To defend this, you have to show how the *design* cannot be efficiently   
   implemented.  Otherwise you're asserting your implementation is slow.   
      
   > first example of operator overloading abuse.   
      
   Define abuse, please.   
      
   > It also separates formatting from the data.   
      
   I don't understand this statement.  printf(3) puts the formatting in   
   one argument and the data in another.  iostreams has built-in   
   formatting for built-in types, and requires user-defined types to   
   define their formatting.  How is the latter "separate" and the former   
   not?   
      
   > Have you ever tried to  print a hex byte with iostreams? Its really   
   > ugly.   
      
   What's a hex byte?  What's ugly about   
      
   	  cout << hex << 65 << endl;   
   ?   
      
   > Printf while not typesafe, is much more convenient, efficient, easier   
   > to use   
      
   That is the first time I've seen someone argue that something not   
   typesafe is easier to use.  Like C-style casts, it is until it ain't.   
      
   > I'd really like to see a new IO library that uses printf like syntax   
      
   Have you noticed how complex the printf fmt string has become over the   
   years?  Quick, what's %j do?  How has your luck been printing size_t   
   portably?   
      
   There's a fundamental problem, too, one that Stroustup must have   
   encountered in the cfront era.  Fundamentally, printf is a binary   
   operation: it uses a character sequence from its fmt argument to   
   process the data.  In your mind, how would user-defined types provide   
   that sequence to the printing function? How would you standardize the   
   formatting characters across user-defined types?   
      
   iostreams solves these problems by not having them.   
      
   > iostream is a relic from when C++ was still new and good object   
   > oriented design was still not well understood.   
      
   While I wouldn't say nothing has been learned about OO in the last 20   
   years, the idea that good OO design wasn't well understood is frankly   
   laughable.  Not least because "good OO design" has no objective   
   meaning.   
      
   Stroustrup himself said designing an I/O library is hard.  He's right.   
   Writing a good library is hard, and writing a good I/O library is   
   harder yet because there are more failure modes.   
      
   Consider an analogous common I/O problem, where there's been a lot of   
   experimentation: communicating with a DBMS. Any C++ database interface   
   library you care to name is abysmal. (It's not surprising; the C   
   libraries aren't much better.)  Choose any such library and   
      
   1.  Count the lines of code and named operations   
   	to move the data in and out of the DBMS.   
   2.  Compare with iostreams.   
   3.  Weep.   
      
   As someone who's made a study of DBMS I/O libraries and written a few   
   modelled on iostreams, I can tell you the narrow interface   
   provided by the iostream model is very good at containing complexity.   
   Perhaps it could be improved on, but the evidence to date stands   
   against.   
      
   --jkl   
      
      
   --   
         [ 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)