Re: [Opensg-core] FC rewrite?

[Allen B. <al...@vr...>]

What is the current status of the FC rewrite?  Is there anything that 
people could start looking at and commenting on?

-Allen


Dirk Reiners wrote:
> 	Hi Gerrit (and anybody else who wants to comment),
>
> it fits well that you're out of town next week, that means you're not working on 
> OpenSG much. :) Can you make sure that you have all your changes committed, 
> especially in the FC?
>
> As it happens, my wife is out of town next week, too. Which gives me a good 
> chance to get some work done on OpenSG, and I would like to get the dreaded 
> FC/CPtr thing done. At the same time, I would really like to simplify the FC 
> code significantly, as, frankly, the current version is just scary.
>
> So the goals are:
> - simplify the code. Remove the mixins and use simple derivation as far as 
> possible. And don't worry about a little bit of code duplication, if it keeps 
> things more understandable. Code is not just for compilers, it's for people, too. ;)
> - switch to cptrs only. I don't think the code will change much from the current 
> CPTR mode: have an AspectStore refed from the class and use that to keep the 
> RefCount
> - add weak ptrs and make ref counting more efficient. To do that I want to use 
> the boost::sp_counted_base, which supports weak pointers and also has 
> specializations for lock-free thread safe counting. It's not quite the way I 
> would like it to be as you pretty much have to use a pointer to it instead of 
> deriving the aspect store from it, but maybe I can figure that one out, too.
> - remove the PointerBuilders, as they are not necessary any more if we don't 
> have different modes. This one will go a long way to make the code look more normal.
> - change the fields to use RefPtrs, remove explicit ref handling in the code. 
> This does not mean using RefPtrs everywhere, just for storage. This should also 
> go some way towards making the reflexive interface more complete
> - add AutoPtrs to avoid ref/unref for just passing out values. This should avoid 
> overhead when accessing field data.
> - Use fcd2code as much as possible, to avoid having to manually mess with Fields.
>
> Structure-wise I think I'll derive RC and FC from a base that has common stuff 
> (not totally sure what it's going to be, but probably not too much). The reason 
> they're not derived from each other is that RC and FC probably need to handle 
> RefCounting differently.
>
> Questions that I have:
>
> - Should we get rid of the ...Ptr types? They're not strictly necessary any 
> more, but without them Allen's memory debugging won't be possible, which i think 
> is very helpful. In non-memdebug mode they would be direct CPtrs.
> - are the aspect-specific refcounts life? Are they needed, did they fix something?
> - what did I miss why this is a bad idea?
> - what did I miss to make this an even better idea?
> - any general comments?
>
> Thanks
>
> 	Dirk
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Opensg-core mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-core
>
>