From: firstname.dot.lastname@googlemail.com   
      
   On Fri, 01 Feb 2013 00:35:49 -0600, Öö Tiib wrote:   
      
      
   >>   
   >> Being facetious: so that output doesn't get unpleasantly interleaved.   
   >   
   > Ok, it was unexpected to me that someone might want to write to same   
   > file from multiple threads with zero attempts to orchestrate that   
   > process. Locks? Are locks right tool to manage structure of file or to   
   > organize human interface? I consider any interface to be worth slightly   
   > more care than just fighting such outright race conditions and   
   > interleaving.   
      
   Locks do seem like the right tool for preventing output from becoming   
   interleaved. I never seriously considered ostreams to be locked, though.   
   The lack of a lock was just an omission on my part.   
      
   That said, I can see the benefit of having cout and cerr locked enough so   
   that one can do quick debugging dumps from disparate threads without   
   risking race conditions introducing extra bugs.   
      
   > 100Mb text file is "easier to debug" than a SQL database of same size?   
      
   Depends on the kind of data stored in the file or database. Often, yes.   
   There are also many, many more binary formats than just SQL databases.   
   Image files, of which there are a huge variety, straight raw dumps of   
   data and many others.   
      
   SQL databases are great for storing tabular, relational data, especially   
   if there are interesting constraints.   
      
   > That amount of data is comparable with text in hundreds of books. I read   
   > about 2-3 books/week so it would take me couple years to read it.   
      
   I'm not seriously suggesting you slowly read through the entire file. It   
   is easier to verify by inspection that the file is coming out correctly   
   (or what errors are happening) for small amounts of data in a text file   
   compared to a custom binary one.   
      
   > Without proper tools I am lost there. For database there are most tools   
   > one can dream of ... often even integrated into IDEs.   
      
   That's a narrow view of the world. Databases are not the only way of   
   storing data, neither are they the most suitable way of storing every   
   type of data.   
      
      
   >> This is the case where programmer time is important, and text files   
   >> generally save a lot of it. Programmer time is always important: it   
   >> gives the users the choice between being patient for the software to   
   >> finish and not having any software at all.   
   >   
   > The stories that text is always simpler and faster to handle do perhaps   
   > sell well to some pointy-haired boss.   
      
   I doubt anyone would claim that text files are more efficient to handle,   
   but they are often simpler to handle.   
      
   > In reality the guys who screw with   
   > spagetthi that inputs/outputs/modifies yet-another text format work at   
   > least 4 times longer time on it than others who use some database engine   
   > for same goal. The results performance loses about 10:1.   
      
   I could say the same equally well of binary file formats. Doing a simple   
   analysis of the data involves writing a program which makes nontrivial   
   numbers of API calls to some binary file reader, when a 1 line AWK   
   program could have done the same job had it been a text file.   
      
   -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)