From: brangdon@cix.compulink.co.uk   
      
   nevin@eviloverlord.com ( Liber) wrote (abridged):   
   > Being dependent on order of destruction within a container is rare.   
      
   Agreed. However, the point remains. Why take away a guarantee from   
   users, albeit one that is needed rarely, if the corresponding freedom   
   isn't needed at all by implementors?   
      
      
   > 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.   
      
   Agreed. We can work around design flaws in the library. Again, why   
   should we need to? No-one has yet produced a convincing argument for   
   it not being a design flaw.   
      
      
   > If we tighten the requirements on the destructor, what should the   
   > following do:   
   >   
   > v.clear()   
   > v.erase(v.begin(), v.end())   
      
   Destroy in reverse index order. Why not?   
      
      
   > Should other sequence containers also be changed?   
      
   Unless there's a good reason not to. For singly-linked lists, for   
   example, it would be impractical. For unordered_map, there is a clue   
   in the name (ie it makes sense not to define the order). For a normal   
   map, which has a well-defined order and may be used as an over-blown   
   vector, then a defined destruction order could be useful.   
      
   -- 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)