24

There are some cases when we include .cpp file instead of standard header file (.h), for example:

#include "example.cpp"

instead of

#include "example.h"

It seems to work but is this safe or should I avoid it?

What about the compilation time?

sysop
  • 800
  • 2
  • 9
  • 18
  • 1
    It's as safe as you make it. It shouldn't generally be necessary. Programming isn't about blindly following some cargo plane, but rather about *understanding* what you're doing and making decisions based on understanding and reasoning. – Kerrek SB Feb 12 '12 at 23:38
  • 1
    The only valid reason I've ever seen for doing this is to save on link time. [Unity Build is explained here](http://stackoverflow.com/questions/543697/include-all-cpp-files-into-a-single-compilation-unit). – Ben Voigt Feb 12 '12 at 23:40
  • 1
    @sysop: As I said: **understand** what you're doing, and asking, first. Includes are processed by the *preprocessor*, long before any compiling happens. Understand the preprocessor and you will know when it's OK to include things. – Kerrek SB Feb 12 '12 at 23:42

4 Answers4

21

It's lazy coding. Use header files. Yes they can increase compile time but they mean that you can easily re-implement chunks of your code, or better yet, another developer could at anytime. The header file serves as a template for what your C/C++ code is going to do. It's a bad idea to discard or ignore it.

zellio
  • 31,308
  • 1
  • 42
  • 61
  • I'm always use .h, but we have quite debate here and that's why I ask. – sysop Feb 12 '12 at 23:48
  • 2
    @sysop -- to be fair, "It's lazy coding" is a bit hyperbolic. There are cases where it might actually be the right thing to do, but in the general case I would argue that it's poor form. – zellio Feb 12 '12 at 23:59
  • 8
    Including `.h` files instead of the `.cpp` files can **speed up** compile time a lot because it lets you do partial recompilations. – tom Feb 13 '12 at 06:05
8

I agree with Kerrek SB.

I did this once. I was building an excellent, widely used compression library that needed to be built separately for 8-bit images and for 12-bit images. The cleanest way I could come up with to fit this into the build system was (oversimplifying a bit) to have two master .cpp files, one that set #defines for an 8-bit build, the other for a 12-bit build. The master .cpp files then #included the source files of the compression library.

It's okay to not follow a general rule if you understand the rule well enough to know the reasons for it and why it might not apply in your case. (But those cases ought to be rare.)

Dan K
  • 720
  • 10
  • 8
3

There are legitimate uses for #include "impl.cpp":

  1. testing for access to static/etc variables

  2. ad hoc templates like these if c++ template mechanism proves inadequate (rare)

    #define MACRO (...)

    #include "impl.cpp" // uses MACRO

Note that #include "impl.cpp" can be unsafe it same file is included in separate compilation units that are later linked together.

Dima Tisnek
  • 11,241
  • 4
  • 68
  • 120
1

I have used it before and had no problem but I cannot ensure that this is safe. Sometimes this was the only option for me so I used it, otherwise I will use the .h file.

Joqus
  • 585
  • 5
  • 19