Quote Originally Posted by mkuhac
I agree that using machine code stored as variable(s) is not portable but there is absolutely no overhead.
Let me tell you what overhead is:

1. create a map of handles and 'this' pointers
2. jump into static / global function
3. during WM_CREATE or similar message insert a pair of 'this' and hWnd into map (internally implemented as dynamic heap allocation which is slow)
4. during any other message lookup the map to find 'this' pointer that is associated with current hWnd
5. when obtained 'this' call appropriate member function
6. when a window is destroyed remove this-hwnd pair from the map

It is overhead because :
1. it jumps from function to function (slow)
2. it uses heap for dynamic allocation (slow)
3. uses too many processor instuctions

Using windows properties is equally slow because 'properties' mechanism is internally implemented as a map.
I already pointed out in my last post what my opinion about "perfomance" and "slow" is. The point still stands. "Slow" and "performance" related matters to moderate extent are of NO relevance.

Run a loop with looking up 1000000 window objects from their handles using window properties, and see how long it takes. An average application operates with 10 windows at most at a time, so I dont see any specific reason to use assembler to speed up the application in this way. Optimise the logic first, I say.