In article ,   
   Dave Abrahams   wrote:   
   >   
   >> 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 :-)   
   >   
   > Is your code exception-safe, Nick?  I'm curious, because it's been my   
   > experience that using std::vector is a *major* simplification,   
   > especially when that's not the only resource your class has to manage,   
   > if you're writing exception-safe code.  Try writing a Compressed Sparse   
   > Row matrix both ways and you'll see what I mean.   
      
   I have done worse - I have designed and written code that was safe   
   against asynchronous exceptions!  Yes, it is WAY beyond the ability   
   of most people, and hell even for the few people who can do it.  C++   
   exceptions were originally intended to allow for those to be included,   
   but C++11 took a decision to formally exclude them, though I doubt   
   most people in WG21 took that on board.  The key is transferring   
   exceptions between threads - that is an absolute no-no for such   
   things.   
      
   More generally, when writing code, I rarely use exceptions, precisely   
   because they are so hard to get right.  Since the 1960s, many experts   
   have said that all forms of alternate return (of which C++ exceptions   
   are merely one example) are the spawn of the devil.  I would not go   
   quite so far, but there is something in that.  I generally favour   
   the intermediate state (i.e. supporting trap-diagnose-and-terminate   
   only), which is VASTLY easier to do than trap-recover-and-continue.   
      
   If std::vector WERE exception-safe, I would be more impressed, but   
   I am afraid that it isn't.  The standard specifies that insertion   
   is, but nothing much else - and that, in itself, can't be done if   
   the exception is thrown by a destructor following reallocation!   
   Most of the STL allows more-or-less arbitrary data corruption, by   
   the omission of defined behaviour (see 1.3.12 in C++03).   
      
   This could be improved considerably, especially with regard to   
   parallelism, and there is an outstanding offer from me to help if   
   WG21 were to take on such a project seriously.   
      
      
   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)