Special Member Functions in C++ - Kris van Rens - C++ on Sea 2023

cpponsea.uk/
---
Special Member Functions in C++ - Kris van Rens - C++ on Sea 2023
All class types in C++ have a set of non-static special member functions. Among them is the constructor, destructor, copy constructor and copy assignment operator. In C++11, move semantics were introduced, and the move constructor and move assignment operator were introduced. Special member functions, when not defined explicitly, may be automatically generated by the compiler. But this is not always the case. Exactly when are they defined, and when not? What is the rule of all or zero? And is it any good? Did you know there are about eight different forms of constructors? And when it comes to copy/move operations, do you know when you need to implement them yourself? And how? In this session, I will guide you through the wonderful world of special member functions. We will look into definition rules, constructor forms, copy/move operations, implementation idioms, and testing of special member functions. Also, we will take a look at some commonly encountered situations involving special member functions, such as class state initialization/reinitialization, and how to create consistent implementations for these cases. As a C++ software engineer equipped with a clear understanding of special member functions, you will be more confident and effective.
---
Slides: github.com/philsquared/cppons...
Sponsored by think-cell: www.think-cell.com/en/
---
Kris van Rens
Ever since the first time Kris got in touch with his dad's 1983 ZX Spectrum, he was captivated by the wonderful world of computer programming. In 1995, he learned to program 'Pacman' in x86 real-time assembly, which was soon followed by learning C and then C++, which came to be his bread and butter. He is very serious about code quality and is mostly interested in C++, Rust, Linux, programming languages/paradigms, software architecture and performance optimization. He currently works as the lead developer at ViNotion in Eindhoven (NL) and as a trainer at High Tech Institute Eindhoven. If he is not working, coding for fun or doing dad-/husband-related things, he is probably playing the guitar or running out in the woods. Kris studied mechatronics at FH Niederrhein, Krefeld (DE), and electrical engineering at the TU/e in Eindhoven (NL). He can be contacted at [e-mail]
---
C++ on Sea is an annual C++ and coding conference, in Folkestone, in the UK.
- Annual C++ on Sea, C++ conference: cpponsea.uk/
- 2023 Program: cpponsea.uk/2023/schedule/
- Twitter: / cpponsea
---
CZcams Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
#cpp #cpponsea​ #cppprogramming

[@SamWhitlock]

49:26 just in case anyone is wondering, this is not UB: C++ member initialization is done based on the order in which they're declared in the class, not the initialization list order. However, this is extremely confusing to not have them line up, so don't do it IRL (lest you confuse colleagues).

[@N....]

48:48 it's not clear from your explanation, but initialization order is always the order of the data members in the class definition. The order in each constructor is ignored. So this code is perfectly fine, it's just confusing to read. The only warnings would be a suggestion to re-order the constructor initializer list so it matches the actual behavior, but either way the behavior is the same and, in this case, well-defined.

[@krizzzlybear]

Yes I could have done a better job there. Thanks for the comment and proper explanation!

[@VoidloniXaarii]

Thank you for this great talk

[@cpponsea]

You are so very welcome! Thank you for your comment.

[@VoidloniXaarii]

@@cpponsea such an unexpectedly warm response, thank you so much, made my day

[@krizzzlybear]

Thank you very much!

[@tal500]

Notice that in Version 5 on the last minutes, you can leave the same class definition the same and init the Algorithm directly by a Configuration, no need for the user to explicitly constrcut AlgorithmInit from it.
Why? Because of C++ can automatically convert Configuration->AlgorithmInit.

[@Roibarkan]

55:51 the topic of self-move is a little controversial- many experts say it’s OK for self-move to change/clear the object state, and the only requirement is that the object is left in a valid state.

[@N....]

15:10 on the left, I think b is a function declaration due to most vexing parse, instead you'd have to write auto b = Zaphod();

[@krizzzlybear]

Yes! You're right, I should have seen that one. Thanks for the heads-up!

[@volodyanarchist]

For me the object that was moved from is a no-go for any use. If you use it, you are doing something wrong. To waste time and to try to safeguard against purposefully bad code is useless, that's akin to trying to guard against your object being memcopied with 0 bytes or something like that. Of course, you can do that, but why would you?