I'm a complete noob when it comes to C++ and I've been hacking away on Moai trying to add support for an Xbox 360 gamepad via XInput. When I include the header for XInput there are two options:
XInput
and
Xinput
Further, in order to use XInput I need to include windows.h. All the examples I've seen use the following syntax:
#include <windows.h>
But the auto complete in Visual C++ Express 2010 inserts
#include <Windows.h>
In the case of XInput/Xinput it seems that case-sensitivity matters but in the case on Windows.h it does not seem to matter.
Does case-sensitivity matter when including header files? Is there some logic to this?
Is the XInput difference simply a matter of there being a header for something called XInput and another something called Xinput?
Case sensitivity in header names and include directives is implementation defined. Generally it works out to whether the platform you're building on is case sensitive or not.
I'd have to test to make sure, but I suspect that if you type any variety of 'xinput.h' it will find the the one that occurs first in the header search paths, even if the file that occurs later in the search paths is a better match in terms of case. This would be quite unintuitive from the perspective of a developer not familiar with these issues, because it would mean that you could use one of those auto-completions, and VS would then include the file not selected.
It's also possible that VS is smarter than that and will search for the best case match.
It only matters if the underlying file system is case sensitive. The Windows filesystem is not case-sensitive, but the file systems of operating systems like Linux are. Try to use the exact actual name of the real file to ensure that your code works if/when you port it from one OS to another.
On Windows, filenames are not case-sensitive, and this extends to #include. Any case will do.
On some platforms (e.g. Linux), filenames are case-sensitive, so you would need to match the actual filename.
Windows is not case sensetive as others have said. But that's not your problem. Your problem is with include-file settings in Visual Studio. The compiler will look for standard headers (header inclusion using <> syntax), in the order they are setup. Launch Tools->Options, and then lookup Projects and Solutions->VC++ directories and see the sequence of Include Files.
Related
Question:
Once my code is working how should I prepare my files so that a stranger on a different computer can compile it without difficulty?
Additional Details:
I am sending a code sample to a company as part of an application so obviously an elegant solution would be better (i.e. minimise number of files required etc) and no work should be necessary by the stranger at the other end.
Although I am only using one simple library, even so I need to set include directories, include lib files, images, dll files etc so that it all compiles correctly.
If it matters, I am using Visual Studio 2015 and the simple library is SDL.
Sorry if this is a duplicate, I was sure that this question would have been asked before but if it exists I just don't know the correct terminology to find it amongst the noise.
Apologies if this is overly simplistic, but you might want to bound the scope of your project by deciding which computers you want to support, and build your code yourself on those platforms, in advance, just to be sure.
List the supported platforms in your release notes, including any platform-specific instructions or information (which VC++ versions, which C++ versions, which OS versions, which DLLs, directory structure, etc.).
You may have to stick some "#ifdef"s and such in your code, but only by building on a particular platform/configuration will you really know for sure.
You can use properties/props files in your VS solution which sets the paths to includes and precompiled libs, then reference the build variables in your project files.
To compile on another machine, you just need to change the values in the properties files.
When I attempt to compile a MFC project I get told I need to include this file. What and where is it? Why do I need it?
It's a rather important Windows SDK header file, the very first one that gets #included in <windows.h>. It declares Windows version numbers, the kind you should use in your program that states what version of Windows you want to be compatible with. The MSDN Library article is here.
If this file is actually missing on your machine (it isn't clear from the question) then you've either got a very old SDK version and are mixing headers (very bad) or you've got some disk damage (very very bad). It is the kind of problem you'd get when you are stuck on an ancient version of Visual Studio and are trying to use modern Windows api functions. Do not mix and match, it won't come to a good end.
So, I am trying to deal with small differences in the various versions of the Windows SDK but am having trouble determining during compilation precisely what version of the Windows SDK I am building against in C++.
As of version 6.1 of the Windows SDK, there is a WinSDKVer.h file that contains some version information that I could use to determine what version of the SDK is being used even though it does not contain a direct version number for the SDK. However, 6.0A does not include this header file, so simply inserting #include and then using something like #ifdef will not work since there is no WinSDKVer.h in the environment.
A colleague of mine had a vague recollection of a way to include a header on Windows if and only if it exists, but could not remember any details and I have so far failed to find any information on doing so either on stackoverflow or the internet.
I've already done what I can to our make process to try to force the use of a 6.1 or greater SDK if installed on the developer's machine, but I'm also interested if others have run into this general kind of issue before and if/how they solved it.
Any ideas?
(ugly) create your own empty version of the header file and place it on a folder. Then add this folder last in your include directories. if the file exists in the SDK it will be included; otherwise your file will be used.
You cannot do it on C++ level. You can do it on build system level — e.g. in SCons see "Checking for the Existence of Header Files". The basic idea is to compile a little program that just includes the file, and see whether compilation succeeds or fails. Then you can set a macro that says if you have the header, or not, and do
#ifdef HAVE_WINSDKVER_H
# include <winsdkver.h>
#endif
or whatever.
Do some spelunking through historic versions of the SDK headers, looking for a header file that has existed in all versions of the SDK but contains subtle variation in its #defines in different SDK versions. You can test these with #ifdef to distinguish the SDKs.
Obviously it'll have to be some file other than WinSDKVer.h, and in some cases you may need a combination of several files.
I did something similar for Palm OS SDKs many years ago.
I am porting a C++ large project form Windows to Linux. My C++ files include header files that do not match those on the project directory due to the case sensitivity of file names in Linux file systems.
Any help?
I would prefer finding a flag for gcc (or ext4 file system) to manual editing or sed'ing my files.
Thanks for all!
You're out of luck on your preference. Linux is case-sensitive, and always will be. Just identify the names that need to be changed, and sed away.
As far as I know the problem is with the file system. Unix file systems are case sensitive while windows ones are not. As far as I know there is no way round this. gcc certainly has no flags to help with this.
One point to bear in mind is directory separators. You can always safely use forward slashes "/" in #includes. This will work even for Windows.
I have a very large project with tons of convoluted header files that all include each other. There's also a massive number of third-party libraries that it depends on. I'm trying to straighten out the mess, but I'm having some trouble, since a lot of the time I'll remove one #include directive only to find that the stuff it was including is still included through one of the other files. Is there any tool that can help me understand this? I'd really like to be able to click on a .h file and ask it which CPP files it's included in (directly or indirectly), and the paths through which it is included, and likewise click a cpp file and ask it which .h files are included (directly and indirectly). I've never heard of a tool that does this, and a bit of quick googling hasn't turned anything up, but maybe I don't know what to search for.
http://www.profactor.co.uk/includemanager.php
For VS2003 there is /showIncludes flag (in C/C++/Advanced properties). This will print all headers each .cpp file includes and what they include, so you can go from there.
I'm sure there is same option in same place for VS2008.
if you use GCC compilers, try this
g++ -M abc.cpp
it will show all include dependencies for the file abc.cpp
Your situation reminds me of my own. I have a bunch of headers that I have created that I use as a library instead of bothering with a DLL.
Of course the cyclic-includes can become troublesome, so I find that a tool like Visual Assist X (1) helps with this sort of thing. It has a function that can find references to stuff, so that you can easily weed out where something is being defined/declared/included etc. It also has a lot of other useful features, so I consider it to be pretty useful.
There’s probably other tools/plugins that have a referencing function, but usually as one feature among the other refactoring and productivity functions of the utility.
HTH
It's pretty tedious, but you can binary-search your way to where an #include happens by using #error (and #pragma message) to narrow down which include line is pulling in the third party. I've done this in the case of a single file I was trying to track down, but it sounds like your problem is bigger so probably one of the tools others have mentioned would be more effective.