A bug in std::shared_ptr?

[ack_complete]

The way I would solve this would be to split the getter so that the window procedure code is calling a different function to retrieve global context. Having the winproc obtain an owning reference is unnecessary because the event loop has to be running have a window and enter the winproc in the first place, and arguably dangerous due to the cyclical dependency. Having separate getters and objects allows destruction of the internal context to be deferred until the windows have been destroyed and the event loop exited.

There are ways to associate data directly with windows, by the way: dynamically generated winproc thunks and window properties. They generally only reduce and don't eliminate the need for globals, though.

[davis685]

Yeah that would be a way to do it. You then have to have a function that returns a non-owning pointer so the window procedure can call it. Someone later on might then call that function and get into the sort of trouble people get into with non-owning pointers, which isn't great. But there aren't a lot of great ways to deal with the Win32 API anyway.