Rants about auto
-
@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 withauto
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).
-
@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 aQByteArray
and people writeQString ret = someFunction();
(I'm looking at you,QIODevice::readAll
) even when they have no assurance the returned value is a UTF-8 encoded string. usingauto
would forceret
to beQByteArray
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 -
@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.
-
My 2¢: when you have
MyRidiculouslyLongClassNameWhichIDontWantToTypeInEachTimeSoIUseEvilAuto
, trytypedef MyRidiculouslyLongClassNameWhichIDontWantToTypeInEachTimeSoIUseEvilAuto Z; Z abc;
:)
-
@JonB First of all
using Z = MyRidiculouslyLongClassNameWhichIDontWantToTypeInEachTimeSoIUseEvilAuto;
because C++11 :) -
@VRonin
Sigh, looks like my C knowledge is increasingly invalid :( But I don't see what's wrong withtypedef
here, I'm not using a template.
BTW, I wouldn't really name itZ
here, of course I'd useMRLCNWIDWTTIETSIUEA
because it's much clearer what that means! -
@JonB said in Rants about auto:
But I don't see what's wrong with
typedef
hereNothing, I was just taking the piss. they are equivalent with the only difference that the
Z
type can be a template withusing
while it can't withtypedef
. -
@VRonin
Oh, lol! Once I started reading up about this newusing
I suspected that now I was supposed to use that every time....With
typedef
s you can string them together for a nice extra level of confusion ;) So you writetypedef int I, *PI;
which makes me wonder: without you looking it up, if I write:
typedef int *PI, T;
is
T
typeint
orint *
? :) -
-
@kshegunov
Hmm. OK, then, could you please explain how the*
binds intypedef int *PI, T;
.Why is that
typedef
notint *
forT
? And if you wanted it to bind asint *
forT
(i.e. making it same asPI
), 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...?
-
@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
ischar *
, butn
ischar
.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.
-
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 thetypedef
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, intermediatetypedef
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 writechar *p
and notchar* 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.
-
@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
-
@kshegunov
The declaration layout is just style, but I meant thatchar *p
instead ofchar* p
makes clear how C type declarations with*
actually bind, relevant if you have a list of them (char *p, *q
better thanchar* p, *q
). -
Hi,
@kshegunov said in Rants about auto:Can please someone tell me what environment is using Gary Bernhardt in that video ?
-
@LeLev
He is not using a special "environment" or IDE. He's just using a terminal/console, then running a Ruby/JS command-line interpreter which allows you type in statements to evaluate. -
I believe it's
zsh
that he uses, otherwise Jon's right, he just starts the interpreters from the command line. -
@kshegunov
And the relevance of it being specificallyzsh
is... what? :) You just looking for extra points? ;-) -
@JonB said in Rants about auto:
And the relevance of it being specifically
zsh
is... what?Environment of the interpreter.
You just looking for extra points?
Yep! Gimme, gimme!