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,642 of 33,346   
   =?UTF-8?B?RGFuaWVsIEtyw7xnbGVy?= to All   
   Re: lambda objects not assignable   
   08 Nov 12 15:51:51   
   
   From: daniel.kruegler@googlemail.com   
      
   Am 08.11.2012 19:01, schrieb Vladimir Petrović:   
   > The standard explicitly states that operator= is deleted from the   
   > lambda object's type. What is the rationale for such decision ?   
   > In case everything is captured by value and all types have operator=,   
   > compiler could generate the operator =.   
   >   
   > The issue came up while working with boost's transform itertator and   
   > trying to pass lambda as a functor. Transform iterators shoudl be   
   > assignable. This requires creating a wrapper class around the lambda   
   > that will have operator= which destroys and copy constructs the lambda   
   > member variable.   
   >   
   > Are there any performance issues with this approach, depending on the   
   > specific compiler implementation of lambdas ?   
      
   This is not related to performance, I'm pretty sure. The main reason   
   should be to give implementations enough "degrees of freedom" to allow   
   for robust realizations. It would also restrict the ways how   
   reference-captures could be implemented. To give implementations   
   sufficient freedom to provide "reference-invalidation" test tools within   
   the lambda-expression the special wording was added that says:   
      
   "It is unspecified whether additional unnamed non-static data members   
   are declared in the closure type for entities captured by reference."   
      
   Note also that for the "first shot" there is often the tendency to   
   impose stronger requirements on the user, because once you give too much   
   permissions, it is much more difficult (if not impossible) to undo such   
   a permission. So any defects found in the mental model are harder to   
   fix. Lets give implementations some time to settle and lets look at that   
   question at some later time. If it really turns out that the current   
   user restrictions in regard to assignability are unnecessary, that can   
   be relaxed in the future.   
      
   HTH & Greetings from Bremen,   
      
   Daniel Krügler   
      
      
   --   
         [ 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