From: firstname.dot.lastname@googlemail.com   
      
   On Fri, 25 Jan 2013 10:00:16 -0800, James K. Lowden wrote:   
      
   >> 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.   
      
   It certainly used to be slow: it used to make calls via FILE* in   
   common implementations, making it slower than C style   
   implementations. Later, when it didn't if sync_with_stdio was left to   
   default true, then it was slow due to the need to potentially   
   interleave with printf.   
      
   I haven't checked recently but those two could lead to the mis(?   
   )conception that it is slow.   
      
   >> first example of operator overloading abuse.   
   >   
   > Define abuse, please.   
      
   I'd disagree that it's abuse. I see so much more IO than bitshifting,   
   that my brain defaults << to write. I think DLSs are generally fine.   
      
      
   >> 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.   
      
   It's not that printf is easy to use because its typesafe, it's easy to   
   use because it makes many common actions very terse. You also get to   
   share the same formatting with many other tools and the lack of   
   typesafety is a non-issue since almost all compilers now make it   
   effective typesafe by emitting suitable warnings. The lack of proper   
   typesafety is a wart and means that many people have tried to get   
   around it.   
      
   I've been using a typesafe printf for years (using GCC's variadic   
   macro extension), as have many others, because I and many others like   
   the interface. Mine uses iostreams internally, and I suspect so do   
   many others.   
      
   Basically, with a function like sPrintf (think like sprintf, but it   
   returns a std::string and is typesafe), you can do quick hacks like:   
      
   ofstream tmp(sPrintf("some-temp-file-%05i.tmp", iteration_number));   
      
   which is much less verbose than using ostreams directly. Also, another   
   very important point is that you can get the format string from an   
   external source: it doesn't have to be set at compile time. I use the   
   latter feature of printf (well, my own custom safe printf) all the   
   time.   
      
   >> 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.   
      
   Sure, it solves the problems. The thing is that printf does 99% of   
   what you want with a small fraction of the effort and with extra,   
   handy useful features, and with a consistent syntax relative to an   
   awful lot of other tools. The fact that I can't remember what the   
   format string for size_t is immaterial since I don't generally need   
   them. Almost all of the time I (and I strongly suspect many others)   
   want to do the basic things like fixed field width, integers as hex,   
   integers with leading zeros, float/ double losslessly and possibly a   
   few others.   
      
   A well integrated solution allows the convenience of printf with the   
   flexibility of iostreams, since you can freely mix and match them.   
      
   My personal, non general solution is to always use << for   
   stringification, and to only use type-specific formatting when the   
   type is correct.  Otherwise, I just use the field width.   
      
      
   FWIW, most of the time (when I don't need anything beyond default   
   formatting), I use << directly. For dynamic formatting or when I need   
   the formatting to change frequently, I use printf-style functions. For   
   everything else, I use <<.   
      
   -Ed   
      
      
      
      
      
      
      
      
   --   
         [ 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)