Hi Gerrit,
Gerrit Voss wrote:
>
> yeah I know that opens another box of things ;-)
Let us know what you're thinking, and where you see problems. We see a bunch
already, but it's always good to know what you're getting into.
>>> Wouldn't it be easier to have the weak pointer use the aspect store as
>>> the binary blob and by storing the aspect it should be straight
>>> forward to implement the correct behaviour ?. I probably give it a short
>>> try for the current version as we need it anyway.
>> That would force the WeakPtr to go through the AspectStore and back to
>> the FC, which would remove one of the advantages of the C* redesign.
>
> But that is the price you pay for weak ptrs, you need to have some kind
> of indirection or check.
Yes and no, IMHO. See below.
> Hmm, what I don't like is that the class holding the weak pointer is not
> going to realise that the object behind it is nearly destroyed. So it
> keeps calling back to something which is in a kind of twilight zone.
> This is not so much a problem for one level parent ptrs but beacons and
> other cross references could behave interestingly. Similar you might
> continue to collect changes.
The WeakPtr semantics say that you cannot access the WeakPtr directly, you have
to turn it into a RefPtr before you cna use it. You can only onyl do that while
there are still other references, so a WeakPtr pointing to a dead object will
return NULL, and there is no way to resurrect a dying object through a WeakPtr
to it. No zombies allowed! ;)
>> I'm not too excited about it, as it another area of possible confusion
>> and abuse. if we can find a way to not go behind the back of the refPtr
>> I'd prefer that.
>
> Yes and no, adding a duplicated set of pointers (e.g. the internal
> variants) doesn't sound clear of confusion to me. As we will confuse
> somebody anyway the question than is more whom are we going to
> confuse.
We talked about that one too, and concluded that somebody who uses a class
named
'Internal' which has a blinking red warning not to use it cannot be helped. If
that's the price to pay for not having to deal with manual refcounts I'd be ok
with it.
We also thought about hiding them inside the Fields, but that would be
difficult
with the Fields being in Base and would probably complicate some other things.
We didn't think it through to the very end, but it might be an option.
Dirk
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
