Properly use #include <> and #include ""

[Matthias Kretz]

On Friday 15 June 2007, Michael Olbrich wrote:
> Please don't use "" for _any_ installed header. This can result in very
> confusing errors.

My statement was: Please don't use <> for _any_ installed header. This can 
result in very confusing errors.

> ----- /usr/include/a/foo.h --------
> #include "bar.h"
> ...
> -----------------------------------
>
> ----- /usr/include/a/bar.h --------
> // something
> -----------------------------------

I'd assume a/foo.h and a/bar.h to belong to the same lib or at least libs that 
have some relation (like kdecore and kdeui). That means if I include a header 
of that lib I want all the dependent headers from the same version of that 
lib.

I.e. if I include <foo.h> (knowing it'll pick the header a/foo.h) then I'd 
expect it to include all dependent headers from a/ and not some other version 
or even other unrelated lib in some other dir.

> ----- /usr/include/b/bar.h --------
> // something else
> -----------------------------------
>
> /usr/include/b/foo.h does _not_ exist.
>
> ----- test1.c ---------------------
> #include <foo.h>
> ...
> -----------------------------------
>
> ----- test2.c ---------------------
> #include <bar.h>
> #include <foo.h>
> ...
> -----------------------------------
>
> compiling with -I/usr/include/b/ -I/usr/include/a/

test1.c I'd expect to always compile fine. I'd expect test2.c to fail only if 
a/bar.h and b/bar.h use the same include guard. (Now here's a good reason why 
you should namespace your include guard, too. E.g. all my Phonon headers have 
guards of the form PHONON_CLASSNAME_H.) If a and b are incompatible versions 
of the same lib then you're supposed to get compile errors - if you don't 
debugging can get really hairy.

> gets different 
> results for test1.c and test2.c. That is imho wrong. The order in which
> headers are included and whether they are included directly or
> indirectly (via another header) should never change the result.

Can you make your example a bit more concrete? So far it looks designed to 
break. Any real world examples?

Have you read the rationale on 
http://techbase.kde.org/Policies/Library_Code_Policy#As_library_developer ?

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- 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/20070616/71627eb6/attachment.sig>