Is having a function call within a destructor a good practice?

Question

Suppose there is a destructor for an object as:

anObject::~anObject()
{
    _functionCalledfromDestructor=1; //this sets the flag = 1
    functionCall(); //this function does something different than usual
                    //on seeing the flag
}

My question:

Is this style/method of coding in the destructor a good practice?

Be sure `functionCall` doesn't throw exceptions! – ildjarn Jul 18 '12 at 19:13 — ildjarn, Jul 18 '12 at 19:13

score 10 · Accepted Answer · answered Jul 18 '12 at 19:08

"Hidden channels" like this are always a bad idea. The behavior of a function shouldn't depend on invisible state. You could give the function an argument, and then pass one value in the destructor and another value everywhere else. You could use a default value for the more common case, if you wish.

score 7 · Answer 2 · answered Jul 18 '12 at 19:07

7

Is this style/method of coding in the destructor a good practice?

If the function does two different things depending on where it's called from, then you have two functions, not one. Make the two functions actually be two functions and you don't need to ask this question.

answered Jul 18 '12 at 19:07

R. Martinho Fernandes

228,013
71
433
510

It does not do entirely different things - it just write to a register different sets of bit in each of the 2 cases. – armundle Jul 18 '12 at 19:09
8

@armundle Most people would use a parameter where you've used a global variable. – Waleed Khan Jul 18 '12 at 19:10

score 4 · Answer 3 · answered Jul 18 '12 at 19:09

Generally, no. I think you're better off doing something like this:

class anObject 
{
private:
  void doSomethingInternal(bool fromDestructor) {...}
public:
  void doSomething() {doSomethingInternal(false);};
  virtual ~anObject() { doSomethingInternal(true); };
}

score 0 · Answer 4 · edited May 23 '17 at 12:04

0

Calling functions inside a destructor is commonly not considered a good practise, as there is the possibility that an exception is thrown. This leads to not correctly cleaned up memory and the behaviour of exceptions in the destructor is undefined.

Here is more information about throwing exceptions in the destructor:

SP on throwing in the destructor

In your case, a well defined clean up via a public interface is a whole better way to go. You could for example provide a Dispose method that does the clean-up.

Consider something like the following (in pseudocode):

public:
    void Dispose()
    {
        bool isDestructing = true;
        functionCall(isDestructing);
    }

edited May 23 '17 at 12:04

Community

1
1

answered Jul 18 '12 at 19:10

Mare Infinitus

8,024
8
64
113

2

Calling functions from the destructor is just fine as long as the function has the nothrow guarantee. On the other hand, requiring a cleanup to be explicitly performed before destruction is a bad practice (`std::thread` does this though), after all, this cleanup would not be called during an exception unwind. – avakar Jul 18 '12 at 19:31

Is having a function call within a destructor a good practice?

4 Answers4