Programmer Humor

38564 readers

228 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.

founded 6 years ago

MODERATORS

cat_programmer@lemmy.ml

AgreeableLandscape@lemmy.ml

Low effort meme (lemmy.ml)

submitted 2 weeks ago by voodooattack@lemmy.world to c/programmerhumor@lemmy.ml

13 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] thebestaquaman@lemmy.world 1 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

Similarly, what would you gain by saying uint32_t const* x = my_var.get<uint32_t>();

To be frank: You gain the information that MyConcreteType::get<uint32_t> returns a uint32_t, which I otherwise couldn't infer from the docs. Of course, I could assume it, based on the template parameter, but I don't want to go around assuming a bunch of stuff in order to read docs.

Take an example like auto x = my_var.to_reduced_form(), it's very clear that x is the "reduced form" of my_var, which could be meaningful in itself, but what type is it? I need to know that if I want to do anything with x. Can I do x += 1? If I do, will that modify my_var? Let's say I want to make a vector of whatever to_reduced_form returns... and so on.

All these questions are very easily answered by MyConcreteType x = my_var.to_reduced_form(). Now I immediately know that everything I can do with my_var, I can also do with x. This makes me happy, because I need to do less digging, and the code becomes clearer to read.

[–] ugo@feddit.it 2 points 2 weeks ago

To answer you: no, x += 1 cannot mutate my_var, because it’s a copy. If you wanted something else you would say auto& or auto*.

And if the type of x is such that even a copy can mutate the original (e.g. maybe it’s a wrapper around an index with an overloaded operator+=() that mutates the original entry in the storage), you are probably working with a specialized system of some kind, since that breaks the semantics of the language, and hopefully you would know from context that you have such cases.

And yes, in such an environment I would see “never use auto for this wrapper type” as a valid additional strategy to help ensure code correctness.

But by and large my direct experience is that using auto “almost always”, as Herb Sutter puts it, is beneficial and doesn’t harm readability or understandability.