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
