Self-Deleting Objects with Inheritance

[Paul McKenzie]

A very common example usage of my class would be a button that brings up the Settings form. i.e:

void btn_Settings(Object *sender, EventArgs *e)
{
	FormSetup fs(L"Settings", 600, 400);
	fs.Events.Create = fSettings_Create;

	Form *fSettings = new Form(fs);
	
	// After the next line Show() this function finishes and the shared_ptr goes out of scope which deletes my object.
	// As soon as I move the mouse over the Settings window my program crashes because of an Access Violation when Windows tries calling Form::WndProc.

	// std::shared_ptr<Form> fSettings(new Form(fs));	// Deletes Form too soon!

	fSettings->Show();
};

Of course it will delete it too soon. This has nothing to do with shared_ptr, but with C++. You create a local variable, so what happens to local variables when a function returns?

You need to have a high-level design that properly implements your idea of how long of a lifetime each one of your objects will have. If you declare a local variable, then its lifetime is local to that scope. If you declare a class member, its lifetime is determined by the lifetime of the object, etc.

Regards,

Paul McKenzie

[Paul McKenzie]

I just spent a while looking up as much RAII info as I could find, and then implemented an example of the std::shared_ptr. Though, this failed because the class isn't ready to be destroyed when the reference count is 0. Effectively, once the Form is created, for most cases, the only external reference pointer to the form is passed via WNDCLASSEX.lpfnWndProc parameter. So interaction to the Form is via it's WndProc method. It's not until this method receives WM_DESTROY does the object need to be destroyed. I'm not sure a pointer class (except where I mentioned maybe a good GC) could determine such a case, and therefore I figured I have to implement my own destruction of the object.

The problem in general (forget about smart pointers for the moment) is that you're trying to fit a non-object oriented paradigm such as the Windows API to an object-oriented paradigm. Unfortunately, your approach is very rudimentary and needs to be addressed in a better way.

The proper way to handle this comes in many forms. MFC and OWL are two examples.

You also have this:
http://www.relisoft.com/rswl.html

To the above: Their link to "auto_vector" may be outdated, as you now have shared_ptr that doesn't have the drawbacks of auto_ptr.

Then there is this standby (which is still relevant):
http://www.dilascia.com/wpp.htm

Each one of the examples above have their own approaches as to how to wrap the Windows API in a more object-oriented fashion.

Regards,

Paul McKenzie

[OReubens]

I'm not sure what you're getting at? I'm trying to discuss a means of which I can appropriately have the object self-delete itself. I know I could expose methods and call delete, but it's redundant. Right now, their is no clear-method I've seen to delete the Form object. It only works in WinMain() because that remains in scope throughout the entirety of the program. Even though, if I made it load a splash window or something, I would like to have that object delete sooner that later.

What I'm getting at is that you're looking at things the wrong way. You're trying to make c++ respond to things that really have nothing to do with C++ at all (i.e. responding to WM_DESTROY).

While there certainly is a correlation between the two.. your form destroys, so you want to clean up the objects related to that destroy. This isn't something you can solve purely in C++.

Yes, you can get help from C++ features such as smart pointers, but the event based nature of how windows works and the C++ world need some handshaking to work together, and that handshaking you have to code explicitely, and it'll involve a good understanding of how windows works and what happens in windows that's related to that WM_DESTROY of the form.

For starters, when a form destroys, all it's child controls will be destroyed also, so all those child controls will equally receive a WM_DESTROY (assuming they're actual windows). If you created your own window manager, and only have your form and everything else is just painted on top, then you'll have something similar inside your own window manager. It's this diestruction of the child control that should be the trigger to destroy the matching c++ object.
This "pairing" of a Windows window (handle) and a C++ object instance (pointer) is often referred to as "subclassing" (typically in MFC because the function names are named that way, even though it has no relation to the "sub classing" in c++). And it either involves storing the pointer to the C++ object instance in the windows window, or you managing a container with a window handle and a pointer.
when you get a destroy (or detach) you use the handle to find your object pointer and delete the pointer.

I'm oversimplyfying here, there's a lot of extra rules and details to take into consideration. All I can say it that creating your own C++ framework isn't the easiest of things. There's a reason why the majority of C++ windows projects are written in one of the handfull of premade c++ frameworks and not everyone rolls their own.

[FrOzeN89]

Thanks for the replies!

I've decided for the time being that I'm going to put this project design on hold, and focus on reading up on design patterns and looking into well-established wrappers such as MFC.