Actually, as I closed my browser, it suddenly struck me why we differ in opinion here.
I look at Qt as being merely a library, embedded in a larger language environment. You're looking at it as a language itself. So long as you stay within the confines of Qt and it's primitives and objects, then we can say that yes, it does equivalent stuff. But then I have to differ with your statement that Qt doesn't have weak references. I claim that the things that "do what weak references do" ARE in fact, weak references. Weak references are not unique to Java -- they did not even originate there. We had them in Lisp Machines decades ago. (Well, technically, weak pointers, but they filled the same role-- they just turned the reference that held them into a weak reference). Nor are they unique to tracing garbage collectors. Python has them. A weak reference is simply a way of referring to an object that meets two simple requirements: 1) The object is not protected from reclamation 2) The object becomes inaccessible via the reference one it IS reclaimed. C++ foo* pointers meet the first, but the second is trickier, and is what requires language support. Which, Qt can do for itself, so long as you view it as the language in question. (It's perfectly reasonable to view it as a sub-language embedded within a host language). On Jul 27, 2:29 am, Bob Kerns <r...@acm.org> wrote: > 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
