member functions to free member variable memory

Question

Recently I have noticed some of my objects become quite large and after a while I might not need them any longer. I could wait until the end of the local scope for the destructor to release the memory or use custom scopes using code blocks.

However, I had this idea to implement, for each object, a void MyObject::clear() method that clears the memory:

class MyObject{
    bool is_cleared;
    // Other stuff

public:
    MyObject();
    ~MyObject();

    void clear();
    // Other stuff
};
MyObject::MyObject()
    : is_cleared(false)
    {
        // construct the class
    }
void MyObject::clear(){
    if (!is_cleared){
        // clear memory
        is_cleared = true;
    }


}

MyObject::~MyObject(){
    this->clear();
}

This way I can either let the destructor clear the memory or do it myself. Is this considered a good or bad practice? How can I improve it?

wouldn't calling the destructor explicitly and easier way to do just that ? — MimiEAM, Aug 22 '12 at 04:19
@MimiEAM As long as your destructor is safe to call repeatedly — David, Aug 22 '12 at 04:20
@Dave true, and also as long as some part of the code does not reference the object after it's destructor has been called. — MimiEAM, Aug 22 '12 at 04:26

score 0 · Answer 1 · edited May 23 '17 at 11:50

0

There is nothing particularly bad with this technique (it is used by STL containers, for example). But you will also need to implement a copy constructor and an assignment operator (or make your object not copy-able and not assign-able). This is because you have implemented a destructor, so you will have to follow the rule of three.

edited May 23 '17 at 11:50

Community

1
1

answered Aug 22 '12 at 04:17

jxh

69,070
8
110
193

STL containers do this in a very different context. It's not really so you can clear their memory as an optimization before they destruct. It's a logical feature for a _container_. Just like it's logical to add to a container in some way, it's logical to be able to clear a container. The OPs proposal is unrelated IMO. – David Aug 22 '12 at 04:32
To add to Dave's comment, `clear` for STL containers has the advantage that you can reuse the memory, which is probably different than the OPs case. – Jesse Good Aug 22 '12 at 04:36
It is unclear what the OP's intentions are. But it is premature to condemn the technique. The technique is neither good or bad without more context. I simply offered my input on what needed to be improved if the technique is used as proposed in the question. – jxh Aug 22 '12 at 04:39

score 0 · Answer 2 · answered Aug 22 '12 at 04:17

It's bad practice. You should design ownership of objects in such a way that they are destructed when you "[don't] need them any longer".

This can be as simple as allocating the object on the heap and deleting it when you're done with it. It will then clean up any dynamic memory it allocated.

score 0 · Answer 3 · answered Aug 22 '12 at 04:20

I would flag this as a bad practice.

First, you should free stuff you don't need as soon as possible if is it of significant size. You should not use members to store large data in an object if that data should not survive till the object dies. There should be few exceptions to this rule. If many of your objects require it, you are designing objets with too many responsibilities.

Then, did you measure that you need to clean the memory before ? If not this is likely to be an unecessary optimization. Just wait till they go out of scope, why bother ?

member functions to free member variable memory

3 Answers3