[Development] Changing the return type of QMetaMethod::signature()

Kent Hansen 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 mailing list