Back to Basics: Pointers and Memory - Ben Saks - CppCon 2020

cppcon.org/
github.com/CppCon/CppCon2020
---
The prevailing wisdom in Modern C++ is to favor smart pointers and container classes over raw pointers and built-in arrays -- there are too many traps and pitfalls that come with using those more-primitive types. However, many C++ programmers can’t avoid using them because they’re still so prevalent in legacy C++ code and C libraries. If you have to use raw pointers and built-in arrays, then you should learn to use them safely and effectively.
This session explains the true nature of built-in pointers and arrays, and why they’re so easily confused despite actually being distinct types. It covers the rules for pointer and array type conversions, along with the mechanics of pointer arithmetic and array subscripting. It compares and contrasts pointers with references and iterators, as well as the pointer and reference member types in the STL, to help you make more informed choices about what to use when. This session also explains the origins of the types size_t and ptrdiff_t, and their relationship to size and difference types in the STL.
You’ll leave with a clearer understanding of how pointer operations behave, whether you’re using raw pointers and built-in arrays or smart pointers and container classes.
---
Ben Saks
Chief Engineer, Saks & Associates
---
Streamed & Edited by Digital Medium Ltd - events.digital-medium.co.uk
[e-mail]
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*

[@LarsonOliveira]

One of the BEST Talk about *Pointer &Reference I've ever seen! Thank you so much, Sir. Ben Saks!

[@henami552]

Even with all the scorn raw pointers are getting, I still love them.

[@LightLord1870]

I think they are cool. It's the granular control that makes it useful for certain applications.

[@harshpatel4390]

This cleared my all doubts related to pointers... Great talk Ben. Cheers!

[@dkutagulla]

Simply the best talk about pointers and references

[@kamilziemian995]

Thank you Ben Saks for another very informative and very needed talk. I really need to go back to basics.

[@CppCon]

Glad it was helpful!

[@kar_prz]

Excellent resource! Thank you for delivering this talk

[@jvsnyc]

This talk is consistent with what others have been saying. Modern C++ written from scratch will most of the time use the newest and safest facilities provided by the latest STL versions, and we should reach to those by default. Especially the stuff about Bounds Safety and Memory Safety by default. But, the whole history of the evolution of C++ is still there, nobody is taking it away with very few notable exceptions. Old code uses it, directly and new code that is doing the hard work of providing the safer and more robust interfaces uses it under the hood. Good stuff!

[@kamilziemian995]

Thank you for you comment. It is very helpful.

[@janjezewski1205]

I watched just as repertory... but then I learned something new.

[@sanjaygatne1424]

Great talk to demistify c/c++. But i think that having distinct operater for ptr , deref ,and ref rref will automatically demistify c/c++. because of operater overloading optical illusion occers. Which causes confusion. Which lead to brain stall to dectect errors which can be easily dectected while coding. If we avoid same operater for different functionality.

[@rafalmichalski4893]

Simple topic, but well presented / explained.

[@kuxnal]

This is the best explanation. Thank you for this!

[@opethforlife]

Amazing lecture, keep up

[@abhishekroy938]

Really interesting.. Thanks

[@jvsnyc]

The talk is fantastic, not sure I am buying the details of the example used to show the hazards of comparisons between size_t and ptrdiff_t, which is a real hazard. We never initialize field on screen, but if there are no commas occurring between its start and the null terminator, we get back nullptr, and length becomes a huge positive number. The example shown could presumably be fixed by adding:
if (nullptr == field_end) field_end = strchr( field, '\0');
before calculating the length, but signed unsigned comparison is always a hazard to watch out for nevertheless.

[@kalucardable]

Very good stuff, thank you. I have a question about const pointer. After deallocating the memory where a const pointer is pointing to, the const pointer becomes a dangling pointer and I cannot make this pointer point somewhere else. How can we deal with this situation?

[@matgat]

Hi, that would be a huge "code smell", in the sense of bad designed code. In that situation you would want to reformat your code to ensure that the const pointer never outlives the pointed object.

[@Maciej-Komosinski]

How would you want to deal with this situation? What is wrong about it and why this situation requires dealing with? You made a pointer const so... it is const :-)

[@jvsnyc]

++rating for mentioning that tho the optimizer will probably make sure there is no difference on built-in types when the result is thrown away, the meaning of ++var and var++ is distinctly different, and most of the time when people write var++ they actually mean ++var. This is indeed a bad habit to get into for the times it will make a difference in behavior.

[@jvsnyc]

+1 for correctly defining dangling pointers. Too many people use the term in reference to memory leaks. The most bizarre and hard-to-debug misbehavior imaginable comes from reading, and worse still, writing to them....they are an OSHA and ISO-certified workplace safety hazard!

[@IndellableHatesHandles]

I don't think dereferencing nullptr will ever _not_ segfault. I could be wrong, but unless you're using some ancient system from the 80s, it'll always segfault.

[@JoeBurnett]

Great presentation, Ben! Thanks for making this.