I'm using box2d and as you already may know, it holds a void* to an object which i can use as reference when collisions occur between different entities. Problem is that the original item is saved inside a shared_ptr since the ownership is unknown and different classes (example player class) can 'equip' another class (weapon).
I'm just wondering if its possible to put this pointer inside a shared_ptr and refer to the same object as the original one?
This is an example:
std::vector<std::shared_ptr<Environment>> listEnvironment;
listEnvironment.push_back(std::make_shared(new Weapon()));
//takes a void pointer
box2d->userId = listEnvironment.back().get();
//some shit happens somewhere else and collision occurs and I get pointer back from box2d's callback:
Environment* envPtr = static_cast<Environment*>(box2d->userId);
As you can see envPtr is going to cause trouble.
Is there a way to refer to the old smart-pointer and increase its reference value?
PS:
In actuality every class creates an box2d body which holds a 'this' pointer so i don't actually have the address to the smart-pointer either. The example above is kind narrowed down to give you a hint of the problem i'm facing.
Best regards
nilo
If Environment has std::enable_shared_from_this<Environment> as a parent class then, yes. Just call envPtr->shared_from_this().
I've recently started using OpenSceneGraph. I'm wondering how it deals with memory management( if at all ). For example, we have the geometry class. The geometry class accepts arrays of vertices, colours, texture coordinates as you'd expect. Except, it expects these things as a pointer to an object:
void Geometry::setVertexArray(Array* array)
{
if (array && array->getBinding()==osg::Array::BIND_UNDEFINED) array->setBinding(osg::Array::BIND_PER_VERTEX);
_vertexArray = array;
dirtyDisplayList();
dirtyBound();
if (_useVertexBufferObjects && array) addVertexBufferObjectIfRequired(array);
}
This is from the OpenSceneGraph source code. As you can see an Array* is passed to the method, which is expected to be allocated by the user. If that's the case, who deletes it? Obviously not OSG( and that makes sense ), because we can see that it blindly overwrites the last array pointer when a new one is assigned. This is fine, however now the user must make sure that the array they allocated outlives the geometry class. Also for every array the user gives this geometry object, they must keep a reference to this array.
This leaves us with an absurd amount of pointers that must be deleted only after the object is deleted. The result is I'm finding this very cumbersome to use. Am I missing something here? Why is the system designed like this?
osg::ref_ptr<Array> _vertexArray;
_vertexArray is defined in the header like this. This means when it is assigned to array in that method, the reference count will increase to 1. When the reference is removed the count will go to 0 and will delete the object.
This means you can't rely on the array data outside the geometry object unless you also defined the array as a ref_ptr. This is quite confusing and makes me wonder why they didn't have the parameter be a ref_ptr.
I'm sure this will lead to some obscure problems, but I guess the rule is do not rely on non-ref pointers if you're passing it on. This is probably meant for the cases where you blindly create an object and immediately pass it on to the method, though I wish OSG would make this more clear.
I am building a game engine library in C++. A little while back I was using Qt to build an application and was rather fascinated with its use of Implicit Sharing. I am wondering if anybody could explain this technique in greater detail or could offer a simple example of this in action.
The key idea behind implicit sharing seems to go around using the more common term copy-on-write. The idea behind copy-on-write is to have each object serve as a wrapper around a pointer to the actual implementation. Each implementation object keeps track of the number of pointers into it. Whenever an operation is performed on the wrapper object, it's just forwarded to the implementation object, which does the actual work.
The advantage of this approach is that copying and destruction of these objects are cheap. To make a copy of the object, we just make a new instance of a wrapper, set its pointer to point at the implementation object, and then increment the count of the number of pointers to the object (this is sometimes called the reference count, by the way). Destruction is similar - we drop the reference count by one, then see if anyone else is pointing at the implementation. If not, we free its resources. Otherwise, we do nothing and just assume someone else will do the cleanup later.
The challenge in this approach is that it means that multiple different objects will all be pointing at the same implementation. This means that if someone ends up making a change to the implementation, every object referencing that implementation will see the changes - a very serious problem. To fix this, every time an operation is performed that might potentially change the implementation, the operation checks to see if any other objects also reference the implementation by seeing if the reference count is identically 1. If no other objects reference the object, then the operation can just go ahead - there's no possibility of the changes propagating. If there is at least one other object referencing the data, then the wrapper first makes a deep-copy of the implementation for itself and changes its pointer to point to the new object. Now we know there can't be any sharing, and the changes can be made without a hassle.
If you'd like to see some examples of this in action, take a look at lecture examples 15.0 and 16.0 from Stanford's introductory C++ programming course. It shows how to design an object to hold a list of words using this technique.
Hope this helps!
I have a class named Texture that has a pointer to a SDL_Surface. When I want to add it to a vector I need to have a non-default copy constructor to prevent problems when the original goes out of scope. I know that the copy constructor is called whenever the object is passed by value to a function. Will passing many Texture objects by value to my render function every frame cause my program to slow down? I know I can pass by reference to avoid this problem but I would like to keep my existing code as is if possible.
First of all, if you are really concerned about performance, then you should be passing references around, passing by value could get very expensive, no matter if you use the default or a custom copy constructor.
Now, if you are completely set on passing stuff by value and using copy constructors, I think the default copy constructor is nice, because it takes care of everything for you. You should try to adapt your class so that you can continue using it, if possible.
If your class has pointers, then one approach is to wrap them inside some kind of smart pointer. For example, if instead of SDL_Surface* you use std::shared_ptr<SDL_Surface> (or boost::shared_ptr<SDL_Surface> which is the same) then you enable that pointer to be copied. The shared_ptr class will keep a reference count on it and only delete the surface when all the references are gone. Note that if you do this approach you need to use a custom delete function for SDL_Surface, as shown in this question.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Should objects delete themselves in C++?
In my application, I'm creating many objects that "own themselves" - in the sense that after they are created and told to "go," only the object itself can determine when it should be deleted.
For example, if I was writing a game, I might have multiple Enemy objects. Only the Enemy object knows when it should die.
As a result, I end up using delete this inside some of the member functions inside the Enemy object. Is this bad form? Is this something I should avoid, and if so, what is the correct way to handle this type of situation?
The thing to be careful of is that if too many member functions have self-deletion as a side effect, it's easy to accidentally use a reference to the object after it's deleted.
One approach to avoid this is to defer the deletion - that is, put the object on a list, and from your game's main loop, delete everything on that list at the start/end of a tick.
Depends on the memory management strategy. There are cases that it really makes sense and it's the correct thing. For instance, in a reference counting system like COM, the object would do a delete this when the refcount gets down to zero.
For example, if I was writing a game, I might have multiple Enemy
objects. Only the Enemy object knows
when it should die.
The enemy object may know when it enters a "dead" state, yes. But that is not necessarily the same as "the object should be deleted".
Think of all the other objects that may have a reference to it? They may at any time attempt to call a function on the Enemy object (say, TakeDamage()), and if the object has been deleted without informing them, you'll probably have a crash. How do they know that the Enemy they're shooting at is dead?
So the Enemy object knows when it is dead, but not when it should be deleted. It does not own itself.
Who does own it then?
The game world may be a good bet. When the enemy dies, it sends a message to the game world saying that it is dead, and the game world could then be responsible for making sure no one holds a pointer to it, and finally, when it is safe to do so, deleting the object.
It seems odd to me, i myself would prefer someone or something getting rid of them. The fear of someone referencing the object is just terrifying to me. It also seems very possible for a "child" method to unknowningly destroy the object. When you return to a higher level method: you're operating on a non-existant object.
It sounds like you're inventing referencing counting, perhaps explicitely use the reference count pattern.
Or have the objects add themselves to a "to be destroyed" list - and you have yourself a garbage collection system.
As long as the Enemies manage all the references to them (eg. list of units, list of units in groups etc.) it's OK (and used quite often).
But if you want to be on the safer side, the Enemies should register themselves for some destruction routine run at some "safe spot" in the program execution (for an example, see QObject::deleteLater() in Qt.
You could use shared_ptrs to objects to have them automatically clean up when no references to them are available anymore.
Or call the destructor on the class.
To be honest you should try to stick away from that. Otherwise you might delete something that is used by something else and finish off by having a really odd result and probably some memory leak with it.
I think that the object should delete its resources in the destructor. Your class should use another class to know when the enemies are dead.
The referring object(s) should do the deletion, and they should do so by asking the object if the conditions for deletion are met. One of the conditions (besides being eliminated from use in the game) are how many other objects still refer to the object. This is something that can be tracked with static reference counting. Generally, if you write it carefully, you might be able to build it in such a way that enemies are only tracked in one place in your game loop. That place will check collisions and other conditions, and when it's ready to delete the object it will not have to ask if deletion is okay because it knows it's the only client, and can safely dereference what it allocated.
Abstractly, I don't think you want an object deleting itself.
What you want to do is create a control structure that retrieves a SIGNAL or message from the object that it's time to "die", in this case, and the control structure will "delete" or take the particular necessary action on the object.
This way, you leave the control of the object existing or not on the control structure, and when everything has a centralized control unit, you prevent potential calls to deleted objects.
Also, remmeber to differentiate between a soldier "dying" as you say, and an object being actually "deleted" from memory. The dying portion, the object itself can accomplish by setting a flag, such as "dead = true." But the deletion of the object from memory should be accomplished by the control structure I'm referring to.