Closed igorski closed 5 years ago
At the risk of going a little too Bjarne Stroustrup here, I prefer the code to be structured in such a way that ownership and hierarchy are defined by clear relations. Also, being able to control the exact moment a potentially large chunk of memory is destructed (e.g. before or after sequencing-and-render rather during) prevents performance bottlenecks.
The puzzling thing about this issue is that the ownership of the OpenSLStream* (which leads to the crsh here) resides within the _openslio which is wrapped by DriverAdapter. Construction, destruction and writes to the stream all happen within this single class...
Alright, I get where you are coming from with ownership and when you are writing the framework, you get to make that call. :)
I guess it really comes down to how you just answered that question, you know who owns what. :)
BTW, I basically have UML for most of these classes, so it is becoming evident what is going on to me.
Problems like this are still over my head because I haven't got as low as the OpenSL layer yet. Still diving. :)
Merging as there are overall improvements in this PR. Will however treat https://github.com/igorski/MWEngine/issues/55 as not-resolved for as long as it occurs on the Cat S60.
Just a thought but have you pondered implementing std::unique/shared_pointer<> wrappers for some of this stuff?
I am no C++ guru but I have been reading a ton and really, using raw pointers sounds like it ends up like this, chasing your tail.