On 11-01-01 06:28 PM, Ted Kremenek wrote: > Suppose FOO is defined by the including source file, or by *another header* > that includes that header. Sometimes headers aren't fully self-contained; > they are intended to be used in the context of other headers. One can argue > whether that is good or bad practice, but it does happen. Thus context > matters here as well; in this case, it can change what is actually valid > source code defined by the header, and what isn't. > > Another example is a header that can be included by both an Objective-C or > Objective-C++ source file. In one case it is Objective-C code, and in the > other case it is Objective-C++ code. The difference can really matter in > some cases. > > Ultimately, no source file, whether it is a header or a vanilla .c file, has > any intrinsic semantics until is parsed, in the full proper context, by the > compiler. That context includes all the -I and -D flags, etc. Since headers > are inherently tied to the preprocessor, they can be used in all sorts of > ways, and so ultimately their semantics are determined by the file that > includes the header. That said, you can often skirt the issue with > approximations, but if you are interested in replicating the semantics of a > header that is seen by the actual developer in their project, headers need to > be analyzed in the context of how they are actually used.
Given that there is all this context sensitivity, why don't we obey the caller when the caller tells us that a given file is C++, and instead go "oh, it is .h, it must be C"? Sean _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
