Map Close method to destructor when implementing IClosable if the Close method isn't implemented by the user

[jaigak]

Today if you implement IClosable but forget to implement the Close method, C++/WinRT will not map the call to the destructor. It would be better if C++/WinRT maps the call to the destructor when Close isn't implemented

[sylveon]

This will lead to UB, since you're supposed to still be able to use the object (but maybe not in an useful way) after a call to Close. Notably, any call to AddRef or Release would now use uninitialized memory, and once the ref count reaches 0, the destructor would be called a second time.

UB-by-default behavior isn't good.

[jaigak]

Right but C++/CX seem to does it. Does it use some kind of an extension?

[sylveon]

C++/CX being a language extension, it twists some language rules to allow that to happen. Note that it still says that accessing any member after doing delete t or t.Close() is UB, so I'd argue it's still bad behavior.

[oldnewthing]

In C++/CX, the destructor very strange. It is more like a C# finalizer than a true C++/CX destructor. In particular, "delete"-ing a C++/CX ref pointer does not destroy the object.

This has made a lot of people very confused and been widely regarded as a bad move.

// C++/CX
DataReader^ reader = ref new DataReader();
delete reader; // does not actually destroy the DataReader
auto order = reader->ByteOrder; // Not UAF! Still works!¹

In C++/CX, when you write

ref class Something
{
    ~Something() { /* destructor body */ }
}

it gets transformed to something like this:

class Something : IClosable
{
  ~Something() { Close(); }
  void Close() {
    if (!m_closed) {
        m_closed = true;
        /* destructor body */
    }    
  }

  bool m_closed = false;
};

To complement this secret transforming, delete reader is transformed to reader->Close().

There's an even weirder rule that kicks in if you declare DataReader reader without the hat. It is not worth going into.

C++/WinRT is standard C++, and in standard C++, running the destructor ends the lifetime of the object. It would be incorrect to map Close() to the destructor because the object lifetime does not end when you call Close().

¹ It is up to each class to determine what works and what doesn't work after being closed. That's why the documentation says that the behavior is undefined, although it's misusing the term UB here. It really should say that it is implementation-defined, and the implementation is permitted to raise an ObjectDisposedException if you use an object after closing it. DataReader for example allows you to get and set properties after closing, but raises ObjectDisposedException if you call any methods.