Testing Pointers for Arrays

Started by
7 comments, last by MaulingMonkey 16 years, 9 months ago
I was wondering if there is any way to test a pointer for an array. My animation data class is hitting a bug when I am deleting the pointers, and I think it is because I am using delete [] x; on a pointer which only points to one item. Is there a way to test the pointer for this (so I can use a conditional to properly handle the deletion). Also, if this doesn't have a bearing, what can make a delete call fail? Should I be catching exceptions? Here is what is going on:


Animation2d::Animation2d()
{
m_data = NULL;
}

//somewhere in my program

m_data = new Animation2d[size];

Animation2d::~Animation2d()
{
delete [] m_data;
}


size is 1 right now. I'm using VC++2005EE, and the Debugger is listing this as a bug. Thanks for the help!
___________________________________________________Optimists see the glass as Half FullPessimists See the glass as Half EmptyEngineers See the glass as Twice as big as it needs to be
Advertisement
The answer is no, not unless you keep track of the allocations. Anyway, if you implement the allocation and deallocation properly, you shouldn't need to.

Your code doesn't make sense. You allocate an array of Animation2d objects, and when the elements of the array are destructed (presumably by deleting the array), they delete the array they are in? Perhaps, you should explain what you are trying to do -- it's not clear.
John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!
  • If an array was allocated with new[], it should be destroyed with delete [] even if it contains only one element.
  • There is no way to determine, in a portable and sane way, whether a pointer points to memory allocated by new[], new, the stack, malloc or any other kind of allocator.
  • JohnBolton: looks like a tree implementation.
Quote:Original post by Plasmarobo
Also, if this doesn't have a bearing, what can make a delete call fail?


Trying to delete the same chunk of memory more than once, or using the wrong kind of delete (as per ToohrVyk's post), or trying to delete using the wrong memory address (e.g. trying to delete an individual element of an array is nonsensical, because none of the array elements is itself an allocation). Note that a delete call on a null pointer is perfectly safe, and the language is specifically designed to let you do that; so *do not* check for nulls before making the call - it is poor style, and gives a false sense of security.

Quote:Should I be catching exceptions?


In general, maybe ;) But I assume what you mean is, "is there an exception that the delete call might throw, which I should check for?" And the answer is no, there is no exception you can, let alone should check for. The *new* call might throw std::bad_alloc, but it is usually best to ignore that possibility, and let the program crash (with an unhandled std::bad_alloc), because in a *properly-written* program, this will only happen if you are out of memory.
Crap! I mixed up two of my classes into one here. Sorry, that was less than intelligent. What I actually meant to show was this:
struct AnimData2d{//data for the animation frames}class Animation2d{protected:AnimData2d *m_data;public: Animation2d(){m_data = NULL;}~Animation2d(){delete [] m_data;}//somewhere in the program executionLoad(std::String dir){//allocate the memory in this function. Called alongside object creationm_data = new AnimData2d[size];}

Ha... that is more like it. But as far as everything else goes, I think I'm doing it right... so why is VC++2005EE having issues with my deletion?
[edit]
The specific assertion that I'm getting is "_CrtIsValidHeapPointer(pUserData)"
It's propping up on the delete calls ( as I said before). Since it is halting the execution of my program I dunno if this is the only one or not.

[Edited by - Plasmarobo on July 9, 2007 9:16:45 AM]
___________________________________________________Optimists see the glass as Half FullPessimists See the glass as Half EmptyEngineers See the glass as Twice as big as it needs to be
Quote:Original post by Plasmarobo
Crap! I mixed up two of my classes into one here. Sorry, that was less than intelligent. What I actually meant to show was this:


Nothing looks wrong there.

Quote:so why is VC++2005EE having issues with my deletion?

[edit]
The specific assertion that I'm getting is "_CrtIsValidHeapPointer(pUserData)"
It's propping up on the delete calls ( as I said before). Since it is halting the execution of my program I dunno if this is the only one or not.


Primary suspects:

1) m_data is a bad pointer
1.a) You're delete[]ing m_data when you've already delete[]ed it before. Avoid this by assigning m_data to 0 or NULL after any delete[]s in any non-destructors you might have.

2) this is a bad pointer
2.a) You're delete([])ing an Animation2d* when you've already delete([])ed it before. Same solution.
2.b) You're delete([])ing an uninitialized Animation2d*. Initialize it to 0 or NULL to avoid this as well.
Ok, why can't you use RAII?

struct AnimData2d{//data for the animation frames}class Animation2d{  public:    Animation2d( std::string dir )    {       // do whatever, find out the size      // m_data( new AnimData2d[size] ); <- no more      m_data.resize( size );    }    AnimData2D & operator[](int index)    {      return m_data[index];    }    ~Animation2d() {      // delete [] m_data; <- no more    }  private:    std::vector<AnimData2d> m_data;};


Also, are you passing your AnimData2D by value somewhere? If so, then you have multiple deletion, since you don't copy the m_data properly.

Don't mess with custom allocation in this way, when there's facilities that take care of that for you.
Quote:Original post by Antheus


I would go as far as:

// ~Animation2d() {       <-//   delete [] m_data;    <- no more// }                      <-


[wink]

Quote:Original post by Antheus
Ok, why can't you use RAII?

*** Source Snippet Removed ***

Also, are you passing your AnimData2D by value somewhere? If so, then you have multiple deletion, since you don't copy the m_data properly.

Don't mess with custom allocation in this way, when there's facilities that take care of that for you.


Good calls all around. And so quoted.... FOR EMPHISIS AND/OR SPARTA!!!

EDIT: Also, I now note that the original sports a Rule of three violation, the symptoms of which you pointed out just now.

This topic is closed to new replies.

Advertisement