Hi Gerrit,
Gerrit Voss wrote:
> On Wed, 2007-10-03 at 18:00 -0500, Carsten Neumann wrote:
>> typedef MFForegroundInternalRefPtr ForegroundFieldType;
>>
>> MFForegroundInternalRefPtr const *getMFForegrounds(void) const;
>> MFForegroundInternalRefPtr const &getForegrounds (void) const;
>> ForegroundPtrConst getForegrounds(UInt32 const index) const;
>>
>> void addForegrounds(ForegroundPtrConstArg value);
>> void assignForegrounds(MFForegroundInternalRefPtr const &value);
>> void insertForegrounds(
>> UInt32 const uiIndex, ForegroundPtrConstArg value);
>> void replaceForegrounds(
>> UInt32 const uiIndex, ForegroundPtrConstArg value);
>> void replaceForegrounds(
>> ForegroundPtrConstArg pOldElem,
>> ForegroundPtrConstArg pNewElem);
>> void subForegrounds(UInt32 const uiIndex);
>> void subForegrounds(ForegroundPtrConstArg value);
>> void clearForegrounds(void);
>
>> 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.
>
> hmm, could you do a quick preview branch, so that we can have a closer
> look at it. Judging this from the already existing interface with
> just the typedefs updated is not really possible. At least I would like
> to see the details behind the interface.
ok, but the point was more that if we want to keep read access to
pointer fields (via the first two functions above) they expose the type
stored in the field. For pointer fields this would be
{M|S}Field< InternalRefPtr<ContainerType> >, for "linked back" pointer
fields it would be
{M|S}Field< ParentWeakRefPtr<ContainerType> >.
While users are encouraged to use RefPtr<ContainerType> or
MTRefPtr<ContainerType> in their applications and for efficiency reasons
we would very much like to pass around raw C pointers.
So, in the end we'd launch quite a wave of different pointers at a user
making these things even harder to comprehend.
> Also knowing what sits behind
> ForegroundPtrConst and ForegroundPtrConstArg would help.
raw C pointers, these are the typedefs generated by the
OSG_GEN_CONTAINERPTR macros, so they are
typedef Foreground * const ForegroundPtrConst;
typedef Foreground * const ForegroundPtrConstArg;
> As for the special field with custom iterator option. As I said before I
> don't think it is needed and that common. If it would be something that
> a lot of other projects use we might have to think about it, but I
> actually can not remember any other project that lets you access
> internal pointer fields directly.
>
> Anyway for fields where the contents does not link back to the parent
> I don't see that you need special iterators. So at least for these
> fields you could allow an edit function.
At this point I was not considering to return non-const pointers or
references to pointer fields, i.e. no
MFForegroundInternalRefPtr * editMFForegrounds(void);
MFForegroundInternalRefPtr & editForegrounds(void);
> But again without seeing the
> actual code this is a little bit guess work ;-)
ok, I'll try to get something that compiles over the day.
Cheers,
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
