Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > closure type for lambda-expressions and constness

Reply
Thread Tools

closure type for lambda-expressions and constness

 
 
Paul Bibbings
Guest
Posts: n/a
 
      04-20-2010
I'm currently trying to cememt my understanding of n3091
[expr.prim.lambda]. In particular, however, I'm wanting to be sure that
I understand how the constness of the closure type's public function
call operator affects the viability of assignments within its function
body, depending upon whether capture occurs by copy or by reference.

In §5.1.2/5 it says that "This function call operator is declared const
if and only if the lambda-expression's parameter-declaration-clause is
not followed by mutable."

Now, for objects captured by copy the situation appears clear. In
§5.1.2/14 it says "For each entity captured by copy, an unnamed
non-static data member is declared in the closure type." In this
instance it is easy to understand that such unnamed non-static data
members may not be assigned to in the body of the function call operator
on an object of closure type that is not declared mutable.

So, in the following - forgetting for the moment that the `algorithm'
itself fails simply because it has selected capture by copy - the code
fails on the grounds that it omits to add mutable after the
lambda-expression's parameter-declaration-clause:

#include <algorithm>

int main()
{
double d_array[] = { 1.1, 2.2, 3.3, 4.4 };
double sum = 0;
std::for_each(d_array,
d_array + 4,
[=](double d) { // error: not mutable
sum += d;
});
}

What is not clear to me from the specific wording, however, is how this
should behave if we `correct' the code to fit the algorithm and specify
a default capture-by-reference in the lambda-introducer.

Intuitively I would expect the following to be okay:

#include <algorithm>

int main()
{
// as before

std::for_each(d_array,
d_array + 4,
[&](double d) { // OK: not mutable?
sum += d;
});
}

and certainly gcc-4.5.0 agrees:

21:47:59 Paul Bibbings@JIJOU
/cygdrive/d/CPPProjects/CLCPPM $i686-pc-cygwin-gcc-4.5.0 -std=c++0x
-pedantic -c non_mutable_lambda.cpp

21:48:32 Paul Bibbings@JIJOU
/cygdrive/d/CPPProjects/CLCPPM $

However, I then notice where it says - in §5.1.2/15:
"It is unspecified whether additional unnamed non-static data members
are declared in the closure type for entities captured by reference."

To my reading, this appears to introduce an ambiguity over whether the
second example above is valid or not since, where this were to be the
case - that is, where additional non-static data members /are/ declared
for entities captured by reference - it would appear that the assignment
in the function body should fail on the same grounds as for the case of
capture by copy - that it constituted an attempt to assign to a member
of an object of const closure type.

So, any clarification on this point would be accepted gratefully.

Regards

Paul Bibbings
 
Reply With Quote
 
 
 
 
SG
Guest
Posts: n/a
 
      04-21-2010
On 20 Apr., 23:06, Paul Bibbings wrote:
> [...]
> * * * double sum = 0;
> * * * std::for_each(d_array,
> * * * * * * * * * * d_array + 4,
> * * * * * * * * * * [=](double d) { *// error: not mutable
> * * * * * * * * * * * *sum += d;
> * * * * * * * * * * });
> [...]
> double sum = 0;
> std::for_each(d_array,
> d_array + 4,
> [&](double d) { // OK: not mutable?
> sum += d;
> });
>
> and certainly gcc-4.5.0 agrees:
>
> * *21:47:59 Paul Bibbings@JIJOU
> * */cygdrive/d/CPPProjects/CLCPPM $i686-pc-cygwin-gcc-4.5.0 -std=c++0x
> * * * -pedantic -c non_mutable_lambda.cpp
>
> * *21:48:32 Paul Bibbings@JIJOU
> * */cygdrive/d/CPPProjects/CLCPPM $
>
> However, I then notice where it says - in §5.1.2/15:
> * *"It is unspecified whether additional unnamed non-static data
> members*are declared in the closure type for entities captured
> by reference."
>
> To my reading, this appears to introduce an ambiguity over whether the
> second example above is valid or not since, where this were to be the
> case - that is, where additional non-static data members /are/ declared
> for entities captured by reference - it would appear that the assignment
> in the function body should fail on the same grounds as for the case of
> capture by copy - that it constituted an attempt to assign to a member
> of an object of const closure type.


