release of Java; when people realized just how broken they were,
WeakReferences (and, specifically, ReferenceQueues) were added much
later, as a replacement / "this is how to do it (more) properly". Of
course, this being Java, finalizers were never removed from the
language even when WeakRefs were in place....
public class Foo {
private static final List<Foo> myList = new ArrayList<Foo>();
protected void finalize() {
myList.add(this);
}
}
etc. etc. :)
--Alan
On Jul 27, 1:12 pm, DanH <danhi...@ieee.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."
>
> Not so. The only requirement is that the object class be derived from
> QObject, which embeds all the logic for this. No different from Java
> deriving all classes from Object.
>
> "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."
>
> I've never delved into it, but I understand that Qt implements a
> pointer type similar to the raw ref pointer that underlies the soft/
> weak ones in Java -- receives notification of when an object is at
> zero references. And even without that you're guaranteed that your
> object destructor will be called -- much more robust than Java's flaky
> finalizer scheme (where you're not guaranteed it will be called and
> you can't rely on it for "various cleanup strategies").
>
> Note that I'm not arguing that this stuff is better, but simply
> pointing out that there are indeed other ways to deal with the general
> problem. The Java approach is good but not great, and certainly not
> unique.
>
> On Jul 27, 4: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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment