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,321 of 33,346   
   Seungbeom Kim to Zoltan Juhasz   
   Re: Broken interaction between std::prio   
   21 May 12 06:18:49   
   
   From: musiphil@bawi.org   
      
   On 2012-05-20 21:19, Zoltan Juhasz wrote:   
   >   
   > I am not sure if combining top and pop is essentially bad, for   
   > example if you are dealing with thread-safe queue or stack,   
   > combining pop and top is a well-known way to eliminate inherent   
   > race-conditions on the container's interface, I guess the question   
   > is how do you combine them, for example:   
   >   
   > value_type faulty_pop()   
   > {   
   >   auto e = move_if_noexcept( internal_top() );   
   >   internal_pop();   
   >   return e;   
   > }   
   >   
   > does not provide strong exception guarantees, b/c when you return 'e',   
   > an exception might occur, and at that point you've changed the   
   > container in an irreversible way.   
      
   Can't we enable that function only for value_types with a non-throwing   
   move constructor?   
      
   > The pop( value_type& e ), on the other hand, does not suffer from   
   > these kind of problems;   
      
   But then you need to default construct an object of value_type and   
   ask the top element to be move-assigned to it. It may not be always   
   possible or desirable to default construct such an object, just to   
   be overwritten later.   
      
   This signature reminds me of the "hack" of using reference parameters   
   for what should semantically be return values just to avoid expensive   
   copying:   
      
        void get_some_large_value(vector& result);   
      
        vector result;   
        get_some_large_value(result);   
      
   I thought that it was ugly, and that finally with C++11 we wouldn't need   
   it any more. And this thread seems to suggest that we still need it. :(   
      
   > until now, there were no reason to provide   
   > such an overload, since top() + pop() provides the same functionality.   
      
   That was because of the possible exception during copying that may break   
   exception safety. If we don't copy but just move without exceptions, or   
   even if we do copy but it is guaranteed not to throw, then the two don't   
   really to be separated. In fact, as you mentioned, there are situations   
   where we want them to be combined.   
      
   --   
   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)   

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


(c) 1994,  bbs@darkrealms.ca