Wskaźnik na niestatyczną metodę obiektu.

Ogólnie wygląda OK.

Trzeci parametr tej funkcji nie jest typu long ale LONG_PTR, więc należy rzutować na LONG_PTR, do tego celu najlepiej użyć reinterpret_cast, tak samo z rzutowaniem wyniku GetWindowLongPtr.

Możesz też poczytać o tzw. thunkingu ( czy jak to się odmienia ).
Na kompilatorze od MS thiscall różni się od stdcall tylko tym, że pakuje wskaźnik 'this' do rejestru ECX. Wystarczy więc stworzyć drobny thunk, który poprzez assemblerowe instrukcje wrzuca 'this' do ECX i robi skok do dowolnie wybranej niestatycznej metody. Taki thunk podajesz podczas rejestracji klasy okna i voila :P

Wiki mówi, że GCC zamiast rejestru ECX wrzuca 'thisa' na stos, więc tu by było więcej kombinowania.

Jego celem jest utworzenie wrappera do łatwego tworzenia okna WinAPI, a nie stosowanie 'brudnych' rozwiązań, które we własnych implementacjach można osiągnąć równie dobrze za pomocą eleganckiego _{» standard C++11 ♦} function.

 zwraca obiekt funkcyjny, którego nie da się zrzutować na goły wskaźnik do funkcji, więc nie wiem jak by to miało wyglądać.
Thunking to jedyna opcja żeby uniknąć statycznych metod czy kolekcji i żeby mieć możliwość obsłużenia wszystkich komunikatów łącznie z tymi przychodzącymi przed WM_CREATE. Dodatkowo ma minimalny overhead w postaci zaledwie dwóch(MSVC) instrukcji asm. W tym przypadku moim zdaniem cel uświęca środki i dodatkowo człowiek może się nauczyć trochę niskopoziomowych pierdółek ;)

Nie mam alergii na funkcje statyczne, chodziło po prostu o to aby podczas obsługi komunikatu mieć dostęp do różnych niewątpliwie kiedyś potrzebnych danych bez obracania się w zmiennych globalnych. A moim celem było utworzenie kodu, który będę sobie rozbudowywał do poszczególnych projektów - kontrolki czy rysowanie dodam jak zechcę, w zależności od potrzeby czy nastroju. Po prostu chcę mieć dobrą, prostą i solidną podstawę na to.

Spoko, ja tylko napisałem że istnieją też inne sposoby.
A każdy robi jak mu wygodnie ;)