Wow, thanks for all the replies everyone!
I'm in the process of following the Rule of Three in my code; after some trial and error, I have a handle on the concept. It's a small project, so I won't be using smart pointers yet - however I'll keep them in mind for future projects.
Once again, thanks for all the insight and time!
By the way, to the OP, I think your on the right track wanting to learn about const correctness and the rule of three,.
Another good thing to learn at this point, if you don't already know, is how to use the std library smart pointer classes std::unique_ptr and std::shared_ptr.
I think you would be on a better track learning the Rule of Two and RAII (repeated because it was likely lost in the slew of other previous replies).
Honestly, RAII probably takes priority over either Rule or Three or Rule of Two, which is not to say the rules are not important, but RAII is just such a core principal that can and should be applied vigorously throughout all of your code, as it prevents memory leaks (even complicated ones caused by exceptions), failure to release file handles, failure to leave critical sections, failure to delete pointers, etc.
Failure to follow one of the Rules of X will bite you in the ass when you copy complex objects, but from a performance standpoint that is something you should be trying to avoid as much as possible anyway. While it is still sometimes necessary to copy complex objects, you will get bitten in the ass far more often by failing to release some resource or leave a critical section, as these cases simply happen magnitudes more often in practice than copying complex objects.
So once you have thoroughly employed RAII, Rule of Three no longer makes sense.
Better to prioritize RAII and then go with Rule of Two without wasting time on the less-safe (due to exceptions) and more time-consuming Rule of Three.
L. Spiro
Wow, thanks for all the replies everyone!
I'm
in the process of following the Rule of Three in my code; after some
trial and error, I have a handle on the concept. It's a small project,
so I won't be using smart pointers yet - however I'll keep them in mind
for future projects.
Once again, thanks for all the insight and time!
As jwezorek says, you do want to learn and use smart pointers. Even in small projects. Smart pointers and STL containers are the preferred way of managing memory so that you don't have a leak.
The rule of three has it's place, but smart pointers make it much more rare.
I think you would be on a better track learning the Rule of Two and RAII (repeated because it was likely lost in the slew of other previous replies).
Honestly, RAII probably takes priority over either Rule or Three or Rule of Two, which is not to say the rules are not important, but RAII is just such a core principal that can and should be applied vigorously throughout all of your code, as it prevents memory leaks (even complicated ones caused by exceptions), failure to release file handles, failure to leave critical sections, failure to delete pointers, etc.
Failure to follow one of the Rules of X will bite you in the ass when you copy complex objects, but from a performance standpoint that is something you should be trying to avoid as much as possible anyway. While it is still sometimes necessary to copy complex objects, you will get bitten in the ass far more often by failing to release some resource or leave a critical section, as these cases simply happen magnitudes more often in practice than copying complex objects.
So once you have thoroughly employed RAII, Rule of Three no longer makes sense.
Better to prioritize RAII and then go with Rule of Two without wasting time on the less-safe (due to exceptions) and more time-consuming Rule of Three.
L. Spiro
I agree that RAII is a concept that johnmarinelli needs to learn, but he could do without the rule of two. I made this objection earlier in the thread. You don't want a single object managing more than one resource. Also, writing a rudimentary smart pointer, then implementing different copy semantics on top of it, as link you showed suggests, is not, in my opinion, generally the best way to ensure RAII.
EDIT:These quote tag are very annoying to work with!
You probably don't want to manage resources in your objects at all, for that matter, but get references to them from an object pool/manager/cache of some sort that actually does the lifetime management of the resources.I agree that RAII is a concept that johnmarinelli needs to learn, but he could do without the rule of two. I made this objection earlier in the thread. You don't want a single object managing more than one resource. Also, writing a rudimentary smart pointer, then implementing different copy semantics on top of it, as link you showed suggests, is not, in my opinion, generally the best way to ensure RAII.
Good point. I recently had to implement copy and assignment operators for a class with reference members. And as you say, you don't need a destructor for that.But sometime it's even not about resources. Do you need to follow the rule of three if your object has a const POD member?
My point is one should be useing smart pointers with the right copy semantics, or a wrapper that implements copy semantics per resource.Also, i saw the linked article to be more about not needing the rule of three if you use smart pointers/RAII, and not about implementing your own smart pointers.
What do you mean by that?My point is one should be useing smart pointers with the right copy semantics, or a wrapper that implements copy semantics per resource.
Just thought I'd throw a slight spanner in the works there by mentioning value_ptr.If you copy a smart pointer you just get another smart pointer—if the object to which it points needs to also be copied it will be by its own copy semantic, not by those of the smart pointer.
What do you mean by that?My point is one should be useing smart pointers with the right copy semantics, or a wrapper that implements copy semantics per resource.
When you copy a smart pointer, the result is another smart pointer. The object to which they point doesn’t change, nor do you need to write different copy semantics for smart pointers of different kinds/different resources.
I think you are confusing copying the smart pointer itself and copying the object to which it points. If you copy a smart pointer you just get another smart pointer—if the object to which it points needs to also be copied it will be by its own copy semantic, not by those of the smart pointer.
If you copy the object to which it points you still have to implement copy semantics for that object if it is complex, regardless of whether or not it is a raw pointer being dereferenced or a smart pointer being dereferenced. This in itself is not related to either Rule of X.
The only thing that is related is that the smart pointer will delete the object to which it points for you automatically, eliminating the need for you to write an explicit destructor.
L. Spiro
If you need to duplicate an object on copy, then you don't need a pointer at all.
A single resource should be managed by a single object. If copying the resource duplicates the resource, then that's part of managing the resource. The example of int * as a resource is contrived. Wanting resources to duplicate on copy is a rare. More often, a shared_ptr will implement the right semantics. If no smart pointer exists that does the right thing, then a single class that manges the resource and implements copy semantics is the way to go.
You only need a const qualifier if you're passing by reference/pointer and you don't want the function to change the object being passed.
In addition to documenting your intent, const does have a function in this case -- it prevents you from modifying the argument inside the function body.
Very good point. Others have made the argument that it's about documentation. I fail to find that a useful argument. This, on the other hand, does make sense. While I'm personally in the habit of never modifying function arguments myself, I do see the value in this case of helping to identify potential mistakes before they happen.
