Robert,
May I ask what the issue was in src.osgUtil/Simplifier.cpp? I'd be
interested to find out as there may be a nice clean fix that avoids
conditional compilation. I wonder if it might be worth considering a traits
or policy based solution for parameterising conversions?
Neil
On Fri, Oct 3, 2008 at 1:52 PM, Robert Osfield <[EMAIL PROTECTED]>wrote:
> Hi Neil,
>
> I've just applied you changes and am doing a compile and fix. So far
> I've only had a compile problem in src/osgUtil/Simplifier.cpp due to
> the changes. What I will probably do is make the ref_ptr<> change an
> option compile, so we can easily revert to the old methods in case of
> issues. I am also a bit nervous about the implicit type conversion
> introducing bugs. Do you know of any web pages (i.e. boost) talking
> about issues with smart pointers and use of an output conversion
> operator? It might be useful to strike up a debate about the pro's
> and con's of going this route.
>
> The change to Referecend to help support boost::intrusive_ptr<> look
> fine and I'll go ahead an integrate these changes once I have complete
> build.
>
> Robert.
>
> On Fri, Oct 3, 2008 at 1:07 PM, Neil Groves <[EMAIL PROTECTED]>
> wrote:
> > Hi Robert,
> >
> > I believe that this submission shows the way to make the ref_ptr more
> > interoperable with the raw pointer. I think after some consideration and
> > re-evaluation that this is probably the optimal solution for OSG. It was
> a
> > good thing for you to question the conventional wisdom of requiring a
> get()
> > for conversion of an intrusive pointer.
> >
> > Clearly this modification required implementation of the output
> conversion
> > operator to T*, and then required the removal of many comparison
> operators
> > to avoid ambiguous overloads.
> >
> > I trust that this will help.
> >
> > I have learnt from my passed submission that it is a good idea to include
> > the test program. It's a bit of a shamefully simple test program, but
> covers
> > most of the code paths. I have to confess that I have only tested this on
> > MSVC 8 since this is all I have access to at work.
> >
> > Regards,
> > Neil Groves
> >
> > On Fri, Oct 3, 2008 at 11:07 AM, Robert Osfield <
> [EMAIL PROTECTED]>
> > wrote:
> >>
> >> Hi Neil,
> >>
> >> On Fri, Oct 3, 2008 at 10:40 AM, Neil Groves <[EMAIL PROTECTED]>
> >> wrote:
> >> >> Feel free to implement the safe type conversion to bool as it would
> be
> >> >> useful addition as long as it compiles.
> >> >
> >> > I'll do this within the next week.
> >>
> >> Thanks.
> >>
> >> >> Another possible addition would be automatic conversion to a C
> >> >> pointer, but this is something that submissions have also
> experimented
> >> >> with in the past and failed to get working safely across platforms.
> >> >> But as with all the ref_ptr<> changes it was a while back and we've
> >> >> dropped one of most problem compilers of the bunch since then. There
> >> >> is also the big question about implicit conversion of types...
> >> >
> >> > This isn't an idea that has worked well historically despite the clear
> >> > attraction to behave like a raw pointer. It often leads to bugs in
> >> > client
> >> > code. This was the rationale for all of the boost smart pointers and
> the
> >> > std::tr1::shared_ptr having a get() function instead.
> >>
> >> I am familiar with both the attraction and downsides to having this
> >> implicit type conversion to C*, ref_ptr<> having the get() for the
> >> same reason as boost. I wonder if there is a safe half way point.
> >>
> >> In particular I'm think of methods like:
> >>
> >> Group::addChild(Node*)
> >>
> >> Right now we have to use a
> >>
> >> group->addChild(myptr.get());
> >>
> >> Which is a bit awkward. No we have the template<> constructor in
> >> ref_ptr<> one could get away with converting the addChild method to
> >> be:
> >>
> >> Group::addChild(ref_ptr<Node> node)
> >>
> >> But this would involve a ref/unref() pair occuring just because of the
> >> existence of a temporary ref_ptr<>. The other possibility might be to
> >> have a adapter class that takes C pointers or ref_ptr<> as a
> >> parameters i.e.
> >>
> >> struct NodePtr
> >> {
> >> NodePtr(Node* ptr):_ptr(ptr) {}
> >> NodePtr(ref_ptr<> Node* ptr):_ptr(ptr.get()) {}
> >> Node* _ptr
> >> }
> >>
> >> Group::addChild(NodePtr node);
> >>
> >> But this is pretty hacky...
> >>
> >> Perhaps just have two methods, but this leads to code bloat and
> >> potential for errors to come in...
> >>
> >> Is there any neat tricks you can suggest?
> >>
> >> Robert.
> >> _______________________________________________
> >> 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
> >
> >
> _______________________________________________
> 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
