Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ 11 Auto: How to use and avoid abuse

acodersjourney.com

Post reply on HN
Print view View original

11–20 of 47 posts

Re: C++ 11 Auto: How to use and avoid abuse

#11

Post by Avernar »

albinofrenchy wrote: post #8

I'd be more than annoyed if I saw someone name a function "xxInteger()" because it returns an integer. I don't actually think the first example was that bad, modulo some context. Sometimes even knowing the type for this kind of thing isn't super important to understand what the code is doing; ala opaque types.

I agree. When the return type changes now you'd have to change every spot it's called regardless if the return value is used or not. This would be very annoying if you don't have a refactor function in your IDE or if the ammount of changes crosses a company policy trigering a full program test taking days of your time, etc.

The original function name was named poorly however.

Re: C++ 11 Auto: How to use and avoid abuse

#12

Post by takeawayandrun »

nercury wrote: post #6

"auto a = ConjureMagic();" "SetMagic(a);" The problem here is actually is an old one of failing to separate a getter from a command. It looks like ConjureMagic is causing side effects and modifying the state of whatever class it belongs to. This is also the reason one can't answer the question "what the heck is a?". If the "ConjureMagic" is only a getter and does not modify class state, it may probably need a better…

Having Getters for each member variable always seems fine and reasonable. It's when you have getters that do "magic" that I feel a little.. unsure. Like if it's taking a member and returning it in a different unit that seems kosher... But there is a fuzzy line where at some point the Getter is doing too much work to genuinely be a getter. It gives a false impression for the internal structure of the program. But conveying the const'ness is important as you describe (or semi-constness if you have caching)

Re: C++ 11 Auto: How to use and avoid abuse

#13

Post by takeawayandrun »

albinofrenchy wrote: post #8

I'd be more than annoyed if I saw someone name a function "xxInteger()" because it returns an integer. I don't actually think the first example was that bad, modulo some context. Sometimes even knowing the type for this kind of thing isn't super important to understand what the code is doing; ala opaque types.

What exactly is annoying?

I always want my variable names to be as long and descriptive as possible. We're no longer in the teletype era and our monitors are huge. With autocomplete there is no reason to keep variable names short

Re: C++ 11 Auto: How to use and avoid abuse

#14

Post by modulus1 »

cheez wrote: post #5

auto, the new range for and lambdas are my most used C++11 features. Also make_shared/make_unique. auto ptr = make_shared () Reads very nicely so I agree that if the type should be somewhere in the auto expression. That is, use auto to remove redundancy. I just wish they would have extended type deduction to lambda arguments so I could do: [](a,b){ ... } Instead of: [](int a, int b) {...} My understanding is that the…

> [](a,b){ ... }

Is valid if a and b are types.

Re: C++ 11 Auto: How to use and avoid abuse

#15

Post by zeta0134 »

takeawayandrun wrote: post #12
nercury wrote: post #6

"auto a = ConjureMagic();" "SetMagic(a);" The problem here is actually is an old one of failing to separate a getter from a command. It looks like ConjureMagic is causing side effects and modifying the state of whatever class it belongs to. This is also the reason one can't answer the question "what the heck is a?". If the "ConjureMagic" is only a getter and does not modify class state, it may probably need a better…

Having Getters for each member variable always seems fine and reasonable. It's when you have getters that do "magic" that I feel a little.. unsure. Like if it's taking a member and returning it in a different unit that seems kosher... But there is a fuzzy line where at some point the Getter is doing too much work to genuinely be a getter. It gives a false impression for the internal structure of the program. But conv…

I'm of the somewhat unpopular opinion that "getters for everything!" is a philosophy that sounds good on paper, but results in writing a lot of getter and setter functions and feeling safe, while ignoring these sorts of traps cropping up everywhere.

Member variables are easy to reason about; they behave exactly like the type they are, and in the case of built in types, have extremely consistent behavior. Getters / setters are a black box of mystery; I like to reserve that pattern for when there's going to be extra work to retrieve some value, so my call site knows it needs to tip-toe around possible failures. While I can see the value in using getters/setters for everything in something like an API or framework, I don't see the value in trying to use them all the time, "just in case."

Re: C++ 11 Auto: How to use and avoid abuse

#16

Post by pjmlp »

dman wrote: post #10
CyberDildonics wrote: post #7

Earlier quoted context omitted.

I would be very surprised if someone can meaningfully review C++ templates without an IDE. Really not reviewing a program inside an IDE is a poor idea in general.

Some of us still use emacs and vim.

Yeah, some of us still listen to vinyl and tube radios.

Re: C++ 11 Auto: How to use and avoid abuse

#17

Post by fenesiistvan »

So auto allows you to deal more easily with c++ crap, especially STL. My first thing to do in all my c++ project is to import my in-house STL wrapper, which makes STL usable for me. I never understood how people can work with raw STL. I don't like at all working with templates and i am using it only in internal class implementations. C++ without templates is so much more beautiful.

Re: C++ 11 Auto: How to use and avoid abuse

#18

Post by danra »

No.

In Herb Sutter's words, avoiding auto since it makes the code "unreadable":

...reflects a bias to code against implementations, not interfaces. Overcommitting to explicit types makes code less generic and more interdependent, and therefore more brittle and limited. It runs counter to the excellent reasons to “write code against interfaces, not implementations”

See http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-...

Re: C++ 11 Auto: How to use and avoid abuse

#19

Post by dbyte »

cheez wrote: post #5

auto, the new range for and lambdas are my most used C++11 features. Also make_shared/make_unique. auto ptr = make_shared () Reads very nicely so I agree that if the type should be somewhere in the auto expression. That is, use auto to remove redundancy. I just wish they would have extended type deduction to lambda arguments so I could do: [](a,b){ ... } Instead of: [](int a, int b) {...} My understanding is that the…

auto with lambdas can be quite dangerous if you are adding different types inside their bodies. Type promotion rules should be well understood. During code reviews we spotted several overflow bugs when using ints because the dev were thinking auto as a sort of very powerful resource.

Explicit casting if often required to make sure subtle bugs won't show up in production.

Re: C++ 11 Auto: How to use and avoid abuse

#20

Post by p0nce »

danra wrote: post #18

No. In Herb Sutter's words, avoiding auto since it makes the code "unreadable": ...reflects a bias to code against implementations, not interfaces. Overcommitting to explicit types makes code less generic and more interdependent, and therefore more brittle and limited. It runs counter to the excellent reasons to “write code against interfaces, not implementations” See http://herbsutter.com/2013/08/12/gotw-94-solution…

Why this dismissive comment? auto is definately overused in ways that are unreadable, exactly like the blog author says. Marking the type explicitely may be less generic in a way, but it helps readability so much by providing redundancy.
Post reply on HN