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
