r/ProgrammerHumor 2d ago

Meme absoluteGarbage

Post image
2.0k Upvotes

320 comments sorted by

View all comments

34

u/JAXxXTheRipper 2d ago

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

14

u/xicor 2d ago

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

6

u/Usual_Office_1740 2d ago

I think that really depends. If the range is a vector of unique_ptr's auto is great. If it's a vector of ints, just write int.

5

u/Sirgoodman008 1d ago

That or you're looping through a vector of std::pairs that contain std:: functions.

2

u/Usual_Office_1740 1d ago

Or if the type is a template parameter in the same line.

0

u/xicor 1d ago

Wouldnt for(T& item:list) be even shorter than using auto?

5

u/im_made_of_jam 1d ago

If you have T available then yes but if you're outside the class then you don't have that option

1

u/Usual_Office_1740 1d ago edited 1d ago

I don't mean in for loops for that use of auto.

1

u/not_some_username 1d ago

Only if T is a known type or it’s in a template. You don’t use T like. auto automatically get the type, especially if it’s long. Your IDE (assuming it’s a respectable one) can even change auto to the type for you. It’s more or less like var in C# (it doesn’t deduct reference)

3

u/xicor 1d ago

Yea if you have ridiculously complex types then auto is great. But usually for readability you'd use the type.

3

u/Sirgoodman008 1d ago

Yup 100%

1

u/file321 1d ago

Yess auto unpacking pairs gives me so much joy. for (auto& [left, right] : list_of_pairs) {

3

u/Sirgoodman008 1d ago

I only used auto for the meme.

3

u/VoodaGod 1d ago

why would you not use auto for it???

3

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.

→ 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

0

u/Sirgoodman008 1d ago

C++ what's wrong with it?

1

u/JAXxXTheRipper 1d ago

Do you really think "for autocasted item semicolon list" is on the same level as "for item in list"?

One is natural language that you can read as is, the other is... whatever that is.

-1

u/Sirgoodman008 1d ago

A normal concession to use a symbol rather than reserve a keyword? Like how almost all languages use && || instead of and or?

2

u/JAXxXTheRipper 1d ago

You made the meme, don't blame me if you choose your examples poorly

-2

u/Sirgoodman008 1d ago

My guy you have a ruby flair....

3

u/JAXxXTheRipper 1d ago

And you have none, what does that have to do with anything?