Pointers to member functions...

[User Name:]

class Window{
    public:
        Message Msg;

        Window(HINSTANCE hInstance,
                LPSTR lpstrTitle,
                HWND hwndParent,
                HBRUSH hbrBackground,
                DWORD dwStyle,
                DWORD dwExStyle,
                int width,
                int height,
                int x,
                int y);
    private:
        LRESULT CALLBACK WindowProcedure(HWND, UINT, WPARAM, LPARAM);
};

I want to "wincl.lpfnWndProc = &WindowProcedue", but I'm getting really complicated errors that I kinda understand. They seem to say what I'm doing is forbidden, is there another way to do it?(I Googled, found this: [33] Pointers to member functions ..Updated!.., C++ FAQ Lite, but I really don't like that solution. )

[Elysia]

There is no easy solution to that one (if there were a general solution to a callback function that takes N arguments, I'd love to hear it).
You simply have to do what the link says. Blame C for that.
The reason is that the member functions are coupled to an instance. So if you pass a pointer to your member function, which instance of the function will it call?

Btw, I have also implemented a simple Window class. You may have a look at it and expand on it if you wish:

#ifndef WINDOWS_H_20100708_1707
#define WINDOWS_H_20100708_1707

#include <Windows.h>
#include "GetInstance.h"
#include <assert.h>
#include <boost/thread.hpp>

namespace Stuff
{
	namespace Window
	{
		typedef LRESULT (CALLBACK WndProc_t)(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
		class CWindow
		{
		protected:
			HWND m_hWnd;

		public:
			// WndProc is a pointer to WndProc procedure. MUST call CWindow::WindowProc!
			void Initialize(WndProc_t* WndProc)
			{
				// TODO: Place code here.
				WNDCLASSEXW wcex = {};

				wcex.cbSize = sizeof(WNDCLASSEX);

				wcex.style			= CS_HREDRAW | CS_VREDRAW;
				wcex.lpfnWndProc	= WndProc;
				wcex.cbClsExtra		= 0;
				wcex.cbWndExtra		= 0;
				wcex.hInstance		= Stuff::Handle::GetAppInstance();
				wcex.hIcon			= 0;
				wcex.hCursor		= 0;
				wcex.hbrBackground	= 0;
				wcex.lpszMenuName	= nullptr;
				wcex.lpszClassName	= L"Callback window";
				wcex.hIconSm		= 0;

				assert(RegisterClassExW(&wcex));
				// Perform application initialization:

				m_hWnd = CreateWindowW(L"Callback window", L"", WS_OVERLAPPEDWINDOW,
					CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, nullptr, nullptr, Stuff::Handle::GetAppInstance(), nullptr);

				assert(m_hWnd);

				// Main message loop:
				boost::thread(&CWindow::MessageLoop, this);
			}

		protected:
			void MessageLoop()
			{
				MSG msg;
				while (GetMessage(&msg, nullptr, 0, 0))
				{
					TranslateMessage(&msg);
					DispatchMessage(&msg);
				}
			}

		public:
			LRESULT CALLBACK WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
			{
				switch (message)
				{
					case WM_DESTROY:
						PostQuitMessage(0);
						break;
					default:
						return DefWindowProc(hWnd, message, wParam, lParam);
				}
				return 0;
			}

			~CWindow() { DestroyWindow(m_hWnd); }

			HWND GetHwnd() { return m_hWnd; }
		};
	}
}

#endif

[User Name:]

> (if there were a general solution to a callback function that takes N arguments, I'd love to hear it)
Huh? What are you talking about?

It works now. I just added static and it compiled.

P.S. You really need to change your avatar back. Every time I see it, with your name, it confuses me.

[Elysia]

What I mean is this:
Consider a slew of functions, F1 ... Fn whose callback functions takes only one parameter - void*. Essentially they forward this argument to their callback functions. We could then generalize this to:

template<typename T> struct SCallback
{
    T Functor;
}

template<typename T> SCallback<T>* make_callback(T Functor)
{
    return new SCallback<T>(Functor);
}

template<typename T> void Callback(void* arg)
{
    T* pArg = static_cast<T*>(arg);
    pArg->Functor();
    delete pArg;
}

class foo
{
    void bar1() 
    {
        auto pArgs = make_callback([]() { this->MyCallback() }) );
        F1(&Callback<decltype(pArgs)>, pArgs);
    }
    // ...
    void barN() 
    {
        auto pArgs = make_callback([]() { this->MyCallback() }) );
        FN(&Callback<decltype(pArgs)>, pArgs);
    }

    void MyCallback();
};

I use one function as a callback function to ALL the functions F1 ... FN by passing a simple argument. Saves a function for each callback.

But what if the callback functions for F1 .. FN doesn't take 1 parameter? They this solution won't work.

And no, I like this new avatar The old was one was getting old.

[adeyblue]

Btw, I have also implemented a simple Window class. You may have a look at it and expand on it if you wish:

It'll need fixing before it gets expanded upon. For starters, writing effectual code in an assert is just wrong; the message pump has to run in the same thread the window was created on; and CloseWindow only minimizes the window, you want DestroyWindow. You're also missing the intervening * between the calling convention and the name in your Wndproc_t typedef.

[phantomotap]

the message pump has to run in the same thread the window was created on

No, it doesn't. It is possible to separate them. It just isn't worth while.

That said, he isn't doing that; what he is doing will probably fail. He should be doing what you said.

You're also missing the intervening * between the calling convention and the name in your Wndproc_t typedef.

Not really, look at the way he is using the `typedef'.

Soma

[Elysia]

It'll need fixing before it gets expanded upon.

Aye, it is by no means perfect, and I'm not that good on Windows stuff. I usually just use a framework. But for times when I can't/don't want to use MFC, we have to do it the old fashioned way.
So without further ado, I shall comment upon, reflect and fix the feedback.

For starters, writing effectual code in an assert is just wrong;

I am not sure what you mean. Just putting an assert(hWnd) is a bad idea, certainly. I am aware of that. Ideally it would throw an exception if it fails, but I haven't implemented any exception handling in the class really because it's still unfinished and so few components still use it, so I can get away with it.

the message pump has to run in the same thread the window was created on;

May you consider expanding upon the why? I don't claim it works perfectly or is right, but at least right now it works (but we all know that work is not the same as right).

and CloseWindow only minimizes the window, you want DestroyWindow.

Good point. I've fixed that locally. Thanks.

You're also missing the intervening * between the calling convention and the name in your Wndproc_t typedef.

And I didn't, as Soma pointed out. It's a function type, not a function pointer type. So I create a pointer to the type, hence a function pointer. Nifty and easily more readable IMO.

[cyberfish]

I am not sure what you mean. Just putting an assert(hWnd) is a bad idea, certainly. I am aware of that. Ideally it would throw an exception if it fails, but I haven't implemented any exception handling in the class really because it's still unfinished and so few components still use it, so I can get away with it.

asserts with side effects are bad because if you disable asserts, the expression won't be run at all.

assert(hWnd) is fine, but not assert(RegisterClassExW(&wcex)), assuming RegisterClassExW does something.

int rtn = RegisterClassExW(&wcex);

assert(rtn && "Some error message");

seems to be pretty standard.

[Elysia]

Yeah, I'm aware of that. I could put the whole create window in an assert, but didn't for the outlined reasons.