Im trying to create a window manager class to handle the creation of a windows window.

currently I have Main.cpp which is the class that executes when we run the program. then all the managers etc are created and called from the Main class.

I moved the window intialization code from the main class and put it in a WindowManager class but I cant see anything else that I can move to the WindowManager.

I need to keep the WINAPI WinMain function in the Main class because this is where the app runs from.

I tried moving the WindowProc function over to the WindowManager but I get an error that LRESULT cannot be assigned to WNDPROC. Im not sure why this doesnt happen in the main class but does when I move it to another class.


Can anyone explain what you do when you create a window manager?

thanks,

I tried moving the WindowProc function over to the WindowManager but I get an error that LRESULT cannot be assigned to WNDPROC. Im not sure why this doesnt happen in the main class but does when I move it to another class.

Can you show us a little code snippet and the exact error message?
Have you tried to make this callback function a member of your window manager? This will likely fail, since non-static members have different signatures than ordinary C function pointers (c.f.).

For small projects, I just keep the WNDPROC callback global in the cpp file of the manager. It listens to basic messages like WM_RESIZE, WM_SETFOCUS, WM_KILLFOCUS etc and raises respective events. Besides the window manager triggers the initial creation and final destruction of resources, and invokes the update and draw loops.Thats a rather simple approach that I often use for small demo projects.

Ah yes thats it, I was making it a member of the class.

I was just wondering if you could explain how the window manager can trigger the update and draw loops?

do you mean that you would then create an instance of your game class or scene manager within the window manager?

I thought the point of the window manager was just to seperate the window initialization from the everything else?

I do this always a little differently.
The easiest way is to inherit your game class from the window manager; however you usually don’t want to have virtual functions called very frequently. (Nevertheless that would be a nice object-oriented way.)

A little dirtier (in terms of object orientation and reusability) is to make your game global and then call the draw and update loops from the window manager. If I’m aiming for high performance and am just writing some small tech demo I usually go this way. However, I never had my bottleneck on the CPU.

I’d personally never place an instance of the game or something else in the window manager. That simply doesn’t feel right.

Well, I guess that is simply a matter of taste.
I often keep the instance of the game global anyway, so I don’t have to pass “parent” objects into constructors all the time. Of course, I try to keep the usage of the global variable to a minimum. But sometimes it simply doesn’t feel natural to pass an instance of this and that into a constructor just that you have it around later. This makes the construction more complicated I think, since the constructing methods too, need to know the objects that must be passed all the way down (so they have to get them in their constructors as well).

Thanks for taking the time to explain that I understand what you mean.

When you say you dont want to have virtual functions called very frequently do you mean even the derived classes functions which override the virtual function?

Do you know why this is? or know any websites that explain why? I couldnt find any info.

what would be the alternative to this?

Would you simply not make the function virtual and call the base classes function within the derived classes function?, for example.


void DerivedClass::Update()
{
BaseClass::Update();

//etc
}


where baseclass::update is just a normal void function and not virtual

Hi!

When you say you dont want to have virtual functions called very frequently do you mean even the derived classes functions which override the virtual function?

Virtual functions are very powerful and definitely useful, but they require an indirection when calling them. This is a thing one should always have in mind. Let’s assume we have a base class that declares a virtual function (doesn’t matter whether pure or non-pure) and we have a derived class that overrides it. If you have a pointer to the derived class and call the function everything is fine (the execution path is determined as always). But if you have a pointer to the base class and call the function the execution path depends on the type of the object. The compiler can’t resolve this at compile time, so the decision where to jump to is selected at runtime. The entry pointer to the function is then stored in the vtable (which by the why increases the required memory) and must be looked up. With improving caches and branch predictions the cost for this indirection decreased a little; nevertheless, calling virtual functions is always slower than calling non-virtual functions.

Do you know why this is? or know any websites that explain why? I couldnt find any info.

Searching for the keyword "vtable" reveals some more infos.

what would be the alternative to this?

You could use function pointers instead or don't make your code (over) flexible at all.
Personally I don’t mind the extra vtable costs for resource loading code etc. (since it’s usually called just once), but in the rendering and update loop I try to avoid virtual functions. You don’t have to avoid them entirely. Just try to keep them to a minimum. As I’ve mentioned before, I’ve never been seriously CPU bound.

Would you simply not make the function virtual and call the base classes function within the derived classes function?, for example.

void DerivedClass::Update()
{
BaseClass::Update();

//etc
}

where baseclass::update is just a normal void function and not virtual

This compiles but it might not do what you want. If you have a pointer to an instance of BaseClass and call update no vtable indirection will be made, instead BaseClass::Update will be called directly. Even if the pointer BaseClass* points to an instance of DerivedClass!