Yep there's an STL version of QSharedPointer and QWeakPointer but we prefer Qt to STL wherever possible.
Cheers, RJ Ryan Julien Blanc wrote: > Russell Ryan a écrit : > >> A quick look at all the classes which have member variables which store >> references to TIO's indicates to me that we're going to need many more >> mutexes than just those 2. >> >> I'm kind of against adding an explicit lock per instance of thing that >> uses the TIO. I think it'd be better if we added a generic reference >> count to the TIO that you could increment() and decrement(), not >> set()/get(). All places in Mixxx which store a pointer to the TIO (the >> analyserqueue, the waveform, the player, the reader, the engine, etc) >> would increment() once they receive the TIO (and store a pointer to it), >> and decrement() once they are done with it and have erased all >> references to the pointer. The player, reader, and waveform would all >> automatically decrement() once a new track is loaded, so those would >> never cause dangling references. We could even make it delete itself >> once its reference count drops to 0. >> >> An alternative way of doing this is to use QSharedPointer, which would >> lock us into requiring Qt 4.5. I'm also wary of using this because not >> every reference to the TIO is worthy of reference counting. Disregarding >> the large amount of work that would need to go into replacing every TIO >> pointer with a QSharedPointer, this is not a bad plan. >> >> In either case, we would make the TIO destructor emit a signal like >> aboutToDelete() and then delete itself. The thing that created the TIO >> would connect this signal to some slot it has and do whatever logic it >> needs to to clean up after it (e.g. the TrackCollection would serialize >> the TIO's relevant data to the database). This way whatever source >> created the TIO in the first place knows which TIO's are resident in >> memory and which have been gc'd so they can hand out new references to >> the existing TIO on request, or load it from wherever (eg the database). >> > > I hadn't time to dive into mixxx's codebase, although it's many month now that > i'd like to, so this may be completly off-topic, but the problem here is, as > far as i understand, typically what std::tr1::shared_ptr/std::tr1::weak_ptr > are designed for. > > Looks like the player should use a shared_ptr, while the other components of > mixxx should store weak_ptr on this instance. This would not require any > additional run-time dependancy, but would still require to change any pointer > to a TIO into a shared or weak_ptr. > > regards, > > Julien > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
