I'm wondering how to exclude a specified system header file in VS2010, which makes an ambiguous problem.
In my project, I use an opensource project. In which a cpp file calls
std::something::max()
where the max is a method in something.
However, max is also defined in a system header file "minwindef.h", which in my case lies at \Windows Kits\8.0\shared\minwidef.h
#ifndef max
#define max(a,b) (((a) > (b)) ? (a) : (b))
#endif
I think this is not necessary for my project.
So how do I manually prohibit this file to be included (perhaps recursively)?
You might want to #define NOMINMAX before #includeing any Windows headers.
This is such a common problem that they added this macro to remove the min and max definitions that conflict with the stl versions.
I'll try and dig up some MSDN reference for this.
Most likely, your opensource project is not designed to be "mixed" with "windows" headers.
Just don't do #include <windows.h> into the same files that include your opensource project. The limit the includes of <windows.h> to only be included in files that ABSOLUTELY need to have it, and idealy have one or more files with "windows only" functionality that are then provided to the rest of the code via it's own headers, isolating any windows functionality - that will also help if you ever decide to port your system to something other than windows.
(There are whole bunch of other macros that will sooner or late come back and bite you if you keep including Windows in your overall project)
Related
I'm developing a game engine for Sega Dreamcast and Windows. I have implemented my own library for the Dreamcast hardware, which pretty much does the same thing as OpenGL for PC. Now, I want to merge the two builds into one project, so I don't need to dev to different project doing the exact same high level stuff.
I know you can add a preprocessing line like this: #define DREAMCAST, and then the Dreamcast headers will be included and the appropriate low level function will be called instead of OpenGL. This has been done before, but I don't know how to make that possible.
This has really nothing to do with Dreamcast, it could be Mac, Linux or whatever. I have different compilers for each platform. So when #define DREAMCAST, I want the G++ KOS compiler to include the Dreamcast-specific headers and classes. If #define DREAMCAST is not present, I want MingGW to include the Windows OpenGL headers and classes.
How can I do this?
For the initial problem of including different versions depending on a predefined symbol, a simple solution is available:
#if defined(DREAMCAST)
#include <my_dreamcast_header>
#else
#include <opengl_header>
#endif
This functionality should be available on just about any C or C++ compiler - and it definitely is on MinGW. You still need to invoke the correct compiler yourself of course, as there is no way to change the compiler once compilation starts.
I have a precompiled header that contains includes for various 3rd party libraries, e.g.:
#ifndef PRECOMPILED_H
#define PRECOMPILED_H
#include "booststuff.h"
#include "luastuff.h"
#endif
Where booststuff.h and luastuff.h are header files in my project that just include various boost / lua related things and set up some typedefs / usings / namespace aliases.
I set up the precompiled header in the usual way inside visual studio (2012), and use the force include option to include it in every cpp file.
In the cpp files, I've also been fairly careful to #include "booststuff.h" where I actually use it as well (I sometimes disable precompiled headers to test this). However, I've been wondering lately whether that's a good idea. So:
Does anything bad happen if I include a file again that's already included in the precompiled header (I don't see why it would, but I've seen things about headers having to be included "in the same order", and not really understood what they were on about)?
Does it affect Intellisense (unusably slow with a fairly small project)? I'd be happy to give up some portability for better Intellisense since I currently have no desire to switch platforms.
If each include file has #pragma once in it, the compiler will completely skip reading the file on the second and subsequent attempts to include it. It isn't stated explicitly but I assume the precompiled header tracks this information as well.
And where does Microsoft get away with
#define small char
You can't just add reserved words to the language and quietly include them in a platform SDK!
And more importantly how do I get rid of it!
edit : how to find what is being included where and by what in Visual Studio - Displaying the #include hierarchy for a C++ file in Visual Studio
You didn't say whether you wanted to get rid of the header include or of #define.
If you want to get rid of the include but don't know where, you could try to define the include flag in your header above where the SDK includes are listed.
#define RpcNdr.h //find the real flag in the header
#include "sdk.h"
If it is just the #define of 'small', then how about putting this in your headers right after the list of SDK includes.
#ifdef RpcNdr.h //find the real flag in the header
#undef small
This is part of the interface definition for the RPC NDR engine (for RPC and DCOM marshalling).
Well on my SDK it's described as "Definitions for stub data structures and prototypes of helper functions."
I'm deep in trouble with my project.
I have to link two radar with my program, but the first has its own library that uses winsock, while in the second I want to use winsock2.
How can i do that?
At the moment i get many redefinition errors from the includes within winsock.h and winsock2.h.
Take into account that the first radar library is already an DLL, i've got only a header and lib file (no source).
Thank you in advance for any answer.
You could possibly work around the compilation problem by structuring your code (and precompiled headers) so that no file includes both winsock.h and winsock2.h, this may mean either not using precompiled headers at all or using them in a more complex way than is normal in MFC projects...
You could wrap each DLL in a COM object and access them via COM from your main program. This has the advantage of completely separating the use of the two DLLs from your main compilation.
You could wrap each of the DLLs in a new DLL (one each) which provides an interface to your program that does not need the winsock headers in the interface headers.
Of course this may simply be an issue with your Windows.h include order, try putting this at the top of your precompiled header...
#ifndef _WINDOWS_
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#undef WIN32_LEAN_AND_MEAN
#endif
#include <winsock2.h>
I have some .h files as follows (on Linux)
Source/Server/connect.h
Source/Server/message.h
...
I am developing another application that needs the two .h files but is in a different directory
Source/App2/..
How can I include the connect.h file in the App2 application, considering that I use perforce and everyone else working on the application would have their own copy so adding an absolute path to the include library might not be a good idea but im not sure.
EDIT:
I use a proprietary build mechanism for building the code so will not be able to specify gcc options directly.
You can #include a relative path to the files:
#include "../Server/connect.h"
or you can add a flag to tell the compiler to look in the other directory. For gcc you can use -I../Server; for Visual C++ you can use /I"../Server"; other compilers, I'm sure, have their own flags for this purpose.
I think the second is better in most cases, since it allows you to move your projects around while only requiring you to modify the include path in one place (the makefiles or property sheets).
What about adding include search path to he compiler, for gcc it's -I switch.
I suggest removing paths from the #include statements. As others have stated, put the paths into the parameters to the compiler. Resolve the path differences in the makefile or use environment variables (may need to do both).
My experience is that files will move. Anything that doesn't use relative paths will break the build (which is very bad).
in addition static relative paths, you can also play with preprocessor chicanery. One technique I saw used at Adobe for cross-platform code, was to do something like this:
/* globalplatform.h */
#ifdef MAC
#define PLATFORM "../Platform/Mac/MacPlatform.h"
/* custom standard IO etc */
#define STDIO "../Platform/Mac/io/stdio.h"
#define CTYPE "../Platform/Mac/io/ctype.h"
#endif
#ifdef WIN32
#define PLATFORM "../Platform/Win/WinPlatform.h"
#define STDIO <stdio.h>
#define CTYPE <ctype.h>
#endif
/* etc */
#ifndef PLATFORM
#error undefined PLATFORM
#endif
/* some C file */
#include "globalplatform.h"
#include PLATFORM
#include STDIO
/* don't need CTYPE, no penalty */
While the platform problem isn't your problem, you can define the relative paths based on build configuration if you want to and the config changes happen in one place instead of many and client files only pull in what they need. The down side is that any tools you use for browsing header files (right-click and so on) are hosed.
You can change the compiler directives as above, or modify the path within your code (either relative or absolute).
I would suggest that you consider the best locations for headers and object files (and libraries) for all your projects and set that up.
If you have standard include and lib locations you'll simplify the development down the road