lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Overriding wx member functions


From: Greg Chicares
Subject: Re: [lmi] Overriding wx member functions
Date: Sat, 25 Mar 2006 23:18:14 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

On 2005-11-27 14:58 UTC, Vadim Zeitlin wrote:
> On Sat, 26 Nov 2005 23:40:47 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> 1. Is there any general rule that indicates whether the base-class
> GC> member should be called explicitly in a derived-class override, and,
> GC> if so, whether it should be called at the beginning of the overriding
> GC> function or at the end?
> 
>  No, unfortunately not. You can only hope that it is mentioned in the
> documentation or in the base class comments but even this is not always the
> case. The usual -- but by no means 100% -- rule is that you do have to call
> the base class virtual function.

I'm struggling with wxApp::OnInit(). I override it because one
important customer, probably the biggest one, emphatically wants
a single binary that acts like either a GUI app or a console app
depending on the contents of an external file.

I don't want wx's command-line parser. I use GNU getopt instead;
I use it for separate command-line-only builds of lmi, too. To
avoid using wx's, I override OnInit() and don't call the base-
class version, which is what I think the documentation suggests.

Now, wxAppConsole::OnInit() currently (20050323 cvs) just calls
the command-line parser, but that could change in a later version.
To be sure, I guess I'd have to read each new version's sources,
for wxAppConsole, wxAppBase, and the gtk and msw versions of
wxApp. That sounds like a lot of deferred maintenance.

Or I could look for a configure option to undefine
  wxUSE_CMDLINE_PARSER
but then my wx build may not work for other applications that use
the wx parser--some interesting sample program, for example. And
manipulating the library's configury seems like the wrong way to
change runtime behavior in a particular app.

Is there a better way?

Further questions arise wrt wxApp::OnExit(), which is called iff
OnInit() returns true. My OnInit() may return either true or false
depending on whether that important customer selects console or
GUI behavior. Today, at least, wxAppConsole::OnExit() deletes the
wxConfig object, which I create in the ctor and want to delete
unconditionally, after saving file history. I've been deleting it
with an OnExit() override, but now I review the code and surmise
that this function doesn't get called for the console behavior.
So maybe I should implement an OnExit() override that does nothing
and put OnExit() behavior in the dtor.

Am I missing some clean way to do all of this?

I know that a "real" OS is supposed to clean up any memory leaks
when a program exits, but I'm not sure msw really does that, and
our big customer might run our program hundreds of times a day.
Besides, zero leaks should be an attainable goal, and it's one
I can test automatically.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]