How to understand header files?

Question

Eclipse

Started migrating VS2013 project to Eclipse IDE (G++). The project itself consists of one .cpp file and several .h files that are connected to it (and some of them to each other) via #include "%filename%.h".
As far as I could google, there are some "sort of" conventions about how code should be placed in header files. In particular, now Eclipse (or the compiler? ..) point-blank does not want to see data (classes and functions) from included files, you have to write externs and prototypes, what to do for, in general, a rather large number of functions and classes especially want.
Until such a close acquaintance with the subject, I did not attach importance to the fact that the file itself is also a relatively isolated concept. According to the logic (which Visual Studio also adhered to), if it is indicated where to substitute it, you just need to substitute everything that is in the file. Now new details are being revealed that I would like to overcome as painlessly as possible.
Therefore, the main question is this: how in C++ to simply stick all the code from a file to the specified location without creating billions of .h/.c/.hpp files with prototypes, implementations, and other #ifdefs, #ifndefs, extern, etc. with them?

Answer 1

#include - oddly enough.
You never understood such a thing as a "compilation unit". The fact is that in C c-files are compiled independently of each other (the linker collects everything into a single program). And to say "it is, only in a different compilation unit", they use prototypes and externs.
And if you just want to put the code in the same compilation unit, just write it in the header, that's all. Only in most compilers does this exclude precompiled headers - and you probably don't need to precompile SUCH headers.
<grunt mode on>
Don't generate code (which means it's in the headers in a traditional system with lots of compilation units)
• extern and prototypes
• inline
• not fully specified templates
• static fields in the class (but then this static field will have to be repeated in some one compilation unit)
• maybe something else, but I forgot ...
<grump mode off>