Suppose I have the structure:
struct Image { char huge_image[ONE_ZILLION]; cyclic_ptr<whatever> ptr; };
As I understand it, in order to discover 'ptr', you'd invoke operator=() on each Image structure you came to. Correct, or incorrect?
Correct. So it would be smart to write an operator= for Image that avoids copying huge_image to itself.
OK -- so I see why you're saying it's the same as sp_collector -- because it covers the same amount of memory. Of course, sp_collector
is merely scanning the memory, while you're constructing objects
throughout the memory. Also, sp_collector fails to scan alot of
memory which it needs to -- cyclic_ptr never fails to "scan" the
required memory.
And it would best if the
uber-pointer used a less intrusive discovery method.
Ah yes - the old "uber-pointer" from way back (maybe yesterday...). I ended up tossing its intrusive discovery method, as it was inefficient.
However, that led me to my new-and-improved "juju_pointer". It achieves perfect discovery, but without any (significant) overhead.
I think sp_collector is on the right track, if it could be made precise.
"precise" could mean 2 things here. sp_collector has the obvious problem that it fails to examine all the memory which could contain "internal" pointers (that is, pointers which will be destroyed when a shared_ptr-owned object is destroyed). In particular, it won't examine the contents of any STL containers.
Another meaning of "precise" would be in the direction of "perfect discovery" -- i.e. knowing exactly where in each structure the pointers are, so that an sp_collector-style raw memory scan, or cyclic_ptr's
"*p = *p", isn't necessary. (Am I using the phrase "perfect discovery" correctly?)
Which did you mean?
Do you believe (my definition of) "perfect discovery" is a worthy design objective, if it can be done without significant overhead?
- Chuck Messenger
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
