Is it ok to use the destructor inside function of a class to reset values?

Question

In my lectures I don't see anyone using the destructor for reseting values to there starting parameters instead doing every variable manually in the function. Will using a destructor in a class function for reseting/deleting cause any issues

Small example of what I mean:

    class Test1{
        private:
            int *test;
            bool valid;
        public:
        Test1(int value,bool valid=false){
            test=new int(value); this->valid=valid;
        }
        ~Test1(){
            delete test; test=nullptr; valid=false;
        }

    void ResetStats(int NewValue){
        this->~Test1();
        test1=new int(NewValue);
        valid=false;
    }

    }

`new int(NewValue)` throws `std::bad_alloc`. The code the called `ResetStats` catches it. But yet somehow the object is toast and they can't work with it anymore, even if they can recover. — StoryTeller - Unslander Monica, Aug 01 '17 at 15:12
or [calling destructor explicitly](https://stackoverflow.com/questions/16720201/calling-destructor-explicitly) — underscore_d, Aug 01 '17 at 15:13
"In my lectures I don't see anyone using the destructor for reseting values to there starting parameters" - because that's not what destructors do, that's what constructors do. — , Aug 01 '17 at 15:15
Yes, people don't do it because it's a terrible idea that will render your program 100% UB. The given code won't compile and, even once fixed syntactically, will be totally broken semantically. The proposition fundamentally misunderstands the purpose of destructors and the nature of object lifetime. — underscore_d, Aug 01 '17 at 15:20
I'm curious as to why you would use `int* test1;` over just `int test1;`. It seems the storage is always handled internally. Even if there is a good reason to use a pointer, you should prefer `std::unique_ptr` for an owning pointer. — François Andrieux, Aug 01 '17 at 15:24
@François Andrieux My exams use this format. I know that unique_ptr are superior but I cant use them in my exams... — Adin Sijamija, Aug 01 '17 at 15:29

score 5 · Accepted Answer · answered Aug 01 '17 at 15:21

Calling a non-trivial destructor explicitly ends object's lifetime (why?).

Share the functionality between ResetStats and destructor by putting it in a separate private function:

// Both destructor and ResetStats call Reset
~Test1(){
    Reset(nullptr);
}
void ResetStats(int NewValue) {
    Reset(new int(NewValue));
}
// Shared functionality goes here
private Reset(int *ptr) {
    delete test;
    test=ptr;
    valid=false;
}

Christopher Pisz · Answer 2 · 2019-02-28T20:55:42.453

No. Destructors are to be called when objects are being destroyed, not when attempting to reset its state.

In order to reset values I would prefer a swap with a default constructed object, copy/move construction with a default constructed object, or move assignment to a default constructed object.

Test1 test;
// Do stuff
test.swap(Test());

Of course, one would have to implement a swap method, a copy constructor, or assignment. Lookup move semantics to implement these properly.

Consider classes that enforce RAII. In our example, test gets a file handle in its constructor. If you called the deconstructor for purposes of resetting values, then the object no longer has a file handle when you attempted to reset it, because it is obtained in the constructor and released in the deconstructor.

Deconstructors should be only be called when an object is being destroyed, imo.

Is it ok to use the destructor inside function of a class to reset values?

2 Answers2