[osg-users] Using c++11 smartpointer instead of osg::ref_ptr?

[Maik Klein]

I am wondering if it is possible to use the c++11 smartpointer instead of osg::ref_ptr? Is there any advantage in using the osg::ref_ptr?

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=53854#53854





_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Ulrich Hertlein]

On 29/04/2013 2:53, Maik Klein wrote:
> I am wondering if it is possible to use the c++11 smartpointer instead of
> osg::ref_ptr?
> Is there any advantage in using the osg::ref_ptr?

Mixing the two is a bad idea, as they will happily ignore one another ;-)

One benefit of osg::ref_ptr is that the reference count is part of the object, so even if
you return a raw pointer at some point you could stuff it back into a ref_ptr without
things getting stuffed up.

/ulrich

[Alexandre Vaillancourt]

As Ulrich said, it's a bad idea.

osg::ref_ptr works from _withing_ the object (roughly) while std::shared_ptr works from the outside.

You'll have to use the osg::ref_ptr for everything that is osg:: and std::shared_ptr for everything else.

There is also the osg::observer_ptr for 'weak' references.

--
Alexandre Vaillancourt

2013/7/31 Ulrich Hertlein <u.her...@sandbox.de>

[Judson Weissert]

On a related note, in boost, there is the concept of intrusive pointer
(which I believe has similar semantics to ref_ptr).

http://www.boost.org/doc/libs/1_54_0/libs/smart_ptr/intrusive_ptr.html

It just rang some bells in my memory, so I figured I would post.

Regards,

Judson

On 7/31/2013 4:51 PM, Alexandre Vaillancourt wrote:
> As Ulrich said, it's a bad idea.
>
> osg::ref_ptr works from _withing_ the object (roughly) while
> std::shared_ptr works from the outside.
>
> You'll have to use the osg::ref_ptr for everything that is osg:: and
> std::shared_ptr for everything else.
>
> There is also the osg::observer_ptr for 'weak' references.
>
> --
> Alexandre Vaillancourt
>

[Judson Weissert]

Ah... I should have done a little more research. Seems like
intrusive_ptr is already well considered and used within OSG.

Judson

On 7/31/2013 5:55 PM, Judson Weissert wrote:
> On a related note, in boost, there is the concept of intrusive pointer
> (which I believe has similar semantics to ref_ptr).
>
> http://www.boost.org/doc/libs/1_54_0/libs/smart_ptr/intrusive_ptr.html
>
> It just rang some bells in my memory, so I figured I would post.
>
> Regards,
>
> Judson

[Robert Osfield]

Hi Maik? Klein? how do you like to be addressed?

On 29 April 2013 00:53, Maik Klein <maik...@googlemail.com> wrote:
> I am wondering if it is possible to use the c++11 smartpointer instead of osg::ref_ptr? Is there any advantage in using the osg::ref_ptr?

As others have said osg::ref_ptr<> is an intrusive smart pointer like
boost::intrusive_ptr<>, and osg::observer_ptr<> is kinda equivalent to
weak_ptr<>.

The OSG doesn't have or use an equivalent to std::shared_ptr<>, and if
I were to write a new scene graph tomorrow I would not use a
std::shared_ptr<> for general nodes in the scene graph. shared_ptr<>
isn't as robust as ref_ptr<> in general usage as you are forced to use
a single shread_ptr<> group to reference a single object, you can't
just assign a C pointer to a node and create your own shared_ptr<> to
it as it breaks the design and you'll end up with dangling pointers.
This design problem with shared_ptr<> forces you to copy
shared_ptr<>'s all the time when access data members which just can't
be efficient and requires end users to always stick to this rule.

It's a shame that intrusive_ptr<> isn't part of the standard.

Robert.

[Shue, John A]

Robert,

While speaking of the new C++11 standard, do you have any plans or have you thought about how to start introducing new parts of the language? Doing so would obviously break the build for those with non-compliant compilers, and the ugliness of #ifdef'ing old and new syntax is very unappealing.

Does this mean OSG will remain C++03 for the foreseeable future (not a bad thing)? Are there any triggers that you have identified that could indicate when it is beneficial to move to C++11 (i.e. less use of older compilers in the community)?

For smaller projects, or newer projects, the decision about using or not using C++11 is sometimes easier to make, but I'm curious about your thoughts for OSG's present and future.

Thanks,

John Shue

This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.

[Robert Osfield]

Hi John,

On 1 August 2013 14:14, Shue, John A <John...@mantech.com> wrote:
> While speaking of the new C++11 standard, do you have any plans or have you thought about how to start introducing new parts of the language? Doing so would obviously break the build for those with non-compliant compilers, and the ugliness of #ifdef'ing old and new syntax is very unappealing.
>
> Does this mean OSG will remain C++03 for the foreseeable future (not a bad thing)? Are there any triggers that you have identified that could indicate when it is beneficial to move to C++11 (i.e. less use of older compilers in the community)?
>
> For smaller projects, or newer projects, the decision about using or not using C++11 is sometimes easier to make, but I'm curious about your thoughts for OSG's present and future.

I believe it sensible to keep the OSG working on older compiler for now.

