• Advertisement
Sign in to follow this  

Rule of Three, and const-correctness questions

This topic is 1628 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

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.

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.

My point is one should be useing smart pointers with the right copy semantics, or a wrapper that implements copy semantics per resource.

Share this post


Link to post
Share on other sites
Advertisement

My point is one should be useing smart pointers with the right copy semantics, or a wrapper that implements copy semantics per resource.

What do you mean by that?
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 Edited by L. Spiro

Share this post


Link to post
Share on other sites

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.

Just thought I'd throw a slight spanner in the works there by mentioning value_ptr. smile.png
http://www.mr-edd.co.uk/code/value_ptr

Share this post


Link to post
Share on other sites

My point is one should be useing smart pointers with the right copy semantics, or a wrapper that implements copy semantics per resource.

What do you mean by that?
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.

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

First, better post ever.

 

Second, shouldn't this thread be stickied or something. It seems too good to be archived and be forgotten.

 

Three, I take it that Rule of Three, Rule of Two, and RAII are just C++ rules. Or do they apply to languages like C# and Java?

Edited by Alpha_ProgDes

Share this post


Link to post
Share on other sites

... shouldn't this thread be stickied or something. It seems too good to be archived and be forgotten.

 

Agreed that there's a lot of good stuff here. It would be nice to have a way of immortalizing things like this somehow without making them sticky; you'd soon enough overrun the front page with stickies. Its a hard problem, actually, to bubble content to the top in an effective way that also scales, even when all the content is curated. We have the same problem on MSDN, where I work. Most places, and most users, rely on search.

 

Arise thread long since dead. Haunt thy forums from which thou were created.

 

Please check the last posting date before you post.

 

Nice image! But the thread is only ~6 months buried, and Leeor was even on-topic. That's only low-level necromancy at best biggrin.png.

Share this post


Link to post
Share on other sites

Three, I take it that Rule of Three, Rule of Two, and RAII are just C++ rules. Or do they apply to languages like C# and Java?

The Rules of Two or Three are C++ specific. RAII is a more general principle that may be applied to languages like java and C#, but not as effectively, because those languages don't schedule object destruction predictably.

Share this post


Link to post
Share on other sites

The Rule of Three is out-dated and does not play well with exceptions. The Rule of Two is much safer as it relies on RAII, which is in itself (almost) always the correct choice.
Rule of Two

 

 

L. Spiro

 

 

It's worth noting it has become significantly simpler now:

 

The Rule of Zero (which is actually a particular instance of the Single Responsibility Principle):

 

"Classes that have custom destructors, copy/move constructors or copy/move assignment operators should deal exclusively with ownership. Other classes should not have custom destructors, copy/move constructors or copy/move assignment operators."

 

See: http://flamingdangerzone.com/cxx11/2012/08/15/rule-of-zero.html

Edited by Matt-D

Share this post


Link to post
Share on other sites

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.

Note that if you want to prevent modification of the function parameters in your function you don't need to put const on the parameters in the header, only in the implementation. The C++ overloading rules make T and const T the same for parameter types. So you can have foo(int a) in the function declaration in the header and foo(const int a) in the function definition. (Barring compiler bugs anyways. I've heard of one compiler that doesn't perform parameter type resolution properly.)

Share this post


Link to post
Share on other sites
I looked at L. Spiro's link about the Rule of Two.

I'm confused about a couple of points. What is the purpose of the reset() and swap() functions? Reset deletes the pointer then assigns the incoming pointer to the deleted pointer! O.o How does that work and under what circumstances would I use swap?

Share this post


Link to post
Share on other sites

Arise thread long since dead.

 

 I didn't think it was that old... whoops. Besides, I felt the need to respond to a valid counter point to my original argument.

 


Note that if you want to prevent modification of the function parameters in your function you don't need to put const on the parameters in the header, only in the implementation. The C++ overloading rules make T and const T the same for parameter types. So you can have foo(int a) in the function declaration in the header and foo(const int a) in the function definition. (Barring compiler bugs anyways. I've heard of one compiler that doesn't perform parameter type resolution properly.)

 

More good points.

Share this post


Link to post
Share on other sites

 

 

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.

 

Note that if you want to prevent modification of the function parameters in your function you don't need to put const on the parameters in the header, only in the implementation. The C++ overloading rules make T and const T the same for parameter types. So you can have foo(int a) in the function declaration in the header and foo(const int a) in the function definition. (Barring compiler bugs anyways. I've heard of one compiler that doesn't perform parameter type resolution properly.)

 

 

Adding to that, this is perfectly fine if the parameter is passed by value -- it doesn't communicate the constraint to the client, but this is fine (maybe even preferable) since it doesn't impact them.

 

But for parameters passed by reference or pointer types, its critical that const appear in the header as well, because then you need to communicate to the client that even though you're taking the parameter by ref or ptr, you are promising not to change it. I don't actually know off-hand, but passing by ref or ptr might affect the overload rules sicrane mentions (that is, are &T and const &T treated differently than T and cont T, WRT overloading), so the point in practice may be moot, enforced by the compiler anyhow. Just be aware that you need to think about how the parameters are passed in this context.

Share this post


Link to post
Share on other sites
When a T is a pointer or reference then [tt]const T[/tt] is not the same as adding [tt]const[/tt] to the thing it refers to. Say T is [tt]U *[/tt]. [tt]const T[/tt] is [tt]U * const[/tt], a const pointer to non-const U, not [tt]const U *[/tt], a non-const pointer to const U. So for the purpose of overload resolution [tt]foo(U *)[/tt] and [tt]foo(U * const)[/tt] are the same, but different than [tt]foo(const U *)[/tt].

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement