Last week in Qt development (week 22 2012)
06.06.2012
This post is part of an ongoing series about developments and discussions in Qt.
Some parts of this report are still under discussion, and don’t necessarily reflect the final state of Qt 5. The target audience is people involved in Qt development itself, but without the time to follow everything that happens, and others with a strong interest in Qt, Qt 5, and the community.
This week we cover a rewrite of QVector for code sharing with QString and QByteArray, improvements in the printing system, efforts to make Qt build with some features removed.
QVector implemented with QArrayData interface
QArrayData is a new interface in Qt 5 to represent C++ classes which are sufficiently similar to C arrays, but which have features common to Qt value types such as implicit sharing, shared empty/null objects, raw data access, iterating over the data, and an expectation that the data is laid out in a contiguous block in (virtual) memory, which is relevant to allocating memory for the container. The QArrayData code simplifies maintenance for these common features while allowing specialization for type-specific optimizations as required for QString, QByteArray and QVector.
The QString and QByteArray ports to QArrayData were previously merged, and most recently the QVector port to QArrayData was completed, completing the implementation of the topic as far as Qt 5.0 is concerned, (though QVector continues to get interesting attention).
Printing
John Layt has been working on printing for Qt 5. Recent work includes isolation of the CUPS related code in Qt so that Qt can be built without CUPS, and can still be useful for printing to PDF for example. Simultaneously support for using LPR in Qt is removed.
Making Qt 5 compile with fewer features
On embedded systems, it can sometimes be useful to strip features out of Qt. For example, it might make sense to remove all code related to the clipboard or mouse cursor if the platform does not make use of them or does not provide the APIs required to build them.
Some work has been ongoing in Qt 5 to make it build with a reduced feature set. Configurations like this are not tested or supported, but as they can significantly reduce the size of the library binaries, it can be useful to make it possible.
QMutex future directions
A thread about QMutex for Qt 5. The discussion centers around several topics, such as optimizing for recursive mutexes (or not), ensuring that tooling such as valgrind/helgrind can work effectively to find threading and mutex issues in code, code complexity, and overall performance and memory efficiency.
The patch that implements the ‘de-inlining’ landed in the repository last week.
Platform specific minor patches
Ongoing effort on multiple platforms underscores the portability of Qt and the various platforms the community is working on. RaspberryPI gets hard-float support, clang gets compile fixes with C++11, warnings on MSVC in QVector got fixed, MSVC shadow building was fixed, and many patches updating the QNX platform code were applied.
Optimization in QMetaObject signal handling
The internal API used for processing signals, used by qtdeclarative, QSignalSpy, and other parts of Qt has been optimized. This won’t have any effect on how developers using Qt use signals, but internal optimizations should make for a faster Qt overall.