[Development] RFC: more liberal 'auto' rules?
Matthew Woehlke
mwoehlke.floss at gmail.com
Fri Dec 4 22:33:26 CET 2015
On 2015-12-04 15:35, André Pönitz wrote:
> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
>> and it's one reason less to make errors:
>> Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray
>> is way to frequent. (and the compiler won't complain)
>
> ["QString instead of QByteArray" does not happen with proper
> QT_NO__CAST_*_ASCII settings. Not to mention the cases where mindless
> replacement of explicit types by 'auto' doesn't produce identical results.]
But wrongly mixing integer types *does* happen. I speak from personal
experience based on a code base that has a relatively large mess of
*exactly* such errors.
> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.
Which of these is easier to read? (More importantly, which is easier to
*verify* that it is correct?)
for (int i = 0; i < list.size(); ++i)
foo(list[i]);
for (auto i : qtIndexRange(list.size())
foo(list[i]);
Which is *really* more meaningful? "The type of 'i' is 'int', and I
really, really hope that 'list' is actually indexed by 'int'", or "the
type of 'i' is the index type of 'list'¹"?
Do you really *care* what is the type of 'i'? Or do you care that it is
the *correct* type. I (and others) submit that the latter is more valuable.
(¹ ...assuming that decltype(list.size()) is the index type, which it
had darned well better be or whoever wrote the API of decltype(list)
needs to have their coding privileges revoked.)
--
Matthew
More information about the Development
mailing list