From: francis.glassborow@btinternet.com   
      
   On 25/01/2013 23:39, fmatthew5876 wrote:   
   >> To defend this, you have to show how the *design* cannot be efficiently   
   >> implemented.  Otherwise you're asserting your implementation is slow.   
   >   
   > int x, y, z;   
   > printf("%d %d %d\n", x, y z); One function call with one resource lock   
   > acquire and release.   
   >   
   > cout << x << " " << y " " << z << endl; Five function calls, each with   
   > resource lock acquire and release.   
   >   
   > Also what happens if two threads print to stdout at the same time? In the   
   first   
   > case its two atomic printf calls, the second its 5 with no guarantees that   
   the   
   > output will be not be interleaved.   
      
   almost everything you write is based on your perception as to how to   
   provide output. Clearly you have invested a great deal of thought to how   
   to use printf style output and assumptions you then make as to how it   
   will be implemented.   
      
   Let me respond to just a couple of your points.   
      
   1) The << and >> operators have no meaning outside the context of the C   
   family of languages. That is in marked contrast to mathematical   
   operators (and I wish we had a way to provide new operator symbols so   
   that expressions would look more familiar to domain specialists. Unicode   
   has all the glyphs available and even has a page of mathematical   
   symbols.) Even the logic operators, though sometimes using strange   
   glyphs map to non-computing concepts. However bit shifting and other bit   
   level operations are computer domain specific. That is why I have no   
   problem with them having overloaded meanings that are completely   
   different to the original ones. In addition (though this was not the   
   primary reason for their choice) they are visually appropriate.   
      
   Actually now that I reflect on it, << and >> have sometimes been used in   
   mathematics to mean 'much greater than' and 'much less than' so using   
   them for bit shifts is already a little suspect (to those who wish to   
   confine operator overloading to a single overarching meaning)   
      
   2) I have never had a problem with providing different formats for user   
   defined types depending on context. When writing overloads it is easy to   
   distinguish between various types of I/O stream and change the output   
   appropriately. For example I often want more detailed output to the   
   screen than I do for a data file (think of complex numbers where pairs   
   of values are fine in a data file but where many would want something   
   more in a display.   
      
   If you really need a great deal of variability in output/input and do   
   not want to write your own manipulators (can be quite hard work, but   
   once it is done it can be used forever) you can use inheritance and casting:   
      
   class mytype{   
   // what ever   
   };   
      
   class mytype_to_file: public mytype{}   
      
   ostream & operator << (ostream &, mytype_to_file const &){   
   // provide output formatted for file storage   
   }   
      
   void foo(){   
   // create an object called mt   
   cout << (mytype_to_file)mt;   
   }   
      
   Yes, ugly but it can be polished up considerably and the above is just   
   an outline to show how taking a little time designing and implementing   
   your i/o for a UDT can produce largely self documenting code.   
      
   Francis   
      
      
   --   
         [ 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)