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

* 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

Barry <bg_ie@yahoo.com> wrote in news:efac0ea9-d335-42da-8b92-
cf773ad3718e@q23g2000yqd.googlegroups.com:

> 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?

Yes, the only thing shared_ptr does is to keep the object alive until it is 
not needed any more. If you are not deleting any Sound anyway before the 
end of the program, then you do not need shared_ptr. OTOH if you foresee 
that you might want sometimes to delete a Sound in the middle of the 
program, for example by replacing it with an updated version loaded from 
disk, then shared_ptr would probably be the simplest way to achieve this 
feature.

cheers
Paavo