views:

140

answers:

3

What are the best strategies for finding that missing semicolon that's causing the error? Are there automated tools that might help.

I'm currently using Visual Studio 2008, but general strategies for any environment would be interesting and more broadly useful.

Background: Presently I have a particularly elusive missing semicolon (or brace) in a C++ program that is causing a C2143 error. My header file dependencies are fairly straightforward, but still I can't seem to find the problem. Rather than post my code and play Where's Wally (or Waldo, depending on where you're from) I thought it would be more useful to get some good strategies that can be applied in this and similar situations.

As a side-question: the C2143 error is showing up in the first line of the first method declaration (i.e. the method's return type) in a .cpp file that includes only its associated .h file. Would anything other than semicolons or braces lead to this behaviour?

+4  A: 

Did you forget the semicolon after the class definition in the header? That's a fairly common cause of errors on the first method in the cpp file. I don't think there's a general magic "find the missing semicolon" tool; VS tries to make an educated guess, but if it's off it's because the code you wrote is somewhat legal without it, even if it's not what you intended

Michael Mrozek
The first thing I checked was that all the classes brought in with header files have semicolons. I'd probably have that as step one in my strategy in this case.
Dr. Monkey
+3  A: 

Start from the line that the compiler told you the error is on and look at the code immediately preceding that line.

R Samuel Klatchko
Funny that. Why can't the error messages be smarter? `;]` +1
Xavier Ho
+1  A: 

It's unlikely to be a missing semicolon, except (as @Michael suggested) from the end of a class. Generally a missing semicolon causes an error within a line or two.

If it's a scope brace then it's usually not too far away, although sometimes they can be a long way off..

Backtrack from the error line (go backwards up the code, and then backwards through each include from the bottom one), checking the braces. Chances are it's at the start of your cpp file just prior to the site of the error, or the end of the last include, so that's the best place to start.

You can use various techniques:

  • Just read the code. If you follow a clean symmetrical coding style a missing brace will often slap you in the face. (You can use Edit->Advanced->Format Document to tidy up code if it is in an inconsistent style).

  • Place the cursor on each end of scope } and press ctrl+} to take the cursor to the matching brace. This will either do nothing, in which case there is no match, or will jump to the match and you can check that it is the correct brace.

  • If you have a lot of code to consider, just comment a lot of it out with #if FALSE. You'll get different compiler errors, but if the original error stays you know it's not caused by the commented code, and you can move on to the next include/class/block.

  • The worst case scenario is that it's some code in a macro. If you have added/edited/used any macros in the last day, then check them first.

Jason Williams
Why would `#if FALSE` be a good way to comment out huge code blocks?
Kotti
@Kotti Using standard /* */ comments wouldn't work because the first */ closing tag in the file will stop the comment. #if FALSE should tell the compiler to only include the code up to the next #endif when FALSE is TRUE (i.e. never)
Dr. Monkey
+1 for great tips with document formatting and finding matching braces - I'm used to Eclipse which highlights the matching brace when the cursor is next to a brace, etc.
Dr. Monkey
Hm, visual assist takes these problems away, because you can press one button and your block will be commented with `//`. And the same for uncommenting. But thanks for pointing out.
Kotti
You don't need Visual Assist for that - ctrl+k,c comments the selection in VS. But I'm old school :-) ... #if avoids the possibility of any uncommenting disasters later (e.g. missing a bit of commented code that leaves your program compiling but broken in some way).
Jason Williams