This is one of my most dreaded C/C++ compiler errors:
file.cpp(3124) : fatal error C1004: unexpected end-of-file found
file.cpp includes almost a hundred header files, which in turn include other header files. It's over 3000 lines. The code should be modularized and structured, the source files smaller. We should refactor it. As a programmer there's always a wish list for improving things.
But right now, the code is a mess and the deadline is around the corner. Somewhere among all these lines—quite possibly in one of the included header files, not in the source file itself—there's apparently an unmatched brace, unmatched #ifdef or similar.
The problem is that when something is missing, the compiler can't really tell me where it is missing. It just knows that when it reached end of the file it wasn't in the right parser state.
Can you offer some tools or other hints / methodologies to help me find the cause for the error?
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.
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.
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.
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
Very late to the party, but on linux you can use fgrep -o
-o, --only-matching
Print only the matched (non-empty) parts of a matching line,
with each such part on a separate output line.
So if you fgrep -o { then you'll get a list of all the opening braces in your file.
You can then pipe that to wc -l and that will give you the number of opening braces in your file.
With a bit of bash arithmetic, you can do the same with closing braces, and then print the difference.
In the below example I'm using git status -s to get the short-format output of all modified files from my git repo, and then I'm iterating over them to find which files may have mismatched braces
for i in $(git status -s | awk '{print $2}'); do
open=$(fgrep -o { $i | wc -l); # count number of opening braces
close=$(fgrep -o } $i | wc -l); # count number of closing braces
diff=$((open-close)); # find difference
echo "$diff : $i"; # print difference for filename
done
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.
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).
This might not be relevant to your problem, but I was getting an "Unexpected #else" error when framing some header files in an #if/#else/#endif block.
I found that if I set the problem modules to not use pre-compiled headers, the problem went away. Something to do with the "#pragma hdrstop" should not be within an #if/#endif.
Have a look at this question (Highlighting unmatched brackets in vim)
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.
I recently ran into this situation while refactoring some code and I'm not a fan of any of the answers above. The problem is that they neglect to incorporate a pretty basic assumption:
Any given file (most likely) will have matching braces and if/endif macros.
While it is true one can have a C++ source file that opens a bracket or an if block and includes another module that closes it, I have never seen this in practice. Something like the following:
foo.cpp
namespace Blah{
#include "bar.h"
bar.h:
}; /// namespace Blah
So with the assumption that any given file / module contains matching sets of braces and preprocessor directives, this problem is now trivial to solve. We just need a script to read the files / count the brackets & directives that it finds and report mismatches.
I've implemented one in Ruby here, feel free to take and adapt to your needs:
https://gist.github.com/movitto/6c6d187f7a350c2d71480834892552ab
I just spent an hour with a problem like this. It was very hard to spot, but in the end, I had typed a double # on one line:
##ifdef FEATURE_X
...
That broke the world.
Easy one to search for though.
The simplest and fastest solution is to comment file from the end by consistent blocks. If the error still exists, then you not yet comment the open brace.
Related
I start to work on a huge project with tones of C and C++ files, already wrote by someone else.
Is there any faster/simpler ways to find in what file any macro or function is define other than a grep -r ? It is kind of long.
In some IDE there is this magical thing like right click and "go to definition". But I'm currently using emacs. I don't know if there is any customisation that can do this ?
Each time, I have to copy past the name in my terminal, run a grep and re copy past the file path in my emacs. (And you know, I am lazy...)
CTags. You can try using Ctags with emacs and it will help you to navigate to the function declaration directly. For its usage, please refer to https://www.emacswiki.org/emacs/EmacsTags
You can also explore Cscope, It has a better feature set than ctags which works directly on pattern recognition. But sometimes, you just need to navigate through code and more often than not ctags does the job.
Each time, I have to copy past the name in my terminal, run a grep and re copy past the file path in my emacs.
You can improve on this by using M-x rgrep inside Emacs. It asks for the regular expression, a glob pattern of files to look in, and a directory to start in. It then does a recursive grep, outputs the results in a buffer, and you can jump directly from the hits to the corresponding file.
For the glob pattern, you could type something like *.c, or you could use one of the aliases defined in the variable grep-files-aliases. For example, ch is equivalent to *.[ch] (C source and header files) and cchh is equivalent to *.cc *.[ch]xx *.[ch]pp *.[CHh] *.CC *.HH *.[ch]++ (C++ source and header files).
You might find that this works well enough that you don't need ctags and other tools suggested in the other answers and comments.
For ease of finding function definitions in C, some projects use the convention that the function name in the definition starts in the first column:
/* this is just a declaration */
int main(int argc, char *argv[]);
/* in the definition, the function name starts on its own line */
int
main(int argc, char *argv[])
{
...
That means that you can find the definition, excluding any calls to the function, with the regex ^main.
grep should be really fast if you limit the search to the directories and file types (generally .h and .hpp) that are likely to contain it. For example if you know it is in your application just search there, if you know it's from FreeType (generally FT_*) search there.
More RAM will help the system cache files better, and if your on a HDD best to get an SSD. If your working directly on a VM, especially one with remote disks, if can work locally that will often be faster.
Otherwise many fully functional IDE's (Visual Studio, XCode, Eclipse, etc.) have C++ integration to keep track of these things, and will for example offer a "Go to declaration" and "Go to definition" option as a shortcut or context menu when over a symbol.
I am having an annoying behavior in Sublime.
When I start typing out the line...
using namespace SomeNamespace;
The keywords 'using' and 'namespace' are properly colored the keyword coloring. Then when I add the semicolon to the end of the line, the namespace keyword goes white (default text color). I know this is not that significant, but it really annoys me.
Has anyone noticed this behavior before? The code compiles without errors or warnings, so I know sublime is not detecting some so of code problem.
Does anyone have any suggestions on how to fix this problem?
The problem is in this particular regex in the C++ syntax definition:
\b(namespace)\s+([A-Za-z_][_A-Za-z0-9:]*\b)?+(?!\s*?(;|=|,))
At the very end, in the negative lookahead - (?!...) - we see that semicolons are excluded from the match, meaning that if a semicolon is present at the very end of the line, there's no match.
To fix it, you'll need to install the very useful PackageResourceViewer plugin from Package Control. Then, open the Command Palette, type prv to bring up the PackageResourceViewer options, select the Extract Package one, then scroll down and select C++. There will now be a C++ directory in the directory opened by choosing Preferences -> Browse Packages.... Go into that directory and you'll see a bunch of files. Depending on what version of Sublime Text 3 you're using, you'll want to open either C++.tmLanguage or C++.sublime-syntax in Sublime. The .tmLanguage format is XML, so you can pick that for syntax highlighting if you wish, while the .sublime-syntax file is in YAML.
Once the appropriate file is open (you'll either have one or the other, not both), search for the regex above, or just search for namespace, you should find it pretty easily. Delete the ;| from near the end, making the whole thing:
\b(namespace)\s+([A-Za-z_][_A-Za-z0-9:]*\b)?+(?!\s*?(=|,))
Save the file, and that's it! Your C++ source files should update their behavior immediately - if not, just close and reopen them, and in the worst case you can just close them, restart Sublime, then reopen them.
Currently I am working on a fairly large project. In order to increase the quality of our code, we decided to enforce the treatement of return values (Error Codes) for every function. GCC supports a warning concerning the return value of a function, however the function definition has to be preceeded by the following flag.
static __attribute__((warn_unused_result)) ErrorCode test() { /* code goes here */ }
I want to implement a bashscript that parses the entire source code and issues a warning in case the
__attribute__((warn_unused_result))
is missing.
Note that all functions that require this kind of modification return a type called ErrorCode.
Do you think this is possible via a bash script ?
Maybe you can use sed with regular expressions. The following worked for me on a couple of test files I tried:
sed -r "s/ErrorCode\s+\w+\s*(.*)\s*\{/__attribute__((warn_unused_result)) \0/g" test.cpp
If you're not familiar with regex, the pattern basically translates into:
ErrorCode, some whitespace, some alphanumerics (function name), maybe some whitespace, open parenthesis, anything (arguments), close parenthesis, maybe some whitespace, open curly brace.
If this pattern is found, it is prefixed by __attribute__((warn_unused_result)). Note that this only works if you are putting the open curly brace always in the same line as the arguments and you don't have line breaks in your function declarations.
An easy way I could imagine is via ctags. You create a tag file over all your source code, and then parse the tags file. However, I'm not quite sure about the format of the tags file. The variant I'm using here (Exuberant Ctags 5.8) seems to put an "f" in the fourth column, if the tag represents a function. So in this case I would use awk to filter all tags that represent functions, and then grep to throw away all lines without __attribute__((warn_unused_result)).
So, in a nutshell, first you do
$ ctags **/*.c
This creates a file called "tags" in the current directory. The command might also be ctags-exuberant, depending on your variant. The **/*.c is a glob pattern that might work in your shell - if it doesn't, you have to supply your source files in another way (look at the ctagsoptions).
Then you filter the funktions:
$ cat tags | awk -F '\t' '$4 == "f" {print $0}' | grep -v "__attribute__((warn_unused_result))"
No, it is not possible in the general case. The C++ grammar is the most complex of all the languages I know of, and C++ is not parsable via regular expressions in the general case. You might succeed if you limit yourself to a very narrow set of uses, but I am not sure how feasible it is in your case.
I also do not think the excersise is worth the effort, since sometimes ignoring the result of the function is an OK thing.
I've tried a bunch of different methods.
1.
*
!.gitignore
!./src/com/AleXander/*
2.
/*
!.gitignore
!src/com/Alexander/*.java
3.
*
!.gitignore
!./*.java
as well as multiple other variations of this. I came across this question that looks like it's using Regex. Is regex needed for this to work? Any ideas?
I also tried these regex patterns but I am not the best at regex.
1.Logic: ignore all files ending with the file extension pattern "java"
*
!.gitignore
!*.[^java$]
2.Logic: ignore all files ending with a "j" followed by an "a" with anything else after that.
*
!.gitignore
!*.j[^a]*
Ignoring * is a bad idea.
This will ignore every file and every directory in every part of your repository.
Especially git will not look at all at ignored directories. Therefore the exceptions you define later will have no effect at all.
There are quite longish include/exclude hacks to make something like this work, but usually the best way is to just explicitly ignore the files you want to ignore and avoid any exceptions whenever possible.
If you feel the need for some more complicated ignore rules this is usually an indicator that your repository layout needs a better structure.
In a repository for a well known open source project, all files contain a version string with a timestamp as their first line:
<?php // $Id: index.php,v 1.201.2.10 2009-04-25 21:18:24 stronk7 Exp $
Even if I don't really understand why they do this - since the files are already under version control -, I have to live with this.
The main problem is that if I try to 'st' or 'diff' a release to get an idea of what was changed from the previous one, every single file contained in the repository is obviously marked as modified and the diffs become unreadable and unmanageable.
I'm wondering if there's a way to ignoring the first lines doing a diff/st when they match a regexp.
The project is under cvs - cvs, yes, you've read correctly - and included in a bigger mercurial repository.
I don't know about cvs, but with hg you can use any external diff tool with the bundled extdiff extension, and any modern tool should have the ability to let you ignore diffs that match certain patterns.
I swear by Beyond Compare, which allows arbitrary syntax definition.
kdiff3 has preprocessor commands that you can pipe the input through.
If you try
man diff
you'll find
--ignore-matching-lines=RE Ignore changes whose lines all match RE.
search "ignore matching lines" on the web gives examples :
diff --unified --recursive --new-file
--ignore-matching-lines='[$]Author.[$]'
--ignore-matching-lines='[$]Date.[$]' ...
(http://www.cygwin.com/ml/cygwin-apps/2005-01/msg00000.html)
Thus try :
diff --ignore-matching-lines='[<][?]php [/][/] [$]Id:'