Why CLS() has different meanings in C++11 - c++

Question

VS2010 has supported the C++11 partially. I compile the code below in VS2010 RTM. I'm confused why the code CLS() is analyzed to different meanings. In the line "decltype(CLS()) obj1;", the CLS() denotes an class object entity. But in the line "CLS obj2(CLS());", the CLS() denotes a function pointer, which retuns a CLS object with no parameter. Is the behavior expected? Is it described in the standard?
struct CLS
{
int mi;
};
int _tmain(int argc, _TCHAR* argv[])
{
decltype(CLS()) obj1;
obj1.mi = 10;
CLS obj2(CLS());
obj2.mi = 10; // error C2228: left of '.mi' must have class/struct/union
return 0;
}
UPDATE 12/8/2011
Per C++11 7.1.6.2/1, the expected string in the parenthesis is an expression. The compiler just needs to check if the string can be parsed as a valid expression. If yes, the code is well-formed. So for the code “decltype(CLS()) obj1;”, the "CLS()" is treated as a valid expression which denotes a difinition of object.
decltype-specifier:
decltype ( expression )
UPDATE 1/3/2012
Potatoswatter gives the explanation why "CLS obj2(CLS());" is a declaration other than an object definition.
Anything that may be interpreted as either an expression or a declaration is a declaration, however unusual it may be. CLS obj2( CLS() ); declares a function whose parameter type CLS() is a function with no arguments returning CLS, and whose return type is CLS.

Answer 1

Is it expected: Yes
It is known as the "most vexing parse".
CLS obj2(CLS()); // function forward declaration.
CLS obj2 = CLS(); // Creates object zero initialized.
CLS obj2; // Creates object default initialized.

Answer 2

As others have said, this is the Most Vexing Parse. Anything that may be interpreted as either an expression or a declaration is a declaration, however unusual it may be. CLS obj2( CLS() ); declares a function whose parameter type CLS() is a function with no arguments returning CLS, and whose return type is CLS.
For example,
CLS obj2( CLS() ); // forward declaration
CLS obj2( CLS fun() ) { // definition
return fun(); // use unusual functional argument
}
CLS foo() { // define a function to use as unusual argument
return CLS();
}
int main() {
CLS obj2( CLS() ); // still a forward declaration, even in this context!
CLS x = obj2( foo );
}
The solution is to use C++11's uniform initialization:
CLS obj2{ CLS() };
or simply
CLS obj2{};

Answer 3

In the argument of decltype, an expression is expected. The only way of interpreting CLS() as an expression is to parse it as default constructed object of type CLS.
However, in CLS obj2(CLS()) (which BTW works the same way in C++03) there are two possible parses: One as function declaration and one as object definition. As function declaration, the outer parentheses form a parameter list, and the content is expected to specify a parameter (or a list of them) by giving types and optional names. In that parse, CLS() is interpreted as function type.
The other valid parse is as definition of an object. For that parse, of course in the parentheses there has to be an expression (or a list of them), giving the interpretation of CLS() as default-constructed object of type CLS.
Now in C++ there is a rule that if something can be parsed both as a declaration and as a definition, it will be parsed as a declaration. That is, in this case the first interpretation will be used.
This of course gives rise to the question of why the first interpretation is chosen when we would clearly expect the second one here. And the answer is that otherwise it would break C compatibility (and in some cases even our expectations). For example, look at the following line:
int f();
Now you would agree that this declares a function taking no arguments and returning int, right? But it could also be parsed as definition of a default-initialized variable of type int. Thanks to the rule mentioned above, it indeed declares a function returning int.
A rule which gives always the result which one would expect would in the best case be complex, but most probably impossible.
Note that in C++03, an easy way to avoid it for automatic variables would have been to prefix the definition with auto: Since function declarations never start with auto, this would have forced the compiler to interpret it as variable definition. Since the old meaning of auto was removed in C++11, this no longer works (and for non-automatic variables it never worked anyway).