Why won't this compile without a default constructor?

Question

I can do this:

#include <iostream>

int counter;

int main()
{
    struct Boo
    {
        Boo(int num)
        {
            ++counter;
            if (rand() % num < 7) Boo(8);
        }
    };

    Boo(8);

    return 0;
}

This will compile fine, my counter result is 21. However when I try to create the Boo object passing the constructor argument instead of an integer literal I get a compile error:

#include <iostream>

int counter;

int main()
{
    struct Boo
    {
        Boo(int num)
        {
            ++counter;
            if (rand() % num < 7) Boo(num); // No default constructor 
                                            // exists for Boo
        }
    };

    Boo(8);

    return 0;
}

How is a default constructor called in the second example but not in the first example? This is error I get on Visual Studio 2017.

On the online C++ compiler onlineGDB I get the errors:

error: no matching function for call to ‘main()::Boo::Boo()’
    if (rand() % num < 7) Boo(num);

                           ^
note:   candidate expects 1 argument, 0 provided

Galoot

@NeilButterworth I'm aware of the most vexing parse, but it didn't strike me as a case of it because I was passing local variable to the constructor, and thought that this was not ambiguous because I didn't see it as ambiguous when passing a local variable identifier. user10605163's answer is enlightening as it explains that types or non-types are not used in disambiguation. I don't know anything about the upvotes other than that I upvoted both answers as I found them helpful. You can close this if this is dupe. – Galoot

@NeilButterworth: "Any problems with these proposals?" Because the most-vexing parse is usually presented as a competition between creating a temporary and declaring a function. This is instead treated as creating a variable. Similar idea, similar resolution, but ultimately a different source. – Lamanna

@Nicol "Any problems with these proposals?" - um, what? Where? – Orthopterous

@NeilButterworth: That was a copy-and-paste error. That was supposed to be a reply to "Is there any reason I should not close this as a "most vexing" dupe?". As to the upvoting, I don't see what's so surprising about it. It's an unexpected manifestation of the most-vexing parse, so that gives it at least some credibility as a useful question. – Lamanna

I upvoted the question and answers because I learned something new. I was aware of the most-vexing parse, and this manifestation of it was different enough from previous ones I've seen. The answers were helpful, and the workarounds were interesting. – Colburn

What is that code supposed to do anyway? Call the constructor like a function? – Stale

@NicolBolas The source of the error usually doesn't matter. If all answers to one question can be posted to another they can be closed as duplicate. --- duplicate closure serves as signposts – Spinous

@user202729: But they aren't. Simply saying "most vexing parse" doesn't answer the question. You have to explain how it is a "most vexing parse". And that requires explaining that it's trying to declare a variable in this case, but a function in other cases. Those are different things, for different reasons, and thus have to be different answers. – Lamanna

lol +45 votes for a MVP, seriously – Museology

@Museology Yes, this site confuses me. I asked this because I thought the issue of MVP was resolving whether something was a function signature or the creation of an object. In the words of the guy who coined the term "if it can be a function declaration, it is.” I didn't see how Boo('identifier') could be a function declaration, and I still don't. The answer has cleared up what the actual problem is. It seems not all people are in agreement as to what MVP is exactly. One example is some people saying int a(5); in a class definition is MVP, others say it isn't, but just disallowed by the language. – Galoot

Yeah some people have a narrower definition of MVP, others (including me) use it for any case where the person intended an expression but the code was actually parsed as a declaration. the int a(5); thing seems entirely unrelated – Museology

Answer 1

Clang gives this warning message:

<source>:12:16: warning: parentheses were disambiguated as redundant parentheses around declaration of variable named 'num' [-Wvexing-parse]
            Boo(num); // No default constructor 
               ^~~~~

This is a most-vexing parse issue. Because Boo is the name of a class type and num is not a type name, Boo(num); could be either the construction of a temporary of type Boo with num being argument to Boo's constructor or it could be a declaration Boo num; with extra parentheses around the declarator num (which declarators may always have). If both are valid interpretations, the standard requires the compiler to assume a declaration.

If it is parsed as declaration, then Boo num; would call the default constructor (the constructor without arguments), which isn't declared either by you or implicitly (because you declared a another constructor). Therefore the program is ill-formed.

This is not an issue with Boo(8);, because 8 cannot be a variable's identifier (declarator-id), so it is parsed as a call creating a Boo temporary with 8 as argument to the constructor, thereby not calling the default constructor (which is not declared), but the one you defined manually.

You can disambiguate this from a declaration by either using Boo{num}; instead of Boo(num); (because {} around the declarator is not allowed), by making the temporary a named variable, e.g. Boo temp(num);, or by putting it as an operand in another expression, e.g. (Boo(num));, (void)Boo(num);, etc.

Note that the declaration would be well-formed if the default constructor was usable, because it is inside the if's branch block scope rather than the function's block scope and would simply shadow the num in the function's parameter list.

In any case it doesn't seem a good idea to misuse temporary object creation for something that should be a normal (member) function call.

This particular type of most-vexing parse with a single non-type name in the parenthesis can only happen because the intend is to create a temporary and immediately discard it or alternatively if the intend is to create a temporary used directly as an initializer, e.g. Boo boo(Boo(num)); (actually declares function boo taking a parameter named num with type Boo and returning Boo).

Discarding temporaries immediately is usually not intended and the initializer case can be avoided using brace-initialization or double-parantheses (Boo boo{Boo(num)}, Boo boo(Boo{num}) or Boo boo((Boo(num)));, but not Boo boo(Boo((num)));).

