Q for Roberto et al. Are #includes evil?

[Steven T. Hatton]

I've been reading through the various parts of the KDevelop code related to 
parsing C++.  For example the lib/cppparser/ast.cpp.  It seems reasonable 
that the people who wrote this code would have significant insight into 
whether my ideas about the #include preprocessor directive are well founded, 
and reasonable.  So I ask for your opinion on the following:

I have convinced myself that the #include is perhaps C++'s greatest liability.  
Much of this comes from the difficulty I had in learning to work with 'header 
files' when first learning C++.  But my dislike for #inclusion has survived 
my newbie phase.  I still believe it is kludge waiting for a solution.  Here 
are some of the reasons I believe they are bad:

* #includes obscure the concept of translation because they can be nested;

* this makes the concept of 'file scope' unclear in many contexts;

* a single #include can drastically change the content of a translation unit 
making it far more difficult to parse  translation units for purposes of code 
completion or validity checking 

* #including is monolithic and introduces significant amounts of superfluous 
content into the translation unit forcing the compiler or IDE to parse and 
otherwise consider far more content than is relevant to the user code being 
supported

* #including is redundant in that it is a means of introducing content into a 
translation unit, and this content is already uniquely specified by the fully 
qualified identifier of the type being imported.  This means the programmer 
and/or IDE must manipulate more information than is logically required.



Both Java and C# have placed the burden on the implementation to resolve the 
mapping between fully qualified identifiers and external entities based on 
an /import/ statement, or the occurrance of the fully qualified identifier in 
the body of the code.  I believe this could be accomplished for C++ as well.  
I also believe it would greatly improve the usability of the language, and 
also improve the performance of compilers and tools such as IDE that provide 
code completion and validation.

I also believe the CPP support in KDevelop provides 50% or more of what would 
be required to accomplish the goal of providing the superior mechanism.
-- 
Regards,
Steven