Hi,
On Sun, 2007-10-28 at 03:42 -0500, Dirk Reiners wrote:
> Hi Gerrit,
>
> Gerrit Voss wrote:
> > Not quite, the goal was to simplify things, not per se getting rid of
> > something. So IMHO if 'getting rid' of something does not work towards
> > the goal something should be changed.
>
> True, but the idea was that moving the refcounting into the pointer
> types would help make move it into one place and one place only, making
> it simpler and less error-prone.
Hmm, we are running circles anyway and I guess we have slightly
different views on 'simpler' ;-). But after having taken quite some
beating on the 'simpler' code side maybe I'm a little bit biased on that
one ;-)
> > where did the auto ptr go ?
>
> We benchmarked it and there was not enough performance difference to
> make it worth keeping.
ok, just for my understanding, you did use 'by reference only'
passing ?
> > Hmm, but in order to do this you record, transmit and apply ref count
> > operations to the remote aspect (or has this changed, the code looks
> > still the same ?). As you do it only for a limited set of objects/calls
> > I still would call it an optimisation ;-). Because it should work if you
> > do it for all objects/calls.
>
> Well, the optimization is just a side effect but not the goal.
>
> > Good so I'm not alone ;-). Maybe we should take a step back and see if
> > we can find a nicer user space solution ;-) Maybe we should really start
> > from the user interface and work our way towards the core ;-)
>
> That sounds painful.
Maybe, but again for me this 'simpler' thing is to a great extend
something that has to be reflected in the user interface. Because
a lot of the general complains are related to the user interface
of OpenSG.
> > But than why not put the ref counting into fields instead of pointer
> > classes. This way we get this part out of the normal class code (which
> > AFAIK is the goal). And if you want to put the parent handling into the
> > fields to you blow them up anyway.
>
> Hmm, worth a thought. Should have thought about it earlier. :(
Well it is never to late, I wrote the internal stuff a couple of times,
so all except the last one were thrown away. And if it's benefits the
result I'm all for throwing whatever we need away, even if it took a
long time to write. Well, I'm doing it all the time, so I'm kind of
used to it ;-). And we are not working on something officially
released, so we have to time change it to get a better result ;-)
> > If you want to force the user to use ref ptrs you can still do so by
> > returning a kind of auto ptrs from everything , the class interface and
> > the fields. This currently is the solution I tend to find the best
> > compromise.
> >
> > And it gives you more options to optimise internally without sacrificing
> > a clean user interface.
>
> Optimization is not that much of an issue, simplicity and stability are
> more important IMHO.
Hmm, as in the beginning we kind of agree, only that I would make more
use of the general OpenSG design we already have in place. And only
if we run out of options there I would start thinking about adding new
stuff.
For example having the auto-generated storage base class gives you a
clean cut to define what can be manipulated directly and what not.
Currently we do not make much use of it because nearly everything
is protected or public and within the derived classes we never took
to much care. Well, more on the read access side because in order
to make 2.x work the write access had to be correct.
Fields are to a certain extend the same on a lower level, they give you
another way of controlling what should happen in case of changes.
So you have the following kind of data access hierarchy involved:
field content
|
field
|
base class
|
final class
for 2.x we moved one level up from final class to base class without
fully exploiting the base class.
IMHO, before I would jump to the top of the hierarchy (field content) I
would make use of what else is available, e.g. fully exploiting the base
class and the fields.
There is even use for RefPtrs inside OpenSG, like the StatePtr which
is not stored inside a field or stuff inside utilities like
SimpleSceneManager.
kind regards,
gerrit
-------------------------------------------------------------------------
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
