I have a class with a vector of pointers to objects. I've introduced some elements on this vector, and on my main file I've managed to print them and add others with no problems. Now I'm trying to remove an element from that vector and check to see if it's not NULL but it is not working.
I'm filling it with on class Test:
Other *a = new Other(1,1);
Other *b = new Other(2,2);
Other *c = new Other(3,3);
v->push_back(a);
v->push_back(b);
v->push_back(c);
And on my main file I have:
Test t;
(...)
Other *pointer = t.vect->at(0);
delete t.vect->at(0);
t.vect->erase(t.vect->begin());
if (pointer == NULL) { cout << "Nothing here.."; } // Never enters here..
Deleting a pointer doesn't have to zero it, it just frees the memory assigned there. Using pointer is undefined after the delete though, as the memory is free to be used for other things. Technically the C++ spec intentionally leaves it up to implementations whether they want to zero a deleted pointer or not, but practically none that I know of do so
The deletion of memory pointed by a pointer, doesn't set the pointer to NULL.
You set pointer equal to the address of something, and never touched it again, so of course it won't be null. The fact that you then did something to the object is irrelevant.
Using simple pointers, there is no safe way for pointer to determine whether the object it once pointed to has been deleted. The simplest way to do what you seem to want to do is by leaving it to the containers: if you're interested in that object, search for pointer in the vector to see whether it's still there (and don't delete the object without erasing the corresponding element from the vector, or you'll have the same problem all over again).
To overcome the checking a deleted ptr problem you could use boost::shared_ptr.
Instead of delete use .reset() and to check if the ptr is still valid use .get()
(Actually you can just use if(p) where p is the shared_ptr because it has a conversion to bool)
Related
I am trying to find out how can I delete children of my Block class. I tried to do it with raw pointer. I don't know why, but it didn't work. I was getting the scalar deleting error. I now tried to do this with std::shared_ptr. I t didn't work as well. I am removing the children with:
void Block::remove(Block* block)
{
std::shared_ptr<Block> ptr(block);
auto it = std::find(children.begin(), children.end(), ptr);
if (it != children.end())
{
*it = NULL;
children.erase(it);
}
}
and the Block deleter is:
Block::~Block()
{
for (auto& child : this->children)
{
child = NULL;
}
if (!this->children.empty())
this->children.clear();
}
According to the debugging process, the ptr variable is found and then deleted. At the point of deleting everything works well until the last line, where I am getting the scalar deletion error. Just for the record: the children variable is of type std::vector<std::shared_ptr<Block>>.
EDIT:
The full code is here: https://github.com/DragonGamesStudios/Ages-of-Life. All the block functions are defined in AOLGuiLibrary/source/Block.cpp
You are mixing shared_ptrs with raw pointers, and that is a bad practice. If I understand correctly, you store the blocks in the vector of shared pointers, and that means that this vector has an ownership on these objects. When you create an additional shared_ptr out of a raw pointer you create another object that has the ownership on the same object:
std::shared_ptr<Block> ptr(block);
As the result, you would try to delete the object twice, and that leads to the undefined behavior.
First of all: do you need shared pointers? Consider using unique_ptr as a less error prone idea (if only one pointer object has the ownership, it is easier to understand who and when would destroy the underlying object).
Next, NEVER use raw pointers in this context: you may use raw pointers only when you don't store/delete the object. And for sure don't create smart pointers out of something that is already stored in one of them already.
Once a pointer has been given to a shared_ptr, that shared_ptr owns it. You must never again give that pointer to another shared pointer.
int * ptr = new int(1234);
{
std::shared_ptr<int> shp1(ptr); // shp1 owns ptr
std::shared_ptr<int> shp2(ptr); // shp2 owns ptr ???
}
// at this point ptr has been deleted twice
Note: it's preferable to not use new but to call std::make_shared and never give raw pointers to shared_ptr in the first place.
What you are doing to search for a child is exactly this problem. Passing in a raw pointer, you create a new owner for it. If that pointer is a child, it's already owned. You must not create shared pointers from raw pointers after they have been given to a shared pointer.
Also, the destructor you showed for Block isn't wrong, but it is completely unnecessary. All of what you coded there would happen automatically. Block is destroyed, it destroys the vector it holds (so clearing it is unnecessary.) The vector destroys its elements, so the shared pointers it holds are cleaned up too.
If block points at array code, this code is illegal, because for a new[] you have to call delete[], and std::shared_ptr<Block> would call delete. After that heap would be corrupted and further operations may fail. Same happens if blocks points to an element of array. If blocks points to object not located in heap, it also would result in error.
In general it's bad idea to delete a pointer passed to a function. There is no guarantee that the pointer was one returned by new, and even if it was: by which new?
To create a strong reference counter for an array, you have to use std::shared_ptr<Block[]>, but usually it's better idea to use some kind of container.
To find a value of pointer object in array of shared pointers:
auto it = std::find_if( children.begin(), children.end(), [=](auto& el) {
return el.get() == block;
});
If childrenis not static (that's not some kind of factory), then that destructor code is completely redundant. After call to ~Block() there will be calls to destructors of every member of Block, including that collection which would deallocate its resources and call destructor to every pointer, which would call destructor to every Block.
I have a class "DMRecSessionObj" whose objects are dynamically allocated using new and stored in a map.
static std::map<string,DMRecSessionObj*> mapExpSessData;
DMRecSessionObj* dmRecSessObj = new DMRecSessionObj(atoi(p_callNum),atoi(p_totCalls), sessionKey);
mapExpSessData.insert(std::pair<string,DMRecSessionObj*>(sessionKey,dmRecSessObj));
During the deallocation of memory, I use the below obvious method
delete dmRecSessObj;
dmRecSessObj = NULL; //to prevent it from being a dangling pointer
But I am little bit confused while trying to deallocate the memory using iterator as below:
std::map<std::string,DMRecSessionObj*>::iterator itr_del = mapExpSessData.find(tmp_sessionId);
if (itr_del != mapExpSessData.end()){
mapExpSessData.erase(tmp_sessionId);
delete itr_del->second;
}
In this case, should the iterator itr_del be somehow set to NULL? As normal pointers can result in dangling pointers if not set to NULL, how would the iterator behave in this case? Is anything more need to be done in this case to be safe?
Please suggest.
Thank you.
Once you call mapExpSessData.erase(tmp_sessionId);, the node in the map that itr_del points to has been deleted. Calling delete itr_del->second; is then Undefined Behavior because you try to access deallocated memory.
You need to delete the value in the map first, then delete the node in the map:
delete itr_del->second;
mapExpSessData.erase(itr_del);
The code block the iterator is in should be small at this point, and the iterator itself going out of scope so you shouldn't need to do anything with it to clear it out. But if you really want to you can assign the default value for its type back to it.
Recently, I was confused on why I continuously was faced with a segmentation fault trying to access an element in a vector of pointers of certain objects. I didn't manage to resolve the issue, but I suspect that it is because after I pushed the object pointer into a vector, I called delete on it, thinking that the vector stored a copy.
In the following code:
std::vector<SomeObject *> testvector;
SomeObject * testobject = new SomeObject(/* some arguments here, call constructor */)
testvector.push_back(testobject);
delete testobject; // does this affect the element in the vector?
The debugger confirms that the pointers getting added to the vector do indeed have proper data, but once I call delete on them, I'm unsure if the element inside the vector is affected. Does the vector store just a copy? When I call delete on the object, I suspect that delete is being called on the pointer in the vector, but I am unsure.
Now I tried to print out the data in the vector after calling delete, I get this: ??? ?? ???? ???
And I am assuming that the call to delete has affected the vector element. Is this the case? I thought that after I added the pointer to the vector, I could safely free the object without affecting the element in the vector, but it seems that I end up accessing memory that is no longer allocated. Does the call to delete affect the pointer in the vector?
"Does the call to delete affect the pointer in the vector?"
It doesn't affect the pointer. It affects the behavior invoked by using this pointer since the object it points to no longer exists. When you call delete, the object is deleted and whatever you try to do with that object using invalid (old, dangling) pointer, the behavior is undefined.
std::vector<SomeObject *> testvector;
SomeObject * testobject = new SomeObject()
testvector.push_back(testobject);
Constructs a vector of pointers, creates an instace of SomeObject and pushes an address of this object to your vector. Then when you call:
delete testobject;
There is no way how std::vector could know that the object has been deleted. Your vector still contains an old pointer, which has became invalid by the time the object was deleted. A possible solution could be using a vector of smart pointers such as shared_ptr, however at first you should consider whether you want to use a vector of pointers at first place. Maybe std::vector<SomeObject> would be more reasonable way to go.
The vector contains pointers not the objects theirself. So after deleting an object the corresponding pointer will be invalid.
When you copy a pointer, you only copy the address of the object, not the object itself. That means the pointer in your vector and your pointer outside the vector were still referring to the same thing when you called delete.
The reason the debugger may still have shown seemingly valid data is because the memory doesn't necessarily get overwritten when you delete something. It's simply marked as 'free' so that it can be used by something else later if required.
Yes, both testobject and the inserted element into the vector are pointing to a same address. After deleting one of them another will be a dangling pointer and dereferencing it is undefined behavior.
You can use smart pointers such as std::unique_ptr or std::shared_ptr.
std::vector<std::shared_ptr<SomeObject>> testvector;
std::shared_ptr<SomeObject> testobject(new SomeObject);
testvector.push_back(testobject);
or
std::vector<std::unique_ptr<SomeObject>> testvector;
std::unique_ptr<int> testobject(new SomeObject);
testvector.push_back(std::move(testobject));
// After `std::move` you can not use `testobject` anymore!
This is a follow up question from
Safe in C# not in C++, simple return of pointer / reference,
Is this:
person* NewPerson(void)
{
person p;
/* ... */
return &p; //return pointer to person.
}
the same as?
person* NewPerson(void)
{
person* pp = new person;
return pp; //return pointer to person.
}
I know that the first one is a bad idea, because it will be a wild pointer.
In the second case, will the object be safe on the heap - and like in c#
go out of scope when the last reference is gone to it?
Yes, the second case is safe.
But the caller will need to delete the returned pointer. You could change this to use boost::shared_ptr and it will be destroyed when it is no longer in use:
boost::shared_ptr<person> NewPerson()
{
boost::shared_ptr<person> pp = boost::make_shared<person>();
return pp;
}
If C++11 then you can use std::shared_ptr or std::unique_ptr.
It's safe, the object will still be alive after the return.
But don't expect the object to be automatically cleaned up for you in C++. Standard C++ does not have garbage collection. You'll need to delete the object yourself, or use some form of smart pointer.
person* NewPerson(void)
{
person* pp = new person;
return pp; //return pointer to person.
}
I know that the first one is a bad idea, because it will be a wild
pointer. In the second case, will the object be safe on the heap - and
like in c# go out of scope when the last reference is gone to it?
Correct on the first one: it would be returning a pointer to data on that functin's stack, which will be reclaimed and modified once the function finishes.
On the second case: the object is created on the heap, which is separate from the execution stack. When the function finishes, the object on the heap is safe and stays the same. However, C++ does not automatically do garbage collection, so if you lost all of the references to a heap object, this would constitute a memory leak--the object's space would not be reclaimed until the program ended.
The latter is safe. However, C++ does not (usually) provide garbage-collection, and thus you need to arrange for an explicit delete of the returned object.
Like you say, the first case is bad as the pointer will not be valid. As for the second case, memory in C++ is not managed, you have to clean up after yourself. C++ doesn't keep track of references on normal pointer, that's what std::shared_ptr is for.
I have a struct like this:
class Items
{
private:
struct item
{
unsigned int a, b, c;
};
item* items[MAX_ITEMS];
}
Say I wanted to 'delete' an item, like so:
items[5] = NULL;
And I created a new item on that same spot later:
items[5] = new item;
Would I still need to call delete[] to clean this up? Or won't this be needed since bounds of array items[] are known before compiling?
Is setting that pointer to NULL valid or should I be calling delete there?
You need to call delete before setting it to NULL. (Setting it to NULL isn't required, it just helps reduce bugs if you accidentally try to dereference the pointer after deleting it.)
Remember that every time you use new, you will need to use delete later on the same pointer. Never use one without the other.
Also, new [] and delete [] go together in the same way, but you should never mix new [] with delete or new with delete []. In your example, since you created the object with new (rather than new [] which would create an array of objects) you must delete the object with delete (rather than delete []).
As Kluge pointed out, you'd leak the object at index 5 like that. But this one really sounds like you shouldn't do this manually but use a container class inside Item. If you don't actually need to store these item objects as pointers, use std::vector<item> instead of that array of MAX_ITEMS pointers. You can always insert or erase vector elements in the middle as well if you need to.
In case you need to store the objects as pointers (usually if struct item is actually polymorphic, unlike in your example), you can use boost::ptr_vector<item> from Boost.PtrContainer instead.
Example:
class Items {
private:
struct item {
unsigned int a, b, c;
};
std::vector<item> items;
}
if (items.size() > 5) // (just to ensure there is an element at that position)
items.erase(items.begin() + 5); // no need to use operator delete at all
To delete an item use:
delete items[5];
after deleting the item it is advisable to set the deleted pointer to NULL, so you won't have an error if you later delete it again by mistake.
items[5] = NULL
Say I wanted to 'delete' an item, like so:
items[5] = NULL;
I know little Visual Basic, but that smells like a Visual Basic programming idiom, since "Set a = None" (or Null, I'm not sure) would delete the object pointed by a (or rather decrement its reference count, for COM objects).
As somebody else noted, you should use either:
delete items[5];
items[5] = newContent;
or:
delete items[5];
items[5] = NULL;
After delete[5], the only possible use of the pointer stored in items[5] is causing you trouble. What's worse is that it might happen to work at the beginning, and start failing only when you allocate something else over the space previously used by *items[5]. Those are the causes which make C/C++ programming "interesting", i.e. really annoying (even for who likes C like me).
Writing just delete items[5]; saves what can be an useless write, but that's a premature optimization.
Just to be clear: you refer to calling "delete[]". I think you mean delete.
I mention this because C++ has two separate operators, operator delete and operator delete[]. The latter is used for deleting arrays of objects allocated with operator new[], and does not apply in this case. You have an array of pointers to objects, which you must have initialised with repeated calls to operator new rather than a single call to operator new[].
All I'm really trying to say is: your use of delete[] is confusing and ambiguous; change it to delete.
There are a few, related, questions here:
According to the code you posted, the array itself is not allocated on the heap unless the struct is, so you don't need to delete[] the array. If you created the array with new[] you would have to delete[] it.
The code posted doesn't say how the objects being pointed to from the array are allocated. If you allocate those objects on the stack you must not delete them (then again, this is highly unlikely because your pointers will become invalid when the objects they point to fall out of scope). If you allocated them on the heap (with new) then you must delete them when they fall out of scope.
As others have already suggested, life is much easier if you use a container -- especially an STL container -- and smart pointers -- which for now means pointers out of Boost.
C++ isn't my strong suit, but I'm pretty sure you'd be leaking the memory if you set the pointer to NULL.
EDIT: The memory being leaked would be the memory being pointed to by the pointer in the array.
Setting items[5] to NULL doesn't delete the memory associated with the item, it simply sets the pointer to that item to NULL, therefore the memory is leaked.
You can delete the item by calling:
delete items[5];
Since C++ has not automatic garbage collection, you need to delete any memory you no longer need.