Back to Basics: The Rule of Five in C++ - Andre Kostur - CppCon 2023 

When you move to the new compiler, the presence of the copy operations would cause the move operations to be not declared. So attempts to move would "fall back" to the copies.

Would it make sense for SString? No, because SString is supposed to be the example to talk about a "broken" implementation. Could you use it in EString? Sure. std::vector behaves correctly using the rule of 0. Whether either of these would constitute a "good" string class is beyond the scope of the talk.

@@andrekostur2683 ​ I don't think the point for it was to be broken, just simplified(like std::string but worse) and showing the incremental improvements. EString or extended string was called such as it utilized composition to wrap std::string with extra functionality, rather than working with more primitive base components I thought? Unless I'm misunderstanding here? He also said that he stepped away from simple string to extended string as he didn't find a nice way to represent that. That's what I was asking about when I asked if it made sense to use that(as a nice way to represent that). I think we can both agree that this isn't a 'good' way to write a string class as there is a lot more to them typically, including short string optimizations that we are completely ignoring here, but for the purposes of this talk on the rules of 0, 3, and 5 I was wondering if it would be a nice way to represent the string that handles it correctly. Based on your response though, it sounds like it would behave as expected with the rule of 0 if I'm understanding right? ((I am not familiar with all the nuances of the compiler's auto generated constructor definitions when using std::vector, which is mostly why I'm not sure, but I *think* if I understood this talk right, it should work as expected?)) That was more what I was wondering.

@@Firestar-rm8df Yep, using std::vector as the final refinement to SString to make it work with the rule of 0 would work fine. It knows how to copy, move, and destroy itself well.

No. If you =default the moves, then they would be present and thus move operations would call those (compiler-generated) functions instead of the copy operations. And the idea was that one wanted to force everything through the copy operations.

I just created one of these the other day. I called it HeapObject. It knows how to copy and move itself, and it supports declaring an inherited class, and it looks to see if a function is defined for copying the inherited type and if not, defaults to using operator=, it also will implicitly cast to T* and explicitly cast to any other type of pointer, and it defines operator* and operator-> I'm also going to do this with a reference type Reference, and a HeapArray, and I'm pretty sure once I do that, every singel class in my code base will fall under the rule of 0

@20:30 This also sounds incorrect. "If you don't provide one [move assignment operator], the compiler will move-assign each of your member variable". Is this behavior simply true?

You are right, I misspoke. The intent of this example was to illustrate the preceeding statement about classes which take away the copy operations. std::unique_ptr is movable, but not copyable. Good catch!

@@IsaacC20 Assuming that one hasn't provided copy operations, or the other move operation, or a destructor, yes. What situation are you concerned about?

What is the Rule of 5? Slide 20 @15:50. Rule of 5 applies to any case where you do something special in any of the 5 special members. Manual dynamic memory handling is probably one of the easiest examples for the intended audience to generally immediately understand.

it's the king of all, others are made with either C or C++ or assembler.

Get out of here rust fanboy! Cpp will never die 😤

The class' intent on copying is to end up with two separate instances (separate copies of the data) of a string. But if you copy the shared_ptr, what you end up with two strings that are sharing the _same_ data. Which means that when you change one of them, the other one is also "changed" since the two are sharing the data.

The example presented is contrived - we can use std::string. We can't use a string_view variable when we want that variable to own the data as well.