Most Vexing Parse

The most vexing parse is a counterintuitive form of syntactic ambiguity resolution in the C++ programming language. In certain situations, the C++ grammar cannot distinguish between the creation of an object parameter and specification of a function's type. In those situations, the compiler is required to interpret the line as the latter.

Occurrence

The term "most vexing parse" was first used by Scott Meyers in his 2001 book ''Effective STL''. While unusual in C, the phenomenon was quite common in C++ until the introduction of uniform initialization in C++11.

Examples

C-style casts

A simple example appears when a functional cast is intended to convert an expression for initializing a variable:

void f(double my_dbl)

Line 2 above is ambiguous. One possible interpretation is to declare a variable i with initial value produced by converting my_dbl to an int. However, C allows superfluous parentheses around function parameter declarations; in this case, the declaration of i is instead a function declaration equivalent to the following:

// A function named i takes an integer and returns an integer.
int i(int my_dbl);

Unnamed temporary

A more elaborate example is:

struct Timer ;

struct TimeKeeper ;

int main()

The line

TimeKeeper time_keeper(Timer());

is ambiguous, since it could be interpreted either as
# a variable definition for variable of class , initialized with an anonymous instance of class or
# a function declaration for a function that returns an object of type and has a single (unnamed) parameter, whose type is a (pointer to a) functionAccording to C++ type decay rules, a function object declared as a parameter is equivalent to a pointer to a function of that type. See Function object#In C and C++. taking no input and returning objects.

The C++ standard requires the second interpretation, which is inconsistent with the subsequent line 10 above. For example, Clang++ warns that the most vexing parse has been applied on line 9 and errors on the subsequent line 10:

timekeeper.cc:9:25: parentheses were disambiguated as a function declaration
Wvexing-parse''

timekeeper.cc:9:26: note: add a pair of parentheses to declare a variable

timekeeper.cc:10:21: member reference base type '' is not a
structure or union

Solutions

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"

// declares a variable of type int
int i((int)my_dbl);
or a named cast:

int i(static_cast(my_dbl));
In the variable declaration example, the preferred method (since C++11) is uniform (brace) initialization. This also allows limited omission of the type name entirely:
//Any of the following work:
TimeKeeper time_keeper(Timer);
TimeKeeper time_keeper;
TimeKeeper time_keeper;
TimeKeeper time_keeper( );
TimeKeeper time_keeper;
Prior to C++11, the common techniques to force the intended interpretation were use of an extra parenthesis or copy-initialization:
TimeKeeper time_keeper( /*Avoid MVP*/ (Timer()) );
TimeKeeper time_keeper = TimeKeeper(Timer());
In the latter syntax, the copy-initialization is likely to be optimized out by the compiler. Since C++17, this optimization is guaranteed. Note, however, the caveats covered in

Notes

References

External links

* Discussion in the C++03 standard final draft (see §8.2 Ambiguity resolution '' cl.ambig.res'): https://web.archive.org/web/20141113085328/https://cs.nyu.edu/courses/fall11/CSCI-GA.2110-003/documents/c++2003std.pdf
*CppReference on direct initialization (the sort vulnerable to the most vexing parse): https://en.cppreference.com/w/cpp/language/direct_initialization

{{C++ programming language

C++
Ambiguity
Articles with example C++ code