Explain the rule of 5 in C++ like I'm 29 years old

It's slightly more nuanced

Not him but please explain.

You only need the rule of 5 when you're allocating memory in the destructor (which means you're also deallocating it in the destructor). If I implement a destructor that does something non-memory related, for example output a line of text, then I wouldn't need to bother with the rule of 5.

Furthermore, the rule should actually be avoided whenever possible by not allocating class data manually.

In C++, you can only initialize by constructor and always needs to run destructor.
The rule describes how to properly implement ownership semantics for the class.
The issue would appear if destructor clears some resource and you copy this instance of class - then both instances attempts to clear the same resource = bug.
If you implement one of the destructors/assignment operators then it means you probably have some ownership semantics for the class. Thus the rule.
Copying has to ensure that those instances don't clear the same resource. The resource should be copied or be designed towards it (e.g. reference counting container).
Moving should ensure that the instance moved out doesn't clear the resource any further. It's still not a complete solutions though, as the destructor still runs for the instance that has been moved. You need to make sure that the move assignment operator changes it into the state where destructor has no undesired effect.

This. I've only ever had to define all this stuff a couple times when dealing with C APIs. Otherwise smart pointers work just fine.

t. retard who thinks memory allocation is the only type of resource management there is.

Chances are if you aren't, you don't need move semantics either

That looks like the angriest nerd I've ever seen.

The compiler automatically generates the destructor, the copy and move constructors, and the copy and move assignment operators, but only if none of them were previously defined by the user. The reason for this is that if any of those are defined by the user then the automatically generated ones would most likely be incorrect. For example, if your class has a user-defined destructor because it allocates memory, then a compiler generated copy constructor that simply copies the pointer to the allocated memory would lead to double delete/use after delete errors.
The rule of five says that you should therefore define all five whenever you define at least one of them. There are obvious exceptions to this rule, such as move-only types (like std::unique_ptr).
There is also the rule of zero, which says that you should try to avoid having to define any of them by using smart pointers, STL containers, and other RAII stuff whenever possible.

So in C++29 there will be a rule of 36, right?

Attached: avgn.gif (490x360, 3.53M)

t. has never used a mutex

>If I implement a destructor that does something non-memory related, for example output a line of text, then I wouldn't need to bother with the rule of 5.
Wrong, retard.

>all of this boilerplate code just to allow ownership rules that still need to be managed manually
Why should I bother with any of this when I can just use Rust and have all this shit generated and managed for me for free? Is there any benefit?

Explain, retard

Rust legally requires you to become a tranny and puts you through a buttplug training program

>rule of 5 in C++
The ability to read and understand any C++ code will take at least 5 hours.

If you write any of the following
>Copy constructor
>Move constructor
>Copy assignment operator
>Move assignment operator
>Destructor
You probably want to write the other four.

If you don't write one, don't write any.

C++ tries a lot to move tons of semantics from being implemented by compiler to being implemented in a library from more core primitives. This is a result, it hurts performance and usability, but hey at least you can do all that crazy stuff that other languages can, but with all the pitfalls you have never even dreamed of.

>define non-trivial constructor
>somehow the other constructors should magically know what that non-trivial should be handled for their use case
ok retard

t. uses t. unironically

What the fuck is a move semantic?

Attached: 407502250-DMT_Crystals_10.1.jpg (1000x440, 75K)

Fun fact: we have search engines that let you take your question and google it for an instant answer.
Try it sometime.

Fun fact: you can not be an asshole for 5 minutes of your life and explain things as you understand them yourself instead of telling people to google it

It's not being an asshole, it's making you grow up and do the right thing instead of being a brainlet baby that needs every idea predigested by hivemind.

This is not reddit. Actually, it is, but I feel like telling you that it is not.

ur a poopyhead

Have fun being limited by trivially copyable types

Using rvalue references to implement proper move constructors and assignment operators.

class foo{
T* bar;
}

now we write

foo()
{
bar = new()
}
[\code]
now the default ~foo() will leak bar. so we write

~foo()
{
delete bar;
}
[\code]

for copy operator its the same.

default foo(foo&) will make a copy of bar

what will happen for
{
foo a{};
foo b = a;
} ->
a delete bar;
b delete bar;
thats a double delete;

sounds like a lot of Nerd shit lol

Too honest

Most to the point answer in thread

>Denial
>Anger
>Bargaining
>Depression
>Acceptance

kekimus maximus

What the fuck am I reading

Please indent and properly format your code, you uncultured barbarian

Attached: 1c8.jpg (637x394, 19K)

yeah no brain babby
you obviously don't belong here