If Boo wasn't a type name, it could not be a declaration and no problem occurs.

I also want to emphasize that Boo(8); is creating a new temporary of type Boo, even inside the class scope and constructor definition. It is not, as one might erroneously think, a call to the constructor with the caller's this pointer like for usual non-static member functions. It is not possible to call another constructor in this way inside the constructor body. This is only possible in the member initializer list of the constructor.

---

This happens even though the declaration would be ill-formed due to missing constructor, because of [stmt.ambig]/3:

The disambiguation is purely syntactic; that is, the meaning of the names occurring in such a statement, beyond whether they are type-names or not, is not generally used in or changed by the disambiguation.

[...]

Disambiguation precedes parsing, and a statement disambiguated as a declaration may be an ill-formed declaration.

---

Fixed in edit: I overlooked the declaration in question being in a different scope than the function parameter and the declaration therefore being well-formed if the constructor was available. This is not considered during disambiguation in any case. Also expanded on some details.

Chickpea

Thanks for your answer, that makes sense if it's a type of vexing parse problem. What I don't get is that num is a local variable, and don't see how this could be mistaken for a type, which is usually when the vexing parse problem comes up I think. – Galoot

@Galoot I added the paragraph of the standard which seems to be responsible. It is not mistaken for a type. It is used as a variable name and the only confusion seems to be that the name is already declared in the scope with different type. – Chickpea

I see. So it seems it allows Boo(8) not so much because 8 is unambiguous with respect to an argument, but more because 8 can't be the name of an identifier for an object, if I understand right. – Galoot

Yes that is correct. The issue also does not exist if the temporary Boo(...) is used inside another expression, because then it cannot be a declaration statement. You are only seeing this weird case because you are creating unnamed temporaries and then immediately discarding them again. Simply don't do that. – Chickpea

+1 to clang for actually including the words "vexing-parse" in the warning. two improvements to clang would be using the actual words "most-vexing-parse" and to actually say instead: "google most vexing parse" - now that would be an excellent warning message! – Deutschland

Been coding in C/C++ for so long and never would have guessed int(x)=5; is valid syntax... Vexing indeed. – Incorrupt

@Apollys There is a talk from this year's CppCon listing some of the unexpected results and difficulties of C++ parsing rules. This particular type of problem with parentheses around declarators is discussed starting at 18:05. – Chickpea

Or another talk by the same guy very short here – Indoaryan

Should not have watched that in my office, almost died trying to hold in my laughter... – Incorrupt

Answer 2

This is known as the most vexing parse (The term was used by Scott Meyers in Effective STL).

Boo(num) does not invoke the constructor nor does it create a temporary. Clang gives a good warning to see (even with the right name Wvexing-parse):

<source>:12:38: warning: parentheses were disambiguated as redundant parentheses around declaration of variable named 'num' [-Wvexing-parse]

So what the compiler sees is equivalent to

Boo num;

which is a variable decleration. You declared a Boo variable with name num, which needs the default constructor, even though you wanted to create a temporary Boo-object. The c++ standard requires the compiler in your case to assume this is a variable declaration. You might now say: "Hey, num is an int, don't do that." However, the standard says:

The disambiguation is purely syntactic; that is, the meaning of the names occurring in such a statement, beyond whether they are type-names or not, is not generally used in or changed by the disambiguation. Class templates are instantiated as necessary to determine if a qualified name is a type-name. Disambiguation precedes parsing, and a statement disambiguated as a declaration may be an ill-formed declaration. If, during parsing, a name in a template parameter is bound differently than it would be bound during a trial parse, the program is ill-formed. No diagnostic is required. [ Note: This can occur only when the name is declared earlier in the declaration. — end note  ]

So there is no way out of this.

For Boo(8) this cannot happen, as the parser can be sure this is not a decleration (8 is not a valid identifier name) and invokes the constructor Boo(int).

By the way: You can disambiguate by using enclosing parentheses:

 if (rand() % num < 7)  (Boo(num));

or in my opinion better, use the new uniform initialization syntax

if (rand() % num < 7)  Boo{num};

Which will then compile see here and here.

Indoaryan

You're quoting the wrong section and "requires the compiler in your rcase to assume this is a function declaration" is not true, since num is not a function but a variable. – Swastika

Thanks for spotting, will have to fix it later. – Indoaryan

There is no such thing as "a call to the constructor" in the manner you describe; the intent was an utterance of a functional-cast to create a temporary; the syntax to do this looks a bit like a "constructor call" but in fact no such thing is syntactically (or semantically) possible. There are a few scenarios in which a constructor is invoked but these are all triggered for you by the language when you do other things. – Theatrics

@LightnessRacesinOrbit Correct. Fixed it. Thanks for taking the time and help improving the answer. – Indoaryan

It's kind of embarrasing that Boo (num) compiles; probably should have been a syntax error with only Boo (num)() allowed. – Hybridize

@Hybridize Wouldn't Boo (num)() be a function? – Cecilececiley

@curiousguy: It would be a forward declaration of a function, yes. My personal opinion is allowing parens there when not declaring a function, pointer to function, or reference to function (and the second two require the parens) is the mistake. – Hybridize

Answer 3

Here is clang warning

truct_init.cpp:11:11: error: redefinition of 'num' with a different type: 'Boo' vs 'int'

Exuberance