If i do this: char* Ptr=new char[Number]; and then do this: char* Ptr2=Ptr; to free the memory I would do this: delete[]Ptr2; because Ptr2 is a pointer to the memory that was allocated in the first line right? Thats my first question. Here is my second: So I could have a class:

class FileInfo
{
    char* m_cPtr;
    FileInfo(){m_cPtr=NULL;}
    ~FileInfo(){delete[]m_cPtr;m_cPtr=NULL;}
}

//Then in my program I do:
//
char* Ptr=new char[Number];
//
FileInfo* FilePtr=new FileInfo[DifNumber];
//
for (int x=0;x(is less than)DifNumber;x++)
    FilePtr[x].m_cPtr=Ptr;
//
//do other stuff
//
//then when i come to tidy up I do:
delete[]FilePtr;
//which will call the destructor for each FileInfo which in 
//turn frees the memory used in m_cPtr which is
//"pointing" to the memory allocated by 
//char* Ptr=new char[Number];

  

Is this right or am i missing something? Thanks for any help you can offer Edited by - Zeke on August 9, 2001 10:33:38 AM

1. Yes.

2. As posted, that will work, but IMHO it is a bit dodgy...

As a general rule, any class that allocates its own memory in a constructor should deallocate it itself. Any memory allocated outside of the class, should be deallocated outside of the class. You should make sure that whoever "owns" the pointer should be responsible for freeing it, and no one else.

The problem with the fileptr object you have defined here is that they are all pointing at the same chunk of data. This is fine, but lets say one of the fileptr objects is local to a particular function. As soon as that fileptr object goes out of scope, it gets destroyed, all the data that all of the fileptrs are pointing at will also be destroyed, and next time you try and use it you'll get an access violation or assert failure.

Edited by - Sandman on August 9, 2001 11:50:59 AM

Thanks Sandman.

I see what you are saying however I cant really see a way round it for my app. Im using MFC with multiple views and at the moment the only way i can find to pass information from one view to another is to bounce it off the document class (i.e. View1 creates a * with new but View2 needs that info so I store View1''s info in the doc class, update the views so that View2 can get the info from the doc class and we might not go back to View1 so View2 needs to delete[] the info, if you see what I mean). Therefore I have tried to make it so that the classes tidy themselves up.

Thanks for the info.

No offense, but it sounds like a design issue. You really need to clarify how data ownership works in your design, or you will will code yourself into a bug infested corner.

Perhaps you want a global DataManager class that looks after the data, and handles requests from your views in a client server style? This would centralise your memory management and make it far easier to track memory leaks and data access bugs than by allocating the responsibility for data management at runtime.

Yeah that sounds like a good idea. It will be a hell of a lot of work to change my app around for that but like you said im gonna end up overrun by bugs and memory leaks (that is the reason i asked the questions- because i am having problems with a few memory leaks at the moment).

Thanks again for the info