[Development] What qtbase looks like with extensive use of auto
Thiago Macieira
thiago.macieira at intel.com
Tue Mar 22 00:00:26 CET 2016
On sábado, 19 de março de 2016 19:02:08 GMT Stephen Kelly wrote:
> Hi,
>
> In case you missed it, I wrote an auto-modernizer
>
> https://steveire.wordpress.com/2016/03/19/aaargh
>
> It is not quite AAA, as it doesn't convert
>
> QString s;
>
> into
>
> auto s = QString();
Thanks Stephen
The post is very informative. Thanks for the tool too.
I'd just like to add a bit of a drawback. Take this code, for instance:
QString s = tr("%1 (%2)").arg(someString()).arg(42);
As we all know, currently arg() returns a QString. So your tool would replace
that declaration with "auto". This would prevent future source-compatible
changes we've done in the past like that of QStringBuilder.
Note that the code actually has 3 QStrings in-flight at the same time, due to
tr() and each arg() returning a QString. Wouldn't it be dandy if we had rvalue
overloads for the above? But we already have 18 overloads for arg(): do we
want to double that?
So I implemented that about two years ago (patches never pushed). The solution
was to add one pair a variadic template arg() to QString that forwarded the
actual arg() code to a QStringArgBuilder, which in turn returns *this by
reference (it always modifies in-place). Unlike QStringBuilder,
QStringArgBuilder *is* a QString (derives from it), so all members are still
present.
But if the code above were auto, s would be a QStringArgBuilder. And if you
had later:
someFunction(s.arg(M_PI));
We'd have a behaviour change...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list