A strange problem with Visual Studio (error C1075 and C2601)

[M.Haephrati]

Using Visual Studio 2013 C++, I got compilation errors that I couldn't explain.

The compilation errors were:

*main.cpp(325): error C2601: 'FLAG' : local function definitions are illegal

main.cpp(323): this line contains a '{' which has not yet been matched

main.cpp(326): fatal error C1075: end of file found before the left brace '{' at 'main.cpp(323)' was matched*

But there was nothing wrong with my code. I counted all brackets and the number matched. There weren't any function inside another function.

I solved it by removing all "//" comments from the source code. It seems that the reason for that is bad line formatting which causes the compiler to miss a line break, so the line after a comment is treated as a comment as well.

For example:

// This is a comment This_is_a_line;

is treated as:

// This is a comment This_is_a_line;

There are many posts of the net about similar problems and some even suggested that they could be caused by a memory (RAM) fault on the machine, so before you replace your RAM, just remove the comments and see...

• Michael Haephrati מיכאל האפרתי

[mike_2000_17]

It is probably caused by line-breaks being different. If you grabbed code that was developed on a unix-like operating system (Mac, Linux, BSD... and pretty much every OS except Windows), then the lines are broken with a "line-feed" character (i.e., '\n'), but in Windows, lines are broken with a "carriage return" and a "line-feed" (i.e., "\r\n"). In C++, everything could appear on a single line because the compiler basically ignores new-lines, and only cares about semi-colons to separate statements. So, basically, the only C++ feature for which new-lines matter is the comment-line, beginning with // and ending with the new-line. If your text file use Unix-style line endings, then the MSVC compiler will not recognize them as such.

I'm a bit surprised by this because my understanding was that MSVC could deal with either styles of line-breaks, at least, in its more recent version. (I'm pretty sure I've done this before without any issues) But I guess it can't. Just try to take the original code and convert the line-breaks to the Windows style. If I remember right, I'm pretty sure that Visual Studio will warn you about the non-Windows line-breaks when you open the file and will give you the option of converting them. Otherwise, I'm sure there are utility programs out there that can do this conversion easily.

Another possibility is to convert the line-comments into block comments /* .. */).

There are also other weird characters that can be invisible in the editor, but could throw off the compiler. One such character I've had problems with is the "non-breaking space", which I often typed accidently (alt + space on my keyboard, which is a common mistake, because I need alt a lot (french-canadian keyboard)). The typical fix for that is to simply go to the problem line (or at the end of the line before that), and erase and retype the characters and new-lines around that area, which should get rid of the weird invisible character, if any.

One common trick that people use, including myself, is to configure their version control system to do the conversion when committing or retrieving code from the server (line-breaks get converted from Windows to Unix when commiting code to the repository, and get converted from Unix to Windows when retrieving code from the repo onto your computer's directory).