From: nevin@eviloverlord.com   
      
   In article ,   
    Seungbeom Kim  wrote:   
      
   > 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.   
      
   Being dependent on order of destruction within a container is rare.  And   
   once you learn you cannot rely on the containers doing it, you deal with   
   it.  If you really need it, you can always make your own destructor   
   enforce it.   
      
   > (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.)   
      
   If we tighten the requirements on the destructor, what should the   
   following do:   
      
   v.clear()   
   v.erase(v.begin(), v.end())   
      
   Should other sequence containers also be changed?  Arguably, people use   
   deques and lists for FIFOs, so they could use the guarantee too.  (On   
   the other hand, you can still make a FIFO with push_front and pop_back.)   
      
   > 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.   
      
   My own feeling is that I wouldn't be opposed to this change, unless   
   library vendors have some compelling reason (such as efficiency) to keep   
   the status quo.   
      
   --   
   Nevin ":-)" Liber     
      
      
         [ 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)