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:
[snip] > 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 :( Right. Unless the field classes wrapped the underlying store with a c-ptr interface. > While most of the functions in my initial mail can hide these types and > just take/return C ptrs this fails when the pointer fields are exposed. Ok. That makes it sensible to provide some kind of wrappers. However, I (as a user) find myself interacting with the mfields as stl-containers sometimes, and therefore I would prefer if they could be exposed as member variables of a container type, rather than a set of functions in the containing class. I also understand that the parent logic makes that hard to do. (Unless you'd create a temporary wrapper object with an internal parent pointer, which I suspect has it's own set of issues). >> 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. > > do you think it would work equally well if you had more than one smart > pointer type ? This is not a rhetoric question, I'd really like to hear > your opinion, as I imagine this to cause some problems/inconveniences. I can't forsee any such issues. Our pointer-container actually stores two types of ref-ptrs (refptrs and proxyrefptrs, the latter holds interfaces that do not inherit refobject, but the object implementing them does) and that works. The interface doesn't change (it uses mostly c-ptrs), only the underlying storage type. My users don't care what the store is, as long as they can search/iterate/mutate these containers in a coherent fashion. Since all smart pointer types are comparable with c-ptrs, they just have to decide whether to work with pointers or objects, each having their uses. The interface allows both (albeit in a somewhat limited fashion for the moment). >> 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? > > it might cut down on code size, so it is very worthwhile to keep in > mind, but it is essentially an orthogonal issue. Yes, but it does relate. I'd say it certainly is easier to implement if you have your own "pointer container" with a well defined interface, rather than exposing ten (or so) functions per field in the fieldcontainer. (I think I have some kind of allergy to that solution. But I can't find good logical reasons against it, except that the fieldcontainer class-interfaces become a bit bloated.) 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
