I'm trying to convert a project from VS2008 to VS2013 and one (of the many) problem's I have encountered is this:
c:\program files (x86)\microsoft visual studio 12.0\vc\atlmfc\include\atlbase.h(4953): error C3861: '_beginthreadex': identifier not found
I've searched the net for a solution, I have already include process.h in my StdAfx.h, (not sure if it matters, but I placed it below the #include and #include or else I receive a "Windows.h" already included error).
I am using MFC as shared dll, I am compiling with /MDd and checked that -D_MT flag is on.
(I am also not doing #undef _MT in my code).
How can I solve this issue?
I found out what the problem was. I had a different "process.h" file in one of the additional include directories, after adding "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include" first in the additional include directories the problem was solved.
You need:
#include <crtdefs.h>
#include <process.h>
crtdefs.h will define/undefine _CRT_USE_WINAPI_FAMILY_DESKTOP_APP which _beginthreadex is wrapped in within process.h.
You have to include process.h to get access to this function.
Inside of an MFC application you should use AfxBeginThread.
Related
I needed a boost's "filesystem" so I downloaded and successfully build the whole boost. Its directory is C:\Program Files\Boost\boost_1_60_0\boost
Then I created a vs project and specified include directories, additional include directories and library directories. A couple of ways. Tried to add it to the system path, created a system variable bouth with setx an manually.
C:\Program Files\Boost\boost_1_60_0; $(BOOST_ROOT);
"evaluetes to" C:\Program Files\Boost\boost_1_60_0
But I still can't include and use anything.
#include <boost\filesystem> // error
#include "boost//filesystem.hpp" //error
#include <boost\filesystem.hpp> //error
#include "C://Program Files//Boost//boost_1_60_0//boost" //error
// those are working but still useless due to includes in the "filesystem.hpp"
#include "C:\Program Files\Boost\boost_1_60_0\boost\filesystem.hpp"
#include <C:\Program Files/Boost//boost_1_60_0\boost\filesystem.hpp>
#include <filesystem> // does not give an error, but following
using namespace boost::filesystem; //still does
By the way, I worked with boost in this same ide a couple of weeks ago. And things were ok, not sure how I got it working back then though.
What could possibly be wrong? I'm kind of lost.
Assuming you already built the library. You need to right-click on your Visual Studio project and click Properties.
As you can see on those pictures, specify the Additional Include Directories to C:\Program Files\Boost\boost_1_60_0 and Additional Library Directories to C:\Program Files\Boost\boost_1_60_0\stage\lib:
Then click OK
To include the boost filesystem write:
#include <boost/filesystem.hpp>
Let me know if you're still having problems after this.
I have begun writing a little C++ recently, and I decided to write a Qt program as an introduction, since I already know many of the function names etc. I have a file that gets the Jumbo icons using some win32 api. To use this I have the following includes:
#include <commoncontrols.h>
#include <shellapi.h>
#include <CommCtrl.h>
//other include statements for Qt
I keep getting an error
C:\Program Files (x86)\Windows Kits\8.1\Include\um\commoncontrols.h:198: error: C2061: syntax error : identifier 'IMAGELISTDRAWPARAMS'
and
C:\Program Files (x86)\Windows Kits\8.1\Include\um\commoncontrols.h:212: error: C2061: syntax error : identifier 'IMAGEINFO'
How could the error be in commoncontrols.h? As I understand it, the compiler cannot find a reference to those structs since CommCtrl is included after commoncontrols. So I reversed their include positions, thinking that would solve the problem, but that caused 127 other errors, so it seems not the correct direction. I am using Qt creator with Qt 5.4.1 and I am on Windows 8.1, so I am using the windows SDK for that. The kit is x64, since I am using the MSVC x64 compiler in VS 2013.
What am I doing wrong and why is it wrong?
You have a circular dependency problem. You didn't provide much information about the other header files.Example;
Header A.h might depend on header B.h and header B.h depend on header A.h.
You mostly solve this problem by replacing #include "A.h" in header B.h with a forward declaration of header A.h like so; class A in header B.h or vice versa.
I'm attempting to compile a C++ solution in VS 2010, but for some reason it can't locate the standard libraries.
I'm including as so:
#include <cstddef>
VS is returning an error as so:
main.cpp(10): fatal error C1083: Cannot open include file: 'cstddef': No such file or directory
However, I check my installation directory, and it's right where it's supposed to be (VC\include), and this directory is a part of my include directory list in the project settings ($(VCInstallDir)include).
Any ideas why this is happening, and how I can fix it?
Give a try using #include <stddef.h> instead.
However, MSVC 10 should have <cstddef>: msdn
However, as #captain-obvlious pointed out this may require additional changes in your code..
I want to begin programming with C++ OpenGl, and thus have downloaded freeglut to be included in my programn.
I have defined statically FREEGLUT_STATIC
Here is my source.cpp:
#include <GL\glew.h>
#include <GL\GLU.h>
#include <GL\freeglut.h>
#include "Source.h"
using namespace std;
int main()
{
return 0;
}
source.h
#define FREEGLUT_STATIC
But it does not work, the error is:
1>LINK : fatal error LNK1104: cannot open file 'freeglut.lib'
It's worth mentioning that I have added the libraries directories to the project, and even when I type Gl/ visual studio 2013 automatically suggest the libraries and headers which means it knows the directory,
I have found the problem. I should simlpy do the following:
Right click on my project in Visual Studio, go to the properties, and then to VC++ Directories, click on "Library Directories" and then add a new path:
under the freeglut main directory in your hard drive, there is a folder called lib/x86/Debug, just add the full path and then apply that.
Your script should be executed properly.
The include works alright (otherwise you'd get an error at compile time, not at link time). The library file itself (freeglut.lib) seems to be missing. This SO question addreses your problem.
EDIT: Updated my answer because obviously just the binary for the lib is missing. Same link already given in a comment by swaldi.
I'm sure that many of you are familiar with this set of warnings. These are most of the time generated by a include file. Solution is pragma push/disable/pop, but identifying the header is not a nice task.
Does anyone knows a way of identifying the header except trial-and-error ?
1>File1.cpp
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstdio(49) : warning C4995: 'gets': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstdio(53) : warning C4995: 'sprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstdio(56) : warning C4995: 'vsprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstring(22) : warning C4995: 'strcat': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cstring(23) : warning C4995: 'strcpy': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cwchar(36) : warning C4995: 'swprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cwchar(37) : warning C4995: 'vswprintf': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cwchar(39) : warning C4995: 'wcscat': name was marked as #pragma deprecated
1>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\cwchar(41) : warning C4995: 'wcscpy': name was marked as #pragma deprecated
1>Linking...
In my case, moving #include <strsafe.h> to the bottom of the list got rid of the warning without using extra compiler directives.
A good way to find out where #pragma deprecated was being called was to go into the compiler settings under "Preprocessor" and to set Generate Preprocessed File to something like With Line Numbers (/P). Rebuild, then open up the *.i file and search for deprecated. Nearby will be the name of the offending include.
I'm using VS2003, so the dialogs may be slightly different for you.
The standard include files should have include guards. So you may be able to explicitly include those files at the top of your own file, with that warning disabled:
#pragma warning(push)
#pragma warning(disable: 4995)
#include <cstdio>
#include <cstring>
#include <cwchar>
#pragma warning(pop)
// rest of your #includes
That way the warnings will be disabled for the headers where you know there are problems. This needs to be at the top of your code so the headers are included for the first time inside the warning-disabled section.
I would like to second what #Celdecea said.
Clearly it would be nice if MS did what GCC does and specified the included path (stack?) for the file, which I presume is what you were looking for; unfortunately, I was unable to find a compiler directive to do that, so grepping through the .i file was a painful but effective replacement.
I too found that my problem stemmed from adding #includes after <strsafe.h>. Since my error list was (almost?) identical to yours I wouldn't be surprised if that also solves your problem.
If not, or if you wish to employ the pragma push/disable/pop style, then it seems that #Greg has the best solution in preemptively and explicitly defining those headers that are causing you pain.
The notes for #include strsafe.h include the line:
To use the Strsafe functions inline, include the header file as shown here, following the #include statements for all other header files.
In the MSDN offline help it says:
Important: The include line for strsafe.h should follow all other headers' include lines.
Make sure that you've only included in cpp files and after all other c++ library header files and the warnings goes away.
Kevin
To add to Greg Hewgill's post, I found the problem in set and I did not suspect this file.
#pragma warning(push)
#pragma warning(disable: 4995)
#include <set>
#pragma warning(pop)
Doing the above solved my problem.
In Visual Studio 2010 (and probably other versions too) set the C++/advanced 'show includes' option to Yes or add the /showIncludes command line option.
Then compile one file at a time and search the build output window for the warning number that you're looking for and it will show the tree of include files that is generating that warning.
This technique is useful for most build problems caused by include files.
EDIT: make sure you turn off /showIncludes when the problem is fixed as it can interfere with other compiler options (e.g. /MP (Build with Multiple Processes) is disabled).
To suppress the warning add the offending include files to a 4995 suppression block as suggested by Greg Hewgill above. This can either be at the top of the source file or in a precompiled header or in a 'forced' include file included across the project (C++/Advanced/Forced Include File).
The particular problem with 4995 CRT deprecation errors is that they seem to be generated every time code calls deprecated functions even if warning 4995 was suppressed when the deprecated functions were declared.
In my case for VS2008 these warnings were coming from #include <vector> (or some other std library.) It seems like Microsoft can't follow their own advice.
Doing the following fixed the issue:
#pragma warning(push)
#pragma warning(disable: 4995)
#include <vector>
#pragma warning(pop)
Just make sure that you do it as early as possible in your includes.