Hi all, There's stuff happening on the wiki. I like that. I prefer to give my comments here though, as it's easier to keep track on the discussions.
== FileIO == On handling realtive paths. We need to decide between implicit or explicit management. I proposed implicit first (storing curren path for each protocol & thread) but have lately moved to explicit (loaders are responsible for mapping that) as I think the first is too error prone and not really worth the effort (it is sexy, I'll admit to that, but how much maintenance will it require? ;). I've also put in some sample code there, to try to clarify some concepts. Comments? == ExamplesDemosTutorial == We seem to have agreed on moving Examples out of the Source-tree? I like that. I also agree with Dirk on having demos _outside_ of the dailybuilds, but maybe in a 'Point Release', I.e. something like the large ATI/Nvidia SDKs. (OpenSG-2.X-SDK.. yeah.. sort of like java & .NET & everything else.. :) Reasons: Demos should be big and bulky with fancy content. Minor nitpick: I don't thing tutorials need to be numbered. A doxy-page listing them in some categories as (beginnner/intermediate/advanced) would probably suffice. There doesn't seem to be much more to discuss here? or? == Pointer == Could someone (Gerrit? you seem to be 'in control' ;) clean up the wiki site summarizing current 'consensus' and points of discussion? That type of discussion would probably work out better on the mail-list as we can follow threads and comment more easily on things.' My (IMHO) comments on the current pointer discussions: - I suggest using boost::intrusive_ptr as much as possible, for our internal ref counting, if it is applicable. It eases interoperation with other boost stuff, unless someone is willing to work to make it compatible. :) - I'm fine with passing out c-ptrs & create() not calling addref. (That's how it should be). However, create() ought to return a RefPtr for safety. I strongly feel that public API calls should not leak more than necessary, and create() is such a common things so. - I like the idea of a 'mapping pointer' similar to fcptr today, to use for safety. To have that as a refptr as well would probably also be good. Provides a 'totally safe ptr' for combined safety and comfort. (intializable from c-ptr so I can do Node* n = foo::create(); NodeMegaPtr p(n);). - For MPtrFields iterators there's boost::indirect_iterator which might help out? - I would really like to avoid calls to addref/subref in any OpenSG code, if at all possible (that's not really up to me though). Our framework here manages with boost::intrusive_ptr, our own Refobject class and weakptr or c-ptr's for cycles/"back-pointers". == Documentation == Is it possible to run some kind of diagnostic (ala boost does for licenses etc) to see if classes/methods are documented or not? That way it would be easy to monitor the doc process? /Marcus ------------------------------------------------------------------------- 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
