4 ms·

What does that mean? Import for C doesn't make sense to me because 1) C code is never executed during compilation, and 2) C doesn't even support bare code, ever

What does that mean? Import for C doesn't make sense to me because 1) C code is never executed during compilation, and 2) C doesn't even support bare code, everything has to exist inside a function. So what would be the desired behavior from import in C?

lights0123 6y ago
disclaimer: I'm a Rust dev. * ability to reference other files in a manner other than copy/pasting - allowing the compiler to understand when it should cache what it already knows, instead of having to set up and deal with precompiled headers for large projects - ability to treat a header file as a single unit and not leak preprocessor defines * treating many files as a single compilation unit, leaving LTO to only be needed when linking to a library
sumtechguy 6y ago
I can take a stab at it. I think what trips many new C people is the fact that include is just what it says on the tin, include. You can put anything in there and it is subject to the pre-processor. Many books/faqs/stackoverflow/videos however implicitly tie library include and headers together. So the idea that include means include this library comes somewhat from that. It tripped me up some 27+ years ago when I started on C. The actual include a library comes from a different part of the system, the linker. The includes just handily have the bits needed to have the external references to it so the linker knows what to do. You do not need them in the include to do that. Since they were including those they usually have predefined bits in there. Like you say pythons import is a different beast and it can run code at runtime when it comes across that statement. Some training is not clear on that. Like you point out import does not just import the file it runs the thing. If the file only contains def's then it effectively just defines a bunch of functions/objects and does nothing else But it can. C is not like that. It is more copy the whole file here and apply the current state of pre-processor rules.
- m463 6y ago
  yes, includes are pretty much all syntactic, no semantic.

lights0123 6y ago

disclaimer: I'm a Rust dev. * ability to reference other files in a manner other than copy/pasting - allowing the compiler to understand when it should cache what it already knows, instead of having to set up and deal with precompiled headers for large projects - ability to treat a header file as a single unit and not leak preprocessor defines * treating many files as a single compilation unit, leaving LTO to only be needed when linking to a library

sumtechguy 6y ago

I can take a stab at it. I think what trips many new C people is the fact that include is just what it says on the tin, include. You can put anything in there and it is subject to the pre-processor. Many books/faqs/stackoverflow/videos however implicitly tie library include and headers together. So the idea that include means include this library comes somewhat from that. It tripped me up some 27+ years ago when I started on C. The actual include a library comes from a different part of the system, the linker. The includes just handily have the bits needed to have the external references to it so the linker knows what to do. You do not need them in the include to do that. Since they were including those they usually have predefined bits in there. Like you say pythons import is a different beast and it can run code at runtime when it comes across that statement. Some training is not clear on that. Like you point out import does not just import the file it runs the thing. If the file only contains def's then it effectively just defines a bunch of functions/objects and does nothing else But it can. C is not like that. It is more copy the whole file here and apply the current state of pre-processor rules.

m463 6y ago
yes, includes are pretty much all syntactic, no semantic.