(Why) Is this an example of a vexing parse? - c++

Question

Is this an example of a vexing parse in C++?
#include <pthread.h>
#include <iostream>
class ScopeLock
{
public:
ScopeLock(pthread_mutex_t& m)
: mrMutex(m)
{
pthread_mutex_lock(&mrMutex);
}
~ScopeLock()
{
pthread_mutex_unlock(&mrMutex);
}
protected:
pthread_mutex_t& mrMutex;
};
class Foo
{
public:
Foo()
{
pthread_mutex_init(&m_, NULL);
}
~Foo()
{
pthread_mutex_destroy(&m_);
}
void Func()
{
ScopeLock(m_); // Is this a vexing parse?
std::cout << __FUNCTION__ << std::endl;
}
protected:
pthread_mutex_t m_;
};
int main(int argc, char* argv[])
{
Foo foo;
foo.Func();
return 0;
}
Output:
>g++ main.cpp
main.cpp: In member function \u2018void Foo::Func():
main.cpp:37:17: error: no matching function for call to 'ScopeLock::ScopeLock()'
ScopeLock(m_);
^
main.cpp:37:17: note: candidates are:
main.cpp:7:3: note: ScopeLock::ScopeLock(pthread_mutex_t&)
ScopeLock(pthread_mutex_t& m)
^
main.cpp:7:3: note: candidate expects 1 argument, 0 provided
main.cpp:4:7: note: ScopeLock::ScopeLock(const ScopeLock&)
class ScopeLock
^
main.cpp:4:7: note: candidate expects 1 argument, 0 provided
I think the compiler fails because it is trying to create a ScopeLock object (named m_) with no ctor arguments, and correctly identifies that the only ScopeLock ctor takes one pthread_mutex_t& as argument -- is that correct?
Why is this a vexing parse, though (if it is)? Why is line 37 not interpreted as creation of an anonymous ScopeLock object with ctor argument m_?
If the above is an example of a vexing parse, why is the below not a vexing parse?
#include <iostream>
#include <string>
class Foo
{
public:
Foo()
{
pStr = "Foo";
}
~Foo()
{
}
void Func()
{
const std::string& rStr = std::string(pStr);
std::cout << rStr << std::endl;
}
protected:
const char* pStr;
};
int main(int argc, char* argv[])
{
Foo foo;
foo.Func();
return 0;
}
Compilation and output:
>g++ main.cpp
>./a.out
Foo
>
The second code block seems very analogous to the first. Why, then does the compiler not treat line 18 as creation of a std::string named pStr with no ctor arguments? The cout of rStr resulting in "Foo" actually shows that an anonymous std::string was created with const char* argument.
I'd be grateful if anyone could shed light here. Thank you.
Update
I just noticed that in the first code block changing this:
ScopeLock(m_); // Is this a vexing parse?
to this:
const ScopeLock& rSl = ScopeLock(m_); // Is this a vexing parse?
results in compilation passing. So something about turning the anonymous object to an rvalue fixes the vexing parse problem? I'm unclear.
On the flip side, in the second code block, changing this:
const std::string& rStr = std::string(pStr);
to this:
std::string(pStr);
compiles just fine. However the resulting cout of pStr is empty. I think this confirms that the compiler is actually creating a std::string named pStr using the default constructor. So actually that is analogous to what it was trying to do in the first code block.
I'd still be grateful if someone could confirm if what I've surmised is correct.

Answer 1

The "canonical" meaning of the "most vexing parse" refers to the ambiguity between object declaration and function declaration.
What you have in your case is a different ambiguity: an ambiguity between object declaration and functional-style cast (more formally: functional notation of explicit type conversion, see 5.2.3). This latter ambiguity is resolved in favor of object declaration. Hence the error. Your code is seen by the compiler as a simple
ScopeLock m_;
which makes it to complain about missing default constructor.
6.8 Ambiguity resolution [stmt.ambig]
1 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 first declarator starts with a (. In those cases the statement is a declaration.
Whether you want to call it another flavor of "most vexing parse" is up to you.
There are many different ways to make the compiler to interpret it as an expression instead of declaration. You can also do it as
0, ScopeLock(m_);
or as
(ScopeLock(m_));

Answer 2

Why is line 37 not interpreted as creation of an anonymous ScopeLock object with ctor argument m_?
It's because the Standard has a rule that if code has structure that can be interpreted as either a declaration or a function call, treatment as the declaration is chosen.
It doesn't worry about whether treatment as a declaration causes an error later.
If you think about it, having a fallback to an entirely different interpretation would cause some very nasty action-at-a-distance results during code maintenance. Imagine if you wrote this code and it was accepted as a function-style-cast, and later someone added a default constructor...

Answer 3

Try to replace
ScopeLock(m_); to ScopeLock s(m_);. The object needed its name.
-
Maybe compiler was seeing ScopeLock(m_) as ScopeLock m_. I compiled with clang, and it showed similar error message.
Following line compiles without any complaint :
void Func()
{
ScopeLock(m)(m_);
std::cout << __FUNCTION__ << std::endl;
}