Changes between Initial Version and Version 1 of detect a RenderObject is destroyed unsafely


Ignore:
Timestamp:
Apr 25, 2011 11:55:39 AM (10 years ago)
Author:
Simon Fraser
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • detect a RenderObject is destroyed unsafely

    v1 v1  
     1'''Issue'''
     2RenderObject lifetimes
     3RO destroyed in Node::detach(), which is badly named.
     4
     5Complications
     6        anonymous containers
     7        continuations
     8        multicol stuff
     9        who else is pointing at you
     10                float lists in lines
     11                continuations
     12                line boxes around inline replaced elements
     13
     14Would like a WeakPtr system (but high memory cost)
     15
     16Why do you use RefPtr
     17        secondary use can hold a ref
     18
     19Can we use OwnPtr?
     20        just helps you not leak, and documents explicit ownership
     21        we don't use OwnPtrs because of RenderArenas
     22        are they still a useful opt? Need to measure
     23
     24RO guard is like a debug-only RefPtr. Maybe that's how it should be implemented.
     25
     26Two approaches
     271. Global "I'm holding a ref to some renderer, so don't destroy any". Addresses risk of being too specific
     282. Smart-pointer type object: RenderPtr
     29
     30
     31
     32
     33'''Actionable things'''
     34Rename the detach() method