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

preview_player
Показать описание
---

Back to Basics: C++ Value Semantics - Klaus Iglberger - CppCon 2022

Modern C++ is more than new standards or an assortment of new features. Modern C++ is about a philosophy on how to use the language. An integral part of this philosophy is value semantics: preferring values and value-like types instead of pointers and references.

This talk explains the rational of this philosophy. It demonstrates the benefits of several value types from the standard library, such as std::optional, std::function and std::variant, and the drawbacks of several reference types, such as std::string_view and std::span. It also goes into detail about the most common questions about value semantics, as for instance how to properly use reference types and whether we should stop using reference parameters.
---

Klaus Iglberger

__

#cppcon #programming #cpp
Рекомендации по теме
Комментарии
Автор

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

uiop
Автор

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

robert-yates
Автор

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

bunpasi
Автор

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.

thelatestartosrs
Автор

Great talk Klaus! Very informative and well delivered.

fishoutofwater
Автор

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.

HellCatLeMaudit
Автор

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.

andreysolovyev
Автор

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

DotcomL
Автор

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.

AbelShields
Автор

if C++ 23 brings this then what will happen to the bitwise operator?

hassinayaz
Автор

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.

AxWarhawk
Автор

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).

peregrin
Автор

Is std:variant like zig's tagged union?

张洋-sr
Автор

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?

HomerSimpson
Автор

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

tourdesource
Автор

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.

mcmaddie
Автор

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.

HellCatLeMaudit