[Development] RFC: more liberal 'auto' rules?

Matthew Woehlke mwoehlke.floss at gmail.com
Thu Dec 3 19:35:00 CET 2015

On 2015-12-03 13:02, Thiago Macieira wrote:
> On 2015-12-03 13:49, Marc Mutz wrote:
> I'd at least like to propose, for new code and as 
>> a drive-by, the *required* use of auto for:
>> - all loop variables (both index and iterators)
>>   the reason being that spelling out the name is usually wrong:
>>   size_t i = stdVector.size() // wrong, should be std::vector::size_type...
>>   also helps when porting from Qt containers to STL ones

You probably want my index range helper┬╣ for index iteration...
otherwise you need ugly work-arounds to use type deduction.

The enumerate helper is also useful for iterating over (Qt) associative
containers. (Needs to change to make a copy of the container, though, so
that it doesn't have dangling references in case of temporaries. That's
a trivial change though.)

(┬╣ http://permalink.gmane.org/gmane.comp.lib.qt.devel/21327)

> Except for primitives, because "int" is shorter than "auto".

Automatic matching of the index type to the type that the container
*actually uses for indices* is preferable to a shorter name. Even if you
"know" that the type is int.

Whether or not uses of Qt containers are ever replaced with use of STL
containers, it's just good habit. Maybe less important in Qt itself, but
I still submit that it would be good for Qt to demonstrate the "right"
way to do things. Because for your users, it *does* matter. (I have a
code base that is absolutely rife with index type mismatches because it
predates auto and qtIndexRange. With proper use of those, such errors
are avoided.)

MHO: don't use a possible type conversion if you can avoid it, and if
you do, use uniform initialization so that the compiler will reject a
narrowing conversion.


More information about the Development mailing list