Re: [osg-users] OSGQSG: Error
page 63, fig 2-9 The State example scene graph displayed in osgviewer TBD move TBD move? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSGQSG: Error
http://www.skew-matrix.com/OSGQSG/
p37, Memeory Management Examples.
Misspelled Memory in the errata.
-
p37, Memory Management Examples.
There are multiple solutions to the dilemma of how to return a Referenced object
address. The method employed in this book's example code is to return
a ref_ptr
storing the address, as the code below illustrates.
osg::ref_ptrosg::Group createGroup()
{
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address. This stores the Group
// address in a ref_ptr and places the ref_ptr on the
// call stack as the return value.
return grp.get();
}
Why is it
return grp.get();
rather than
return grp;
Isn't grp.get() a pointer to an osg::Group?
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGQSG: Error
Misspelled Memory in the errata. Fixed, thanks. Why is it return grp.get(); rather than return grp; Isn't grp.get() a pointer to an osg::Group? osg::ref_ptr has a constructor that takes an address. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGQSG: Error
So when I see things like the following in the OSG code base is it wrong?
ApplicationUsage* ApplicationUsage::instance()
{
static osg::ref_ptrApplicationUsage s_applicationUsage = new
ApplicationUsage;
return s_applicationUsage.get();
}
To me this looks like your first example.
// DON'T do this. It stores the address as the return value on
// the call stack, but when the grp ref_ptr goes out of
// scope, the reference count goes to zero and the memory is
// deleted. The calling function is left with a dangling
// pointer.
osg::Group* createGroup()
{
// Allocate a new Group node.
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address.
return grp.get();
}
Should it be as in the second example?
osg::ref_ptrosg::Group createGroup()
{
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address. This stores the Group
// address in a ref_ptr and places the ref_ptr on the
// call stack as the return value.
return grp.get();
}
In other words...
osg::ref_ptrosg::ApplicationUsage ApplicationUsage::instance()
{
static osg::ref_ptrApplicationUsage s_applicationUsage = new
ApplicationUsage;
return s_applicationUsage.get();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGQSG: Error
Hi Fred,
Returning a C pointer is more flexible, and as long as ref counting is
managed cleanly everything works fine, so the
ApplicationUsage::instance() code you suggest is perfectly fine, and
avoids thrashing the reference count something that is helps on the
performance front.
One little change I'm slowly rolling out in the various singletons
that the OSG users is that I'm moving across to using the convention:
osg::ref_ptrApplicationUsage ApplicationUsage::instance()
{
static osg::ref_ptrApplicationUsage s_applicationUsage = new
ApplicationUsage;
return s_applicationUsage.get();
}
The subtle thing here is that the code is passing back a reference to
the static ref_ptr rather than a ref_ptr like in your suggestion.
A subtle difference but really important in a couple of ways - first
up it avoid the thrashing of the ref count as no temporary ref_ptr
are passed around, second it allows uses to reassign the singleton's
static ref_ptr so you can manually delete the singleton or set an
custom objects in its place.
This trick is only appropriate for static ref_ptr object though, I
wouldn't advice this a general solution.
Robert.
On Wed, Dec 3, 2008 at 5:22 PM, Fred [EMAIL PROTECTED] wrote:
So when I see things like the following in the OSG code base is it wrong?
ApplicationUsage* ApplicationUsage::instance()
{
static osg::ref_ptrApplicationUsage s_applicationUsage = new
ApplicationUsage;
return s_applicationUsage.get();
}
To me this looks like your first example.
// DON'T do this. It stores the address as the return value on
// the call stack, but when the grp ref_ptr goes out of
// scope, the reference count goes to zero and the memory is
// deleted. The calling function is left with a dangling
// pointer.
osg::Group* createGroup()
{
// Allocate a new Group node.
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address.
return grp.get();
}
Should it be as in the second example?
osg::ref_ptrosg::Group createGroup()
{
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address. This stores the Group
// address in a ref_ptr and places the ref_ptr on the
// call stack as the return value.
return grp.get();
}
In other words...
osg::ref_ptrosg::ApplicationUsage ApplicationUsage::instance()
{
static osg::ref_ptrApplicationUsage s_applicationUsage = new
ApplicationUsage;
return s_applicationUsage.get();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGQSG: Error
So when I see things like the following in the OSG code base
is it wrong?
ApplicationUsage* ApplicationUsage::instance() {
static osg::ref_ptrApplicationUsage s_applicationUsage
= new ApplicationUsage;
return s_applicationUsage.get();
}
In the code above, s_applicationUsage is a static variable, not a local
variable allocated on the stack, so it does not go out of scope when
instance() returns. This is the classic singleton design pattern.
Contrast this with the code below, in which the grp variable is local,
allocated on the stack. It goes out of scope when createGroup() returns,
thus decrementing the ref count to zero, deallocating the memory, and
returning a dangling pointer.
To me this looks like your first example.
// DON'T do this. It stores the address as the return value
on // the call stack, but when the grp ref_ptr goes out of
// scope, the reference count goes to zero and the memory is
// deleted. The calling function is left with a dangling // pointer.
osg::Group* createGroup()
{
// Allocate a new Group node.
osg::ref_ptrosg::Group grp = new osg::Group;
// Return the new Group's address.
return grp.get();
}
Should it be as in the second example?
I hope that helps?
-Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGQSG: Error
Ah yes, static makes a world of difference. page 47 osg::ref_ptrosg::Geode geode0 = new osg::Geode; group-addChild( Geode0.get() ); osg::ref_ptrosg::Geode geode1 = new osg::Geode; group-addChild( Geode1.get() ); Upper case problem with Geode0 and Geode1. They should be geode0 and geode1. There were two cases of Memeory in the errata. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGQSG: Error
Thanks! All memeory instances should be fixed. One of these days I'll have to find a free tool that spell checks HTML because I'm too cheap to buy one. Thanks for catching the capitalization issue on p47, this is added to the errata and changes in the master book source for a possible future reprinting. -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Sent: Wednesday, December 03, 2008 2:17 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] OSGQSG: Error Ah yes, static makes a world of difference. page 47 osg::ref_ptrosg::Geode geode0 = new osg::Geode; group-addChild( Geode0.get() ); osg::ref_ptrosg::Geode geode1 = new osg::Geode; group-addChild( Geode1.get() ); Upper case problem with Geode0 and Geode1. They should be geode0 and geode1. There were two cases of Memeory in the errata. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
