CppCon 2016: Andy Bond “AAAARGH!? Adopting Almost Always Auto Reinforces Good Habits!?"

[@jaredmulconry]

Almost-Always-Auto was excessive as an idea from the start, but that was the point; for programmers to consider appropriate application. As with all new programming practices, adjusting to a new approach takes time. I've found my own comfort zone for use of type deduction. I'm now sufficiently comfortable with it that I don't find following the deduction of types throughout a program difficult. That largely comes down to having anchoring points, where you coalesce all of this deduction to some common type that you state very clearly. Those who are still on the fence with auto, don't try to apply it everywhere. Apply it where it eliminates some explicit stating of types that aren't necessary for your understanding of your code. Have anchoring points. You'll feel it out pretty fast.

[@tiagodagostini]

THe issue is the good points to use it are far more comon than most people think. Almost everywhere isnide the method is a good place. I just do not likeusing it at the return type (unless its absolutely needed)

[@IsmeGenius]

I think this talk gets so many negative response due to incorrect advertising. The title makes you think speaker will make some strong points towards auto everywhere, but this is not what this talk is about. This talk is about exploration. As William Blake said, You never know what is enough unless you know what is more than enough. This talk presents the code which is more than enough for the most people. And now you can go back and find the right amount of auto for you, as opposed to blindly stopping at "auto only for iterators" or wherever comfort zone is limiting your outlook.

[@marco_foco]

On slide 17 you say that it's an input iterator. I think it should be a ForwardIterator, because InputIterator only allows a single pass, and you're doing two passes: one in std::distance function, and the other in std::next.

[@von_nobody]

`auto&& x = (int[]){ 1, 2 };`

[@YourCRTube]

I am not buying auto&& *at all* for a general variable. This is borderline antipattern - the few corner cases where it might be helpful are dwarfed by the negatives - mainly vast, *vast* majority of variables are actually constants and they should be declared as such - auto&& will be const only if the source the variable is created from is const, which something semantically different. const auto should be the goto default - TheRightThing in 90% of the time. const auto& - if one must avoid a copy (function returning const reference to member, range-for loop, etc) auto& - if one must modify the source (function returning non-const reference, mutating range-for loop, etc) auto - if one will modify the variable or move it. auto&& "to solve it all for all cases" is TheWrongThing. It is not even a "reasonable default".

[@tiagodagostini]

Declare then const auto& = whateversourceyouwant();

[@kwanarchive]

I think a lot of people miss the point about "almost always". It's not "always". My rule of thumb is auto is there to help with DRY principles. You can't apply it as a cargo cult practice. You have to assess if it helps in the code context. auto is good for things like temporary variables, where you get something and pass it to something else; it's mostly useful for passing lambdas into algorithms. Same with the "no raw loops" thing. It's a goal, not a style. I actually find the for_each algorithm unnecessary for one off loops that you can use a simple range-for instead. for_each is better suited for when you are using other algorithms and you're already dealing with iterators returned/modified by those algorithms. In which case it's better to use the iterators than loop through the whole container.

[@MaceUA]

Readability::Hurt()

[@1ron1van]

your comment made my day :D

[@kiffeeify]

First thing that came to my mind was: If I get concepts, I can "Write code against interface, not implementation" without autohell 2.0. Btw: I think you cant have an int_distribtion that would be a uniform_real_distribtution (at least in c++11)

[@peppybocan]

18:15... when I see code like this, I want to cringe. This is some bullshit to sell it to all those JavaScript wannabe programmers...

[@tetsuoshiva]

Man, I lost it much earlier at 4:22 with the "using Life = unsigned int;" thing.

[@EliasDaler]

@tetsuoshiva What's bad about it? Pretty standard and good practice.

[@tetsuoshiva]

I don't like it, for basic types I prefer abbreviations like uint, I want to easily see what I'm dealing with, and know the limitations right away. Using a capitalized name (Life) also makes it look like a class name which it isn't.

[@EliasDaler]

Well, you can easily find out original type by simply hovering your mouse over it (most IDEs support it). Enums are usually capitalized too and people don't have much problem with them. And the good thing about using typedefs like this is that you can easily go from measuring life in uints to measuring it in floats or other data types without changing much code and not accidentally making some bugs in the process of changing.

[@tetsuoshiva]

OK, if the IDE helps it might be useful, the same applies to auto stuff.

[@thsombrerokid]

Almost always throw away the type system.

[@germandiagogomez]

I do not find this talk incredibely useful. It seems to me more like playing with an experiment, but it usefulness does not seem obvious to me.

[@superscatboy]

It *is* an experiment, and like all experiments the usefulness comes from your analysis of the results.

[@rgba32]

Is this for real? Way to take a simple problem statement and obfuscate it such that it's unreadable to the bulk of people on your team. I used to be a big fan of C++ but it's been going down the drain lately.

[@Orgyilkos]

Someone wants to reinvent javascript. He sounds so sad though :(

[@epictetzu85]

This guy's should never be asked to publicly speak again. Painfully slow and monotonal. Who forced this poor guy into doing a talk when he is obviously not cut out for it?

[@zachansen8293]

uhh I uhhmm am uhmm not uhmm sure uhmm this uhmm is a uhmm uhmm good uhmm talk uhmm but uhmm i can't uhmm uhmm make it uhmm long uhmm enough uhmm to uhmm tell uhmm.

[@zordanmarko]

Ahahahahaha :) and you forgot that sound clamp :) which he do with his lips maybe, uhmm don't know.