I am getting C++ Compiler error C2371 when I include a header file that itself includes odbcss.h. My project is set to MBCS.
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\odbcss.h(430) :
error C2371: 'WCHAR' : redefinition; different basic types 1>
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include\winnt.h(289) :
see declaration of 'WCHAR'
I don't see any defines in odbcss.h that I could set to avoid this. Has anyone else seen this?
This is a known bug - see the Microsoft Connect website:
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98699
The error doesn't occur if you compile your app as Unicode instead of MBCS.
There are a half-dozen posts on various forums around the web about this - it seems to potentially be an issue when odbcss.h is used in the presence of MFC. Most of the answers involve changing the order of included headers (voodoo debugging). The header that includes odbcss.h compiles fine in it's native project, but when it is included in a different project, it gives this error. We even put it in the latter project's stdafx.h, right after the base include for MFC, and still no joy. We finally worked around it by moving it into a cpp file in the original project, which does not use MFC (which should have been done anyway - but it wasn't our code). So we've got a work-around, but no real solution.
This error happens when you redeclare a variable of the same name as a variable that has already been declared. Have you looked to see if odbcss.h has declared a variable you already have?
does this help?
http://bytes.com/forum/thread602063.html
Content from the thread:
Bruno van Dooren [MVP VC++] but i know the solution of this problem.
it solves by changing project setting of "Treat wchar_t as Built-in
Type" value "No (/Zc:wchar_t-)". But I am using "Xtreme Toolkit
Professional Edition" for making good look & Feel of an application,
when i fix the above problem by changing project settings a new
linking errors come from Xtreme Toolkit Library. So what i do to fix
this problem, in project setting "Treat wchar_t as Built-in Type"
value "yes" and i wrote following statements where i included wab.h
header file. You can change that setting on a per-codefile basis so
that only specific files are compiled with that particular setting. If
you can solve your problems that way it would be the cleanest
solution.
#define WIN16
#include "wab.h"
#undef WIN16
and after that my project is working fine and all the things related to WAB is also working fine. any one guide me, is that the right way
to solve this problem??? and, will this have any effect on the rest of
project?? I wouldn't worry about it. whatever the definition, it is a
16 bit variable in both cases. I agree that it isn't the best looking
solution, but it should work IF WIN16 has no other impact inside the
wab.h file.
--
Kind regards, Bruno van Dooren bruno_nos_pam_van_dooren#hotmail.com
Remove only "_nos_pam"
Related
Please leave the window-installer tag in - this Q/A is not for
C++ experts, but for people like me, who use C++ when they have to.
They may face this potential time-waster, and need a quick fix to get
msi.h or other includes operational quickly. VS2017 templates must
have changed quite a bit - I didn't see this issue before.
Visual Studio 2017 Community Edition with all available C++ components installed (perhaps this problem does not exist in the professional edition?).
File => New => Project... => Visual C++\Windows Desktop\Windows Console Application => OK.
Do a quick test build to verify there are no errors. Right click solution => Build. As stated no errors should show up.
Now add this include for msi.h directly below #include stdafx.h right above the main() function in the console appliation's CPP file:
#include <msi.h>
// And just to make things link:
#pragma comment(lib, "msi.lib")
A red error chevron should show up in the top left corner at the start of the first line comment saying on hover: "There are too many errors for the IntelliSense engine to function correctly, some of which may not be visible in the editor. PCH warning: an unknown error occurred. An IntelliSense PCH file was not generated."
Doing a build now should reveal numerous errors. In my case from wincrypt.h - and it got me thinking about WIN32_LEAN_AND_MEAN - see answer below. I thought such basics would already be included.
I keep seeing this problem in all new C++ Windows Console Application projects, but when I try in an older project created with Visual Studio 2013 it compiles correctly with msi.h included along with the link pragma.
Judging from the error message there must be something wrong with the precompiled header (PCH). This is what threw me off.
UPDATE: Others have asked about the same error message for other include files (not MSI related). I guess this is a generic problem that strikes every now and then - probably with classes that are in little use (or include Windows.h - perhaps)?
As a general suggestion this might be a hidden dependency problem (an include that is missing), or an incorrect order of the include files (you need to change the order of your includes for some technical reason that is not immediately obvious) or a incorrect or missing define (like seen in the answer below the line underneath). My take on it: get on github.com and search for similar sample code.
These issues can be quite clunky to work out for those of us who need C++ occasionally, and otherwise be "well known" for the C++ pros (who fix it in seconds as second nature). C++ pros: please keep in mind that issues such as these can kill a whole day's worth of productivity for those of us forced to clunk around with C++ when we need to - and have no C++ pros around to ask - terrible situation that! :-) - I hereby declare a "be nice to your C++ guru - if you got them - day!").
In stdafx.h, try adding this after #pragma once and before other includes:
#define WIN32_LEAN_AND_MEAN
// Windows Header Files:
#include <windows.h>
Now try to rebuild your solution and see if the problem has disappeared.
Though simple, the strangeness of the error message (seen in the question above) can throw people off course trying to figure out what is wrong. Also, this behavior seems new in VS2017 - template change.
It looks like including <atlstr.h> will also work, so that probably makes my problem more obscure. Could have sworn I tried this though - maybe after I made project settings changes that made it fail still (exactly what I hope to help others avoid).
If only these basic includes could be present in the file but commented out so they could be enabled quickly in sequence for testing - without any fuss.
I just started programming, but I keep on getting problems with headers and stuff.
So, whenever I try and run the code
// ConsoleApplication4.cpp : Defines the entry point for the console application.
#include "stdafx.h"
#include "std_lib_facilities.h"
int main()
{
return 0;
}
I get this warning saying
Unable to start program 'C:\Users\Gebruiker\documents\visual studio 2015\Projects\ConsoleApplication4\Debug\ConsoleApplication4.exe'.
The system cannot find file specified.
Additionally, the Build outputs:
1>------ Build started: Project: ConsoleApplication4, Configuration: Debug Win32 ------
1>ConsoleApplication4.cpp
1>c:\program files (x86)\microsoft visual studio 14.0\vc\include\hash_map(17): error C2338: <hash_map> is deprecated and will be REMOVED. Please use <unordered_map>. You can define _SILENCE_STDEXT_HASH_DEPRECATION_WARNINGS to acknowledge that you have received this warning.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========_
As you might've noticed, I'm following Bjarne Stroustrup's book on this, and he doesn't specify how to deal with this at all.
Anyways, the std_lib_facilities.h header is in the same folder as ConsoleApplication.cpp, just as he tells me to do.
I don't actually think this has anything to do with this program in particular, since I face this problem with all the projects I make.
Oh yes, I have to say that I've checked multiple related questions to this, but the questions didn't match mine.
I also tried to #include "../std_lib_facilities.h" and #include "../../std_lib_facilities.h", with no results.(Same with stdafx.h) I've tried "building" the program, but I don't actually know what that does, and if I should build the solution or the cpp, and when to debug....
The answer surely isn't in the book, since I've continued on to chapter 8, not doing the exercises because I cannot get the thing to work.
(Please also tell me if I messed something up in this question, i.e. that I need to talk less, give more details or something)
Here is how to remove a deprecation error:
How to fix "<hash_map> is deprecated and will be REMOVED. Please use <unordered_map>"?
If it still does not run, just go to the project directory and remove all Debug\Release folders Visual Studio creates after you run with Debug\Release configuration. Usually works for me.
Try creating "new project" / C++ console application; with your code and without any include statements. - Peter K
This fixed the problem for me, and I basically just copy-pasted the code and it worked.
I also had the hash_map error, because it is no longer supported in MSVS 2017.
This especially happens since one often still finds the old header off of Bjarne Stroustrup's website. Here is the link to the new header provided by Baum Mit Augen (Stroustrup's updated version)
If you're not using the header provided by Bjarne Stroustrup but one you made yourself, one you found on the internet or also one provided by a book, follow this tutorial from a previous answer by WindyFields. (Thanks a lot for that) (Be sure to check their answer out if this doesn't fix it)
If you encountered this problem, you probably messed with the settings when making a new project (like me).
This is a condensation of the comments provided by the community, none of these answers are mine.
I'm creating a project with openframeworks (the full source is here: https://github.com/morphogencc/ofxAsio/tree/master/example-udpreceiver), and the empty project seems to compile fine.
I added the ASIO library, and a few header classes, and now the project seems to be give me the following error:
1>------ Build started: Project: example-udpreceiver, Configuration: Debug x64 ------
1> main.cpp
1>cl : Command line error D8049: cannot execute 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\c1xx.dll': command line is too long to fit in debug record
1>cl : Command line error D8040: error creating or communicating with child process
I couldn't find any examples of error D8049 on stackoverflow or even on Microsoft's pages, and google turned up painfully few results. The only remotely useful one was this github issue:
https://github.com/deplinenoise/tundra/issues/270
But I'm still not sure what's causing the problem. Is anyone familiar with this error, and can recommend a method for troubleshooting what's causing it?
thanks in advance!
For me, working with UE4, this was an intermittent error.
I added "bLegacyPublicIncludePaths = false;" to the innermost block of project.Build.cs and recompiled without errors.
Then I removed that line and compiled again w/o errors.
The error message suggested adding "DefaultBuildSettings = BuildSettingsVersion.V2;" to project.Target.cs which worked.
This is a bit of a weird sounding error, as it is from essentially internally generated data. However, you do have control over that. Taking the error message at face value, you probably have many/lots of defined symbols passed in on the command line (or the the ones you do have have lengthy definitions), or you may have some lengthy file paths.
If you look under the project properties, one of the selections under the C++ section is "Command Line", which will show you exactly what gets passed to the compiler. When you view that you can see where you have many or lengthy parameters, and then make changes to shorten them.
Too many defines? Put them in a header (possibly stdafx.h) and include them that way.
Long file paths? Shorten the paths, put the files somewhere else, or set up file system aliases to your real directories that use shorter paths.
I am testing c++ source codes using the tool cantata++. I created a project, built it and encounter the following error message.
error I9282: the global scope has no "_invalid_parameter" C:\LegacyApp\VisualStudio2005\VC\include\yvals.h 167
I find this error wierd, because yvals.h is not really a file in my source codes. What does this error message imply?
You'll find that yvals.h is probably included by one of the many system header files the Microsoft compiler includes, and you are only seeing it in the error message because the Cantata++ instrumenter is finding a problem with it. My guess would be that there is some problem with the settings in either Cantata++, your Visual Studio project or a mismatch between the two meaning they are not using the same settings.
In order to help diagnose the problem it would help to know a few things about the setup you have, and the code you are building when you get the error.
As Joachim Wuttke said, I would suggest you contact the Cantata Technical Support team directly if you are still having problems with this issue. They will be able to provide you with further information to help solve the problem.
Sometimes VS autos/locals/watches break and instead of variables/values all I have is different kinds of:
CXX0029: Error: not struct pointer
CXX0033: Error: error in OMF type information
CXX0072: Error: type information missing or unknown
CXX0025: Error: operator needs class/struct/union
Rebuilding project, cleaning PDB/NCB etc doesn't solve it. What can I do?
Look at this Microsoft support note on: FIX: CXX0033 Error in OMF Type from Forward Class Declaration
Once you fix the PCH problem cited in the support note, I think all your errors will go away.
There is in fact a solution that lets you keep using precompiled headers: check out this more recent KB article and the documentation of the /Yl switch - which seems specifically tailored to this error.
Just add to the stdafx.cpp (or your own custom /Yc file) command line '/Ylxxxx', where xxxx stands for an arbitrary function name in your lib.
I recently faced symptoms identical to yours (in VS2010), and that solved it for me.
Are you trying to debug the "release" build? If so, many local variables will not exist as "debuggable" elements. You can get around this (if you must debug the release build) by debugging at the assembly level and look at the register values (vs. stack values, where auto/local would be in the debug build) and cast them appropriately in the "watch window".
Otherwise, build the Debug build and debug that build version. You'll get assertions where preconditions are not met, relevant/irrelevant stuff dumped to your output window, and more straight-forward debug single stepping.
It helped me to switch from using a program database (/ZI) to "c7 compatible" (/Z7). Switching off precompiled headers did not make a difference. Neither did rebuilding.