Why does wxWidgets not leak Frames?

Question

I'm trying to learn wxWidgets, but I'm stuck on a point which I can't find an explanation for anywhere in the documentation. I am trying to understand this minimal wxWidgets program:

#include <wx/wx.h>

class MyApp : public wxApp
{
    virtual bool OnInit();
};

IMPLEMENT_APP(MyApp)

bool MyApp::OnInit()
{
    wxFrame *frame = new wxFrame(NULL, -1, _("Hello World"), wxPoint(50, 50),
                                  wxSize(450, 350));       
    frame->Show(true);
    return true;
}

Specifically, why is it that frame does not leak? When does it get released and whose responsibility is is? In a normal program a pointer that does not get passed to anything and that goes out of scope without being deleted is almost certainly a leak, but apparently this is not so in wxWidgets.

It might register itself with the framework, to be deleted when the window is closed. — Bo Persson, Jun 09 '11 at 06:40
@Xeo This code comes directly from the example code in the documentation (cut down for emphasis). I can't find any example code in which the frame is deleted so I am assuming that it does get deleted somehow. At the same time I can't find anything in the documentation that specifically says that the Frame will be deleted, so I'm hoping someone on SO has the full story. — Mankarse, Jun 09 '11 at 06:44
Augh- I found the full answer [here](http://docs.wxwidgets.org/trunk/overview_windowdeletion.html). — Mankarse, Jun 09 '11 at 07:12

score 6 · Accepted Answer · answered Jan 12 '12 at 04:30

6

Cleanup is discussed here: http://docs.wxwidgets.org/2.9.2/overview_windowdeletion.html

answered Jan 12 '12 at 04:30

Arafangion

11,517
1
40
72

score 3 · Answer 2 · answered Jun 09 '11 at 06:43

3

See the note in the Hello World example on the wxWidgets wiki:

http://wiki.wxwidgets.org/Hello_World

"You could be wondering why the frame variable isn't deleted anywhere. By setting the frame as the top window of the application, the application will delete the frame for us (for a more in-depth explanation, see Avoiding Memory Leaks)."

However, the code you posted doesn't call SetTopWindow() the way the code from the wiki does. So I imagine it would leak.

answered Jun 09 '11 at 06:43

HostileFork says dont trust SE

32,904
11
98
167

I dont think this is actually correct. [The Documentation](http://docs.wxwidgets.org/trunk/classwx_app.html#39033ec4c79bc1871c91ada7b31941e6) states that "You don't have to set the top window; it is only a convenience". I just found the documentation for [wxTopLevelWindow](http://docs.wxwidgets.org/trunk/classwx_top_level_window.html) that states that "instances of wxTopLevelWindow are managed by wxWidgets in the internal top level window list". – Mankarse Jun 09 '11 at 07:09
Okay, well it's the top-level-ness that makes it not leak...and if it's implicit that all wxFrames are top-level then I guess it is. Qt doesn't work that way, BTW. I'll chip in that if you haven't tried Qt, it's architected (and documented) much better than wxWidgets: http://doc.qt.nokia.com/latest/tutorials-widgets-toplevel.html – HostileFork says dont trust SE Jun 09 '11 at 15:43
I've looked at QT, but its [lack of exception safety](http://developer.qt.nokia.com/doc/qt-4.8/exceptionsafety.html) makes me consider it unsuitable for any application for which correctness is a high priority. – Mankarse Jan 12 '12 at 08:40
What property of wxWidgets is exception-safe that is not safe in Qt? From the wxWidgets FAQ: *"wxWidgets library itself is unfortunately not exception-safe (as its initial version predates, by far, the addition of the exceptions to the C++ language)."* http://www.wxwidgets.org/docs/faqgen.htm#exceptions – HostileFork says dont trust SE Jan 13 '12 at 14:21
I don't really like wxWidgets either. – Mankarse Jan 14 '12 at 06:00
Exceptions and GUI are always going to be a bit difficult because of the callbacks. In a system that had memory-mapped file access that needed to trap writes, I traced a hard-to-find bug to a callback from the scroll wheel handler that wasn't properly wrapped with the exception handler. Separating the GUI from the critical data app is fairly prudent...web browsers even isolate tabs in their own processes these days... – HostileFork says dont trust SE Jan 14 '12 at 07:29

score -1 · Answer 3 · answered Jun 09 '11 at 14:15

A memory leak occurs when a program keeps on allocating memory and never releasing it. Eventually such a program will run out of new memory to allocate and stop.

MyApp::OnInit() is called once at program start up. The memory for frame is allocated once and kept allocated until the program ends, which is exactly what you need to happen. There is no memory leak because the new wxFrame in OnInit() is called just once.

It may well be that wxWidgets registers the wxFrame pointer and looks after tidying it up if the program shuts down gracefully. That would be nice, but makes no practical difference.

There is a practical difference. First of all, if you just let the program end with an outstanding dynamic object...the destructor never runs. Even if you have a trivial destructor, you still have a problem in that it's hard to tell a "purposeful" memory leak of this sort from an "accidental" one if you're using Valgrind or another reporting tool. — HostileFork says dont trust SE, Jun 09 '11 at 15:50

Why does wxWidgets not leak Frames?

3 Answers3