Re: [Opensg-core] [OpenSG 2] RFC: What to store in pointer fields?

[Carsten N. <car...@gm...>]

	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