Properly use #include <> and #include ""

Michael Olbrich michael-olbrich at web.de
Mon Jun 18 10:24:06 BST 2007


On Mon, Jun 18, 2007 at 09:47:02AM +0200, Matthias Kretz wrote:
> 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.

and if I want to use xyz/foo.h directly and not xyz.h? Include xyz.h
anyways?

c) It's not in the same class: just provide the correct search path for
each source file.

The main question is: Is this a real life example? As far as I can tell
KDE3 uses a mixture of both versions. I have yet to find a real case
that matches your example.
On the other hand there are regular postings on the kde mailing list
from people who don't recognize that their compile errors are caused by
conflicting kde versions in the search path.

Another thing to consider: If "" is better why are other libraries like
libstd and qt using <>?

michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070618/4a30ae16/attachment.sig>


More information about the kde-core-devel mailing list