Hi, 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. Regards, Kent _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
