Rants about auto

[jsulm]

@J.Hilk Hey, I don't like auto that much as well.
This is a constant source of discussions in our team :-)
In some cases it's OK, but some people overuse it and it becomes more difficult to understand the code.

[J.Hilk]

@jsulm

if you have some ridiculously long Class names whom you need an instance of, lets say:

auto agent = new QBluetoothDeviceDiscoveryAgent();

I can see a justified use, you see the return type on the first glance and its really long class name, so it's more readable and it saves time (somewhat) so use it here.

and than you have something along this line

auto a = ConjureMagic();
SetMagic(a);

and I'm like, NO!

[jsulm]

@J.Hilk Sure.
One example for what I don't like: you have a function/method returning something and when you write:

auto ret = someFunction();

What type is ret?

[J.Hilk]

@jsulm very true,
one spends why to much time in header files, looking stuff up, thanks to auto :-)

[kshegunov]

@jsulm @J-Hilk

And there's the occasional case that you can actually get wrong behaviour using such nonsense:
https://eigen.tuxfamily.org/dox/TopicPitfalls.html

[VRonin]

We are going a lot off topic here but auto is not as evil as everybody thinks.
It does not prevent you from hard typing, you can always put it on the right side of the equal with no difference in the compiled code.
It also prevent implicit conversion int ret = someFunction(); with somefunction returning a double introduces a truncation that would have been avoided with auto, this is also the reason why Eigen doesn't like auto, they rely on implicit conversions to delay the calculations to the last minute to increase efficiency.

What I'm saying is that auto is a tool, a useful one. It shouldn't be hated and the usage proposed by the coding conventions of Qt is more than reasonable.

In layman's terms: you can use a wrench to kill a man but that doesn't make the wrench dangerous or useless. Same goes for auto

[kshegunov]

@VRonin said in Why no std::byte in qt?!!:

We are going a lot off topic here

Seeing as the topic is pretty much done, I'd say we are not that much into sin. You can fork it off if you think appropriate, though.

but auto is not as evil as everybody thinks.

Eh, okay. Defining it as just a little bit evil I can accept.

It does not prevent you from hard typing, you can always put it on the right side of the equal with no difference in the compiled code.

Yep, it's still hard typed only hidden hard typing, a.k.a. compiler deduced typing.

It also prevent implicit conversion int ret = someFunction(); with somefunction returning a double introduces a truncation that would have been avoided with auto

Which you should've caught by compiling with pedantic, as is (somewhat) customary for release builds, provided this is not what you intended to begin with.

this is also the reason why Eigen doesn't like auto, they rely on implicit conversions to delay the calculations to the last minute to increase efficiency.

Rather it relies on overloading and implicit constructors, which is completely valid thing to do. Also had been in the language long before they decided that C++ should behave like javascript but compiled.

What I'm saying is that auto is a tool, a useful one.

Sure! A cannon is a tool too, but you don't go around smashing bugs with it, right?

It shouldn't be hated and the usage proposed by the coding conventions of Qt is more than reasonable.

Agreed. Although that convention just says we can take a (safe) shortcut in some very specific places, and specifically warns against using it whenever there's a spec of doubt about readability. So all uses of the type:

auto IAmBothTooSmartToKnowDocsByHeartAndUtterlyLazyToWriteTheType = myObject.someFunctionThatReturnsGodKnowsWhat();

is simply a no-no.

In layman's terms: you can use a wrench to kill a man but that doesn't make the wrench dangerous or useless. Same goes for auto

Indeed, there's also the gun, which you can use to kill a man, and it is dangerous and pretty much useless (beside it's primary purpose).

[VRonin]

@kshegunov said in Why no std::byte in qt?!!:

Rather it relies on overloading and implicit constructors

Yes, I probably I over simplified my terminology, I was thinking at implicit constructors as well as implicit conversions.

