Hi Gerrit,
Gerrit Voss wrote:
>
> Not quite, there are at least the beacons which should be weak too.
Good point. There's also TextureChunks-Images, and probably a few more.
One of my goals in this whole redesign is to get rid of special code for
parent/child relationships, I would like to see this handled inside the
Fields. Carsten and I are looking into that, and we;ll see what we come
up with.
> Why do you need to change the behaviour of weak ptr ?. AFAIK the
> common (boost) understanding a weak pointer is merely an indirection.
> And a weak pointer should never keep the underlying object alive. Is it
> really wise to have yet another OpenSG special interpretation ?
Actually I stole the implementation idea from boost::weak_ptr, so we're
as close as we can get to their interpretation.
> 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.
I'm not sure what much of an impact that would be, but I tried to avoid
it for now.
>> [3] Well, not quite impossible, but the ref pointers would need to have
>> an interface that allows to modify the pointer they store internally
>> without affecting the pointed to objects ref count. However, this
>> somewhat defeats the whole idea of ref pointers.
>
> I actually would not have a big problem with this. The whole syncing is
> quite low level and well hidden so it should be ok, and we know it
> works, well as long as I did not do some of these optimistic
> approximations like in the setFCPtrForAspect case.
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.
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
