Correct format of #include directive

Question

What's the correct/recommended way to include a file? I'm getting trouble with inclusion (VS2005 compiler...).

I know the correct way is this:

#include "source.cpp"

or this:

#include <source.cpp>

Could # include "source.cpp" cause problems (added space after #)? Some of my team mates use that way and we are getting an unsolved problem.

The point I'm including a source file is that I'm developing under and IDE which doesn't allows to define functions in it's editor due to they'll become local functions.

_Could # include "source.cpp" cause problems?_ Are you asking about the space after `#`? — SingerOfTheFall, Sep 29 '15 at 07:46
The answer is that *none* of those formats are correct, because you should not include source files. — Some programmer dude, Sep 29 '15 at 07:49
@joachim These formats aren't incorrect. They may be bad style, but not incorrect. C++ (as a language) doesn't care about filenames or extensions... Poor file naming or other poor decisions do not make bad code incorrect. — rubenvb, Sep 29 '15 at 07:50
@Joachim It can be useful to #include include source files.. particularly when unit testing embedded firmware code since it gives you access to static functions from outside the module. — Pete, Sep 29 '15 at 07:51
@Pete The cases where preprocessio-inclusion of source files are legitimate is, IMO, fewer than the cases where `goto` can be legitimate. — Some programmer dude, Sep 29 '15 at 07:52
@Joachim I would argue that it is round the other way! Unit testing being the prime example. goto can always be avoided with well structured code. — Pete, Sep 29 '15 at 07:55
Your last paragraph makes no sense. You're never allowed to define local functions. — molbdnilo, Sep 29 '15 at 08:02

score 3 · Answer 1 · edited May 23 '17 at 12:24

#include "source.cpp"
# include "source.cpp"

Those are correct (space does not lead to any issue even if pointless) even if not recommended, see this post: Include .cpp file?

At some point I already included .cpp files in my code to do a kind of static import of some other code. But that's definitely not recommended because it leads to lots of problems. For instance, if the same cpp file gets included twice, static objects created by the file will be created twice too...so they are not static as they were supposed to be. Also, compiler may get lost because some functions get defined twice...

syntagma · Answer 2 · 2015-09-29T08:00:50.680

According to the C preprocessor documentation in the GCC manual, you can use whitespace after # in the preprocessing directive (e.g. #include):

Preprocessing directives are lines in your program that start with #. The # is followed by an identifier that is the directive name. For example, #define is the directive that defines a macro. Whitespace is also allowed before and after the `#'.

Therefore that space is definitely not the issue in your case and all of the following are correct: # include <file.h>, #include <file.h>, # include <file.cpp>, #include <file.cpp>, though you should avoid using last two and always include header files.

Having said that, I would advise you to do not use any whitespace after # - your code will be more readable then, as #include is what is used almost all the time and what many code formatters will format your code to anyways.

The C++ standard also states the same on that matter, see: 16.3 Macro replacement [cpp.replace].

score 2 · Accepted Answer · answered Sep 29 '15 at 07:52

To answer your question: no, the space cannot cause an issue. It is perfectly legal to have whitespace (spaces and tabs) between the # introducing a preprocessing directive and the directive's name. VS2005 is sufficiently modern to honour that.

However, what is very strange is that you're apparently including a source file (.cpp) and not just a header file. While technically there's nothing wrong with that, it's quite likely that is not what you really want to do. You didn't specify what errors you're getting, but double definition errors would be a typical class of error caused by including a source file (and compiling it separately as well).

score 2 · Answer 4 · answered Sep 29 '15 at 07:53

The standard specifies the following rule for spaces in preprocessor directives (16/4):

The only white-space characters that shall appear between preprocessing tokens within a preprocessing directive (from just after the introducing # preprocessing token through just before the terminating new-line character) are space and horizontal-tab (including spaces that have replaced comments or possibly other white-space characters in translation phase 3).

Both # and "filename"/<filename> are preprocessing tokens, so you can have as many whitespaces between them as you want.

Correct format of #include directive

4 Answers4