pre compiled headers
Author
Hello
I am rewrting my game achitecture because it had got large and unwieldy. I have done this before and made solid improvements but this time I want to have a closer look. One glaring omission has been the absence of and precompiled header because I never could decide what I should and shouldnt have in there.
I am beginning from a new project(VS7) and have "Use Precompiled Header (/Yu)" selected for use with stdafx.h. All is good but I thought there would be many smaller headers that may only be needed in one source file so that I would levae them out of the PCH. Is it true therefore that I need to inlude the PCH at the top of every source file and then place other 'more local' headers below that?
Can I have 2 or more PCHs?
Can anyone provide me any general philosophies as to what should and should not go in the PCH?
Thanking you kindly in advance for your help ;)
Quote:
Is it true therefore that I need to inlude the PCH at the top of every source file and then place other 'more local' headers below that?
Yes this is true, well I don't know if you can place local headers above the precompiled header, but at least you need the precompiled header in every source file.
I use the precompiled header for three kinds of includes,
1) My own includes which is always needed, stuff like identifying compiler with the preprocessor, detecting endianess etc.
2) Third-party headers I will use in most files, sstream, utility, algorithm, boost/shared_ptr.hpp, boost/thread/thread.hpp etc.
3) Projects this project depend on, for example EngineCore's precompiled header will include EngineBase.hpp and EngineMMGR.hpp.
Also what would you need two precompiled headers for? You need to include both anyway so why not just put the content in one.
Author
good point about the 2 headers. Didn't quite understand the content of your point number 1...but thanks a lot for providing your thoughts.
Quote:Original post by bobbinus
good point about the 2 headers. Didn't quite understand the content of your point number 1...but thanks a lot for providing your thoughts.
If you by point number 1 mean the first kind of headers, then they mostly contain preprocessor stuff, for example if you have programmed DLLs before you probably know that something like this is normally done:
#ifdef _MSC_VER#ifdef PROJECTNAME_EXPORTS#define PROJECT_NAME_EXPORT_OBJ __declspec(dllextern)#else#define PROJECT_NAME_EXPORT_OBJ __declspec(dllimport)#endif#endifThis is the kind of stuff I would classify as a number 1 header. You might not have this kind of stuff in your project, but I have plenty other kind of stuff I have here is a macro pre-fixing L to strings when UNICODE is defined (_T). Another thing I have as a header 1 is detecting of compiler and platform, like this (this is taken directly out of my own headers, M2A is the name of my project):
#ifdef _MSC_VER# define M2A_COMPILER_MSVC# define M2A_COMPILER_VER _MSC_VER# if M2A_COMPILER_VER == 1400 // 1400 = 8.0 = 2005# define M2A_NATIVE_COMPILER_VER 80# define M2A_COMPILER_NAME vc80# elif M2A_COMPILER_VER == 1310 // 1310 = 7.1 = 2003# define M2A_NATIVE_COMPILER_VER 71# define M2A_COMPILER_NAME vc71# elif M2A_COMPILER_VER == 1300 // 1300 = 7.0 = 2002# define M2A_NATIVE_COMPILER_VER 70# define M2A_COMPILER_NAME vc70# else# error Can't identify versions of MSVC below 7.0.# endif#else# error Compiler could not be identified#endif#ifdef M2A_COMPILER_MSVC# ifdef _M_IX86# define M2A_ARCHITECTURE_X86# else# error MSVC cant identify CPU architecture# endif#else# error Code for finding CPU architecture with this compiler haven't been added.#endifThis kind of code can be very useful when you need a way to identify the architecture on different compilers.
One of my precompiled headers look like this:
#ifndef M2A_BASE__STDAFX__HEADER#define M2A_BASE__STDAFX__HEADER#include <sstream>#include <algorithm>#include <vector>#include <iomanip>#include <cassert>#include <boost/static_assert.hpp>#include <boost/tuple/tuple.hpp>#include <boost/thread/thread.hpp>#include <boost/thread/tss.hpp>// The following header:// - detects compiler, endianess and architecture// - Provides useful macros like _T and STRINGIFY// - Gives a common interface ( for example define DEBUG and _DEBUG if one is defined, so that the following code can just check for one of them)#include "global/config/config.hpp"// The next header give types for stuff like hash maps, a typedef for strings (std::string or std::wstring depending on what was detected in the previous header)#include "global/types/types.hpp"// Defines stuff specific to this project, like M2A_BASE_EXPORT_OBJ = __declspec(dllextern) if the current project is compiled.#include "m2abase/config/config.hpp"#endifIf you need more info or doesn't understand something just ask.
Here is the header file I use for every project. I uncomment the files I need.
#pragma once/********************************************************************************************************************//* Windows header files *//********************************************************************************************************************///#define STRICT//#define WIN32_LEAN_AND_MEAN//#define NOMINMAX#pragma warning( push, 3 ) // Some of the system headers generate warnings at level 4//#include <windows.h>//#include <objbase.h>//#include <atlbase.h>//#include <atlcomcli.h>//#include <msxml2.h>//#include <mmsystem.h>//#include <scrnsave.h>/********************************************************************************************************************//* Direct X header files *//********************************************************************************************************************/#if defined( _DEBUG ) #define D3D_DEBUG_INFO#endif//#include <d3d9.h>//#include <d3dx9.h>//#include <dinput.h>//#include <dsound.h>//#include <dxerr9.h>/********************************************************************************************************************//* OpenGL header files *//********************************************************************************************************************///#include <gl/gl.h>//#include <gl/glu.h>//#include <gl/glaux.h>/********************************************************************************************************************//* Standard Library header files *//********************************************************************************************************************///#include <algorithm>//#include <bitset>//#include <cassert>//#include <cmath>//#include <cstdio>//#include <cstdlib>//#include <cstring>//#include <ctime>//#include <deque>//#include <errno.h>//#include <exception>//#include <fstream>//#include <functional>//#include <ios>//#include <iosfwd>//#include <iostream>//#include <istream>//#include <limits>//#include <list>//#include <locale>//#include <map>//#include <memory>//#include <new>//#include <queue>//#include <sstream>//#include <stack>//#include <string>//#include <vector>//#include <xutility>#pragma warning( pop )/********************************************************************************************************************//* Library header files *//********************************************************************************************************************///#include <boost/noncopyable.hpp>//#include <Dxx/Dxx.h>//#include <Misc/Assert.h>//#include <Misc/Etc.h>//#include <Misc/exceptions.h>//#include <Misc/max.h>//#include <Misc/Random.h>//#include <Misc/SafeStr.h>//#include <Misc/Singleton.h>//#include <Misc/Trace.h>//#include <Misc/Types.h>//#include <Wx/Wx.h>
Author
If I have headers that are changing regularly or even once in a while should I put them in the PCH?
Absolutely not until the header is (relatively) stable. Your whole project will recompile every time you touch that header if it is in the PCH.
You can have multiple PCH's in your project... I skimmed this tread and didn't see it mentioned.
But if you find you haven't touched a header in a week or so it's a good candidate for PCH status.
But if you find you haven't touched a header in a week or so it's a good candidate for PCH status.
Author
Well I was a little confused when I mentioned having 2 PCHs. What I really want to know is your thoughts on organising headers in general. I know it can't be black and white but in my project which is getting quite sizey there is often headers that apply to subsets of files etc... is it a good idea, in terms of reducing the amount of code in source files, to have header files that purely have a bunch of include directives and then include that header in the approriate source files? Or is this just a case of outsmarting oneself?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
