Boost logo

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"

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, gregod at, cpdaniel at, john at