|
Boost : |
From: Chuck Messenger (chuckm_at_[hidden])
Date: 2003-05-30 14:43:27
Gregory Colvin wrote:
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk