Carsten Neumann wrote: > Hi Marcus, > > Marcus Lindblom wrote: >> Carsten Neumann wrote: >>> 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. > > the keep it simple is somewhat contradicted by the fact that one kind of > ref pointer just does not do it for OpenSG. There are basically three > ref counts associated with a field container and we are likely to have > about five types of pointers: > > InteralRefPtr<> - manipulates an aspect local ref count, used almost > everywhere inside OpenSG > WeakRefPtr<> - manipulates an aspect local weak ref count, similar to > how boost::weak_ptr and boost:shared_ptr work. Used e.g. for beacon > ptr's to break circular references. > ParentWeakRefPtr<> - a weak pointer that carries additional information > about which field of the parent points to this child. > > RefPtr<> - the single aspect application ref ptr, manipulates ref count > shared by all aspects (called external ref count). Intended to be used > by applications. > MTRefPtr<> - in addition to what RefPtr does this one also can be used > in different aspects/threads and points to the correct copy of the > container for the current aspect. > > In addition to all the other things you have to learn when starting with > OpenSG this seems a bit too much. Especially since the first three are > for internal use only and users should not have to care/know about them. > The problem is that even if we allow only read access to the pointer > fields these types show up in the interface :(
As a user and sometimes developers, I have to say that this looks a bit scary. I know this is needed because OpenSG is so powerful, but we have to make sure the complexity introduced doesn't scare away users. This is probably a redundant question, but is there anything that can be done to further simplify or unify the pointer types. In my book one of the most important goals for OpenSG 2.0 should be to keep things simple and make it easy to use for developers. One idea.... - Merge ParentWeakRefPtr and WeakRefPtr into one. If there is a parent, then the internal parent field id is set, if not then don't run that code. - RefPtr/MTRefPtr. Still separate, but look at them as two sides of the same coin where the user/library just converts back and forth as needed. To me these are really the same pointer type but with slightly different semantics internally to specialize them. This then breaks down to 3 ptr types: InternalRef, InternalWeakRef, and RefPtr (specialized for MT case). This at least seems conceptually simpler, but I don't know how much this would mean in the real-world. -Allen ------------------------------------------------------------------------- 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
