when including libraries c, the line does not end with a semicolon, while other statements do. what is the reason behind this ?
+16
A:
Same reason #define macros don't -- they are for the preprocessor, which expands things like includes and defines before the compiler proper takes over.
JustJeff
2009-10-25 15:48:20
A little more definition - the pre-processor runs BEFORE the compiler gets to run, and it does replacement of text. A #include statement is replaced with the contents of the referenced file. A #define is entered into a lookup table, and then when the define is seen in the code, it is replaced with the stored value, etc, etc. You can in fact use another pre-processor instead of the standard one, but few people do so in the real world.
Michael Kohne
2009-10-25 15:54:43
isn't it also the preprocessor that does the funky line continuation things like \ and concatenating broken string literals?
JustJeff
2009-10-25 16:05:52
@JustJeff: see http://stackoverflow.com/questions/1476892/poster-with-the-8-phases-of-translation-in-the-c-language ; concatenating string literals is done in translation phase 6 between preprocessing (phase 4) and semantic analysis/compilation (phase 7), so you're free to do it in either preprocessor or compiler; joining lines along trailing backslashes takes place in phase 2 before the preprocessor proper gets to work
Christoph
2009-10-25 16:55:38
+9
A:
lines starting with a # aren't part of the C language itself, they are instructions for a pre-processor. When it was first designed, semi-colons just wasn't required.
Alister Bulman
2009-10-25 15:48:54
+4
A:
#include is a pre-processing command like #define. #include tells the compiler to include the specified file in your source code before your code actually gets compiled.
sdp07
2009-10-25 15:53:10
I fixed up the formatting for you; when you're typing an answer, you can look at the preview below the text box to see what it will look like. # is a formatting char, so you need to protect it in some way or another.
Stephen Canon
2009-10-25 15:56:47
+6
A:
"...while other statements do".
Firstly, preprocessor directives are not statements. Statement is an entity that exists at the syntactical/semantical level only. Preprocessor directives are processed at relatively early stages of translation, before any syntax analysis begins, so at that stage there's no such thing as "statement" yet. And, for this reason, there's no meaningful rationale to demand ending the #include directive with a semicolon. If fact, preprocessor directives by definition occupy the entire line, meaning that they are already terminated by a new-line character. Any additional terminator would be redundant.
Secondly, not all "other statements" end with semicolon. A compound statement, for example, doesn't
i = 5;
{ /* <- compound statement begins here... */
i = 10;
} /* <- ... and ends here. Note: no semicolon */
i = 15;
AndreyT
2009-10-25 19:00:29