4a3125af   
   In article <0dfbe6d1-fb8c-49d2-849a-6adb4a2484e2@p11g2000yqe.googlegroups.com>,   
   Mathias Gaunard   wrote:   
   >   
   >> Does anyone use the STL (and I mean the STL, not BOOST) for scientific   
   >> programming and, if so, what parts and for what?   
   >   
   > I write software tools for parallel and high-performance numerical   
   > computing, both for research institutes and businesses, and we use STL   
   > and STL-derived techniques.   
      
   STL-derived techniques is another matter - it's the actual library   
   I am interested in.   
      
   > The interesting things we take from are mostly generic algorithms and   
   > higher-order functions.   
      
   Higher-order functions?  I don't follow.   
      
   > We have found, however, that we very often had to roll our own, for   
   > the following reasons:   
   > - the STL can only really deal with 1-dimensional data. Iterators are   
   > not well suited for N-dimensional data, and std::vector isn't either.   
   > - the algorithms are typically not vectorized (which can be done more   
   > or less well by an iterator adaptor) nor parallelized   
      
   Yes, precisely.  Traditional scientific programming has always relied   
   heavily on N-dimensional data, though the use of graph structures is   
   becoming more common (which the STL doesn't help much with, though   
   boost::graph may well).  And parallelism is mere much of scientific   
   programming has been for a couple of decades, and where almost all   
   will be in the future.   
      
   > Scientific programs are usually written by people who are experts in   
   > the science in question but not in software engineering, so they tend   
   > to not be very well-written.   
      
   That is very true :-(   
      
   > C++ especially isn't very forgiving, and needs discipline to design   
   > and write a good and maintainable C++ program.   
      
   That is even more so :-(   
      
   > The more people who write those programs re-use existing tools, the   
   > less likely they are of writing bad code that leaks memory or does   
   > other horrible things.   
      
   Well, yes, maybe, usually, but ....  When they reuse tools to beyond   
   their specification (e.g. use the STL in parallel code), the result   
   is usually worse than is they had written it from scratch.   
      
   The STL isn't very high quality, anyway, which is another problem :-(   
      
      
   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)