Properly use #include <> and #include ""

[Matthias Kretz]

On Sunday 17 June 2007, Michael Olbrich wrote:
> On Sat, Jun 16, 2007 at 11:41:07AM +0200, Matthias Kretz wrote:
> > 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
> > ?
>
> I have, and I think it is wrong.

Let's see if I can summarize your reasoning correctly:
You think it is wrong because the include guard of two header files with the 
same file name (but different paths, and headers from different libs) could 
use the same include guard and lead to an error that's too hard to find. 
Therefore you'd like the build to break as soon as there are two header files 
of the same file name anywhere in the include directories.

Example:
a) libs are using <> for includes
 Let's assume you want to make use of two libs in your app (staying with 
libxyz and anotherlib). You've successfully used them for a first release. 
Now at some point the build breaks because a newer version of libxyz 
introduced the header foo.h and includes it from xyz.h. What are you as 
application developer to do about that error? You cannot ask the lib 
developers to rename the header file - it's part of their public API now. 
From your reasoning the application is simply screwed and has to include a 
patched version of one of the libs in order to fix the build again.
b) libs are using "" for includes
You as application developer tell the libxyz developers about the problem of 
the include guard being the same for xyz/foo.h and anotherlib/foo.h and if 
they care only a little about their users they'll go ahead and change the 
include guard for the next minor release. Build fixed.

> To use the given example: I think 
> "g++ -I/usr/include/anotherlib -I/usr/include/libxyz ..." should
> _always_ fail.
>
> The problem is the following:
> Many libraries use the same method to generate the include guards.

How about we add another policy for include guards then? It could e.g. say 
that the include guard has to be prefixed with the name of the library.

> If we use <> instead, all source files will break and the error is much
> easier to recognize.

The error is still not easy to recognize. I guess for both cases the best 
thing is to look at the output of the preprocessor. And then none of the too 
is really easier to recognize.

-- 
________________________________________________________
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/20070618/7e802c21/attachment.sig>