Question

We’ve inherited large legacy application which is structured roughly like this:

class Application
{
    Foo* m_foo;
    Bar* m_bar;
    Baz* m_baz;

public:

    Foo* getFoo() { return m_foo; }
    Bar* getBar() { return m_bar; }
    Baz* getBaz() { return m_baz; }

    void Init()
    {
        m_foo = new Foo();
        m_bar = new Bar();
        m_baz = new Baz();

        // all of them are singletons, which can call each other
        // whenever they please
        // may have internal threads, open files, acquire
        // network resources, etc.
        SomeManager.Init(this);
        SomeOtherManager.Init(this);
        AnotherManager.Init(this);
        SomeManagerWrapper.Init(this);
        ManagerWrapperHelper.Init(this);
    }

    void Work()
    {
        SomeManagerWrapperHelperWhateverController.Start();

        // it will never finish
    }

    // no destructor, no cleanup
};

All managers once created stay there for the whole application lifetime. The application does not have close or shutdown methods and managers also doesn’t have those. So, the complex inter dependencies are never dealt with.

The question is: if the objects lifetime is tightly coupled with the application lifetime, is it accepted practice to not have cleanup at all? Will the operating system (Windows in our case) be able to cleanup everything (kill threads, close open file handles, sockets, etc.) once the process ends (by ending it in task manager or by calling special functions like ExitProcess, Abort, etc.)? What are possible problems with the above approach?

Or more generic question: are destructors absolutely necessary for global objects (declared outside of main)?

Answer 1

Will the operating system (Windows in our case) be able to cleanup
everything (kill threads, close open file handles, sockets, etc.) once
the process ends (by ending it in task manager or by calling special
functions like ExitProcess, Abort, etc.)? What are possible problems
with the above approach?

As long as your objects aren’t initialising any resources not cleaned up by the operating system, then it doesn’t make any practical difference whether you explicitly clean up or not, as the OS will mop up for you when your process is terminated.

However, if your objects are creating resources which are not cleaned up by the OS then you’ve got a problem and need a destructor or some other explicit clean up code somewhere in your app.

Consider if one of those objects creates sessions on some remote service, like a database for example. Of course, the OS doesn’t magically know that this has been done or how to clean them up when your process dies, so those sessions would remain open until something kills them (the DBMS itself probably, by enforcing some timeout threshold or other). Perhaps not a problem if your app is a tiny user of resources and you’re running on a big infrastructure – but if your app creates and then orphans enough sessions then that resource contention on that remote service might start to become a problem.

if the objects lifetime is tightly coupled with the application
lifetime, is it accepted practice to not have cleanup at all?

That’s a matter of subjective debate. My personal preference is to include the explicit cleanup code and make each object I create personally responsible for cleaning up after itself wherever practical. If application-lifetime objects are ever refactored such that they no longer live for the lifetime of the object, I don’t have to go back and figure out whether I need to add previously-omitted cleanup. I guess for cleanup I’m saying that I generally prefer to lean towards RAII over the more pragmatic YAGNI.