Carsten Neumann wrote: > Hi, > > the attempt to store smart pointers that handle the reference counting > internally without the need to have the generated code contain any > addRef/subRef calls have reached a point were we would like to ask for > comments on the interface.
[snip] > Dirk and I would very much like to hear your comments and ideas on the > above interface and the outlined alternatives. Also if you have > questions or suggestions on different approaches, please let us know. If I would do it, I'd suggest something that does not add a lot of functions. If you use a std::vector as store, keep it that way and let users work with that interface. This enables STL-alike algorithms to work much better with MFields. Thus avoiding each field to export functions to manipulate it, and users having to learn new APIs and/or rewrite existing functions). In short, keep it simple. And, for containers of pointers, we have a special class in our application that inherits std::vector<OurRefPtr<T>> and augmented it a bit with boost::indirect_iterator so that one can iterate either over objects directly (default), or over pointers (defined as ptr_iterator with ptr_begin(), ptr_end() and ptr_range()). It works well. The boost::pointer_container lib is another related solution (stores pointers, always accesses objects) but it's not directly applicable to ref-counted objects. However, a smart optimization in that lib is the use of std::vector<void*> for all stores, and a thin layer on top that casts to the specific pointer. This reduces the amount of almost equivalent template code instanced quite a bit. I suppose std::vector<InternalFCRefPtr> would be equivalent for OpenSG. What do you think? Cheers, /Marcus ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
