Getting to grips with boost::shared_ptr

[Barry]

Hi there,

I have a class called Sounds which creates a number of Sound objects
in its constructor and adds them to a local std:map variable. I also
define an enum in this class which I use as the key with respect to
the map. This class therefore acts as a look-up for all the sounds I
wish to use.

I also have a Player class which has a Play(Sound&) function. This
function stops the currently playing sound and plays the new sound
supplied by the argument. I also have a Stop() function which stops
the current sound. I use a Sound* local variable to keep track of the
current sound.

The question is, how do I know that I shouldn't be using a shared_ptr
instead of this pointer? - a design change which would also require
storing shared_pts in the map previously mentioned. For example, I can
crash my program by deleting my Sounds object before calling
Player.Stop(). Using shared_ptrs would avoid this crash. However, this
is a reckless way of producing a crash, are there more innocent ways
in which it could occur for my Player class?

For me, it feels that my Player class does not take ownership of a
sound object; it simply keeps track of it and therefore I use a simple
pointer. Is this the correct mentality with regard to whether I should
be using a shared_ptr or a simple pointer?

Thanks very much for your help,

Barry

 

[Alf P. Steinbach]

* Barry:

Hi there,

I have a class called Sounds which creates a number of Sound objects
in its constructor and adds them to a local std:map variable. I also
define an enum in this class which I use as the key with respect to
the map. This class therefore acts as a look-up for all the sounds I
wish to use.

I also have a Player class which has a Play(Sound&) function. This
function stops the currently playing sound and plays the new sound
supplied by the argument. I also have a Stop() function which stops
the current sound. I use a Sound* local variable to keep track of the
current sound.

The question is, how do I know that I shouldn't be using a shared_ptr
instead of this pointer? - a design change which would also require
storing shared_pts in the map previously mentioned. For example, I can
crash my program by deleting my Sounds object before calling
Player.Stop(). Using shared_ptrs would avoid this crash. However, this
is a reckless way of producing a crash, are there more innocent ways
in which it could occur for my Player class?

For me, it feels that my Player class does not take ownership of a
sound object; it simply keeps track of it and therefore I use a simple
pointer. Is this the correct mentality with regard to whether I should
be using a shared_ptr or a simple pointer?

It's OK.

Consider that the same problems that you envision exist with nearly all kinds of
objects in C++. To avoid the /possibility/ of dangling pointers every object
would have to be allocated dynamically and managed through smart pointers and/or
garbage collection. If that is what one wants then some other language, e.g.
Java or C#, is a more practical answer -- it's not the C++ way.


Cheers,

- Alf