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."
Related
So I'm currently working on something that uses OpenCL. The OpenCL spec provides the users with a directive which must be included before the inclusion of the header (cl.h)
#define CL_TARGET_OPENCL_VERSION 110
Which basically defines the version they want to use. Suppose I'm making a library and I want my users to define this instead of me defining this inside my files. What I did was.
-----main.cpp---
#define CL_TARGET_OPENCL_VERSION 110
#include "library.h"
-------x---------
----library.h-----
#ifdef CL_TARGET_OPENCL_VERSION
#pragma message("def")
#endif
#ifndef CL_TARGET_OPENCL_VERSION
#pragma message("ndef")
#endif
.... include other headers.
--------x---------
And the compiler prints both def and ndef messages. And the OpenCL library also throws a warning that it's undefined. I thought that the library header would get substituted into main and it'd only print the def message. Is there anything I understood wrong?
I'm particularly confused as to where does the preprocessor start? If it starts from main.cpp and goes from top to down, then it surely has defined the macro. After that it sees the library inclusion, then it should only print the def message but it prints both.
This leds me to believe the preprocessor does scan the header file before including it in main? Dunno the reason why. Also I have assured that the library header isn't included elsewhere.
One interesting thing I noticed was, if i did this
-----helper.h---
#define CL_TARGET_OPENCL_VERSION 110
-------x---------
----library.h-----
#include helper.h
#ifdef CL_TARGET_OPENCL_VERSION
#pragma message("def")
#endif
#ifndef CL_TARGET_OPENCL_VERSION
#pragma message("ndef")
#endif
.... include other headers.
--------x---------
It prints the def message "twice". If anybody can explain all this I'd be grateful.
EDIT:- The files I'm compiling are main.cpp library.h and library.cpp
Library.cpp includes library.h from the start as usual. Maybe this other cpp is causing the problem?
In C/C++ programs, the compiler handles each .c and .cpp file separately.
The compilers build each source file (NOT the header files, only .c and .cpp files) independently from each other (this source files are called compilation unit).
Thus, when your main.cpp is built, the compiler finds the #define CL_TARGET_OPENCL_VERSION 110 you have added on top of the main.cpp file, emiting the defmessage.
But when the compiler builds the library.cpp file, it does not find the version define, so it emits the ndef message.
So, following this explanation, it is completely normal that in your last case, when you add the define to the .h file, the compiler emits the def message twice, once for the main.cpp file and once for the library.cpp file.
Now, the problem is where should you add the define, in order to have the program built consistently, with the same version for all the .cpp files.
Usually, all the IDEs have some configuration page where you can add global defines, for all the project, which are "inserted" into all the compilation units before everything else. So when the IDE calls the compiler, it passes the same defines to all the compilation units. You should add this kind of defines in this page.
In your IDE (I am using Code::Blocks, v 17.12), you can find this page in the menu: Project / Build Options
For each type (Debug or Release), you have to go to the tab Compiler Settings, and there to the sub tab #defines. There you can add global defines, which can be different if you are building in Debug or in Release mode (of course, if you set the same in both modes, they would be the same).
Once you have added your define here, please, remove it from the main.cpp, library.h and any other place where you may have added it, in order to avoid duplicities.
From the comments about portability:
You have several options:
Always use Code::Blocks: this would be the easiest way, since you can pass the Code::Blocks project along with the source files, and everything would be already setup.
Use cmake, which is a script build system, where you can set defines and so in the same way as using an IDE. cmake is much widely used than Code::Blocks, so maybe it is a better option.
Add a new options.h header file, where you set all the defines, and include it to all your .c/.cpp. This setup has the additional benefit that for different systems, changing only the options.h file the build can be completely different. This is a manually setup of what the IDE is doing. It has the advantage that does not rely on external tools, but the disadvantage that you have to remember to add it in all the new .cpp files added to the project.
My recommendation is go with cmake, just as the others have said.
Prefer using #ifndef XXXX_h #define XXXX_h #endif over #pragma once
If your #include search path is sufficiently complicated, the compiler may be unable to tell the difference between two headers with the same basename (e.g. a/foo.h and b/foo.h), so a #pragma once in one of them will suppress both. It may also be unable to tell that two different relative includes (e.g. #include "foo.h" and #include "../a/foo.h" refer to the same file, so #pragma once will fail to suppress a redundant include when it should have.
This also affects the compiler's ability to avoid rereading files with #ifndef guards, but that is just an optimization. With #ifndef guards, the compiler can safely read any file it isn't sure it has seen already; if it's wrong, it just has to do some extra work. As long as no two headers define the same guard macro, the code will compile as expected. And if two headers do define the same guard macro, the programmer can go in and change one of them.
#pragma once has no such safety net -- if the compiler is wrong about the identity of a header file, either way, the program will fail to compile. If you hit this bug, your only options are to stop using #pragma once, or to rename one of the headers. The names of headers are part of your API contract, so renaming is probably not an option.
(The short version of why this is problematic to use #pragma is that neither the Unix nor the Windows filesystem API offer any mechanism that guarantees to tell you whether two absolute pathnames refer to the same file.)
I beg your pardon if this question has been already answered, but I have been trying to implement precompiled headers in my game engine with no success so far.
My precompiled header is called UtilBase.h:
#pragma once
#if !defined(NF3D_UTIL_BASE_H)
#define NF3D_UTIL_BASE_H
// This is a precompiled header.
#pragma message("Compiling precompiled header.")
// Include engine specific files.
#include <Utilities\Platform\Types.h>
// Include external header files (STL, Win32 API, Direct3D 11, etc)
// There are some typedefs here:
typedef __int32 int32; // And so on.
#endif
Although this is against the standards, I included UtilBase.h in other headers because I need access to some of its contents. It is also included in all .cpp files, first line, from the current project (the solution has two projects).
I need it in some headers because it stores some typedefs that are used in function declarations. For example, I have some file called Window.h:
#pragma once // And include guards that are omitted here
int32 NF3DCreateWindow();
The associated source file is called UtilBase.cpp and has only one line of code:
#include <Utilities\UtilBase.h>
The project has been set up correctly in my opinion:
for all platforms and configurations.
UtilBase.cpp has this setting:
However, when I compile I get this error:
1>Source Files\Utilities\UtilBase.cpp(2): error C2857: '#include' statement specified with the /YcD:\New Frontiers\NewFrontiers3D\Header Files\Utilities\UtilBase.h command-line option was not found in the source file
which points to the only line in UtilBase.cpp (#include <Utilities\UtilBase.h>).
Why does this happen and what can I do to make it work? I will gladly send any further information about this scenario. Thank you very much in advance.
Finally made it! For anybody in my situation here is what I did: in project settings, Precompiled Header File tag, I added $(ProjDir)\Header Files\Utilities\UtilBase.h and it was evaluated to the full path of the file. The correct way is to simply add the file: Utilities\UtilBase.h and that's it.
Thank you for your support.
try #ifndef instead of #if !defined
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)
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