[Development] Changing the return type of QMetaMethod::signature()
kent.hansen at nokia.com
Wed Feb 15 10:06:07 CET 2012
As part of http://codereview.qt-project.org/#change,14763 (new
meta-object data format) it would be good to change the return type of
QMetaMethod::signature() from const char * to QByteArray.
In the new meta-data format, the raw, 0-terminated signature string is
no longer stored; the signature can be constructed from the method name
and parameter type info if needed.
I'm hoping that most usages of signature() outside of Qt itself will
already be wrapping the signature in a QByteArray/QString, since
operating on the raw char pointer isn't so nice.
However, if some code does do
const char *sig = myMethod.signature();
// do something with sig (call strlen et al) ...
that will still _compile_ if the return type of signature() is changed
to QByteArray (unless your project defines QT_NO_CAST_FROM_BYTEARRAY),
but the "sig" pointer will no longer be valid after the assignment.
The typical thing we do with signatures in qtbase is print them in
warnings; such code will have to be changed to pass
signature().constData() instead. (Unfortunately, this case also compiles
without adding .constData(), at least on gcc -- with a warning about
passing a non-POD type.)
qtdeclarative does use the raw signature pointer, but it does so to find
the boundary between the method name and the argument types. With the
new meta-data format and QMetaMethod API (name(), parameterCount(),
parameterType()) that code will be adapted accordingly.
In the current patch for http://codereview.qt-project.org/#change,14763,
we kept the const char * return type, but at the expense of having to
maintain an internal cache of signatures that will be kept alive
forever, just to ensure that the pointer remains valid.
I'm fine with adapting Qt itself if we change the return type, but I
can't judge what the impact will be outside of Qt.
More information about the Development