Most Vexing Parse Confusion: Clarifying the Ambiguity
In C 11, uniform initializers introduce a subtle ambiguity known as "most vexing parse." Let's delve into an example that demonstrates this issue:
<code class="cpp">#include <iostream> class Timer { public: Timer() {} }; int main() { auto dv = Timer(); // What is Timer() ? And what type is dv? int time_keeper(Timer()); // This is a function right? And why isn't the argument " Timer (*) ()"? return 0; }</code>
Analysis:
In the first line:
<code class="cpp">auto dv = Timer();</code>
In the second line:
<code class="cpp">int time_keeper(Timer());</code>
To prove this, consider the following program:
<code class="cpp">#include <type_traits> struct Timer { }; int main() { int time_keeper(Timer()); static_assert( std::is_same< decltype(time_keeper), int(Timer(*)()) >::value, "This should not fire!"); }</code>
This program compiles successfully, confirming that time_keeper takes a pointer to a function as an argument.
In conclusion, the "most vexing parse" confusion stems from the fact that the expression Timer() can be interpreted as either an object of type Timer or a function pointer to a function that returns a Timer. The correct interpretation depends on the context in which the expression is used.
The above is the detailed content of Is \'Timer()\' a function or an object? Understanding the \'Most Vexing Parse\' in C 11.. For more information, please follow other related articles on the PHP Chinese website!