Hi Gordon,
but, in fact, it does. I printed out the reference count of the object
and it is increased by one when I pushed it back to the list. When I
delete the object, the counter is decreased by one.
Funny things these ref pointer things.
Oliver
Gordon Tomlinson schrieb:
Hi
I would not expect myList.push_back(object); to increase the ref count of
object
unless you provide your own overloaded list and method ::push_back
osg::Group::addChild( osg::Node* ) knows that an osg::Node is a reference
count class so it can do a node->ref();
But a std::list knows nothing about an osg::Node or osg::ref_ptr
Best Regards
Gordon
__________________________________________________________
Gordon Tomlinson
Email : gordon.tomlinson @ overwatch.com
YIM/AIM : Gordon3dBrit
MSN IM : <mailto:[EMAIL PROTECTED]> Gordon3dBrit @
3dscenegraph.com
__________________________________________________________
Telephone (Cell): (+1) 214-477-8914
Telephone (Work): (+1) 703-437-7651
"Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival"
- Master Tambo Tetsura
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Oliver Kutter
Sent: Friday, October 06, 2006 10:14 AM
To: osg users
Subject: Re: [osg-users] These ref pointer things
Hi Robert,
first of all, thank you for the link.
Then, I'm asking about the ref_ptr, because I have some code like the
following. I'm storing my objects in a std::list. And now I wonder if I
delete object from that list, are they really deleted?
std::list< osg::ref_ptr<Object> > myList;
Object* createObject()
{
osg::ref_ptr<Object> object = new Object();
// ------ Is the refcount increased or not?
myList.push_back(object);
// ------ I know, I shouldn't do this, but if the refcount is increased,
// ------ everything should be fine.
return object.get();
}
void deleteObject(Object* object) {
std::list< osg::ref_ptr<Object> >::iterator it;
for (it = myList.begin(); it != myList.end(); it++) {
if (it->get() == object) {
// ------ Is the refcount decreased or not?
// ------ And is the object really deleted at the end of the scope?
myList.erase(it);
}
}
}
int main ()
{
Object* myObject = createObject();
...
deleteObject(myObject);
}
regards,
Oliver
Robert Osfield schrieb:
Hi Oliver,
Please read Don's article of ref_ptr<>:
http://dburns.dhs.org/OSG/Articles/RefPointers/RefPointers.html
On 10/6/06, *Oliver Kutter* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
1:
osg::ref_ptr<MyClass> object1 = new MyClass();
object1.release();
release() releases the object and returns the pointer to it without
decrementing the reference count. I'd recommend you own up an editor
and walk through the code.
The only time you should ever use release is when have code something
like:
Node* createNode()
{
ref_ptr<Node> node = new Node;
return node.release();
}
As this prevents the ref_ptr<> from deleting the node object when the
ref pointer goes out of scope.
You'll see this usage pattern very occasionally in the OSG. Its not
normal usage.
In you code block you basically have a memory leak.
2:
MyClass* object2 = new MyClass();
delete object2;
This in dangerous as you should consider what might happen if you
addinged object2 into the scene graph - it'd take a reference to it, but
then you've got an forceable deleted it.
Reference counting is design to prevent this problem, its a very common
tehcnique now in computing so you should be able to find plenty of
refences on the web about it.
Another trick is my you create your MyClass you shoudl make the
destructor private/protected, this will prevent you from doing a delete
object2 at compile time. Have a look at all the core OSG class that are
derived from osg::Referenced, you'll find they all have protected
destructors to prevent you from doing dangerous things like manually
deleting them.
I strongly recommend you invest some time learning about the OSG's ref
pointers from the available docs, and also look to the web, and then
write your own examples and play. TIme invested now will help the rest
of your computing career.
Robert.
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
