Take the 2-minute tour ×

It's common to declared contained objects as a pointers to that class, while "forward declarating" them in header file. This in order to reduce physical dependencies in code.

For example

class B;  // forward declaration   

class A {
      B* pB;

Would it be good idea to declare such a member as shared_ptr, instead of naked pointer?

I would prefer scoped_ptr, but AFAIK it it won't be in standard.

share|improve this question
If you need shared pointer semantics - why not? I'm not clear what you are actually asking here. –  anon May 10 '10 at 8:57
I don't need shared pointer semantic. Since I declare B to be a pointer to B (to reduce phisical dependencies of classes class A), I need to create B by calling new. Therefore I need to delete it in A's d-tor. It's not much work, but the question if using shared_ptr here, to take care of B deallocation, is a good proctice or not. –  dimba May 10 '10 at 9:04
@idimba: if you don't need what a shared pointer has to offer, why would you use one? If you don't need what a pointer has to offer, don't use one of those either. A pretty good rule of thumb is to not use a language feature that doesn't match what you're trying to do. –  jalf May 10 '10 at 16:37
shared_ptr / unique_ptr FTW ! ! –  CyberSpock Feb 7 '13 at 8:22

4 Answers 4

Yes you can (should ?).

This is a common practice. As you stated it avoids the need to explicitely call delete().

You can go even further. Here is an example:

class RSAKey



    shared_ptr<RSA> d_rsa; // A pointer to a RSA structure from OpenSSL

Which I initialize like this:

  RSA* rsa = RSA_generate_key(1024, 1, NULL, NULL);

  if (NULL == rsa) throw DummyException();

  d_rsa.reset(rsa, RSA_free); // Note the specific release method.

When d_rsa will no longer be used, an automatic call to RSA_free() will occur. Isn't that cool ?!


If C++11 is an option, you should probably better use std::unique_ptr instead which has less overhead and is movable.

It depends on how you want your enclosing class to behave in regards to copy.

share|improve this answer
automatic member deallocation is exactly my question :) –  dimba May 10 '10 at 16:24

If this pointer is not passed out of your class impelementation and execution speed is crucial, use scoped_ptr instead of shared_ptr. shared_ptr has an overhead.

share|improve this answer
I believe scoped_ptr is not in incomming C++0X standard. –  dimba May 10 '10 at 16:25
@idimba, unique_ptr is the C++ version of it, which is also movable. –  Johannes Schaub - litb May 10 '10 at 17:55

Using a shared_ptr would allow you to pass ownership to another object, so that it doesn't get destroyed when your outer object is destroyed. You state that this won't be a concern in this particular case.

The only advantage a smart pointer will have is that you won't need to remember to put a delete pB in your destructor. That may be enough advantage for most people.

When you don't need to worry about ownership issues, even an auto_ptr will be good enough.

share|improve this answer

In the case of a composition, yes it is a good idea if you don't want physical dependency. Then your B will be destroyed automatically when A is.

If you don't mind physical dependency, you can just hold the data member by value.

(You can also check for the pimpl idiom if physical dependency is a problem.)

share|improve this answer

Your Answer