>ever heard
>nintendo
>atari
>sega
>video game

Attached: HNI_0058.jpg (416x343, 27K)

ITT: Jow Forums shows their complete lack of understanding of C++

class Integer // implements rule of 5
{
private:
int* data = nullptr;
public:
// default constructor
Integer() : data(new int(0)) {}

// explicit constructor
Integer(int val) : data(new int(val)) {}

// copy constructor
Integer(Integer const& other) : data(new int(*other.data)) {}

// assignment operator
Integer const operator=(Integer const& other) {
if (this != &other) {
delete data;
data = new int(*other.data);
}
return *this;
}

// destructor (can be virtual)
~Integer() {
delete data;
}

// move constructor
Integer(Integer&& other) {
data = other.data;
other.data = nullptr;
}

// move assignment operator
Integer const& operator=(Integer&& other) {
if (this != &other) {
delete data;
data = other.data;
other.data = nullptr;
}
return *this;
}
};

>initializing to nullptr
>then initializing to 0
What the fuck are you doing?

This is a serious question

>rolling rock
based

What a shit language. Just look at this fucking garbage.

Not that user, but you seem to have missed the new.

Learn C++ Jim

int* data = nullptr; // data points to nullptr
int* data = new int(10); // data points to freshly allocated 10

>Why yes I prefer to have no control over the semantics of my types

>Calls init() on a dozen objects
>12th one fails
enjoy calling destroy() on 11 objects and be careful not to double free anything.

Don't manually manage memory in C++ nigger

Don't tell me what to do

>Why yes I prefer to write hideous boilerplate

Lmao!

Why would we want to understand a overly complicated shitty language that makes you write this much boilerplate then wait a week for the program to compile?

There is no boilerplate there pajeet.

desu Greg is the best teacher, the other guy is a savant

Attached: female_wojack4.png (705x705, 212K)

It's pretty disgusting sometimes but I still use it.

Not knowing how to program properly is not a merit user

Based

Attached: 1514168374365.jpg (682x682, 272K)

dilate

that's why one should default to rule of 0 most of the time.

>buttplug

>Wanting a waifu
>Trying to get a waifu
>Making a waifu
>Being the waifu

rolling rock
on the rolling rocker
ROLLING ROCK
ON
THE ROLLING ROCKER!

>overly complicated shitty language
So write Python

Rust doesn't have this problem. It also doesn't have constructors.

What are you talking about? Rust derives clone and drop in the same way that C++ defaults the copy constructors and destructors. And if you need to write them explicitly, you write them explicitly in both langs. You either don't understand the problem or the languages you're discussing.

Based

You can derive Clone function, but that's it. You don't derive Drop and you don't have to implement it unless you do something unsafe.
There is no move constructors, no move assign or any of that shit. You only have static build methods and eventually clone method you derived or implemented yourself.
In practice you only have to implement static build method, nothing more.

Just switch to C# or Java bro ;)

Drop is derived for you, dummy, you don't have to annotate the derivation because it happens already.
Also the lack of move assignment/move constructors is a limitation, not a feature. You can't e.g. update a structure that uses back pointers by using a move function - the borrow checker wouldn't even allow such a construct any way!
The move functions can be defaulted, too.

>>learn these move semantics then write mystical spaghetti that will entrap your future self, goy

It's the other way around, user.
The philosophy of C++ is that all the pain goes onto people writing libraries, so that people writing higher-level code can enjoy comfy programming. Modern C++, at a high level, is as easy as Python, but without all the stupid traps of Python.

The philosophy of C is that all the pain goes onto everyone.

That's an example of overengineering a simple problem just so that you can see what you'd do if you had an actual complicated problem while also making it understandable. Of course in the case of the example is memory management because it's an easy problem (but in reality you'd never have to write all this because 99% of the time any real code that uses new or delete is either ancient or written by a moron who doesn't know C++ or thinks C is the pinnacle of human achievement). A reasonable situation where you'd actually do this would be implementing your own resource management class (e.g. database connection), but this is something you do very rarely.
Not using smart pointers is the equivalent of unsafe code anyway.

>Not using smart pointers is the equivalent of unsafe code anyway.
You can write safe code without smart pointers.

>Rust
>call the type's ::new() function
>everything behaves exactly how you want it to
>don't read from arbitrary memory addresses and have undefined behavior because of a typo or logical error

This but unironically

Rule of five:
>every five lines introduces a bug

I was referring to the concept of unsafe code in Rust, not whether the code is actually safe or not.

LOL

I know, I'm just saying that you can write safe rust code without using smart pointers. You can't solve every problem this way, but why would you limit yourself like that.