C++ most vexing parse

[wcassella]

Hi,

I've been reading about the "most vexing parse" and it looks pretty bad. Take this for example:

int main()
{
    Foo x(Bar());
}

For those unfamiliar, 'x' is not a variable of type 'Foo' constructed with a default object of type 'Bar', but actually a declaration of a function named 'x', which returns a value of type 'Foo' and accepts a pointer to a function that returns a value of type 'Bar'.

So I get why they have to parse things that way, but what I don't get is why the fuck anyone would want to declare a function inside another function! It just doesn't make any sense. Maybe it's some weird holdover back from C which, not having constructors, didn't have any issue with that code. Why don't they just get rid of the ability to do that that, seeing as the use case is so absurd? This wouldn't be the first thing that C++ can't do that C can.

Maybe I'm missing something, but this all seems very silly.

[JLBorges]

> Maybe I'm missing something

Yes. This was fixed in C++11. Foo x { Bar{} };
Uniform initialisation: http://www.stroustrup.com/C++11FAQ.html#uniform-init

[MiiNiPaa]

Why don't they just get rid of the ability to do that that

backward compatibility. Wouldn't be the first thing remaining to allow some C code to work.

why the fuck anyone would want to declare a function inside another function!

Let's say someone want to export function and make it inline (so whole body is in header). THis function calls another function which is implementation detail and newer intended to be exposed to user. So instead of declaring it in header and risking users of header accidentally using it, we declare it in function body, use it and enjoy it never appearing in global namespace.