[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