From: brangdon@cix.compulink.co.uk   
      
   { Reformatted; please limit your lines to 70 characters -mod }   
      
   francis.glassborow@btinternet.com (Francis Glassborow) wrote   
   (abridged):   
   > Against that background it seems unreasonable to require that a   
   > vector keeps track of the order of construction of its members (that   
   > could get quite complex and impose an overhead on the management of   
   > every vector). If we are not going to track the order of   
   > construction there seems no reason to require destruction in any   
   > particular order. ISTM that destructing in index order is just as   
   > reasonable as destructing in reverse index order as neither would   
   > normally be in reverse order of construction.   
      
   I agree with the first part, but not with the second. Apart from   
   anything else, allowing forward order violates the principle of least   
   surprise. If I have an array of objects, and I replace it with a   
   vector of objects, I just wouldn't expect the order of construction   
   and destruction to change. So far as I can tell, there's no reason for   
   it to.   
      
   Destruction order can be important whenever the destructors have side   
   effects, even if they don't directly refer to other objects in the   
   same collection. For example, an object might register itself with   
   some singly-linked list in its constructor and unregister itself in   
   its destructor. Then destruction in reverse order would avoid the need   
   to traverse the linked list, turning an O(n*n) operation into an O(n)   
   one.   
      
   I agree that in complex cases where the user uses insert() or swap(),   
   this won't hold, but for me these cases are not "normal". Most of my   
   vectors are grown only from the end (or not at all). If I wanted to   
   rely on destruction order, I could probably ensure that reverse index   
   order was what I needed. If not, then I'm no worse off than I am now.   
      
   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.   
      
   Daniel Krügler mentions that changing the order would break most   
   existing implementations. Unless someone can show a reason that   
   implementations do need the freedom, I suspect that's the real reason:   
   early vector implementations got it wrong, and now it's too late to   
   change.   
      
   -- 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)