[Development] containers branch to merge into api_changes soon

João Abecasis joao.abecasis at nokia.com
Wed Mar 7 12:48:35 CET 2012


Hello everyone, 

The containers branch has reached a point where it would be beneficial
to have it merged with api_changes (and then master, from there). The
branch has already been tracking master closely.

The plan now is to merge api_changes once more into containers and have
that go through CI. Assuming that goes well, then coordinate with our CI
overlords to have a merge of the branch into api_changes be prioritized
over other integrations.

A short list of changes brought in by the branch follows. All reviewed
and CI-tested, as with master and api_changes. (You can safely skip to
the greeting at the end if you're not interested or already know what's
coming ;-)


* QArrayData
This is a new class that is meant to unify QByteArrayData, QStringData
and QVectorData; so far, those structures have been updated to share the
same layout, but technically they're not the same at this point.

The new layout also "fixes" some gcc optimization bugs due to the use of
arrays of size 1 in QVector.


* QtPrivate::RefCount
The struct was made POD and no longer offers constructors,
assignment or int conversion operators. Despite the actual atomic
reference count being public (required for POD-ness), explicit (or
verbose) API is provided instead so that users don't need to know or
care about individual ref-count values.

It now offers support for setSharable() together with traditional
reference counting. QVector and QList were updated to use this.


* QConst{ByteArray,String}Data renamed to QStatic{ByteArray,String}Data
... and the const qualification in their data members dropped. This made
those structs technically non-POD and this was generating warnings with
the Intel compiler and qmake crashes with Visual Studio 2010.


* New moc revision and meta-object data format
In the new format, method names and type information is stored directly.
The motivation for the change is to enable direct access to method names
and type information (avoiding string-based lookup for types if
possible), since that's typically the information language bindings
(e.g. QML) need.

QMetaMethod::signature() has been renamed to methodSignature() and
returns a QByteArray, since the signature is generated on the fly from
the name and type information, rather than stored verbatim in the
meta-object

New APIs QMetaMethod::name(), parameterCount(), parameterType() and
returnType(), make it more convenient to introspect methods.


* QMetaType::UnknownType
This new enum value is used by the meta-type system to indicate, well,
unknown types. QMetaType::Void was previously used for this purpose,
making it ambiguous, for instance, when used to represent the return
type for a function.


* Assorted bug-fixes and cleanups
These shouldn't impact SC or BC any more than bug fixes going into other
branches ;-)


That is all for now.

Cheers,


João




More information about the Development mailing list