In article ,   
   =?ISO-8859-15?Q?Daniel_Kr=FCgler?=   wrote:   
   >   
   > I'm indeed working with STL components in purely scientific projects   
   > since years. ...   
      
   Thanks very much.  I would like to ask a few specific questions,   
   if I may.   
      
   > associative containers (Often std::map, but arguably most of them are   
   > unordered containers),   
      
   Thanks.  That's what I noted as potentially relevant.   
      
   > a lot of std::vector (internally), std::pair,   
      
   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.   
      
   When writing classes that needed vectors, I discovered that using   
   std::vector didn't simplify the code significantly over ordinary   
   arrays/pointers or provide significant extra checking.  It does free   
   space when writing a simple vector declaration and using exceptions to   
   jump out, but that's about all I found.   
      
   I agree that std::pair could be useful for one-off pairs (not as bases   
   for classes), if one closes one's eyes to the type-matching ambiguities   
   in the standard, but not everyone does that and some people consider   
   it bad practice.   
      
   > IO streams for outputs (IO manipulators),   
      
   Are they really a help compared to ?  I tried hard to use them,   
   found them painful, and then queried it in a C++ expert forum, only to   
   discover that even they found  easier to use and more flexible.   
   Indeed, I found them harder to use than Fortran formatted I/O!   
      
   > std::exceptions   
      
   Yes, if your compiler supports tracebacks and cleaning up when you raise   
   them.  If not, they are just trivial syntactic sugar.   
      
   > std::string   
      
   Yes, but relatively few scientific programmers do much string   
   manipulation.  If they do, obviously they should use that.   
      
   > Further, I'm taking massively advantage of STL algorithms, including   
   > those from numeric.   
      
   Interesting.  Do they really save much complication?  I find that the   
   complexity of setting up an iterator outweighs the benefit for most of   
   them.  For example, calculating the trace of a matrix using accumulate.   
   The number I have looked at where it is significantly simpler to   
   call the algorithms than write out the code (complex transcendentals   
   and sorting excepted) is fairly small.   
      
      
   > When I would restart a new project with a   
   > C++11 library I would have a lot of good usages for the new random   
   > number library   
      
   Be warned: those are not very good classes of generator, and the   
   standard does not specify the quality of implementation.  If your   
   program depends on subtle aspects, and especially if it is parallel as   
   well, they may not be a good solution.   
      
   If anyone wants to look into this area in more depth, a good starting   
   point is Pierre L'Ecuyer's papers.  They are NOT easy reading.  Most   
   Web pages on this topic (and even published papers) are ghastly or   
   worse :-(   
      
      
   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)