Visual Studio C++ compiler weird behaviour

Question

I'm just curious to know why this small piece of code compiles correctly (and without warnings) in Visual Studio. Maybe the result is the same with GCC and Clang, but unfortunately I can't test them now.

struct T {
    int t;
    T() : t(0) {}
};

int main() {
    T(i_do_not_exist);
    return 0;
}

extremly interesting! the most WTF compiler bug I have ever seen! — David Haim, Dec 22 '15 at 13:36
also *int(i_do_not_exist)* works fine, but with undefined variable warning — c.bear, Dec 22 '15 at 13:37
It also compiles with g++: http://coliru.stacked-crooked.com/a/d8dd5a50af7c888d — NathanOliver, Dec 22 '15 at 13:39
See a similar question: [Is Type(::x); valid?](http://stackoverflow.com/q/24623071/1708801) — Shafik Yaghmour, Dec 22 '15 at 15:25
duplicate of http://stackoverflow.com/questions/24622472/why-do-anonymous-objects-sometimes-require-a-default-constructor — M.M, Dec 23 '15 at 04:26

cpplearner · Accepted Answer · 2015-12-23T04:06:38.510

44

T(i_do_not_exist); is an object declaration with the same meaning as T i_do_not_exist;.

N4567 § 6.8[stmt.ambig]p1

There is an ambiguity in the grammar involving expression-statements and declarations: An expression-statement with a function-style explicit type conversion (5.2.3) as its leftmost subexpression can be indistinguishable from a declaration where the ﬁrst declarator starts with a (. In those cases the statement is a declaration.

§ 8.3[dcl.meaning]p6

In a declaration T D where D has the form

( D1 )

the type of the contained declarator-id is the same as that of the contained declarator-id in the declaration

T D1

Parentheses do not alter the type of the embedded declarator-id, but they can alter the binding of complex declarators.

edited Dec 23 '15 at 04:06

answered Dec 22 '15 at 13:46

cpplearner

13,776
2
47
72

20

I sometimes hate C++... like just now. – HiFile.app - best file manager Dec 22 '15 at 13:49
That's why one should use list initialization `T{i_do_not_exist}` which gives a compiler error. – henje Dec 22 '15 at 19:06
7

Can someone clarify: is this an instance of a "most vexing parse" problem or something unrelated? – user10607 Dec 22 '15 at 20:04
2

@user10607 how about we call it "slightly vexing parse"? It could be "vexing" because it's ambiguous, but it is less vexing than the traditional "most vexing" `T func( U(x), U(y) );` , and perhaps also less vexing than the "somewhat vexing parse" `T func();` – M.M Dec 23 '15 at 04:35

score 17 · Answer 2 · edited Dec 22 '15 at 19:54

Because it defines a variable of type T:

http://coliru.stacked-crooked.com/a/d420870b1a6490d7

#include <iostream>

struct T {
    int t;
    T() : t(0) {}
};

int main() {
    T(i_do_not_exist);
    i_do_not_exist.t = 120;
    std::cout << i_do_not_exist.t;
    return 0;
}

The above example looks silly, but this syntax is allowed for a reason.

A better example is:

int func1();
namespace A
{
   void func1(int);
   struct X {
       friend int (::func1)();
   };
}

Probably other examples could be found.

Visual Studio C++ compiler weird behaviour

2 Answers2

Linked

Related