@vaporeon_ I am not a C expert by any means, but my exploration of C++ has taught me a few things. Header files in C++ have proven to be a headache in a lot of situations, and these are more or less fully inherited from C
Since you pull in everything present in a header file you pollute namespaces which can be a nightmare to manage in large projects
Plus header files induce some code repetition
For reasons I don't understand header files also make it difficult for C++ programs to compile quickly
@wallhackio @vaporeon_ well namepsace pollution is purrevented by #ifndef guards but the compiler still has to read the entire header file, even if the entirety of the content is guarded as therefur won't be inlined because it's being read a second or third or tenth time. now imagine deeply nested include chains repeatedly inlining the same header files over and over again
@aescling @wallhackio Just to make sure I understand you correctly: The preprocessor reads it again, removes all the parts between #ifndef and #endif, but the pre-processor re-reading the file is still costly enough that a deeply nested chain is slow?
@wallhackio @vaporeon_ in the early days of go the development team credited their fast compile times to the fact that they had entirely banned importing a dependency twice
@aescling @vaporeon_ in C++ land you avoid this sort of thing with namespaces
In my work's C++ code everything, and I mean everything, was namespaced like nebula::ffph::doAlgo so that there were no namespace collisions
@aescling @vaporeon_ it was a pain in the ass to write and read but this is what industry standard c++ looks like
@wallhackio Valid point about the namespaces, perhaps it's a thing that I don't really notice because I primarily use C and someone does notice if they primarily use another language
How would other languages do the thing that header files do? I never had a problem with header files in C...