8e8a0bf1   
   From: brangdon@cix.compulink.co.uk   
      
   christopher.dearlove@googlemail.com (Christopher Dearlove) wrote (abridged):   
   > On Jun 2, 1:53 pm, brang...@cix.compulink.co.uk (Dave Harris) wrote:   
   > > It seems to me leaving destruction order implementation defined,   
   > > is giving the implementation a freedom that it doesn't need, while   
   > > taking away a guarantee that users sometimes do need.   
   >   
   > I don't see any sensible user needing that guarantee,   
      
   Why was my example not sensible? In this case it's not so much   
   "needing", as being least surprising and most efficient. Destruction   
   in reverse order is O(N), destruction in forward order still works   
   but is O(N*N) because of extra list traversal.   
      
   Francis Glassborow seemed to imply that destruction order was   
   important only when the elements reference each other. My example   
   was of a case where they don't. Another example would be if the   
   elements held locks, and unlocking them in the wrong order could   
   lead to deadlocks. In any case where the destructors have visible   
   side-effects, destruction order could matter.   
      
      
   > even if it weren't for all the examples that show problems.   
      
   The only problems concerned the difficulty of tracking construction   
   order in the face of swaps and insertions. I don't think anyone   
   actually advocated that: it's a straw doll. The suggestion is   
   simply destruction in reverse index order. No-one has posted an   
   example showing problems with that.   
      
      
   > The original code was well-designed as a demonstration of the   
   > point being made, but not in any other way.   
      
   What was ill-designed about my code?   
      
      
   > And I for one would need to dig into the standard in order   
   > to determine if such a class even satisfied the copyable etc.   
   > requirements for an object to put into a vector (as std:auto_ptr,   
   > for example, doesn't). And that's a pretty good warning (to me   
   > at least) to "don't do that".   
      
   My class would be copyable and movable. Why wouldn't it be? You seem   
   to be inventing faults which aren't there.   
      
   -- Dave Harris, Nottingham, UK.   
      
      
   --   
         [ 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)