The most vexing parse is a counterintuitive ambiguity resolution in C++. In certain situations, the C++ grammar cannot distinguish between initializing an object parameter, declaring an object or declaring a function while specifying the function's return type. In these situations, the compiler is required to interpret the statement as the latter, even though this is rarely the programmer's intention.
The problem originates from backward compatibility constraints imposed by the need for C++ to be a superset of C. C has no concept of object creation, and thus will always parse the code as a function declaration. C++ introduced syntax for object creation that inadvertently coincides with function type declaration in some cases.
The term was first used by Scott Meyers in his 2001 book Effective STL. It was a common problem for C++ versions prior to C++11, which introduced an alternative syntax called uniform initialization that uses braces <code>{}</code> instead of parentheses <code>()</code>, avoiding the syntactic ambiguity.
When an object's raison d'être is nothing more than its construction-destruction side-effects (thus creating the allure not to bind an identifier), as is commonly the case for <code>std::unique_lock</code>, most vexing parse can squelch that intent.
A simple example appears when a functional cast is intended to convert an expression for initializing a variable:
Line 3 above is ambiguous. One possible interpretation is to declare a variable <code>i</code> with initial value produced by converting <code>x</code> to an <code>int</code>. However, C allows superfluous parentheses around function parameter declarations; in this case, the declaration of <code>i</code> is instead a function declaration equivalent to the following:
A more elaborate example is:
Line 12 above is ambiguous: it could be interpreted either as
The C++ standard requires the second interpretation, which is inconsistent with the subsequent line 13. For example, Clang++ warns that the most vexing parse has been applied on line 12 and errors on the subsequent line 13:
timekeeper.cc:12:27: parentheses were disambiguated as a function declaration [-Wvexing-parse]
timekeeper.cc:12:28: note: add a pair of parentheses to declare a variable
timekeeper.cc:13:23: member reference base type is not a structure or union
1 warning and 1 error generated.
The required interpretation of these ambiguous declarations is rarely the intended one. Function types in C++ are usually hidden behind typedefs and typically have an explicit reference or pointer qualifier. To force the alternate interpretation, the typical technique is a different object creation or conversion syntax.
In the type conversion example, there are two alternate syntaxes available for casts: the "C-style cast"
or a named cast:
Another syntax, also valid in C, is to use <code>=</code> when initializing variables:
In the variable declaration example, an alternate method (since C++11) is uniform (brace) initialization. This also allows limited omission of the type name entirely:
Prior to C++11, the common techniques to force the intended interpretation were use of an extra parenthesis or copy-initialization:
In the latter syntax, the copy-initialization is likely to be optimized out by the compiler. Since C++17, this optimization is guaranteed.