I thought of that, but I'm sure Robert has said templates are a no goer for osg.
I've come up with several solutions but they all suck in various ways.
Time for the Friday afternoon solution. Ignore the problem till Monday.

2008/11/21 Neil Groves <[EMAIL PROTECTED]>:
> Simon,
>
> How about a NodeVisitor that allows optimal customisation via compile-time
> polymorphism? It would need a bit of thought as to how to refactor the code,
> but first I would like to gauge interest. I would be happy to assist if
> there is benefit to anyone.
>
> We should be able to achieve better customisation with even better
> performance than the current implementation. I also have some
> implementations for hooking together general functors to simple
> free-functions which often eliminates the need to write NodeVisitor derived
> classes, if anyone is interested. Of course the run-time polymorphism offers
> greater flexibility and open-ness and should remain, but it can probably be
> augmented without compromise.
>
> Neil Groves
>
> On Fri, Nov 21, 2008 at 1:21 PM, Simon Hammett <[EMAIL PROTECTED]>
> wrote:
>>
>> Oh. That's awkward. There's no other good way of setting the state in
>> a node visitor in that case.
>>
>> 2008/11/21 Robert Osfield <[EMAIL PROTECTED]>:
>> > Hi Simon,
>> >
>> > I'm not happy with making another very commonly called inline method
>> > virtual as it will the performance implications are not trivial.  The
>> > methods are deliberately made inline to keep the performance overhead
>> > to a minimum.  For this reason I won't be merging this change.
>> >
>> > Robert.
>> >
>> > On Fri, Nov 21, 2008 at 12:10 PM, Simon Hammett
>> > <[EMAIL PROTECTED]> wrote:
>> >> Hi Robert,
>> >>
>> >> Please find attached a modified version of osg/NodeVisitor from trunk.
>> >> The specific changes are to make virtual both:
>> >>        void pushOntoNodePath(Node* node)
>> >>        void popFromNodePath()
>> >>
>> >> The use case for this is to allow derived node visitors to be informed
>> >> when
>> >> the level in the graph changes so they can push & pop their own
>> >> internal state.
>> >>
>> >> Otherwise there is no good way of knowing that this has happened.
>> >> I could possibly do something where I try and store a previous parent
>> >> node pointer
>> >> and check that within the accept methods but that's butt ugly.
>> >>
>> >> --
>> >> The truth is out there. Usually in header files.
>> >>
>> >> _______________________________________________
>> >> osg-submissions mailing list
>> >> [email protected]
>> >>
>> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>> >>
>> >>
>> > _______________________________________________
>> > osg-submissions mailing list
>> > [email protected]
>> >
>> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>> >
>>
>>
>>
>> --
>> The truth is out there. Usually in header files.
>> _______________________________________________
>> osg-submissions mailing list
>> [email protected]
>>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
>
> _______________________________________________
> osg-submissions mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
>
>



-- 
The truth is out there. Usually in header files.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to