I have been pondering about where scene graphs should be going in the
future and believe C++11 is a natural choice. I planned to discuss
this at the Siggraph BOF but alas didn't get an opportunity as the
time was too short.

[Paul Martz]

You can pass references to shared_ptr objects. You only need to copy them for long-term storage, which is typically not a performance critical operation in a scene graph.

--
Paul Martz
Skew Matrix Software LLC

[Robert Osfield]

On 1 August 2013 15:09, Paul Martz <skewm...@gmail.com> wrote:
> You can pass references to shared_ptr objects. You only need to copy them
> for long-term storage, which is typically not a performance critical
> operation in a scene graph.

I hadn't thought of pass them by reference, yep this would help.

I still curious about the interorability side - how do you wrap the
class for integration with other languages as most of these go through
C bindings. Not that smart pointers are the only stumbling block...

[Mathias Fröhlich]

Hi,

On Thursday, August 01, 2013 06:21:10 Robert Osfield wrote:
> The OSG doesn't have or use an equivalent to std::shared_ptr<>, and if
> I were to write a new scene graph tomorrow I would not use a
> std::shared_ptr<> for general nodes in the scene graph. shared_ptr<>
> isn't as robust as ref_ptr<> in general usage as you are forced to use
> a single shread_ptr<> group to reference a single object, you can't
> just assign a C pointer to a node and create your own shared_ptr<> to
> it as it breaks the design and you'll end up with dangling pointers.
> This design problem with shared_ptr<> forces you to copy
> shared_ptr<>'s all the time when access data members which just can't
> be efficient and requires end users to always stick to this rule.

Ack!
Also you need twice as much mallocs because the reference counts need to be
allocated seperately.

> It's a shame that intrusive_ptr<> isn't part of the standard.

That's does not help too much. I have for a different project a weak pointer
that is thread safe with the clear and easy semantics of std::weak_ptr with an
embedded reference count and sadly I never found a way to implement the same
semantics using intrusive_ptr.
And to be honest, this small helpers are so small and easy to do that I don't
mind havind this in a project.

The more problematic part is the atomic count itself that used to be highly
architecture dependent. But now the current standard contains std::atomic.
If I should start today with anything new, I would use std::atomic and build
on top of that.

Greetings

Mathias

[Robert Osfield]

On 1 August 2013 15:09, Paul Martz <skewm...@gmail.com> wrote:

> You can pass references to shared_ptr objects. You only need to copy them
> for long-term storage, which is typically not a performance critical
> operation in a scene graph.

It occurred to me that a reference to a shared_ptr<> is actually a
pointer to a pointer, and depending upon the implementation details of
shared_ptr<> it could well be a pointer to pointer to pointer just to
get access to the object and it's methods.

So efficiency wise I don't think a returning a shared_ptr<>& is going
to be as efficient as just passing back a C* like the OSG does at
present, if fact I think there is probably quite a big difference in
performance. And as Mathias mentions that's without considering the
extra memory allocations that associated with shared_ptr<> over a
intrusive ref_ptr<> design.

My conclusion would be the shared_ptr<> is clever, but it's ability to
be a general purpose smart pointer impacts the performance of it usage
over intrusive ref_ptr<>. For a scene graphs with a consistent class
hierachy and with this ability to provide intrusive ref/unref() makes
intrusive smart pointers a better performing and lighter weight
solution. Like Mathias also suggested, using of std::atomic looks to
be very useful and will simplify codes. Same applies to other
std::thread related functionality.

[Ulrich Hertlein]

On 2/08/2013 17:46, Mathias Fröhlich wrote:
>> This design problem with shared_ptr<> forces you to copy
>> shared_ptr<>'s all the time when access data members which just can't
>> be efficient and requires end users to always stick to this rule.
> Ack!
> Also you need twice as much mallocs because the reference counts need to be
> allocated seperately.

std::make_shared allocates object and ref-counter in one allocation :-)

C++11 also has std::enable_shared_from_this which solves some issues, but still hasn't the
same semantics as osg::ref_ptr.

Cheers,
/ulrich

[Mathias Fröhlich]

Hi,

On Friday, August 02, 2013 19:39:33 Ulrich Hertlein wrote:
> std::make_shared allocates object and ref-counter in one allocation :-)

Hmm, this requires either a lefthand reference constructor to be called
additionally to the original one that you just need. If you have everything
inline that's relatively fine, especially if you have more or less simple
classes, the compiler can relatively well optimize this away. If you either
have implemented these in the implementation file you already rely on link time
optimiziation to find this. Very often not switched on, and if so usually not
that agressive to really find these opportunities. Or of you do not have the
lefthand reference constructor implemented, you end up doing a copy
constructor which is actually way worse than what we are talking about.

> C++11 also has std::enable_shared_from_this which solves some issues, but
> still hasn't the same semantics as osg::ref_ptr.

Also this one, just says that you can get a shared pointer from a plain one.
As far as I can see this says nothing about the storage layout or the amount
of allocations it uses. And actually there are implementations implementing
this just by storing a weak_ptr to this in the base class and on calling
shared_from_this you get the shared pointer from the weak pointer inside.

Greetings

Mathias