Undefined Behavior in the STL - Sandor Dargo - CppCon 2022

cppcon.org/
---
Undefined Behaviour in the STL - Sandor Dargo - CppCon 2022
github.com/CppCon/CppCon2022
In this talk, I will briefly remind you what undefined behavior is and what dangers it can bring to our software - to our products. Then I'll demonstrate that the undefined behaviour is there even in the standard library, in containers, in algorithms. Moreover, I will explain that such behavior was introduced with care and purpose. We will go through some more interesting cases and we will also see how we can protect ourselves.
---
Sandor Dargo
Sandor is a passionate software craftsman focusing on reducing the maintenance costs by developing, applying and enforcing clean code standards. His other core activity is knowledge sharing both oral and written, within and outside of his employer. When not reading or writing, he spends most of his free time with his two children and his wife baking at home or travelling to new places.
__
Videos Streamed & Edited by Digital Medium: online.digital-medium.co.uk
#cppcon #programming #stl

[@DmitryShubin-ym4pj]

Good explanation. Thanks, Sandor.

[@Fetrovsky]

Nit: "class templates" is better than "template classes".

[@metal571]

Dr. Walter E Brown would agree. I will always love his example of "chocolate milk != milk chocolate"

[@YourCRTube]

This should have been "back to basics", I believe.

[@babgab]

The one that always gets me is not being able to modify the elements in std::remove_if. Especially annoying because updating an element at the same time you prepare to remove it makes such code substantially simpler in some scenarios.

[@jeremywmurphy]

In such a scenario, one relatively simple solution might be to partition the container first so that the elements to be removed are at the end, update them, then resize the container to erase them. Then your predicate remains pure and you could potentially reuse it in other situations, not just for removing.

[@babgab]

@@jeremywmurphy You could, and I have done that. But then you're iterating the list twice = potentially more cache misses and depending on what you're iterating over, you may be doubling up on taking locks and things like that. Or you're in a situation where you don't know until *after* the update step completes whether you're going to remove the element. You'd need to track which elements you're going to remove somehow if you're going to do that. If you can't infer that it's going to be removed from the state alone (which may be the case), either a flag on the thing being updated or some external structure (=wasting memory, probably). erase() in a loop is ergonomic in that situation, but it's also O(n^2) when you consider the whole loop (imagine if you remove ALL the elements) and so not at all ideal.
The remove_if algorithm itself is perfect for this exact use case. It's the constraints on the standard version that make it unusable here due to UB. This is one case where I would write my own remove_if implementation to guarantee that mutating predicates are safe.

[@shawnshaw9859]

you can use std::erase_if in c++20 now?