> You have to write everything in a header file and then in an implementation file.
No you don't. You write your guaranteed to the public interface into the header file. When you start to put code in there it stops being a header file.
> because your headers will #include some library that is immense and then every header that includes that header will have transitive header dependencies
Your approach is what leads to this problem. Your header files should be tiny and only composed of, well, headers. Also almost all header files should have include guards, so including more then once should be a no-op.[1] Nothing stops you from including implementation files.
[1] When you say that your or compiler doesn't have that optimization: When it has the complexity to support precompiled header files, it can also implement this optimization.
No you don't. You write your guaranteed to the public interface into the header file. When you start to put code in there it stops being a header file.
> because your headers will #include some library that is immense and then every header that includes that header will have transitive header dependencies
Your approach is what leads to this problem. Your header files should be tiny and only composed of, well, headers. Also almost all header files should have include guards, so including more then once should be a no-op.[1] Nothing stops you from including implementation files.
[1] When you say that your or compiler doesn't have that optimization: When it has the complexity to support precompiled header files, it can also implement this optimization.