In article <87sjnd3af8.fsf@catnip.gol.com>, Miles Bader   wrote:   
   >   
   >> But do those really help compared with rolling your own?  My point is   
   >> not that they don't work, but what practical benefits they convey.   
   >   
   >Isn't "not needing to roll your own" a pretty significant benefit?   
      
   Not in itself, no.  It is VERY common, and not just in computing,   
   for the complication and effort of using an existing 'solution'   
   to be significantly greater than starting from scratch.  The   
   reasons are usually that the existing solution was designed for   
   something different, is insufficiently flexible, excessively   
   complicated, or is just poorly designed.   
      
   Let's take one simple example:  you are using C++11 parallelism,   
   and portability is essential, what do you do?  None of the STL says   
   anything about that, so you can't even use methods on different   
   entries within a single container, unsynchronised.  That's not   
   nice, and plastering enough synchronisation to make such uses   
   safe (if you use the STL heavily when building other codes) is   
   both serious effort and far too difficult for most people.   
   It's actually EASIER to roll your own, even if you don't have   
   my experience.  Seriously.   
      
   I am dreading the day when C++11 starts to be used, and people   
   start coming to me with parallelism problems.  I expect that a   
   LARGE number will assume that actions on separate element sets   
   in a single container are independent, it will USUALLY work, but   
   the failures will be nightmares to identify.  Actually, I shall   
   probably just decide to retire and leave them to it :-)   
      
   >Even if you're not really using the typical std::vector funtionality   
   >like resizability, iterator functions, etc, it's a great default way to   
   >allocate memory.  Even for this simple functionality, it can cut out a   
   >lot of boilerplate, and increase safety (since any time you use   
   >boilerplate, there's a chance to mess it up)...   
      
   That is very true, but my actual tests indicate that it cuts out   
   (say) 30% of the boiler-plate, but adds (say) 20% that could be   
   avoided in a home-brewed solution.  Worse, the 30% is simpler   
   than the 20% :-(  Of course, I was testing on the slightly less   
   trivial requirements that are typical of large scientific codes,   
   and not just allocating memory.   
      
   >[E.g., you write a matrix class, you need memory for the contents,   
   >right?  Why not use a std::vector?]   
      
   Why bother?  It saves perhaps 5% of the code, and the simplest 5%   
   at that, imposes several inconvenient restrictions, and means   
   that you have the complication of worrying about idiosyncracies   
   in its implementation.   
      
   As I said, I did a few tests doing things both ways, and came to   
   the conclusion that the benefit was small, at best.  Take a look   
   Bjarne's matrix.h and boost::multi_array to see the approach others   
   have taken :-)   
      
      
   Regards,   
   Nick Maclaren.   
      
      
   --   
         [ 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)