C++ Weekly - Ep 287 - Understanding `auto`

☟☟ Awesome T-Shirts! Sponsors! Books! ☟☟

Upcoming Workshops:

T-SHIRTS AVAILABLE!

WANT MORE JASON?

SUPPORT THE CHANNEL

GET INVOLVED

JASON'S BOOKS

► C++23 Best Practices

► C++ Best Practices

JASON'S PUZZLE BOOKS

► Object Lifetime Puzzlers Book 1

► Object Lifetime Puzzlers Book 2

► Object Lifetime Puzzlers Book 3

► Copy and Reference Puzzlers Book 1

► Copy and Reference Puzzlers Book 2

► Copy and Reference Puzzlers Book 3

► OpCode Puzzlers Book 1


RECOMMENDED BOOKS

AWESOME PROJECTS

O'Reilly VIDEOS

[fixpontt]

this was the first topic i read from Scott Meyers' book about C++11

[TomHultonHarrop]

Great video! One extra thing that might be worth calling out in a future episode is the difference between 'const auto const_pointer_to_integer = &some_integer;' vs 'const auto* pointer_to_const_integer = &some_integer;' - The first will be a constant pointer and not a pointer to a constant value which I think does catch people out. If you want both you can write 'const auto* const const_pointer_to_const_int = &some_integer;'. I also think it's interesting as an analogy to think of a reference as like a portal to a value (an intangible thing you can't really touch (copy)) and a pointer as a picture you can hold and copy and pass around but with a button to teleport you to the picture (dereference :P). It's not perfect, but I thinks help distinguish how the language treats pointers and references. I think added confusion also comes from people saying how references and pointers are technically 'the same' under the hood which I don't think helps with understanding (definitely for me anyway).

[grahampitt]

In 1984 Bjarne had a working implementation of auto in c++, but that keyword was already being used for something else.

Should he have:
A) Drop that feature for 17 years; or
B) Pick a different keyword, like 'var'.

Obviously the answer chosen was A. 🤔

[Avianable]

at 8:28 it's not an explicit dereference. That would be putting a * in front of a pointer type. You were taking the address of an integer.

[JanSordid]

To me, working in a huge codebase where you encounter unknown parts of code multiple times each day, having a 'very rarely auto' policy is a bliss.
When the type of the variable is stated then I do not have to look at the declaration of the function that initialized it. It makes reading code so much easier.
I definitely like auto for for-loops or in generic contexts, but this use case does not make up too much of most involved developers lives.

[ltstaffel]

Don't know when you switched, but dark mode compiler explorer is a +1 from me :)

[neozoan]

Whoo, boy. Time to find out how much I don't actually understand about auto.

[GeraldSquelart]

around 7:42 "pointer ... is part of the type [of p]", that's why I really prefer the declaration style `int* p = ...;` 😉

[willofirony]

And there was me thinking my ancient brain was confused by auto, when all the time it was that auto IS confusing. I would be interested in knowing what, exactly, was the intention of the creator(s) of auto. Personally, I don't find any problems in not using auto, particularly when it comes to my code's readability. I look forward to the next episode to find out where I have been wrong in that belief.

[xkazinx]

There's an interesting thing about const pointers declared with auto that is not being mentioned here:
const auto* ptr = new int(1); // This results into const int* - Can't call const attributes but can change pointing value
const auto ptr = new int(1); // This results into int* const ptr - Can call const attributes but can't change pointing value
const auto* const ptr = new int(1); // Can't call const attributes nor change pointing value

[abdulrahmanhamdi]

I have some thoughts, the auto shall be accompained by modifiers const and references to get the exact deduction, the reason why it failed to compile the assignment of the address of const int i to pointer p because the address itself is unique and can't be copied ..so i can't manipulate memory location represented by const i. Auto take a copy or deduce the type of the return value and need both & and const to be accompanied with it.

[KennyMinigun]

One more thing about auto, const and pointers:
int* p = nullptr;
const auto constPtr = p; // a const pointer to a mutable object
const auto *ptrToConst = p; // a mutable pointer to a const object

[badasahog]

I've seen decltype(auto) before but I still don't understand what it does. If you could do an episode about it that would be nice

[LogicEu]

I've always thought that the auto keyword is more confusing than helping. I know there are case where auto is extremely helpful, but imagine I want to understand a codebase full of autos, It's gonna be impossible for me to fully grasp what the types are, if they are refs, pointers, consts, etc. My take is; use auto when it's helpful, not because of laziness. I always want to know that an int is an int, not guess or deep dive into the function call tree to know what I'm dealing with.

[josemicorrea]

Can anybody post compiler options as we can barely see it at the right top of Compiler Explorer? Thanks in advance.

[alextrotta]

I would like to see more with decltype(auto). I've tried to understand it, but there's not a whole lot of good material, and to me it doesn't have any intuitive meaning, much less a useful one.

[kyoai]

I usually avoid using auto because while skimming through code I like to have types visible, so all points it is 100% clear what type each variable is, without having to hover my mouse over the variable/returning function. Auto also makes it harder to find type usages when doing a plain text search for types. The only times I really like using auto is for having lambda variables, for template code and for using auto as a quick'n'dirty placeholder for item types in a ranged for loop. However, once the loop is implemented I usually replace the auto with the actual type.

[Omnifarious]

I don't like auto sometimes because it hides type information. This isn't a problem most of the time. Mostly the type is obvious from context. But that's not always the case.

Another place where I think auto is contraindicated is when the code following depends on the variable being a specific type. I would rather the type error than the weird errors that occur when a possibly similar type is used in the wrong way.

[Qazqi]

Unfortunately, there's one small difference between auto and template type deduction (auto allows "deducing the type of" {...}, which doesn't have a type because it isn't an expression). It's a pretty insignificant difference, but a bit frustrating that it removes the otherwise perfect consistency. Though I haven't checked yet, a C++20 `void foo(auto);` might make it slightly more inconsistent in that regard because this auto would probably use the template rules, not the auto ones. (That said, I would still agree with the decision because "auto-based" (placeholder) parameters definitely should just be syntax sugar for a template.)

[DamianReloaded]

I love auto and I try to use it where it makes my code better. auto is more a casual lover than a marriage imc ^_^