A New Krazy Checker for #include

[Thomas Zander]

On Sunday 08 April 2007 19:28, Allen Winter wrote:
> Other ideas that I may implement one day (or maybe someone will do me):
> - if including an installed header, always use #include <foo.h>, not
> "foo.h"

We had some people on IRC all getting entirely confused about this 
point ;)
So let me summarize the points we found.  As Allen asked so nicely;
  "15:41 < winterz> please, please somebody (with a still functioning 
brain) document all this on techbase"
I hope others can correct my mistakes and put the result up on techbase.

intro:
  bar.h
    #include "foo.h".
includes foo.h from the same dir as where bar.h was found.  Note that this 
can be a different dir than the current dir.

  foo.h
    #include <bar.h>
includes bar.h from the first directory it exists in passed to the 
compiler using -I[path] argument.

Directions:
Using files using "..." when it is in the same directory is thefore a good 
idea as it is pretty standard that the two files in that same dir are of 
the same version.  And using "..." style includes therefor avoids any 
conflict of having an outdated version of either file.
So, to avoid problems you should use ".." style includes when the included 
file is in the same directory as the file doing the including. This is 
true for both cpp and header files.

As soon as the files are not in the same directory this rule fails.  For 
example using relative directories ("../bar.h" or "subdir/bar.h") should 
be avoided as moving around files breaks things.
For this and all other cases use <..>

Note that things tend to work OK using <..> most of the time. Its just 
quite a bit less fragile using ".." when possible.

-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070409/855aedde/attachment.sig>