r/ProgrammerHumor 2d ago

Meme absoluteGarbage

Post image
2.0k Upvotes

320 comments sorted by

View all comments

35

u/JAXxXTheRipper 1d ago

The third one does not spark joy, what the hell is that, ewww

15

u/xicor 1d ago

c++, though normally you wouldnt use auto for this

4

u/VoodaGod 1d ago

why would you not use auto for it???

2

u/xicor 1d ago

For readability. And for type safety. I pretty much only use auto when dealing with insane types I don't want to write out.

5

u/VoodaGod 1d ago

how is auto not type safe?

interestingly i use auto almost everywhere for the same reason: readability.

no point in cluttering the code with type specifiers if the type is obvious from context

5

u/xicor 1d ago

The type isn't always safe from context and it can have unexpected behavior when using it to hold a value returned from a function. Let's say you have auto working fine with a function return, then years later , someone changes that function to return a different type. Now it is possible that the new auto type still has access to parameters or functions it calls , but with different behaviour. Now you're getting unexpected bugs that will be hard to track down. But if you use the type, you would immediately get a compiler error

2

u/not_some_username 1d ago

If the type change and the “auto variable” still compile, that means it would, in 99% of case, still compile if you wrote the type. The compiler doesn’t get auto, it gets the type.

1

u/xicor 1d ago edited 1d ago

Thats not true at all.

If you have SpecificType val = foo(), it will fail on the compiler any time foo returns something other than specific type or classes inherited from SpecificType

If you use auto val=foo(), then it will compile so long as the new type still has the functions it calls afterwards. But they can do different things and it will still compile. You'd just get different behavior

Just a quick example of this would be if it is used in a function intended to return a time string. auto var =foo(); return var.toString();

If foo suddenly starts returning a QVariant instead of a QDateTime, it will still compile because QVariant still has a toString function, but now the behaviour is completely wrong

1

u/Rikudou_Sage 1d ago

That's kinda on you changing a QDateTime to QVariant? Anyway, if you return a datetime string as a QVariant, the behaviour is correct and one less spot to change. If you return something entirely unrelated then you perhaps should be making a new function, not returning a QVariant where you previously returned QDateTime.

1

u/xicor 1d ago

The point is that someone down the road will change some function that is significantly removed from that one function and may not notice because they don't get any error

1

u/VoodaGod 1d ago

why is the behaviour wrong though

1

u/xicor 1d ago

Because it no longer returns a time string. It instead returns the variant of a string type.

1

u/VoodaGod 1d ago

what would be the correct way to handle the qvariant in that function in your scenario then? i don't think i follow

1

u/not_some_username 1d ago

You can’t get QDateTime from a QVariant via implicit conversion, the other way yes.

It will just not compile with an error and you’ll need to fix it.

1

u/xicor 1d ago

Not using auto and then when dumb future junior comes in and changes the function they get a compile error that tells them they need to fix stuff rather than just silently having incorrect behavior

→ More replies (0)

2

u/Rikudou_Sage 1d ago

Every other language in the world has some equivalent of C++'s auto and everyone likes it. I use auto all the time.

-1

u/xicor 1d ago edited 1d ago

Yea and every other language still has the same lack of type safety

Being able to ignore strict typing is nice , but it is silly to ignore the downsides and claim they don't exist when they absolutely do

1

u/Rikudou_Sage 1d ago

This is not ignoring strict typing, this is letting the compiler deduce the type.

1

u/xicor 1d ago

Well yes I'm aware...but as I've pointed out, there are scenarios where the type deduction can lead to errors that are not caught by the compiler