shared_ptr

Started by
2 comments, last by joanusdmentia 19 years, 7 months ago
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!
"Game Programming" in an of itself does not exist. We learn to program and then use that knowledge to make games.
Advertisement
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...
[size=2]aliak.net
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;}
Yep, a null_deleter is what you want (assuming that for some reason you really do need a shared_ptr to a statically allocated object).
"Voilà! In view, a humble vaudevillian veteran, cast vicariously as both victim and villain by the vicissitudes of Fate. This visage, no mere veneer of vanity, is a vestige of the vox populi, now vacant, vanished. However, this valorous visitation of a bygone vexation stands vivified, and has vowed to vanquish these venal and virulent vermin vanguarding vice and vouchsafing the violently vicious and voracious violation of volition. The only verdict is vengeance; a vendetta held as a votive, not in vain, for the value and veracity of such shall one day vindicate the vigilant and the virtuous. Verily, this vichyssoise of verbiage veers most verbose, so let me simply add that it's my very good honor to meet you and you may call me V.".....V

This topic is closed to new replies.

Advertisement