I'm currently getting the following errors:
c:\program files\microsoft visual studio\vc98\include\iomanip(15) : error C2059: >syntax error : 'namespace'
c:\program files\microsoft visual studio\vc98\include\iomanip(15) : error C2334: >unexpected token(s) preceding '{'; skipping apparent function body
c:\program files\microsoft visual studio\vc98\include\math.h(36) : error C2059: syntax >error : 'string'
c:\program files\microsoft visual studio\vc98\include\math.h(36) : error C2334: unexpected >token(s) preceding '{'; skipping apparent function body
As they are all in the standard library header files, and therefore read only, I don't know how to fix it!
Any help would be great.
In C/C++, the preprocessor runs before the source code is actually parsed, and #includes basically just splice together different files. One consequence of this is that C/C++ are perfectly happy with having a { in one file match a } in another (included) file. Of course, no one ever does this (or if they do, they should be shot), but because the C/C++ preprocessor is so simple-minded, it's technically allowed.
One consequence of this is that a syntax error in one of your own files can end up looking like a syntax error in some other file. I most often encounter this myself when I forget to put a ; after a class definition. But mismatched {}s can (as you discovered) have the same effect.
So if you ever see an error in some included file that you think probably shouldn't be there (eg a standard library), then the first place to look is whatever file was included just before that file. Sometimes rearranging your #include statements can help narrow down the source of the error as well.
Visual Studio:
Open the project's Property Pages dialog box.
Click the C/C++ folder.
Click the Advanced property page.
Show Includes (Yes)
Build the project, in the build output you should see the include tree.
Find the first occurrence of the error, and scan upwards opening each include file (that you wrote) to find which one has the missing curly bracket "}"
I encountered this error but figured out the problem was that the name of a method that I was defining was already defined as macro in window.h. so I had to #undef it.
I came across the "skipping apparent function body" error in a student's code and it was hard to track down because I expected it was a curly brace mismatch.
My student had a member variable and a member function declared with the same name. The function came after the variable, so parsing failed on the function body. This is most similar to fire in the hole's answer referring to a predefined macro.
Related
I'm trying to compile my project where I've just added the use of 'WinSock2.h'.I'm getting these errors :
c:\program files (x86)\windows kits\8.1\include\um\wingdi.h(2898): error C2208: '_POINTL' : no members defined using this type
c:\program files (x86)\windows kits\8.1\include\um\winuser.h(14564): error C2208: 'unsigned int' : no members defined using this type
more
I have searched solutions to my issue, I've added _WINSOCKAPI_ on preprocesseur rules and only the two errors up there are remaining. I have also tried adding WIN32_LEAN_AND_MEAN and still the same.
My project uses ALLEGRO library and "windows.h" file.
Have you a explanation of my problem ?
The compilator errors point to files winuser, wingdi, propild, oaidl.
These files has been added from the use of network library, on windows.h I guess.
The offending lines deal of following field definitions : unit, date, position.
All these name was already used on preprocessor definition on my project, leading to a conflict of definition.
I feel sorta silly asking this question, but I just cannot find a solution anywhere on the internet.
Notes:
I am using VS2019
C++17 is enabled
My problem is the following:
I want to iterate files in a directory with std::filesystem. To do so, I need to use the directory_iterator. However, when I include the filesystem library, it doesn't find the directory_iterator, so I checked the filesystem header file. It threw me a bunch of errors. I also cannot use experimental/filesystem because for some reason the path class also has errors which make the string functions unusable.
However, when I create a fresh console application, it works fine for me. No errors, directory_iterator has been found, I can iterate without issues.
Here is a small snippet of what the errors I'm being given when trying to compile:
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include\experimental\filesystem(917,28): warning C4003: not enough arguments for function-like macro invocation 'concat'
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include\experimental\filesystem(921,1): error C2365: '_InIt': redefinition; previous definition was 'template parameter'
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include\experimental\filesystem(921): message : see declaration of '_InIt'
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include\experimental\filesystem(921,1): error C2061: syntax error: identifier '_First_InIt'
I have compiled all subsystems of a big, complex, Simulink model into a series of dlls. All of them are working in Visual Studio except one. The one that is not working is the only one that requires the simstruc.h header file, and I get about 120 error messages when I try to compile them. Most of them are in simstruc.h, but also in subsequent includes, like sfcn_bridge.h for example. All of them look the same way:
error C2143: syntax error : missing ';' before '*' c:\matlabr2011b_x86\rtw\c\src\sfcn_bridge.h (37)
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c:\matlabr2011b_x86\rtw\c\src\sfcn_bridge.h (37)
.
error C2143: syntax error : missing ';' before '*' c:\matlabr2011b_x86\simulink\include\simstruc.h (2135)
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int c:\matlabr2011b_x86\simulink\include\simstruc.h (2135)
The code in the line in above example looks like this:
sfcn_bridge.h (37):
SS_SimMode *simModePtr;
simstruc.h (2135):
SparseHeader* slvrJacobianMatrix;
I have been able to compile programs that include simstruc.h before, but suddenly it's not working. Can anyone point me in the right direction?
Check if any of your class declaration missing ";" at the end.
class AAA
{
}; <--- this one
Edit:
Try these tips as well.
Rebuild the project
Right Click on each cpp file and click "Compile" to identify infected files.
Check include paths. specially sub folders in simulink include directory.
Go to the declaration of SparseHeader struct and check if it get skipped by any #ifdefs or any preprocessor definitions.
If your code base is small, comment out half of it until you get a compilable code. This is not easy however.
I am currently working on a Qt application with many #include files from the Qt library. The project is quite large and I have encountered a strange problem when building. The errors displayed are all inside the QPainterpath.h file, but has nothing to do with calls to it from my project. The errors all look like this:
c:\qt\4.8.4\include\qtgui../../src/gui/painting/qpainterpath.h(397) : error C2143: syntax error : missing ';' before '::'
c:\qt\4.8.4\include\qtgui../../src/gui/painting/qpainterpath.h(397) : error C2059: syntax error : '::'
c:\qt\4.8.4\include\qtgui../../src/gui/painting/qpainterpath.h(398) : error C2143: syntax error : missing ';' before '{'
c:\qt\4.8.4\include\qtgui../../src/gui/painting/qpainterpath.h(398) : error C2447: '{' : missing function header (old-style formal list?)
c:\qt\4.8.4\include\qtgui../../src/gui/painting/qpainterpath.h(405) : warning C4003: not enough actual parameters for macro 'elementCount'
I encountered this once before and was able to solve it by moving some Qt #include statements called before other class headers below them. I can't seem to figure out what in particular is causing it this time though. Any thoughts would be great!
Thanks!
I've seen this happen when you forget to close a class definition with a semicolon. If you look at the output from the compiler, and see which file was compiled right before this error started, you may have your answer. Look for syntax errors with missing a ; or an extra } or a missing } at the end of the previously compiled file.
It could also be from a .h file listed above your #include <QPainter> call that has the errors.
Hope that helps.
I'm working with RyGuyFalcore and figured out why this is happening in our code, and nobody else is seeing it. The issue is that our legacy code was redefining the elementCount macro. Therefore, if we included that portion of our legacy code before we included the Qt code, the wrong macro was getting used :( Figured I would post this here to avoid any wild goose chase that others may run into if they hit a similar bug.
I am compiling a Matlab mex file (Using VS2010 under Windows), and the following 2 includes:
#include <algorithm> // for std::copy
#include "mex.h"
give me compile error:
1>d:\svn\trunk\dev\matlab\extern\include\matrix.h(337): error C2371:
'char16_t' : redefinition; different basic types
I have tried putting it in a namespace:
namespace Algo {
#include <algorithm>
}
But then I get tons of other compile errors, without even using anything defined in <algorithm>, for example:
Error 1 error C2039: 'set_terminate' : is not a member of '`global namespace'' C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\exception 192
Error 2 error C2873: 'set_terminate' : symbol cannot be used in a using-declaration C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\exception 192
How can I solve this?
Putting an standard header in a namespace doesn't sound like a good idea, even though you are not using any of the methods or classes there, there is a pretty big chance that another header might (like the mex.h). Putting the namespace around the mex header seems much less probable to create a conflict.
Also including one header before the other might also prevent such a conflict. Some headers take into account that some symbol might already be defined before redefining them (library developer really should take care to do this)
In some cases reading the headers might also give you a good clue what is going on. Some times it might be as simple as defining a symbol, which tells the header to skip the redefinition.