Hi, On Sat, 2007-09-15 at 23:32 -0500, Dirk Reiners wrote: > 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.
yeah I know that opens another box of things ;-) > > 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. But that is the price you pay for weak ptrs, you need to have some kind of indirection or check. > I'm not sure what much of an impact that would be, but I tried to avoid > it for now. 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. > >> [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. 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. kind regards, gerrit ------------------------------------------------------------------------- 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
