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 31,668 of 33,346   
   Joe Gottman to Nikolay Ivchenkov   
   Re: Why should std::call_once use decay_   
   11 Nov 11 11:29:49   
   
   1b0ac538   
   From: josephgottman@comcast.net   
      
   On 11/11/2011 8:30 AM, Nikolay Ivchenkov wrote:   
   > C++11 - 30.4.4.2 provides the following declaration of std::call_once:   
   >   
   >      template   
   >          void call_once(   
   >              once_flag&  flag,   
   >              Callable&&  func,   
   >              Args&&... args);   
   >   
   > According to 30.4.4.2/2,   
   >   
   >      An execution of call_once that calls its func is an active   
   > execution. An active execution shall call INVOKE(DECAY_COPY   
   > ( std::forward(func)), DECAY_COPY   
   > (std::forward(args))...).   
   >   
   > What is the point in using decay_copy here? Why can't an active   
   > execution just call   
   >   
   >      INVOKE(std::forward(func), std::forward(args)...)   
   >   
   > ?   
   >   
   >   
      
      Most of the functions in the threading library call DECAY_COPY so   
   that they have unique copies of all their parameters.  They start new   
   threads, so they need to have all their parameters to be unshared to   
   avoid race conditions.  call_once is called in the current thread, so   
   this doesn't apply, but it is probably called like the others for   
   consistency.   
      
   Joe Gottman   
      
      
   --   
         [ 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