Ok, I cleaned this up, redid it basically with the suggestions from this thread. I put a review request on reviewboard, and the code is in kdelibs whiting/buildwithqt48 branch.
Enjoy, Jeremy On Mon, May 2, 2011 at 11:37 AM, Olivier Goffart <[email protected]> wrote: > Le Monday 02 May 2011, David Faure a écrit : > > > Another one: > > > > - envs << QString::fromLatin1( QByteArray("DISPLAY=") + dpystring ); > > + envs << QString::fromLatin1( QByteArray(QByteArray("DISPLAY=") + > > dpystring) ); > > Should be QLatin1String("DISPLAY=") + QLatin1String(dpystring) > (Assuming dpystring is char*) > > > > > > Is this still because QString::fromLatin1( const QByteArray& ) is > missing, > > so it has to cast to const char* here too? Olivier, wouldn't it make > sense > > to have such an overload? (It would save a strlen, too). > > Yes, maybe QString::fromLatin1(const QByteArray&) would make sens > But it might brake source compatibility if the call becomes ambiguous. > > The reason why we brake source compatibility with QT_USE_FAST_OPERATOR_PLUS > is > because this one was not documented. But maybe the new operator should > only > be enabled if QT_USE_FAST_OPERATOR_PLUS is defined to 2 or something. > > > > >