Probably a better example is someFunction returns a QByteArray and people write QString ret = someFunction(); (I'm looking at you, QIODevice::readAll) even when they have no assurance the returned value is a UTF-8 encoded string. using auto would force ret to be QByteArray and it's also far more efficient.

I agree this is a corner case and I'm the first not to advocate a too libertine use of auto, just pointing out that it's a point of view.

Rather it relies on overloading and implicit constructors, which is completely valid thing to do.

I actually think it's a very smart way of handling and compressing intensive calculations, nevertheless now that auto is a thing users must be aware of this implementation detail more than ever

[kshegunov]

@VRonin said in Why no std::byte in qt?!!:

Probably a better example is someFunction returns a QByteArray and people write QString ret = someFunction(); (I'm looking at you, QIODevice::readAll) even when they have no assurance the returned value is a UTF-8 encoded string. using auto would force ret to be QByteArray and it's also far more efficient.

I have only one thing to say here: QT_NO_CAST_FROM_ASCII ;)

@VRonin said in Why no std::byte in qt?!!:

I actually think it's a very smart way of handling and compressing intensive calculations, nevertheless now that auto is a thing users must be aware of this implementation detail more than ever

I agree on both counts.

[JonB]

My 2¢: when you have MyRidiculouslyLongClassNameWhichIDontWantToTypeInEachTimeSoIUseEvilAuto, try

typedef MyRidiculouslyLongClassNameWhichIDontWantToTypeInEachTimeSoIUseEvilAuto Z;

Z abc;

:)

[VRonin]

@JonB First of all using Z = MyRidiculouslyLongClassNameWhichIDontWantToTypeInEachTimeSoIUseEvilAuto; because C++11 :)

[JonB]

@VRonin
Sigh, looks like my C knowledge is increasingly invalid :( But I don't see what's wrong with typedef here, I'm not using a template.
BTW, I wouldn't really name it Z here, of course I'd use MRLCNWIDWTTIETSIUEA because it's much clearer what that means!

[VRonin]

@JonB said in Rants about auto:

But I don't see what's wrong with typedef here

Nothing, I was just taking the piss. they are equivalent with the only difference that the Z type can be a template with using while it can't with typedef.

[JonB]

@VRonin
Oh, lol! Once I started reading up about this new using I suspected that now I was supposed to use that every time....

With typedefs you can string them together for a nice extra level of confusion ;) So you write

typedef int I, *PI;

which makes me wonder: without you looking it up, if I write:

typedef int *PI, T;

is T type int or int *? :)

[kshegunov]

@JonB said in Rants about auto:

is T type int or int *?

int.
We are not JS devs, you know ... ;P

[JonB]

@kshegunov
Hmm. OK, then, could you please explain how the * binds in typedef int *PI, T;.

Why is that typedef not int * for T? And if you wanted it to bind as int * for T (i.e. making it same as PI), how could you force that, e.g. something like (I'm sure it's not right):

typedef (int *)PI, T

P.S.

We are not JS devs, you know

Ummm, relevance? JS doesn't even have type declarations or pointers, so...?

[kshegunov]

@JonB said in Rants about auto:

Why is that typedef not int * for T?

Not 100% about the theory behind it, but it's like with initialization (I assume it's cause , has very low priority). Say you have:

char * p, n;

p is char *, but n is char.

And if you wanted it to bind as int * for T (i.e. making it same as PI), how could you force that, e.g. something like (I'm sure it's not right):

typedef int *PI, *T;

Ummm, relevance? JS doesn't even have type declarations or pointers, so...?

Simply an ill-concealed insult. :)

PS:

Simply an ill-concealed insult.

https://www.destroyallsoftware.com/talks/wat

[JonB]

@kshegunov

typedef int *PI, *T;

That is cheating! You know it. You know that I know it can be done that way, that wasn't the question. I want the *s to be included in the "base" part of the typedef I am declaring, so that I can write like:

typedef (int **********) PI, PI2_same_as_PI, *PI3_one_extra_pointer;

I don't want to repeat the *s, and I don't want to declare a separate, intermediate typedef to achieve it.

As you say, thinking about the typedef just like a list-of-variables declaration, I guess it cannot be done? The *s just aren't a part of the "base" type being declared, they belong only to each type-name/variable being declared individually? And this is why we tend/are encouraged to write char *p and not char* p in C.

As for the JS. I know I am a cheerleader for C compared to C++, but I have never said I am a fanboi for all the JS stuff I have had to write over the years.

[kshegunov]

@JonB said in Rants about auto:

I don't want to repeat the *s, and I don't want to declare a separate, intermediate typedef to achieve it.

Then you're out of luck.

And this is why we tend/are encouraged to write

That's just style. I write spaces on both sides:

char * p;
char ** p;

and so on.

I know I am a cheerleader for C compared to C++

That's like being cheerleader for FORTRAN against C. ;)

but I have never said I am a fanboi for all the JS stuff I have had to write over the years.

Granted. I was just making fun of JS devs. ;P

[JonB]

@kshegunov
The declaration layout is just style, but I meant that char *p instead of char* p makes clear how C type declarations with * actually bind, relevant if you have a list of them (char *p, *q better than char* p, *q).