4 ms·
"Basically, the compiler has a state which can be modified by these directives. Since every .c file is treated independently, every .c file that is being compil
by roel_v 8y ago
"Basically, the compiler has a state which can be modified by these directives. Since every .c file is treated independently, every .c file that is being compiled has its own state. The headers that are included modify that file's state. The pre-processor works at a string level and replaces the tags in the source file by the result of basic functions based on the state of the compiler."
I almost sort of get what the author means here but then I don't really. I mean, there is no 'state' for the compiler that is modified by precompiler directives, so this is probably an analogy or simplification he's making here, but I don't really understand how he gets to the mental image of 'compiler state'. Why not just say it like it is: the preprocessor generates long-assed .i (or whatever) 'files' in memory before the actual compiler compiles them, the content of which can be different between compilation units, because preprocessor preconditions might vary between compilation units?
- mbel 8y agoIt's neither an analogy nor simplification. When he speaks about "compiler state" he means "preprocessor symbol table state". When preprocessor processes a file its state is mutated -- symbols get defined, redefined or undefined. What you propose as a replacement (an in-memory file) does not provide any insight into why the same file preprocessed twice may end up looking different or why order of included files matter.
- roel_v 8y agoWell in that case, I guess it's a definition thing. When I teach C++, I find it much more useful to make a clear separation between 'preprocessor' and 'compiler', and not make the preprocessor part of the compiler and then make the... uh... 'actual compiler' also part of the compiler. When you take the preprocessed state of a compilation unit, by having the preprocessor write it out to disk, and show someone what the effects are of passing one or the other -D flag, or change the order of includes - that directly and concretely shows what is going on. And then this preprocessed file is passed on to the actual compiler. There is a clear separation between stages, easy to understand, and useful to boot when the time comes you have to debug an issue related to it and you want to look at the preprocessed file to see what's going.
- mbel 8y ago> I find it much more useful to make a clear separation between 'preprocessor' and 'compiler' Yes, I absolutely agree. And to be honest I cannot imagine explaining how preprocessor works without describing it as a separate entity.