This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC - Next refactoring steps


On Fri, Sep 6, 2013 at 10:14 AM, Mike Stump <mikestump@comcast.net> wrote:
> On Sep 5, 2013, at 11:54 PM, Richard Biener <richard.guenther@gmail.com> wrote:
>> Most of the GCC headerfiles do not include all their required headers but
>> rely on .c files doing that (in the appropriate order).  I somehow like
>> that though I cannot explain why ;)
>
> Very old school.  I can explain why I don't like it, but I'll resist.  The universal standard is for each header to include all it needs and for the ordering of includes not to matter any.  Deviations from this are the exception and should virtually never should be the case.
>
>> Also grepping for #includes I see that this doesn't seem to be true anymore.
>
> Yeah, everyone else hates the old school style with a passion, it was never a good idea.  :-)  When they come across it, people have a tendency to fix the headers as broken and over time, all the dependencies eventually get added.

Well, I still think you cannot randomly change include file order in
GCC.  At least some

#ifdef ...

hackery in some headers will suddenly break (that is, change outcome)
if you include for example
tm.h before or after it.

But yes, making all dependencies explicit puts #includes where they
belong and shows where
header refactoring would make sense.  It also removes weird includes
from .c files that are
only necessary to make included required headers not break.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]