Sign in to follow this  

shared_ptr

This topic is 4839 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

been trying out the Boost shared_ptr and I've run into an issue that doesn't make sense to me. When I run this code, it compiles, but when it gives me the runtime error of "Debug Assertion Failed! ... Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)" Code:
// Entity.h
#include <boost/shared_ptr.hpp>

using namespace boost;

class Entity
{
public:
	Entity();
	Entity(shared_ptr<Entity> par);

	shared_ptr<Entity> parent;

	char val;
};

// Entity.cpp
#include "Entity.h"

Entity::Entity()
{
	val = 'a';
}

Entity::Entity(shared_ptr<Entity> parent)
{
	this->val = 'b';
	this->parent = parent;
}

// main.cpp
#include "Entity.h"

void main()
{
	Entity p;
	shared_ptr<Entity> p_ptr( &p );
}

Presently, the only way I can get it to make a working shared_ptr is if I used something like:
shared_ptr<Entity> p( new Entity );

But, what if I want to make a shared_ptr to an object that already exists? Thanks for your help!

Share this post


Link to post
Share on other sites
I dont think you're supposed to use sahred_ptr with objects created on teh stack. sahred_ptr calls 'delete' (by deafault i think, but this behaviour can be changed) on an object at the end of its lifetime. And calling delete on an object on the stack give you troubles...

Share this post


Link to post
Share on other sites
when you allocate memory on the heap with new/new[] the instance persists through-out any scope but the catch is your responsible to give the memory back by explicitly calling delete/delete[].

But when you have lots of raw pointers refering to the same instance on the heap its diffcult to know when to delete. Also if store pointers to heap memory in STL containers then STL containers can't delete heap allocated memory for you, you have to iterate throught the container and explicitly call delete on each element.

This is the point of smart pointers in general and particularly shared_ptr it knows when & how to delete memory for you even in STL containers.

statically allocated memory gets automatically cleaned-up as soon as it goes out of scope so there isn't much point in using smart pointers with them. There are times thou that you wont a smart pointer to statically allocated memory and if that really is the case for you then you need to give shared_ptr a special "null deleter" type that doesn't try to call delete on statically allocated memory:


struct null_deleter {
void operator()(void const *) const {}
};

int main() {

Entity p;
shared_ptr<Entity> p_ptr(&p, null_deleter());

return 0;
}

Share this post


Link to post
Share on other sites

This topic is 4839 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this