Keep in mind that a reference itself is inherently constant. Once
initialized, it cannot be made to refer to a different object. The
object that is referred to can still be modified even if the reference
is a non-static member and the member function that does so is const:

class foo {
int& ref;
public:
explicit foo(int&r) : ref(r) {}
void blank() const { ref=0; }
// ^^^^^ OK
};

I think the purpose of the text you quoted is simply to allow the
compiler to generate "smaller" closure types. Instead of a reference
member for each function-local variable from the surrounding scope
that is captured by reference, a compiler might include a single
pointer to the "stack frame" and access the objects through this
pointer via fixed offsets. Whether the closure type includes reference
members or just a stack pointer is unspecified. But it doesn't change
the fact that the lambda object's function call operator can modify
variables that have been captured by reference even without the
mutable keyword. Just like pointers, references don't propagate top-
level constness down to the pointee.

Cheers,
SG
 
Reply With Quote
 
 
 
 
Paul Bibbings
Guest
Posts: n/a
 
      04-22-2010
SG <(E-Mail Removed)> writes:

> On 20 Apr., 23:06, Paul Bibbings wrote:
>> [...]
>> double sum = 0;
>> std::for_each(d_array,
>> d_array + 4,
>> [=](double d) { // error: not mutable
>> sum += d;
>> });
>> [...]
>> double sum = 0;
>> std::for_each(d_array,
>> d_array + 4,
>> [&](double d) { // OK: not mutable?
>> sum += d;
>> });
>>
>> and certainly gcc-4.5.0 agrees:
>>
>> 21:47:59 Paul Bibbings@JIJOU
>> /cygdrive/d/CPPProjects/CLCPPM $i686-pc-cygwin-gcc-4.5.0 -std=c++0x
>> -pedantic -c non_mutable_lambda.cpp
>>
>> 21:48:32 Paul Bibbings@JIJOU
>> /cygdrive/d/CPPProjects/CLCPPM $
>>
>> However, I then notice where it says - in §5.1.2/15:
>> "It is unspecified whether additional unnamed non-static data
>> members*are declared in the closure type for entities captured
>> by reference."
>>
>> To my reading, this appears to introduce an ambiguity over whether the
>> second example above is valid or not since, where this were to be the
>> case - that is, where additional non-static data members /are/ declared
>> for entities captured by reference - it would appear that the assignment
>> in the function body should fail on the same grounds as for the case of
>> capture by copy - that it constituted an attempt to assign to a member
>> of an object of const closure type.

>
> Keep in mind that a reference itself is inherently constant. Once
> initialized, it cannot be made to refer to a different object. The
> object that is referred to can still be modified even if the reference
> is a non-static member and the member function that does so is const:
>
> class foo {
> int& ref;
> public:
> explicit foo(int&r) : ref(r) {}
> void blank() const { ref=0; }
> // ^^^^^ OK
> };
>
> I think the purpose of the text you quoted is simply to allow the
> compiler to generate "smaller" closure types. Instead of a reference
> member for each function-local variable from the surrounding scope
> that is captured by reference, a compiler might include a single
> pointer to the "stack frame" and access the objects through this
> pointer via fixed offsets. Whether the closure type includes reference
> members or just a stack pointer is unspecified. But it doesn't change
> the fact that the lambda object's function call operator can modify
> variables that have been captured by reference even without the
> mutable keyword. Just like pointers, references don't propagate top-
> level constness down to the pointee.


Of course. Thank you.

That makes perfects sense, now (or should I say, again; I know this, but
for some reason, the central point you make in your last sentence just
seems to want to take a vacation from my memory every once in a
while.

Regards

Paul Bibbings

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
reference counting and constness Marcel Müller C++ 3 12-28-2012 04:28 PM
constness and inheritance sndive@gmail.com C++ 2 07-27-2007 07:57 AM
Constness of the container of shared_ptr and the constness of it elements PengYu.UT@gmail.com C++ 14 04-04-2006 01:57 AM
reference to reference and constness problems with bind1st Marc C++ 6 07-06-2004 02:01 PM
Perl hangs when returning lvalue closure from another lvalue closure Julian Mehnle Perl Misc 0 07-17-2003 03:13 PM



Advertisments