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 :(
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.
> 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.
> 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.
Thanks,
Carsten
-------------------------------------------------------------------------
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
