Back to Basics: Cpp Value Semantics - Klaus Iglberger - CppCon 2022

Klaus is a great presenter, I've enjoyed this talk a lot as always.

it's always a pleasure to listen to klaus' talks

I'm always up for a talk of Klaus. His videos are so digestible.

Great talk Klaus! Very informative and well delivered.

brilliant talk!

Good talk, thank you

15:52 While I agree with the bullets listed, aren't we violating the Open-Close Principle here?! Assuming the original hierarchy-based architecture, one can define their own shapes and extend the visitor to also cover those shapes without modifying the original code. With the variant approach, the variant needs to be changed to account for newly added shapes. It follows that all code using the variant now needs to be updated to account for the new shapes. Furthermore, this might not be possible if the definition resides in a library which you can't modify. While this approach looks a lot simpler, I feel like it contradicts Klaus' previous talks Designing Classes.

One disadvantage of variant is it takes size slightly greater than its largest type, so if one shape is complex but appears rarely, too bad, your vector of shape variants will allocate more than a vector of that largest type. I don't think its a very compromising issue but still its good to know.

My problem with strict object oriented programming is that I need to rotate a polygon but before I can do that I need to think of its inheritance first and build things I don't really need at all. Real life programming is not like academic programming where we can take the time to create principles and implement those principles so we can write a paper about it. Non-academic programming requires that I get that software prototype out the door yesterday. Most first versions of software get thrown away after all. We learn something from our experience and the second version will incorporate those experiences. Perhaps in the third iteration we can think about casting what we learned, the experiences, into a methodology, and get that structure poured in concrete. But not the first version! At least C++ allows me to program without classes first before committing myself or the team to a structure which will turn out to be useless but had to be used because time and resources were spent on it. I can't say the same about Java. Java is the reason IDEs have for existence. The taxonomy of the classes is so complex no one can keep it all in her head.

I did get a bit curious on how you would finish the command pattern using std::function and value semantics

Thank you very much for the great presentation. May I offer another point of view on a trade off between value semantics and pointers? You can overview a class called ObjectHolder that contains different objects. Please compare such a class designed on variant and on unique_ptr. Here you (or anybody) will bump into all sorts of problems - slicing, object hold actual type determining, type casting problems, overheads in using dynamic_cast , etc, etc. Review of such problems and the way of tackling them may be useful for audience.

Don't underestimate Klaus's comments about value semantics in multithreaded and distributed systems. Using reference semantics in those situations is setting yourself up to fail. (If you think you need reference semantics in multithreaded environment then look at std::shared_ptr and pass that as value).

Why doesn't std::erase decrement the target pointers of its upcoming iterations since it knows it just removed one element from the container?

23:17 - this is why people love Rust, it takes care of this sort of stuff for you. You don't need to worry about a reference going invalid when a vector resizes, or a tree is balanced, it tells you what you're doing wrong and where.

Well presented. I'd like some questioning of just how variant beats virtuals and classic visitor. One advantage of visitor is that downstream projects can hook in their own custom types. Seems like variant, because it bakes in a finite number of compile-time cases (shapes) cannot allow this extensibility. Is that fundamentally why the performance gain with variant is possible?

10:00 While value semantics looks good and are the 'new cool thing' I like the 'old' way. That capsulates everything of those shapes in one class. Now instead having everything about for example circle in one place you have the circle class and then you need to implement draw - function for it in another class. It's more of a maintenance point of view than performance. And yes I have GUI library that is implemented similarly to 'old' way so maybe that's why I'm biased towards it, but I like that component knows how to draw itself.

Object oriented programming (or thinking in terms of classes and objects) became such a religion that even reasonable mathematicians convinced themselves that when we have two matrices A and B, then A + B means A adds itself to B (and thus modifying itself in the process) instead of the usual mathematical thinking of A + B being an operation on matrices A and B that results in a third matrix C.

kids play outside --- ha ha ha ! : )