There are some cases when we include .cpp file instead of standard header file (.h), for example:
#include \"example.cpp\"
instead of
There are legitimate uses for #include "impl.cpp"
:
testing for access to static/etc variables
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.
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.
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.)
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.