Most vexing parse

<h2 id="occurrence">Occurrence</h2>
<p>The term "most vexing parse" was first used by <a href="/facts/Scott_Meyers/7lEPrl3A">Scott Meyers</a> in his 2001 book <i>Effective STL</i>.<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a>  While unusual in <a href="/facts/C_(programming_language)/Ky2No763">C</a>, the phenomenon was quite common in C++ until the introduction of <a href="/facts/Uniform_initialization/fI3YCoKQ">uniform initialization</a> in <a href="/facts/C%2B%2B11/fI3YCoKQ">C++11</a>.<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a>
</p>
<h2 id="examples">Examples</h2>
<h3>C-style casts</h3>
<p>A simple example appears when a functional cast is intended to convert an expression for initializing a variable:
</p>
void f(double my_dbl) {
  int i(int(my_dbl));
}

<p>Line 2 above is ambiguous.  One possible interpretation is to declare a <a href="/facts/Variable_(computer_science)/VoCKtwml">variable</a> i with initial value produced by <a href="/facts/Casting_(computer_programming)/FuPD945T">converting</a> my_dbl to an int.  However, C allows superfluous parentheses around <a href="/facts/Function_parameter/LcuLbbSq">function parameter</a> declarations; in this case, the declaration of i is instead a function declaration equivalent to the following:
</p>
// A function named i takes an integer and returns an integer.
int i(int my_dbl);

<h3>Unnamed temporary</h3>
<p>A more elaborate example is:
</p>
struct Timer {};

struct TimeKeeper {
  explicit TimeKeeper(Timer t);
  int get_time();
};

int main() {
  TimeKeeper time_keeper(Timer());
  return time_keeper.get_time();
}

<p>The line
</p>
  TimeKeeper time_keeper(Timer());

<p>is ambiguous, since it could be interpreted either as
</p>
<ol><li>a <a href="/facts/Variable_(programming)/VoCKtwml">variable</a> definition for variable time_keeper of class TimeKeeper, initialized with an anonymous instance of class Timer or</li>
<li>a <a href="/facts/Function_declaration/qT8JwG6T">function declaration</a> for a function time_keeper that returns an object of type TimeKeeper and has a single (unnamed) parameter, whose type is a (pointer to a) function<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> taking no input and returning Timer objects.</li></ol>
<p>The <a href="/facts/C%2B%2B_standard/Et0F2qn9">C++ standard</a> requires the second interpretation, which is inconsistent with the subsequent line 10 above. For example, <a href="/facts/Clang%2B%2B/MH7cjC67">Clang++</a> warns that the most vexing parse has been applied on line 9 and errors on the subsequent line 10:<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a>
</p>
$ clang++ time_keeper.cc
timekeeper.cc:9:25: warning: parentheses were disambiguated as a function declaration
      [-Wvexing-parse]
  TimeKeeper time_keeper(Timer());
                        ^~~~~~~~~
timekeeper.cc:9:26: note: add a pair of parentheses to declare a variable
  TimeKeeper time_keeper(Timer());
                         ^
                         (      )
timekeeper.cc:10:21: error: member reference base type 'TimeKeeper (Timer (*)())' is not a
      structure or union
  return time_keeper.get_time();
         ~~~~~~~~~~~^~~~~~~~~

<h2 id="solutions">Solutions</h2>
<p>The required interpretation of these ambiguous declarations is rarely the intended one.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a><a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a>  Function types in C++ are usually hidden behind <a href="/facts/Typedef/kqSR4VXn">typedefs</a> and typically have an explicit <a href="/facts/Reference_(C%2B%2B)/x0JKew2U">reference</a> or <a href="/facts/Pointer_(computer_programming)/fPoNzy9b">pointer</a> qualifier.  To force the alternate interpretation, the typical technique is a different object creation or conversion syntax.  
</p><p>In the type conversion example, there are two alternate syntaxes available for casts: the "C-style cast"
</p>
// declares a variable of type int
int i((int)my_dbl);
<p>or a named cast:
</p>int i(static_cast<int>(my_dbl));
<p>In the variable declaration example, the preferred method (since C++11) is uniform (brace) initialization.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a>  This also allows limited omission of the type name entirely:</p>//Any of the following work:
TimeKeeper time_keeper(Timer{});
TimeKeeper time_keeper{Timer()};
TimeKeeper time_keeper{Timer{}};
TimeKeeper time_keeper(     {});
TimeKeeper time_keeper{     {}};
<p>Prior to C++11, the common techniques to force the intended interpretation were use of an extra parenthesis or copy-initialization:<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a></p>TimeKeeper time_keeper( /*Avoid MVP*/ (Timer()) );
TimeKeeper time_keeper = TimeKeeper(Timer());
<p>In the latter syntax, the <a href="/facts/Copy_constructor_(C%2B%2B)/16xaBsq8">copy-initialization</a> is likely to be <a href="/facts/Optimizing_compiler/JXnv4LUd">optimized out</a> by the compiler.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a>  Since <a href="/facts/C%2B%2B17/B3gKNeER">C++17</a>, this optimization is guaranteed.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a>
</p><h2 id="notes">Notes</h2>

