Jump to content
  • Advertisement
Sign in to follow this  
ClementLuminy

Smart Pointer And object allocated on the stack or as member variables

This topic is 2921 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone !

I'm implementing a classical system where each "smart pointed" object derive from a base class called CManagedObject, which contain the reference counter.

Everything works fine, but this lead me to one major issue:
Every CManagedObject allocated on the stack or as a member variable cannot be referenced by smart pointer (Because when the ref count reach 0, the memory de allocation could not be done)

This implies limitations that cannot be clearly controlled when used in big code base.

So my question could be: How could i know if my object are dynamicly allocated OR not (in order to control if the object should be destroyed or not)?

I'm trying to figured this out since a lot of time without success, so any clues are welcome !

Note:
When those CManagedObject are dynamicly allocated, allocation goes through a placement new operator

Sample Code:

...
CManagedObject* m = (CManagedObject*) m_Pointer;
m->ReleasePointer();

//
// All the point is to find how to write the IsDynamiclyAllocated() function !!
//
if( m->GetRefCount() == 0 /*&& m->IsDynamiclyAllocated()*// )
{
CMemoryHeap* heap = m->GetMemoryHeap();
DebugAssert( heap );

m->~CManagedObject();

MemoryFree( *heap, m_Pointer );

}
...


Thanks a lot !

Share this post


Link to post
Share on other sites
Advertisement
Have you considered instead using a non-intrusive smart pointer like boost::shared_ptr? Or is this for learning purposes? The limitation of an intrusively reference counted object is that it always be allocated on the heap, because that's where you don't get the automatic RAII of the stack, and that's what the references help provide.

Share this post


Link to post
Share on other sites
You almost certainly don't really want to do that. By making reference counting part of the CManagedObject interface, you've guaranteed to the users of a given CManagedObject that it'll stick around for them as long as they're holding a smart pointer to it. But for stack allocated objects, that's not a guarantee that can be upheld.

Intrusive reference counting of the sort you're describing is a per-class all-or-nothing thing. If you have classes where you want speed and are willing to do manual lifetime management, don't inherit them from CManagedObject. Or, as Zipster said, separate the smart-pointed aspect of the interface from the rest of the interface, by using an extrusive smart pointer type.

Share this post


Link to post
Share on other sites
Quote:

Every CManagedObject allocated on the stack or as a member variable cannot be referenced by smart pointer


I'm not entirely sure I understand the problem, but:
If you create an object on the stack or as a member its lifetime is tied to the stack or the parent object. Why would you use a smart pointer there? It does not make sense to destroy the object before the parent is destroyed or to keep it alive longer than the parent. (Well, maybe sometimes. But IMHO a better design for this case would be to allocate an object separately with shared ownership and then pass a shared_ptr around.)

EDIT: Aargh, too slow again.

Share this post


Link to post
Share on other sites
Quote:
Original post by ClementLuminy

So my question could be: How could i know if my object are dynamicly allocated OR not (in order to control if the object should be destroyed or not)?

Cannot be done.

You could try mucking around with compiler and platform-specific behavior, but that would just end up large pile of unreliable hacks.

Simple counter-proof:
Foo * foo = getFoo(); // getFoo() is in DLL
It is impossible to know how, where or why some pointer is allocated.


This is precisely why smart pointers support custom deleters, so that user can override auto-deletion.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!