0

I enabled heap debugging because of a memory leak error I started seeing in somebody else's code and I pinned down the problem (at least, so I think) to the destructor of a class, right after the call to the delete [] below.

MyClass::~MyClass() {
    delete [] my_class_member_;
}

Now I confirmed that my_class_member_ which is an array of pointers to objects of a struct, say, MyStruct, has been allocated property using new [] so I am not sure what is causing this leak? Here's what the new [] call looks like:

delete [] my_class_member_;
my_class_member_ = new MyStruct[somesize_]; 

Next, the struct MyStruct is also relatively simple and is as follows (stripped down):

struct MyStruct {
    MyStruct() {}
    ~MyStruct() {
        for( PtrList<PClass>::iterator it(ps); it.more(); it.next() ) {
            delete it.cur();
        }
        for( PtrList<RClass>::iterator it(rs); it.more(); it.next() ) {
            delete it.cur();
        }
        delete shift;
    }
    PtrList<PClass> ps;
    PtrList<RClass> rs;
};

Now PtrList is a list of pointers (a built-in type of the application devkit we're using).. I am pretty certain that can't be at fault. Anyways, is anything out of whack that anybody notices here?? Appreciate any insight..

squashed.bugaboo
  • 1,338
  • 2
  • 20
  • 36
  • 1
    Have you followed the **Rule of Three**? From the information you present it is not clear whether you do so.You need to provide a *copy constructor* and *copy assignment operator* which do a deep copy of your dynamically allocated member.If you don't do so and if both these operators are not `private` and not left undefined then You cannot be sure that they are not being used at all and this is where your problem lies. – Alok Save Jun 13 '12 at 17:22
  • Thanks you might be on to something.. I am looking into that. – squashed.bugaboo Jun 13 '12 at 17:32
  • I read the post on Rule of Three, but my understanding is that if no copies/assignments are done, it should be safe the way it is, am I right? – squashed.bugaboo Jun 13 '12 at 17:55
  • Yes, and I quote again *"if both these operators are not private and not left undefined then You cannot be sure that they are not being used at all"* – Alok Save Jun 13 '12 at 18:03
  • Actually I see many assignments being done in the code on the struct like MyStruct s = my_class_member_[someindex]; I am guessing this might lead to a lot of issues, so I'll add only an assignment operator and see if that fixes it. I assume that the Rule applies also to structs? Thanks again for the excellent response! Kindly add as an answer and I'll accept right away. – squashed.bugaboo Jun 13 '12 at 18:10
  • ^ Typo: I meant I saw statements like MyStruct& s = my_class_member_[someindex]; – squashed.bugaboo Jun 13 '12 at 18:25

1 Answers1

1

Adding comment as an answer as requested by OP.

Have you followed the Rule of Three?
From the information you present it is not clear whether you do so.You need to provide a copy constructor and copy assignment operator which do a deep copy of your dynamically allocated member.If you don't do so and if both these operators are not private and not left undefined then You cannot be sure that they are not being used at all and this is where your problem lies

Community
  • 1
  • 1
Alok Save
  • 202,538
  • 53
  • 430
  • 533