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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-core > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
