6

Is there any way to call a field destructor before the class destructor?

Suppose I have 2 classes Small and Big, and Big contains an instance of Small as its field as such:

class Small
{
public:
    ~Small() {std::cout << "Small destructor" << std::endl;}
};

class Big
{
public:
    ~Big() {std::cout << "Big destructor" << std::endl;}

private:
    Small small;
};

int main()
{
    Big big;
}

This, of course, calls the big destructor before the small destructor:

Big destructor
Small destructor

I need the Small destructor to be called before the Big destructor since it does some cleanup necessary for the Big destructor.

I could:

  1. call the small.~Small() destructor explicitly. -> This, however, calls the Small destructor twice: once explicitly, and once after the Big destructor has been executed.
  2. have a Small* as the field and call delete small; in the Big destructor

I am aware that I can have a function in the Small class that does the cleanup and call it in the Big destructor, but I was wondering if there was a way to inverse the destructor order.

Is there any better way to do this?

Rabbid76
  • 202,892
  • 27
  • 131
  • 174
CK.
  • 312
  • 3
  • 13
  • I don't think there's a better way as the `Small` destructor will only be called when `Big` is getting destroyed, thus, after the `Big` destructor. – ForceBru Jul 26 '17 at 15:27
  • 6
    What kind of clean-up require for small's destructor to be called before big's destructor ? – nefas Jul 26 '17 at 15:27
  • 12
    "I need the small destructor to be called before the big destructor since it does some cleanup necessary for the big destructor." Your design is broken. Ask how to fix it, don't ask how to live with a broken design. – n. m. could be an AI Jul 26 '17 at 15:29
  • 4
    "I need the small destructor to be called before the big destructor" - this sounds like an [XY problem](http://xyproblem.info/) - why do you need to do this? – Oliver Charlesworth Jul 26 '17 at 15:29
  • Is there any better way to do what? Objects are destroyed in the reverse order as they are created. Anything else is just wrong in most cases – 463035818_is_not_an_ai Jul 26 '17 at 15:34
  • @n.m Yeah, that's broken, but sometimes require.Whole frameworks have such broken design e.g. QtQuick 5.3 hyrbrid app (C++ and jscript) would require something like that on linux, or app leaves hanging process behind itself. – Swift - Friday Pie Jul 26 '17 at 15:41
  • I would suggest reworking the design instead of trying to circumvent the standard order of construction/destruction. – NathanOliver Jul 26 '17 at 15:43
  • @n.m. Yes, that entered my mind. I guess I don't "need" to do it, I was just unsure if it "could" be done. – CK. Jul 26 '17 at 16:14
  • 1
    @nefas It's for destroying the zmq context, and the small destructor closes some sockets. The big destructor destroys the zmq context and needs all the sockets to be closed before it can be destroyed. – CK. Jul 26 '17 at 16:16
  • @OliverCharlesworth Thank you for that. Reversing the destruction order exactly seems to be Y. I'll see if I can redesign my code. That would be another question, though – CK. Jul 26 '17 at 16:26

3 Answers3

2

Without knowing why you want to do this, my only suggestion is to break up Big into the parts that need to be destroyed after Small from the rest and then use composition to include that inside Big. Then you have control over the order of destruction:

class Small
{
public:
    ~Small() {std::cout << "Small destructor" << std::endl;}
};

class BigImpl
{
public:
     ~BigImpl() { std::cout << "Big destructor" << std::endl; }
};

class Big
{
private:
    BigImpl bigimpl;
    Small small;
};
Chris Drew
  • 14,926
  • 3
  • 34
  • 54
2

call the small.~Small() destructor explicitly. -> This, however, calls the small destructor twice: once explicitly, and once after the big destructor has been executed.

Well, I don't know why you want to keep on with this flawing design, but you can solve the problem described in your first bullet using placement new.
It follows a minimal, working example:

#include <iostream>

struct Small {
    ~Small() {std::cout << "Small destructor" << std::endl;}
};

struct Big {
    Big() { ::new (storage) Small; }

    ~Big() {
        reinterpret_cast<Small *>(storage)->~Small();
        std::cout << "Big destructor" << std::endl;
    }

    Small & small() {
        return *reinterpret_cast<Small *>(storage);
    }

private:
    unsigned char storage[sizeof(Small)];
};

int main() {
    Big big;
}

You don't have anymore a variable of type Small, but with something like the small member function in the example you can easily work around it.

The idea is that you reserve enough space to construct in-place a Small and then you can invoke its destructor explicitly as you did. It won't be called twice, for all what the Big class has to release is an array of unsigned chars.
Moreover, you won't store your Small into the dynamic storage directly, for actually you are using a data member of your Big to create it in.


That being said, I'd suggest you to allocate it on the dynamic storage unless you have a good reason to do otherwise. Use a std::unique_ptr and reset it at the beginning of the destructor of Big. Your Small will go away before the body of the destructor is actually executed as expected and also in this case the destructor won't be called twice.


EDIT

As suggested in the comments, std::optional can be another viable solution instead of std::unique_ptr. Keep in mind that std::optional is part of the C++17, so if you can use it mostly depends on what's the revision of the standard to which you must adhere.

skypjack
  • 49,335
  • 19
  • 95
  • 187
  • Yes, I agree with the dynamic storage. That's what I mentioned in '2'. I'm using this approach for now. – CK. Jul 26 '17 at 17:06
  • 1
    I wonder if a `std::optional` would be preferable to `unique_ptr`. – Chris Drew Jul 26 '17 at 17:34
  • @ChrisDrew `Small` isn't optional as far as I understood. The semantics of an optional doesn't fit well here. My two cents. – skypjack Jul 26 '17 at 17:47
  • Personally, I think the semantics of `std::optional` fits as well as a nullable smart pointer and has the benefit of not using dynamic memory. – Chris Drew Jul 27 '17 at 10:31
  • 2
    In general, `storage` might not be correctly aligned for `Small`. You should use `std::aligned_storage` – M.M Mar 11 '18 at 19:58
0

The order of destructor calls cannot be changed. The proper way to design this is that Small performs its own cleanup.

If you cannot change Small then you could make a class SmallWrapper that contains a Small and also can perform the required cleanup.

The standard containers std::optional or std::unique_ptr or std::shared_ptr might suffice for this purpose.

M.M
  • 138,810
  • 21
  • 208
  • 365