home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,504 of 33,346   
   Kaba to All   
   Re: Why doesn't push_back return an iter   
   24 Jul 12 20:52:25   
   
   From: kaba@nowhere.com   
      
   25.7.2012 4:07, Nevin ":-]" Liber wrote:   
      
   >> In the new data structure you use existing data structures to refer   
   >> to each other in useful ways. Therefore, when you create a part,   
   >> you are not just creating it to be stored and later be traversed as   
   >> part of a sequence (say). Rather, you are creating it to be   
   >> referred to _directly_ (giving you strict constant-time access and   
   >> direct identification for, say, removal).   
   >   
   > Except for list (which is node based), this gets dangerous, as   
   > iterators can be invalidated at the drop of a hat.   
      
   Iterators are not invalidated at the drop of a hat. A data structure   
   specifies rules by which they are invalidated (as the C++ standard   
   also does for its containers). For example, if in a graph data   
   structure I remove a vertex, then also all the edges incident to it   
   are removed.  Then the iterator to the vertex, and the iterators to   
   incident edges are all invalidated. But this isn't a problem;   
   actually, it is the only sensible action. Additionally, this is not   
   about iterators at all: it is about the removal of parts from a data   
   structure. What is removed can not be referred to again, no matter   
   what the technique of referring-to is.   
      
   Out of the STL containers, std::list, std::forward_list, std::set, and   
   std::map are safe in their iterator invalidation. They invalidate only   
   what necessarily needs to be invalidated (e.g. an iterator to the   
   removed element). A graph data structure built using these primitives   
   has the same property.   
      
   The unordered containers need a bit more attention because of their   
   iterator invalidation. The contained parts (the elements, the   
   references) are never invalidated until removal. Here I am unsure what   
   the iterator invalidation actually means in the C++ standard. If I   
   take an iterator to an unordered container before rehashing, can I   
   still dereference it after rehashing (and also get the same element)?   
   If yes, then the unordered containers too are to be included in the   
   basic building blocks of data structures. If no, then the unordered   
   containers are dangerous as you say, since the stored iterators in the   
   data structure can not be used after a rehash.   
      
   Since I have implemented the unordered containers fully, I know that   
   for a chaining-based implementation the answer is naturally yes. But,   
   of course, that does not help much: you need the standard to get   
   portable programs.   
      
   --   
   http://kaba.hilvi.org   
      
      
         [ 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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca