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

[@LarsonOliveira]

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

[@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.

[@dkutagulla]

Simply the best talk about pointers and references

[@harshpatel4390]

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

[@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!

[@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.

[@kar_prz]

Excellent resource! Thank you for delivering this talk

[@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.

[@janjezewski1205]

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

[@kuxnal]

This is the best explanation. Thank you for this!

[@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.

[@JoeBurnett]

Great presentation, Ben! Thanks for making this.

[@rafalmichalski4893]

Simple topic, but well presented / explained.

[@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.

[@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.

[@opethforlife]

Amazing lecture, keep up

[@abhishekroy938]

Really interesting.. Thanks

[@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!