Hints and tools for finding unmatched braces / preprocessor directives

Answer 1

I think using some editor with brace highlighting will help. There should also be some tools around that do automatic indention on code.

EDIT: Does this vim script help? It seems to do #ifdef highlighting.

Answer 2

Hints:

• make small changes and recompile after each small change
• for unmatched braces, use an editor/IDE that supports brace match hilighting
• if all else failds, Ye Olde method of commenting out blocks of code using a binary chop approach works for me

Answer 3

Have a look at this question (Highlighting unmatched brackets in vim)

Answer 4

If the #includes are all in one place in the source file, you could try putting a stray closing brace in between the #includes. If you get an 'unmatched closing brace' error when you compile, you know it all balances up to that point. It's a slow method, but it might help you pinpoint the problem.

Answer 5

Can you create a script that actually does all the including, and then write the whole stuff to a temporary file? Or try the compiler for helping you with that? Then you can use the bracket highlighting features of various editors to find the problem and you'll probably be able to identify the file. (An extra help can be to have your script add a comment around every included file).

Answer 6

Pre-compile your code first, this will create a big chunk with the include files stuffed into the same file. Then you can use those brace-matching scripts.

Answer 7

One approach: if you have Notepad++, open all of the files (no problem opening 100 files), search for { and } (Search -> Find -> Find in All Open Documents), note the difference in count (should be 1). Randomly close 10 files and see if the difference in count is still 1, if so continue, else the problem is in one of those files. Repeat.

Answer 8

Handy tip:

For each header file, auto-generate a source file which includes it, then optionally contains an empty main method, and does nothing else. Compile all of these files as test cases, although there's no point running them.

Provided that each header includes its own dependencies (which is a big "provided"), this should give you a better idea which header is causing the problem.

This tip is adapted from Google's published C++ style guide, which says that each component's source files should include the interface header for that component before any other header. This has the same effect, of ensuring that there is at least one source file which will fail to compile, and implicate that header, if there's anything wrong with it.

Of course it won't catch unmatched braces in macros, so if you use much in the way of macros, you may have to resort to running the preprocessor over your source file, and examining the result by hand and IDE.

Another handy tip, which is too late now:

Check in more often (on a private branch to keep unfinished code out of everyone else's way). That way, when things get nasty you can diff against the last thing that compiled, and focus on the changed lines.