Not even remotely similar. Note carefully your phrase "increments a reference count in the addressed object". Right there, you've gone off the rails, placing a requirement on the referenced object -- that it be managed by reference counts, and in a way that's compatible with how Qt's pointers interface with them. And further, it requires that the application that owns the object manage them in a way that is consonant with the possibility that Qt will be deleting the object. That means, it can't implement various cleanup strategies that depend on knowing when the reference count is zeroed -- because it may happen outside of its control.
And don't even get me started on circular references, and interoperability, or performance, or storage requirements, or the thread-safety/performance trade-off you have to make, or the effect of all those updates on memory caches and memory bandwidth. And I don't think that even I can begin to enumerate all the ways there are to screw up with "smart pointers". But at least reference counting is better than std::auto_ptr. Ever try to explain to someone what happened when they made a std::vector of std::auto_ptr's? And then passed it by value, or resized, or.... And even std::auto_ptr is better than malloc/free. Anyway - care to explain, in a reference counted system, how you would hold onto an object -- up until the object is deleted? All you get is reference-counting smart pointers -- you don't get to impose an I'm- about-to-be-deleted callback protocol. You don't get to have a test for an object being dead. Nope, your choices are -- increment the reference, and keep the object live, or don't increment the reference count -- and don't look at it. Don't even compare the pointer value. That's why even reference-counted languages like Python have weak references. It's really not something you can implement as a user- level feature (i.e. above the reference-counting or tracing GC). On Jul 26, 2:10 pm, DanH <danhi...@ieee.org> wrote: > Qt implements object assignment. One such object is a pointer > (similar pointers are implemented in other C++ dialects) that > increments a reference count in the addressed object when constructed, > decrements on destruction. You can assign the pointer and it's > copied, with appropriate incrementing. If you use the right flavor > pointer (there are several) the object will be be deleted when the > reference count goes to zero. Other flavors (linked in a reference > chain) act like weak references and go null when the object is > deleted. > > All rather automatic (and atomic), with lots of (ahem, shall we say) > "less than stellar" programmers using the stuff and only occasionally > screwing it up. > > On Jul 26, 3:49 pm, Bob Kerns <r...@acm.org> wrote: > > > > > Um, no. For Qt to do what you claim, it would have to traverse all the > > application data -- including data owned by non-Qt code -- to discover > > what application objects are still in use. In other words, it would > > have to implement a GC. > > > Unless your definition of "almost exactly the same stuff" is a lot > > looser than what I would think. > > > Would you care to give an example of which Qt API you mean? And > > perhaps what binding, if that's relevant? > > > On Jul 26, 4:13 am, DanH <danhi...@ieee.org> wrote: > > > > That's odd, because Qt can do almost exactly the same stuff, without > > > weak references or implicit garbage collection, using reference chains > > > that the average user never has to think about. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
