8e8a0bf1   
   From: musiphil@bawi.org   
      
   On 2012-06-06 17:02, Christopher Dearlove wrote:   
   > 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, even if it   
   > weren't for all the examples that show problems.   
      
   A user sensible enough could start something with an array, and then   
   later decide to switch to a vector. If a complex program crashes just   
   after switching from an array to a vector, the user will have to spend   
   a good amount of time debugging it in frustration.   
      
   (Indeed, lots of literature teach readers that they should avoid   
   raw arrays and substitute container classes wherever possible   
   because "arrays are evil", encouraging such switches.)   
      
   I agree that having containers remember the construction order is   
   asking too much, but I also agree that destruction in forward order   
   violates the principle of least surprise, though the degree of surprise   
   might be disagreed on.   
      
   > The original code was well-designed as a demonstration of the point   
   > being made, but not in any other way.   
      
   It's just how a problem buried in a complex real-world situation is   
   reduced to its essence and presented to others, as they'd better be.   
   Such a reduced form may of course seem unrealistic and artificial,   
   but it doesn't mean the problem is irrelevant.   
      
   > 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".   
      
   The OP's example fails for a reason that has nothing to do with   
   the container requirements. Presumably, a container requirement   
   violation would be much easier to diagnose and debug.   
      
   --   
   Seungbeom Kim   
      
      
         [ 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)