most-vexing-parse

C++: bizarre occurrence of “Request for member X of Y which is of non-class type Z”

由 删除回忆录丶 提交于 2019-12-14 01:09:32
问题 The following program, compiled with g++ 4.6, yields the error request for member ‘y’ in ‘a2’, which is of non-class type ‘A<B>(B)’ at its last line: #include <iostream> template <class T> class A { public: T y; A(T x):y(x){} }; class B { public: int u; B(int v):u(v){} }; int main() { int v = 10; B b1(v); //works A<B> a1(b1); //does not work (the error is when a2 is used) A<B> a2(B(v)); //works //A<B> a2((B(v))); std::cout << a1.y.u << " " << a2.y.u << std::endl; } As can be seen from the

Strange compiler error when trying to create a temporary object

由 倾然丶 夕夏残阳落幕 提交于 2019-12-12 15:40:16
问题 After I posting this question I tried to reproduce the problem of accidental rvalue creation when creating a scoped RAII object. Now it appears that I can't reproduce it without compiler errors! In the following code sample, in Test::foo() the second ScopedLock creation doesn't compile. The gcc compiler error seems totally wrong. Can anyone explain? struct Mutex { void lock() { } void unlock() { } }; struct ScopedLock { ScopedLock(Mutex & inMutex) : mMutex(inMutex) { mMutex.lock(); }

Avoid the most vexing parse

由 做~自己de王妃 提交于 2019-12-10 17:05:23
问题 How do I get the compiler to create temporaries, use the default constructor on them while not defining a function? struct B {}; template<class T> struct C {}; template<class T,class T1> struct A { A(const T& t,const T1& t1): m_t(t),m_t1(t1) { std::cout << __PRETTY_FUNCTION__ << "\n"; } T m_t; T1 m_t1; }; int main() { A< B , C<B> > a0( B() , C<B>() ); // Function definition A< B , C<B> > a1( B b , C<B> c ); // dito, *at least A(const T& t,const T1& t1) not called } 回答1: You can wrap one of

Is there a way to force the “most vexing parse” to be an error, even on a class by class basis?

由 这一生的挚爱 提交于 2019-12-10 06:10:29
问题 Is it possible (with any modification of class A) to have the following work? i.e., make the most vexing parse an error? class A { }; int main() { A a(); // can this be forced to be an error?? A b; // this should work } 回答1: No modification of the class A will have any effect on how a declaration A a(); is parsed. The parser determines that this is a function declaration before it even bothers to look at the definition of A . In fact the definition of A doesn't even need to be visible to

Most vexing parse with a qualified-id - or not?

由 社会主义新天地 提交于 2019-12-07 06:15:23
问题 Consider: struct Foo { enum { bar }; explicit Foo(int){} }; struct Baz { explicit Baz(Foo){} }; Baz b(Foo(Foo::bar)); // #1 Is line #1 the most vexing parse, even though Foo::bar is a qualified-id and can't possibly be a valid parameter name? Clang and GCC disagree; which compiler is correct? 回答1: Clang is right. Somewhat surprisingly, the grammar for parameter-declaration permits both qualified- and unqualified-id s, because it accepts all declarator s: parameter-declaration: attribute

Why vexing parse in an if condition? [duplicate]

由 早过忘川 提交于 2019-12-06 00:03:08
This question already has an answer here: Declaring class variable inside an if statement 2 answers Consider the code: #include <iostream> struct Foo { Foo(int){} operator bool() const { return true; } }; int main() { if(Foo foo{42}) { std::cout << "ok\n"; } } It compiles fine under gcc5. However, if I replace the line if(Foo foo{42}) with if(Foo foo(42)) I get a compile-time error: error: expected primary-expression before 'foo' What's going on here? There is no vexing parse imo, so why using braces work? The syntax for a condition does not include classic constructor invocation. C++11 §6.4/1

Is there a way to force the “most vexing parse” to be an error, even on a class by class basis?

由 ℡╲_俬逩灬. 提交于 2019-12-05 16:55:13
Is it possible (with any modification of class A) to have the following work? i.e., make the most vexing parse an error? class A { }; int main() { A a(); // can this be forced to be an error?? A b; // this should work } No modification of the class A will have any effect on how a declaration A a(); is parsed. The parser determines that this is a function declaration before it even bothers to look at the definition of A . In fact the definition of A doesn't even need to be visible to parse this statement; A forward declaration is sufficient. However compilers generally have a warning for this

Constructor not returning usable object

由 一曲冷凌霜 提交于 2019-12-04 11:15:26
问题 I have a problem with the constructor, which is not working as I'd expect. If I try to initialize my class like that, it will work and I get a usable object: vector<float> v; MyClass<2> a(v); However, if I try to build a class like below (which should be equivalent) the results are quite unexpected. There is no error message/warning when compiling or running the program. But if you try to use this variable a somewhere and call its methods (for example a.doSomething()), it will crash. I put

most vexing parse prevents in-class initializing a std::vector<int>

由 一曲冷凌霜 提交于 2019-12-04 00:32:19
问题 C++11 allows in-class initialization: struct Foo{ std::vector<std::string> v{3}; // vector of 3 empty strings }; If we wanted to initialize in-class a vector of ints , we would get something else: struct Foo{ std::vector<int> v{3}; // vector of one element with value 3 }; This issue seems to be a limitation of the language, as discussed in previous questions. However, if this were not an in-class initialization, we would be able to use parentheses instead of braces, and get the desired result

Visual Studio C++ compiler weird behaviour

由 ￣綄美尐妖づ 提交于 2019-12-03 08:10:56
问题 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; } 回答1: 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-statement s and declaration s: An
订阅 most-vexing-parse