GCC, MSVC and Comeau, all treat "(int())" as a cast to function type and report a "invalid cast" compile error.
The standard has this to say:
// C++ 8.2p2:
// The ambiguity arising from the similarity between a function-style cast and
// a type-id can occur in different contexts. The ambiguity appears as a
// choice between a function-style cast expression and a declaration of a
// type. The resolution is that any construct that could possibly be a type-id
// in its syntactic context shall be considered a type-id.
In the above test case, the construct "int()" cannot be a type-id in its syntactic context, shouldn't it be considered as a function-style cast resulting in no compilation errors ?
You might think that all three compilers doesn't consider the type-id's syntactic context beyond the parentheses, but take a look at this:
void f() {
(int());
}
All 3 compilers now regard "int()" as a function-style cast and report no errors.
That doesn't seem consistent, if the second case is regarded as correct, then the first one should be as well.
In my post, change "function-style cast" to "type construction".
"T()" is a specific case of "T( expression-list[opt] )" described in "5.2.3 Explicit type conversion (functional notation)", and I sometimes tend to think the general case as "function-style cast".
In my post, change "function-style cast" to "type construction".
"T()" is a specific case of "T( expression-list[opt] )" described in
"5.2.3 Explicit type conversion (functional notation)", and I sometimes
tend to think the general case as "function-style cast".
-Argiris
Argiris Kirtzidis wrote:
Hi all,
Here's a test case:
void f() {
int x = (int())+1;
}
This can be interpreted as a cast where 'int()' is a type-id so this
interpretation is favoured.
GCC, MSVC and Comeau, all treat "(int())" as a cast to function type
and report a "invalid cast" compile error.
The standard has this to say:
// C++ 8.2p2:
// The ambiguity arising from the similarity between a
function-style cast and
// a type-id can occur in different contexts. The ambiguity appears
as a
// choice between a function-style cast expression and a
declaration of a
// type. The resolution is that any construct that could possibly
be a type-id
// in its syntactic context shall be considered a type-id.
In the above test case, the construct "int()" cannot be a type-id in
its syntactic context, shouldn't it be considered as a function-style
cast resulting in no compilation errors ?
You might think that all three compilers doesn't consider the
type-id's syntactic context beyond the parentheses, but take a look at
this:
void f() {
(int());
}
In this context 'int()' cannot be a type. Any type at this place
would result in a compilation error so the other interpretation is
taken.