I believe your SoundTouch
struct/class has an issue in its copy constructor and/or assignment operator. Or you haven't even written those but need to.
Why do I say this when I can't even see the code for SoundTouch? Well...
Your SoundTouchExt
has problems with how it manages its sTouch member (and fBufferOut as well). Each instance creates its own sTouch, but you don't have a copy constructor or assignment operator to deal with sTouch members whenever your objects get copied. The defaults provided by the compiler will simply do a shallow member-wise copy. So if one SoundTouchExt object ever gets assigned to another, then they will both end up with sTouch pointers pointering to the same SoundTouch. I doubt you ever intended for that to happen. However since you also don't have a destructor to clean up those allocations, you might get away with this situation for a while (since leaking memory would be easy to overlook).
And it looks like you are indeed get happening to get away with it while using vector<SoundTouchExt>
. A vector manages an internal array. When you add entries to a vector, it may sometimes run out of room in its current array and thus need to create a new array to hold the additional entry. In doing so, it has to copy all the entries from the old array to the new one. So that uses the copy constructor and/or assignment operator of SoundTouchExt. You don't notice this because the situation of two SoundTouchExt instances using the same SoundTouch only exists briefly before the one in the old array gets destroyed. And because SoundTouchExt lacks a destructor, there's nothing to cause a problem.
Now consider how things change when the sTouch member is an actual SoundTouch instance rather than a pointer. In that case, when a SoundTouchExt object is copied and thus the sTouch member is copied, that means the compiler will use the SoundTouch copy constructor / assignment operator. And we know your vector can cause that to happen.
Since your SoundTouchExt has the issues I've described with copying, I suspect your SoundTouch also has issues. If that is the case, then by the time you get around to trying to use an sTouch member, it has presumably already been copied and thus caused some kind of problem. That problem then leads to your crash.
So to fix things, you have a few options:
- Make sure all the relevant objects act correctly when being copied. This probably means implementing copy constructors and assignment operators. And in that case you most likely should implement a destructor, as per the Rule of Three.
- Or disable their copy constructors and assignment operators (declare them as private but don't implement) so they can't accidentally be used. That then might require some other refactoring, such as your vector usage. Although if you have C++11 features available, you might be able to make use of move operators/constructors so that your objects can work in standard containers like they do now but properly transfer their members when appropriate. A destructor is probably still necessary either way.
- Or replace those raw pointers with certain kinds of smart pointers (like unique_ptr) which can automatically manage anything allocated with
new
without you having to write any additional code.