Structural differences between TnFOX and Qt

More about Qt can be found at http://www.trolltech.com/

Firstly, there exist API compatible classes for the following Qt classes:

FX::QBuffer (QBuffer)	FX::QBlkSocket (QSocketDevice)	FX::QDir (QDir)
FX::QFile (QFile)	FX::QFileInfo (QFileInfo)	FX::QHostAddress (QHostAddress)
FX::QIODevice (QIODevice)	FX::QMutex (QMutex)	FX::FXStream (QDataStream)
FX::FXString (QString)	FX::QThread (QThread)	FX::QTrans (tr())
FX::QWaitCondition (QWaitCondition)	FX::QByteArray	FX::QCache
FX::QCacheIterator	FX::QDict	FX::QDictIterator
FX::QFileInfoList	FX::QIntCache	FX::QIntCacheIterator
FX::QIntDict	FX::QIntDictIterator	FX::QPtrList
FX::QPtrListIterator	FX::QMemArray	FX::QValueList
FX::QPtrDict	FX::QPtrDictIterator	FX::QPtrVector
FX::QPtrVectorIterator	FX::QStringList	FX::QValueListIterator
FX::QValueListConstIterator

With the above, you can port most non-GUI related Qt code with very little rewriting. However, there are a number of structural changes to the API's which have been done because (a) FOX constraints demanded a different approach (b) Qt's solution was substantially below optimal and (c) Qt's approach makes multi-threaded code hard.

The first most obvious change is the complete absence of reference counting because it is fundamentally non-thread-safe - thus there is no implicit nor explicit sharing. This has two knock-on effects:

• Many more parameters in TnFOX take references rather than values for efficiency purposes and also returns tend to avoid a copy construction where possible by reorganising internal structures.
• A deep copy is performed each and every time a copy construction is made. This tends to break code subtly - if you had assumed that copies referred to the same data for explicitly shared items, then your code will need editing. Note that Qt actually breaks several C++ conventions in doing this - a copy should always mean a copy and passing a reference is the conventionally accepted way of semantically referring to someone else's data as though it were yours. Lastly, and obviously, if you make a lot of copy constructions, your performance will nosedive where it didn't under Qt.

The second less obvious change is that FXString is currently ASCII. When normal FOX finalises its support for unicode, I'll replace normal FX::FXString with FX::FXWString - however, QString is currently two-byte unicode whereas FXWString will be four-byte unicode. Most string processing using the API's won't need to know, but your code might.

Some API's have been slightly altered, whether to provide spelling corrections, remove irrelevent arguments etc. Generally speaking I've provided deprecated overloads to maintain old behaviour. Any Qt API's marked as deprecated in the documentation should be treated as such - do not use them in new code. Furthermore since the API semantics are different, how you wrote efficient code for Qt will not always be the same for TnFOX.

Lastly, TnFOX is fully exception-aware when Qt most certainly is not. Any line is assumed to be able to throw an exception at any time! - thus again your code may break in subtle ways - most likely being resource & memory leaks or causing your internal data structure to become corrupted or inconsistent. Look into TnFOX's transaction support which permits rollback actions to be undertaken when an error arises.

Note:

TnFOX was written to port a substantial Qt project written for Qt v2.x and v3.0. Hence later API additions or revisions may not be reflected here.

---

(C) 2002-2009 Niall Douglas. Some parts (C) to assorted authors.