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