<h2 id="external-links">External links</h2>
<ul><li>Discussion in the C++03 standard final draft (see §8.2 Ambiguity resolution <i>[dcl.ambig.res]</i>): <a href="https://web.archive.org/web/20141113085328/https://cs.nyu.edu/courses/fall11/CSCI-GA.2110-003/documents/c++2003std.pdf">https://web.archive.org/web/20141113085328/https://cs.nyu.edu/courses/fall11/CSCI-GA.2110-003/documents/c++2003std.pdf</a></li>
<li>CppReference on direct initialization (the sort vulnerable to the most vexing parse): <a href="https://en.cppreference.com/w/cpp/language/direct_initialization">https://en.cppreference.com/w/cpp/language/direct_initialization</a> <a href="https://web.archive.org/web/20211213184451/https://en.cppreference.com/w/cpp/language/direct_initialization">Archived</a> 2021-12-13 at the <a href="/facts/Wayback_Machine/nmQ3a6JC">Wayback Machine</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>Meyers, Scott (2001). Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library. Addison-Wesley. ISBN 0-201-74962-9. <a href="0-201-74962-9" target="_blank">0-201-74962-9</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>Coffin, Jerry (29 December 2012). "c++ - What is the purpose of the Most Vexing Parse?". Stack Overflow. Archived from the original on 17 January 2021. Retrieved 2021-01-17. <a href="https://stackoverflow.com/questions/14077608/what-is-the-purpose-of-the-most-vexing-parse" target="_blank">https://stackoverflow.com/questions/14077608/what-is-the-purpose-of-the-most-vexing-parse</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>According 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++.
 <a href="/wiki/Function_object#In_C_and_C++" target="_blank">/wiki/Function_object#In_C_and_C++</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
<li id="fn:4"><p>Lattner, Chris (5 April 2010). "Amazing Feats of Clang Error Recovery". LLVM Project Blog. The Most Vexing Parse. Archived from the original on 26 September 2020. Retrieved 2021-01-17. <a href="https://web.archive.org/web/20200926165432/https://blog.llvm.org/posts/2010-04-05-amazing-feats-of-clang-error-recovery/" target="_blank">https://web.archive.org/web/20200926165432/https://blog.llvm.org/posts/2010-04-05-amazing-feats-of-clang-error-recovery/</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li>
<li id="fn:5"><p>DrPizza; Prototyped; wb; euzeka; Simpson, Homer J (October 2002). "C++'s "most vexing parse"". ArsTechnica OpenForum. Archived from the original on 20 May 2015. Retrieved 2021-01-17. <a href="https://arstechnica.com/civis/viewtopic.php?f=20&t=767929" target="_blank">https://arstechnica.com/civis/viewtopic.php?f=20&t=767929</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li>
<li id="fn:6"><p>Boccara, Jonathan (2018-01-30). "The Most Vexing Parse: How to Spot It and Fix It Quickly". Fluent C++. Archived from the original on 2021-11-25. Retrieved 2021-01-17. <a href="https://www.fluentcpp.com/2018/01/30/most-vexing-parse/" target="_blank">https://www.fluentcpp.com/2018/01/30/most-vexing-parse/</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li>
<li id="fn:7"><p>Stroustrup, Bjarne (19 August 2016). "C++11 FAQ". www.stroustrup.com. Uniform initialization syntax and semantics. Archived from the original on 2021-08-20. Retrieved 2021-01-17. <a href="https://www.stroustrup.com/C++11FAQ.html#uniform-init" target="_blank">https://www.stroustrup.com/C++11FAQ.html#uniform-init</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li>
<li id="fn:8"><p>Boccara, Jonathan (2018-01-30). "The Most Vexing Parse: How to Spot It and Fix It Quickly". Fluent C++. Archived from the original on 2021-11-25. Retrieved 2021-01-17. <a href="https://www.fluentcpp.com/2018/01/30/most-vexing-parse/" target="_blank">https://www.fluentcpp.com/2018/01/30/most-vexing-parse/</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li>
<li id="fn:9"><p>"Myths and urban legends about C++". C++ FAQ. What is copy elision? What is RVO?. Archived from the original on 17 January 2021. Retrieved 2021-01-17. <a href="https://isocpp.org/wiki/faq/myths#copy-elision" target="_blank">https://isocpp.org/wiki/faq/myths#copy-elision</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li>
<li id="fn:10"><p>Devlieghere, Jonas (2016-11-21). "Guaranteed Copy Elision". Jonas Devlieghere. Archived from the original on 2021-11-25. Retrieved 2021-01-17.  Note, however, the caveats covered in Brand, C++ (2018-12-11). "Guaranteed Copy Elision Does Not Elide Copies". Microsoft C++ Team Blog. Archived from the original on 2021-11-25. Retrieved 2021-01-17. <a href="https://jonasdevlieghere.com/guaranteed-copy-elision/" target="_blank">https://jonasdevlieghere.com/guaranteed-copy-elision/</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li>
</ol>

Most vexing parse open-in-new

Most vexing parse