From: daniel.kruegler@googlemail.com   
      
   Am 18.01.2013 23:27, schrieb Andy Venikov:   
   >   
   > Basically, there's no way to capture by const reference. So, when an   
   > an object, that is expensive to copy, is captured by reference, but   
   > not intended to be changed, the only option to the lambda writer is   
   > to be diligent and not modify the referenced object.   
      
   Not really, you can also declare a reference to const T to the actual   
   object and capture only this reference, such as:   
      
   void foo() {   
       SomeExpensiveToCopyClass obj;   
       const SomeExpensiveToCopyClass& r = obj;   
         [&r]() { r.mutating(); }; // Error   
   }   
      
      
   > It's a pity though, as we already have "mutable" there.   
      
   The rationale is vice versa: Lambda closures were introduced to   
   simplify function object generation. Since most such function objects   
   have a const operator() overload, this was considered as the default.   
      
   The keyword mutable was introduced here to allow for lambda closures   
   with a non-const operator() overload. The current state is therefore a   
   consistent application of const-rules to lambda closures. It is   
   exactly the same if you would declare your own function object with a   
   pointer or reference member (because the pointer and reference won't   
   be modified).   
      
   > We could qualify the lambda as const, meaning that it's not going to   
   > modify any reference-captured values.   
      
   Theoretically this would be possible. I'm not so sure that this is   
   really a sufficient reason to extend the rules in that way, though.   
      
   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)