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

31–40 of 47 posts

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

#31

Post by maxlybbert »

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…

The "unreadable" or "annoying" example from the article is only unreadable and annoying because the programmer was new to the project when he read the two offending lines of code.

I believe Stroustrup is correct that we're all beginners at some point, but we quickly move up. It makes more sense to optimize for "proficient, but not expert" than to optimize for "beginner," because more people are at the proficient level, and they stay there longer.

I agree that code shouldn't be unnecessarily complex. But I would quit any project that constantly brought up "but what if a programmer were brand new when they looked at this code?" in reviews. Then again, if other programmers have the same reaction, perhaps the project really would be full of nothing but beginners.

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

#32

Post by tomjen3 »

takeawayandrun wrote: post #13
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

Thats the only acceptable way to write code, but it doesn't mean that names can't be too expressive, for example I wouldn't accept nameing like this:

> RandomizeArrayPositionUsingFisherYatesShuffle

Since the algorithm detail is something I don't want to think about when I use it and something that the implementer should be able to change without changing the contract.

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

#33

Post by cheez »

dbyte wrote: post #19
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.

What do you mean about promotion rules with auto?

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

#34

Post by dman »

pjmlp wrote: post #16
dman wrote: post #10

Earlier quoted context omitted.

Some of us still use emacs and vim.

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

Unfortunately all the ides I tried make it non trivial to write extensions. I program nearly 9 hours a day and using a tool that prevents automation of common tasks is suboptimal.

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

#36

Post by cheez »

modulus1 wrote: post #14
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.

Yeah, I guess that's where the committee is hesitant to deduce parameters without the auto qualifier.

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

#37

Post by pjmlp »

dman wrote: post #34
pjmlp wrote: post #16

Earlier quoted context omitted.

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

Unfortunately all the ides I tried make it non trivial to write extensions. I program nearly 9 hours a day and using a tool that prevents automation of common tasks is suboptimal.

On my case, they provide all the necessary automation features I care about.

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

#38

Post by dman »

pjmlp wrote: post #37
dman wrote: post #34

Earlier quoted context omitted.

Unfortunately all the ides I tried make it non trivial to write extensions. I program nearly 9 hours a day and using a tool that prevents automation of common tasks is suboptimal.

On my case, they provide all the necessary automation features I care about.

Out of curiosity which Language and IDE do you use?

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

#39

Post by RotsiserMho »

dbyte wrote: post #19
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.

Couldn't that have been found by turning on the signed-to-unsigned conversion warning?
Post reply on HN