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 09/06/2013 04:19 AM, Richard Biener wrote:
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.

these would be really good to identify and fix, if possible. (surely they can be fixed.. :-) if they cant be fixed for whatever reason, we ought to protect them with some mechanism.. ie assert that tm.h either has or has not been included before hand... whichever way is required. At least then we get an error if it changes.

Do you know of any of the top of your head?

Andrew


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