Smart pointers as class members, to make copying more efficient

I'm just breaking into the use of Boost smart pointers for the purpose of making the copying of objects more efficient. Is this possible?
Usually when one makes a copy constructor and assignment operator, they look something like this:

Code:

---

class aclass {
  aclass(const aclass &other) {
        really_expensive_copy_procedure(other);
  }
  aclass &operator=(const aclass &other) {
        really_expensive_copy_procedure(other);
        return *this;
  }

---

But say you have "shared" smart pointers for your class members? Is it possible to just pass those around, thereby bypassing those expensive copy procedures? How would I set up my class that way? Yes, I am aware that if any instance of aclass writes to what the smart pointers contained, then all instances will change. The classes I want to write will treat these contained instances as read-only after they are created.

The reason I want to do this is I'd like to hide the use of smart pointers from the owners of aclass, thereby making it abstract. That why I'd have members like:

Code:

---

class aclass {
    aclass foo();
    aclass goo(const aclass &aclass_);
...
};
...
aclass a_class, anotherclass;
aclass yetanotherclass = a_class.foo();
anotherclass.goo(yetanotherclass);

---

You get the idea

Quote:

---

Originally Posted by Angus

But say you have "shared" smart pointers for your class members? Is it possible to just pass those around, thereby bypassing those expensive copy procedures?

---

Yes, it is.

Quote:

---

Originally Posted by Angus

How would I set up my class that way?

---

By storing the smart pointers as members.

Quote:

---

Originally Posted by Angus

The reason I want to do this is I'd like to hide the use of smart pointers from the owners of aclass, thereby making it abstract.

---

As in you intend to abstract away the use of smart pointers from the users of your class? Logically, if you did your class design correctly, you can just do this without breaking client code since it is a change to implementation detail. The problem is that your class copying semantics will change, as you have anticipated, and this is a change to the class interface.

Quote:

---

Originally Posted by laserlight

By storing the smart pointers as members.

---

Can you give me an example in a class declaration? And to be safe, an example of a copy constructor definition would be helpful, too.

My problem is that a typical copy constructor looks like this:

Code:

---

class aclass {
  aclass(const aclass &other);

---

Now if there's a "shared" smart pointer that's a member of aclass, call it m_srtptr, and the copy constructor tries to copy m_srtptr from other it will want to increment the reference counter, but other is const. See what I'm getting at?

Quote:

---

Now if there's a "shared" smart pointer that's a member of aclass, call it m_srtptr, and the copy constructor tries to copy m_srtptr from other it will want to increment the reference counter, but other is const. See what I'm getting at?

---

This is not a problem, you can copy a const smart pointer without any issues. If the reference of the const smart pointer needs to be incremented during a copy (like with shared_ptrs), then that reference count will be declared as mutable.

Quote:

---

Originally Posted by Angus

Can you give me an example in a class declaration?

---

Yes, but I think you want more than that, i.e., a class definition:

Code:

---

class Y;

class X
{
public:
    // ...
private:
    std::tr1::shared_ptr<Y> y;
};

---

Quote:

---

Originally Posted by Angus

And to be safe, an example of a copy constructor definition would be helpful, too.

---

A pretty helpful copy constructor definition would be to show you nothing, since the compiler generated copy constructor would suffice :)

Quote:

---

Originally Posted by Angus

Now if there's a "shared" smart pointer that's a member of aclass, call it m_srtptr, and the copy constructor tries to copy m_srtptr from other it will want to increment the reference counter, but other is const. See what I'm getting at?

---

Firstly, it is not the shared_ptr that you want to be const, but what it points to. Then, even if the shared_ptr was const, you need not worry about the reference counter during copying (other than the need to avoid a cycle).

Quote:

---

Firstly, it is not the shared_ptr that you want to be const, but what it points to. Then, even if the shared_ptr was const, you need not worry about the reference counter during copying (other than the need to avoid a cycle).

---

He is talking about the shared pointer being a member variable. If the class is const, then so are it's member variables. This still doesn't matter though, because you can copy a const shared_ptr.

Quote:

---

Originally Posted by bithub

He is talking about the shared pointer being a member variable.

---

Obviously ;)

Quote:

---

Originally Posted by bithub

If the class is const, then so are it's member variables.

---

Ah yes, I see that I did not mentally register the context that this would be a const reference.

Quote:

---

Originally Posted by bithub

This still doesn't matter though, because you can copy a const shared_ptr.

---

Yes, that is part of what I mean by "even if the shared_ptr was const, you need not worry about the reference counter during copying". The other part is that the reference counter itself is implementation detail, even though its existence (or at least the concept thereof) is exposed in the interface of shared_ptr. Consequently, this is a special case where the observable state of the object might correctly change even if it is constant.

Quote:

---

Originally Posted by laserlight

Obviously ;)


Ah yes, I see that I did not mentally register the context that this would be a const reference.


Yes, that is part of what I mean by "even if the shared_ptr was const, you need not worry about the reference counter during copying". The other part is that the reference counter itself is implementation detail, even though its existence (or at least the concept thereof) is exposed in the interface of shared_ptr. Consequently, this is a special case where the observable state of the object might correctly change even if it is constant.

---

In fact, the most obvious implementation of shared_ptr involves keeping the refcount in a separate chunk of memory, which means that it's not actually within the shared_ptr itself, and can be modified even if the shared_ptr is const, and this does NOT require the use of "mutable"