is "result" a reserved name ?

[OReubens]

class foo
{
	int wesult;
	int result;

	template<class Pred>
	void call(Pred pred)
	{
		Pred();
	}

	void test()
	{
		call([&](){ wesult=1; result=1; });
	};
};

In the lamda function, I am apparently allowed to access/change a variable named wesult, but when I have a variable named result, I get a weird error:

1>c:\test\test.cpp(19): error C2326: 'void `anonymous-namespace'::<lambda0>::operator ()(void) const' : function cannot access 'foo::result'
1>c:\test\test.cpp(19): error C2166: l-value specifies const object

This is with VS2010.
Is 'result' a reserved keyword when used in combination with lambda's ? or is this some weird error ?

If I remove/comment out the result=1; then it compiles and runs normally.

Can anyone give this a try in VS2012 ?

[GCDEF]

Seems like an easy way to find out would be to call it something else and try again.

[VladimirF]

But he did - called it "wesult" and it worked...

[OReubens]

indeed. it works if I rename "result" to anything I tried so far. So is this a bug, or is "result" something special in this case ? A new/planned keyword for which (partial ?) support is present already ?

[Igor Vartanov]

According to the C++ Keywords result is not one.

[superbonzo]

in VS2010, with the exact code you posted I cannot reproduce the problem. It just gives me an error saying that Pred has no default ctor, as expected. Is that a typo ? anyway, replacing "Pred()" with "pred()" as it's probably meant to be, it just compiles fine ...

[Philip Nicoletti]

in VS2010, with the exact code you posted I cannot reproduce the problem. It just gives me an error saying that Pred has no default ctor, as expected. Is that a typo ? anyway, replacing "Pred()" with "pred()" as it's probably meant to be, it just compiles fine ... :confused:

I think that you actually need to use to function to generate the
compile error (after making test() public).

int main()
{
   foo fobj;
   fobj.test();
}

[cilu]

Reproduced with VS2010. No problem with VS 2012 RC.

However, I get a different result:

1>vs2010_win32_test.cpp(54): error C2326: 'void `anonymous-namespace'::<lambda0>:perator ()(void) const' : function cannot access 'foo::result'
1>vs2010_win32_test.cpp(54): error C3491: '__this': a by-value capture cannot be modified in a non-mutable lambda

I guess C3491 is key here, because the following works correctly:

	void test()
	{
		call([=](){ this->result=1; });
	};

Notice that in VS2012 that is not necessary to specify = for capturing this by value, since this is always captured by value.

[superbonzo]

I think that you actually need to use to function to generate the
compile error (after making test() public).

no, foo is not a class template and test is an ordinary member function. The compiler is required to instantiate the call<> template when parsing the test() body, so no need to "use" the function. In any case, in my vs2010 copy the code:

class foo
{
	int wesult;
	int result;

	template<class Pred>
	void call(Pred pred)
	{
		pred();
	}
public:
	void test()
	{
		call([&]{ wesult=1; result=1; });
	};
};

int main()
{
   foo fobj;
   fobj.test();
}

compiles fine as well.

[Philip Nicoletti]

Strange ... the code you posted also compiles on my system.

My code was identical to yours, except I had an

#include <iostream>

at the top, which causes the compile error:

[quote]
1>Source1.cpp(16): error C2326: 'void `anonymous-namespace'::<lambda0>::operator ()(void) const' : function cannot access 'foo::result'
1>Source1.cpp(16): error C2166: l-value specifies const object
[/code]

16 .. is the "result = 1;" line

[superbonzo]

Strange ... the code you posted also compiles on my system. My code was identical to yours, except I had an

ok, for the sake of curiosity, I've traced back the problem into iostream; it's surely a compiler bug involving name lokup:

typedef int whatever;

class foo
{
	int whatever;

	template<class Pred>
	void call(Pred pred);

	void test() { call([this]{ whatever = 1; }); }
};

the above reproduces the error as well; note that if you place the typedef inside a struct you still get the same result ( this is what happens deep inside <iostream> ), in no way this can be legal. BTW, yet another workaround is to write foo::whatever ...

[OReubens]

Took some digging further into this matter via Microsoft, and it is confirmed to be a name lookup issue in VS2010. The issue is apparently (but I can't test this atm) resolved in VS2012.

[cilu]

I've tested with VS2012 RC and is fixed indeed.