+------------------------------------------------------------------------------
| On Tuesday, Mar 28, 2006 at 08:30:37PM +0200, Thiago Macieira wrote:
| 
| To: kde-devel@kde.org, kde-core-devel@kde.org
| From: Thiago Macieira <thiago@kde.org>
| Date: Tue, 28 Mar 2006 20:30:37 +0200
| Subject: Qt #include forms
| 
| Joshua J. Berry wrote:
| >Recommended for KDE, or for Qt?
| >
| >I'm just a Qt4 newbie, but I've been working my way through Trolltech's
| >tutorial (and the API reference), and as far as I've seen they never use
| >that form anywhere in their documentation.
| >
| >If that is the recommended form, why doesn't Trolltech use it?
| 
| Cross-posting to kde-core-devel to clarify the issue.
| 
| You are probably looking at Qt source code. Taking one file as an example 
| (src/corelib/tools/qstring.cpp), we find:
| 
| #include "qstringlist.h"
| #include "qregexp.h"
| #include "qunicodetables_p.h"
| 
| But if you look into a header file (kernel/qvariant.h>, you'll see:
| #include <QtCore/qmap.h>
| #include <QtCore/qstring.h>
| 
| If you looks at http://docs.trolltech.com, you'll see that the recommended 
| form for using QStringList is:
| 
| #include <QStringList>
| 
| Yet I've been telling people to use
| #include <QtCore/QStringList>
| 
| Which form is correct?
| 
| Technically speaking, all of them are correct, provided you passed the 
| correct -I options to your compiler, in your buildsystem. And Qt is 
| compiled using qmake, which passes all the options to the compiler by 
| default. In KDE code, using cmake, we will do that too.
| 
| However, I recommend that for header files, you only use the forms:
| #include <QtModule/QClass>
| or
| #include <QtModule/qclass.h>
| 
| The reason for that is it requires less -I options to the compiler. If 
| someone wants to write a quick Qt program, all he needs to set 
| is -I$QTDIR/include and use that form. But that will only work as long as 
| ALL headers that he includes do it in that form.
| 

It is also nice for those reading your code. I imagine the problem with
doing MODULE/CLASS format is if CLASS moves to another module, then all
the source that uses that CLASS will need to be updated.

I suppose that just being up to speed on QT and where classes are is all
that really matters just using <CLASS>.

I think it is more than just an include issue, but more importantly an issue
of maintaining code and flexibility in the future without breaking things 
much :)


Thanks,
Chris


ps -> Now, to just get rid of those <OS/STANDARD_INCLUDE_FILENAME> source lines 
      and all will be right with the world. (psst, it was a joke if it was missed)

| -- 
| Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
|   thiago.macieira (AT) trolltech.com     Trolltech AS
|     GPG: 0x6EF45358                   |  Sandakerveien 116,
|     E067 918B B660 DBD1 105C          |  NO-0402
|     966C 33F5 F005 6EF4 5358          |  Oslo, Norway



|  
| >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


-- 
Chris Humphries
a programmer with free time, sometimes.

AIM: unixfudotnet, Blogs: http://blogs.unixfu.net/
Email: chris@unixfu.net, IRC: chumphries (freenode)

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<