Subtle syntax error in default parameter not caught by compiler

Question

I started getting the error, "error C2059: syntax error : 'default argument'" for a line of code that declared a function with a string argument that was given a default parameter. This was obviously a bit frustrating, as the error message was not exactly enlightening (I know it's a 'default argument'!), and the exact declaration would work elsewhere.

After shifting about the declaration a bit, I found its position in its containing class actually had an effect. Narrowing it down, I found that I was declaring a different function somewhat erroneously, by including a semicolon after one of its default parameters. The compiler seemed perfectly fine with that, which seemed a bit odd. I investigated a bit more, and came up with the following test case to try to figure out the essence of what was going on:

enum TestEnum1
{
   TEST_ONE
};
class TestClass
{
public:
   enum TestEnum2
   {
      TEST_TWO,
      TEST_THREE,
      TEST_FOUR
   };
   void Func1( int iParm = TEST_ONE; ); // additional semicolon here
   void Func2( std::string strParm = "" );
};

As the code above stands, Func2 will produce the compilation error I mentioned above. If I move Func2 above Func1, then everything compiles fine.

If I switch the default parameter in Func1 to an explicit number or use an enum declared within TestClass, then I get an expected syntax error for that line.

So essentially, the strange thing seems to be that if I set a default parameter's value to an enum not defined directly in the current class and am a little too semicolon-happy, the compiler will ignore the syntax error, until some other seemingly-unrelated thing finally causes the parser to die in a very inscrutable way.

Am I just missing something completely? Is this expected behavior? I'm hesitant to go calling it a bug in the compiler, certainly, but this hardly seems correct. If it's just me misunderstanding something about the standard, then I'd like to know where I'm wrong.

Answer 1

I'd say that this is not exactly a bug in the compiler so much as that the compiler's inability to parse the code is expressed in an unexpected way.

When the compiler hits that errant semicolon, it thinks that it knows something about the code which is not supposed to be true. The compiler sees nothing to contradict that belief until it reaches the default argument of the second function, which apparently does not mesh with the state it thought the code was in syntactically. It calls the error there because that's where it saw the problem, but it doesn't guarantee that that is where the problem with the code actually lies.

This is something I often see involving misplaced or missing curly-braces, parentheses, or other delimiting brackets. The compiler thinks everything is fine until it hits the end of a code block and realizes that there aren't the same number of left- and right-brackets, so calls the error there. It can't actually tell where the missing bracket was supposed to go.

Because this behavior is dependent on the exact parsing process used, it is compiler-dependent. However, while this can often change what sort of error is called and where, it will usually be an error of some sort on every compiler.

Answer 2

Agreed with @tlayton. Having dabbled a bit in parsers myself, I can attest that generating good error messages for syntax errors that confuse the parser's sense of scope can be very hard to do.

This particular case is however close to a defect. The irony is that in VS2010, the compiler still generates the same lousy error message but the IntelliSense parser actually catches it:

3   IntelliSense: expected a ')'    c:\projects\cpptemp14\cpptemp14.cpp 20  36  cpptemp14

That's borked. You can report it at connect.microsoft.com. Let me know if you don't want to take the time, I'll report it (MVP duty).