Q for Roberto et al. Are #includes evil?

[Roberto Raggi]

Hi Steven,

Q for Roberto et al. Are #includes evil?
A: YES!! 

the preprocessor (not only the #include directive) is evil! Well at least for 
applications like KDevelop, but the preprocessor is very useful for many 
other applications. I mean the preprocessor is a Tool and as all the other 
tools it has PRO and CONS.

I'm sure you'll find these papers interesting
https://netfiles.uiuc.edu/garrido/www/publications.html

ciao robe


On Wednesday 08 September 2004 01:33, Steven T. Hatton wrote:
> 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.