Placing #Includes in an Included File
Author
When I do stuff I like to be as organized as possible. Easy navigation around a website, document, or anything else is a must. With my recent start of learning C++ (I've only had experience with BASIC before) some questions have popped up. Is it logical or even possible to "#include" a cpp or h file that only contains other includes? That way you could just say #include "includes.cpp", and add anything you need to includes.cpp, and your main source file wouldn't be all junked up at the top.
Yup it's possible, although you would probably name it "includes.h" instead of "includes.cpp". In Visual Studio projects, they set up a thing like this for you, but they call it "stdafx.h". What "stdafx" actually stands for, I have no idea.
Never include a .cpp file. While it's just a text file, your IDE interprets and handles it differently, meaning it will attempt to compile it. Much confusion will ensue.
There's nothing wrong with including a .h file in another .h file. Many development environment support something called precompiled headers, in which one .h file is created to include all the commonly needed headers, and a matching .cpp file is used to compile the declarations into object code ahead of time. You might want to look into it.
There's nothing wrong with including a .h file in another .h file. Many development environment support something called precompiled headers, in which one .h file is created to include all the commonly needed headers, and a matching .cpp file is used to compile the declarations into object code ahead of time. You might want to look into it.
Yes, it is possible to #include inside other #includes. However, it's bad form to #include a .cpp files; all files intended to be #included should usually be named .h. .cpp files are typically reserved for translation units (that actually get compiled).
However, including from other includes is often a bad idea, because if you change any of those included files, everything that indirectly includes it will have to be re-compiled. When your project has thousands of .cpp files in it, re-compiling everything because you changed a single header is no fun.
The alternative is to use forward declarations as much as possible. Thus, if you have a function called Foo which takes a class CBar pointer, then you can declare it in two ways:
// bad
#include "Bar.h"
void Foo( Bar * );
// good
class Bar; // forward declaration
void Foo( Bar * );
Then, inside Foo.cpp, you have to #include "Bar.h", but that's better than implicitly forcing that #include on everyone who includes Foo.h.
A great book about this is "Large-scale C++ software design," I believe by a guy named Lankos.
However, including from other includes is often a bad idea, because if you change any of those included files, everything that indirectly includes it will have to be re-compiled. When your project has thousands of .cpp files in it, re-compiling everything because you changed a single header is no fun.
The alternative is to use forward declarations as much as possible. Thus, if you have a function called Foo which takes a class CBar pointer, then you can declare it in two ways:
// bad
#include "Bar.h"
void Foo( Bar * );
// good
class Bar; // forward declaration
void Foo( Bar * );
Then, inside Foo.cpp, you have to #include "Bar.h", but that's better than implicitly forcing that #include on everyone who includes Foo.h.
A great book about this is "Large-scale C++ software design," I believe by a guy named Lankos.
Quote:Original post by pinacoladastdafx.h (and stdafx.cpp) is the pre-compiled header. "stdafx" breaks down as "standard afx"; MFC, WTL and a few other Microsoft frameworks use the "afx" prefix for a number of their internal structures and functions (these were created before the advent of namespaces).
In Visual Studio projects, they set up a thing like this for you, but they call it "stdafx.h". What "stdafx" actually stands for, I have no idea.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement