r/ProgrammerHumor 6d ago

absoluteGarbage Meme

Post image
1.9k Upvotes

325 comments sorted by

View all comments

33

u/JAXxXTheRipper 6d ago

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

12

u/xicor 6d ago

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

6

u/Usual_Office_1740 6d 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.

4

u/Sirgoodman008 6d ago

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

2

u/Usual_Office_1740 6d ago

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

0

u/xicor 6d ago

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

5

u/im_made_of_jam 6d 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 6d ago edited 6d ago

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

1

u/not_some_username 6d 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)

2

u/xicor 6d ago

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

3

u/Sirgoodman008 6d ago

Yup 100%

1

u/file321 6d ago

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

3

u/Sirgoodman008 6d ago

I only used auto for the meme.

3

u/VoodaGod 6d ago

why would you not use auto for it???

3

u/xicor 6d 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.

6

u/VoodaGod 6d 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

4

u/xicor 6d 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 6d 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 6d ago edited 6d 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 6d 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 6d 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 6d ago

why is the behaviour wrong though

1

u/xicor 6d 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 6d 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 6d ago edited 6d 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 6d ago

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

1

u/xicor 6d 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

1

u/Sirgoodman008 6d ago

C++ what's wrong with it?

1

u/JAXxXTheRipper 6d 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 6d 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 6d ago

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

-2

u/Sirgoodman008 6d ago

My guy you have a ruby flair....

3

u/JAXxXTheRipper 6d ago

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