Is it safe to deallocate oneself on WM_NCDESTROY? - c++

Question

Consider the following code snippet:
// MyWindow.h
struct MyWindow
{
LRESULT CALLBACK myWindowProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam);
static LRESULT CALLBACK myWindowProcWrapper(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam);
};
extern MyWindow *windowPtr; // windowPtr is initialized on startup using raw new
// MyWindow.cpp
MyWindow *windowPtr = 0;
LRESULT CALLBACK MyWindow::myWindowProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch (msg)
{
case WM_NCDESTROY:
delete windowPtr;
break;
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
LRESULT CALLBACK MyWindow::myWindowProcWrapper(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
return windowPtr->myWindowProc(hwnd, msg, wParam, lParam);
}
The question is whether the given code snippet is safe as written.
Basically, MyWindow is the class for a window created with the WinAPI. I need to do some final cleanup when the window is destroyed.
Notice that the instance of MyWindow, windowPtr, is created using a raw new. I have to delete the instance somewhere in a member function, so I delete the reference to the object itself from within a member function.
The code relies on the assumption that WM_NCDESTROY is the last message ever received by that window.
So the questions are as follows:
Is it safe to assume that WM_NCDESTROY is always the last message a window receives and to perform final cleanup there?
Is the listed code safe? If not, under what conditions could it break?
Remark: I'm only interested in whether the code is technically safe, not if it is good practice to use a raw new and/or global variables. I have some good reasons for this implementation.

Answer 1

It is not explicitly documented, that WM_NCDESTROY is the final message a window receives. If you read in between the lines, you can deduce this information, though.
The documentation for WM_NCDESTROY contains the following remark:
This message frees any memory internally allocated for the window.
Window Features: Window Destruction outlines the consequences of this:
When a window is destroyed, the system [...] removes any internal data associated with the window. This invalidates the window handle, which can no longer be used by the application.
Putting those together, destroying a window invalidates its window handle. Once the WM_NCDESTROY message handler has run to completion, the window handle is no longer valid. An invalid window handle no longer receives any messages.
Your implementation is thus safe.
It is doubtful that any of these rules will change in the future (with so many applications relying on WM_NCDESTROY being the final message), but if you want to be prepared, you might want to consider placing a windowPtr = nullptr; statement following delete windowPtr;. Doing so ensures, that your application fails in a predictable way, in case it receives a message after the MyWindow instance has been disposed.

Answer 2

yes, WM_NCDESTROY is the last message sended to WindowProc (how minimum now).
but direct, unconditionally call delete this in myWindowProc can be unsafe in complex case and produce very bad error (because hard to found)
you not take to account that myWindowProc can be called recursively.
let us first consider a simple version:
case WM_KEYDOWN:
if (wParam == VK_ESCAPE)
{
DestroyWindow(hwnd);
}
so we destroy window on ESCAPE pressed. in this case myWindowProc will be called recursively with WM_NCDESTROY where we delete this and then we return to up level myWindowProc (for WM_KEYDOWN ). but at this point this already destroyed and invalid. so we must not more access any members fields or virtual functions. good if we call direct DefWindowProc in the end of own WindowProc. but what be if say our class implement and call virtual LRESULT DefWinProc(..) for allow overwrite DefWindowProc behaviour ? (say to DefMDIChildProc ) ?
now more complex case - assume you implement some child control. based on WM_SOMETHING_1 you set WM_NOTIFY_SOMETHING_1 to parent (via SendMessage ). and parent decide call DestrowWindow when handle this notify (for self, and as result for all childs). so internally your call delete this and when you return from SendMessage(..WM_NOTIFY_SOMETHING_1..) your this already will be deleted, but you will not even know about this.
access this after it will be deleted real in complex windows case, and if we modify some member data - can be not direct crash(which is good for detection) but heap corruption, which will manifest itself later and this is very hard to detect.
however for this exist 100% correct solution, which will be work even if WM_NCDESTROY will be not final message for window.
we must not use global MyWindow *windowPtr but assign it to window data via GWLP_USERDATA and remove on WM_NCDESTROY . and call myWindowProc only when GetWindowLongPtr(hwnd, GWLP_USERDATA) return not 0 . in this case even if will some WM_* message after WM_NCDESTROY - static myWindowProcWrapper not call myWindowProc and we must use reference counting for MyWindow class :
call AddRef(); before SetWindowLongPtrW(hwnd, GWLP_USERDATA,(LONG_PTR)windowPtr);
call Release(); after SetWindowLongPtrW(hwnd, GWLP_USERDATA, 0);
wrap windowPtr->myWindowProc(hwnd, msg, wParam, lParam) in
AddRef(); Release();
call delete this only from Release and make ~MyWindow()
private:
with this rules we can absolute safe access this pointer in myWindowProc at any time and any situation. and not dependening about WM_NCDESTROY is the last message
struct MyWindow
{
private:
PSTR _somedata;
LONG _dwRef;
public:
MyWindow() : _dwRef(1), _somedata(0)
{
}
void AddRef()
{
InterlockedIncrement(&_dwRef);
}
void Release()
{
if (!InterlockedDecrement(&_dwRef)) delete this;
}
static LRESULT CALLBACK myWindowProcWrapper(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
MyWindow *windowPtr;
if (msg == WM_NCCREATE)
{
windowPtr = (MyWindow *)((LPCREATESTRUCT)lParam)->lpCreateParams;
windowPtr->AddRef();
SetWindowLongPtrW(hwnd, GWLP_USERDATA, (LONG_PTR)windowPtr);
}
else
{
windowPtr = (MyWindow *)GetWindowLongPtr(hwnd, GWLP_USERDATA);
}
LRESULT lr;
if (windowPtr)
{
windowPtr->AddRef();
lr = windowPtr->myWindowProc(hwnd, msg, wParam, lParam);
windowPtr->Release();
}
else
{
lr = DefWindowProc(hwnd, msg, wParam, lParam);
}
if (msg == WM_NCDESTROY && windowPtr)
{
SetWindowLongPtrW(hwnd, GWLP_USERDATA, 0);
windowPtr->Release();
}
return lr;
}
protected:
LRESULT CALLBACK myWindowProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
switch (msg)
{
case WM_NCDESTROY:
PostQuitMessage(0);
break;
case WM_KEYDOWN:
if (wParam == VK_ESCAPE)
{
DestroyWindow(hwnd);
DbgPrint("%s\n", _somedata);// bug can be here if not use ref semantic
}
break;
case WM_CREATE:
if (_somedata = new CHAR[64])
{
strcpy(_somedata, "1234567890");
}
break;
}
// bug can be here if not use ref semantic, because myDefWinProc virtual
return myDefWinProc(hwnd, msg, wParam, lParam);
//return DefWindowProc(hwnd, uMsg, wParam, lParam);
}
// for demo only here, not need in simply case
virtual LRESULT myDefWinProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
return DefWindowProc(hwnd, uMsg, wParam, lParam);
}
private:
~MyWindow()
{
if (_somedata) delete _somedata;
}
};
if (MyWindow* p = new MyWindow)
{
CreateWindowEx(0, L"lpszClassName", L"lpWindowName", WS_OVERLAPPEDWINDOW|WS_VISIBLE,
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, HWND_DESKTOP, 0, 0, p);
p->Release();
}

Answer 3

Yes. Self deallocate is safe in WM_NCDESTROY.
But just to be sure your program will not fail under Wine, for example, I'd recommend to set windowPtr to null after delete, and check it before call windowPtr->myWindowProc.
And, ofcause, it must be only window of that wndclass.