object was a good place for variables needing app scope.
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
See below...
On Sat, 11 Oct 2008 12:03:03 -0700, "Mark Salsbery [MVP]"
<MarkSalsbery[MVP]@newsgroup.nospam> wrote:
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:2ae1f41nhahfp8pf4ooged35vku7402st0@4ax.com...
CWnd is any generic window class, and therefore all windows in your app
derive from CWnd.
CWinApp is nearly totally useless except in very rare cases. For
example,
you would never
put any variables in your CWinApp-derived class that were not used
solely
and exclusively
by your CWinApp-derived class. Other than the OnIdle handler,
InitInstance, and
ExitInstance (rarely), your CWinApp class rarely has anything to do with
your app. The
generic CWinApp class is often used to hold utility functions.
Useless? In a normal MFC app, it represents the initial thread, provides
the execution entry point into the MFC classes (by representing the
initial
thread), and provides a message loop.
****
Yes, but in terms of your actual programming, it is useless. It is pure
framework, and
serves critical purposes in the framework, but it is useless in your main
frame, your
views, your documents, and your dialogs. It's role is simply to provide,
as you describe,
the initial thread handler, the initial execution point (the virtual
method InitInstance),
corresponding cleanup when appropriate, and the message loop. Those are
all critical
*functions*, but their existence is preordained in that module. Adding
other things to
that module that have nothing to do with the aforementioned roles, just
tossing variables
in willy-nilly because someone once said "global variables are bad" and
pretending that
making them class variables of your CWinApp-derived class solves the
problem is wrong.
This is actually poorer practice than having global variables (two of my
thesis advisors
co-authored the paper titled "Global Variables Considered Harmful")
[http://portal.acm.org/citation.cfm?id=953355] so when I say "I come from
the school of
global variables considered harmful" I mean it literally). But creating
variables in the
CWinApp class is actually *more* destructive than the classic global
variables for the
reasons I describe below. There is no rationale that justifies tossing
variables into the
CWinApp-derived class unless they are used by your CWinApp-derived class.
****
Where do YOU put data that is application wide in scope (not specific to a
given window)??
****
Where they belong: as global variables. There might be one or two of
these. Putting them
in the CWinApp-derived class is silly. It means that every module that
uses any "global"
variable requires the header file that reveals ALL global variables, and
ANY change in the
CWinApp-derived class triggers massive recompilations. It introduces
gratuitous
dependencies and interdependencies that make no sense. And potentially
any file that
includes the CWinApp-derived header can access or modify any variable.
If you create a single global variable, create a header file for it, and
include that
header file ONLY in the modules that require it, you have introduced no
incidental or
irrelevant dependencies; only the modules that use it (and there are very
few in most real
programs) ever include it, and it is also clear just by searching for the
#includes
exactly which modules actually care about it.
If you are afraid to declare a .cpp file that has two lines
#include "whatever.h"
Whatever variablename;
and declare a header file
#pragma once
extern Whatever variablename;
then you need to rethink what it means to do development. There's nothing
wrong with
having a single module that defines a single variable and a header file
that gives access
to it. It simply doesn't make sense to include some "blanket" header file
that includes
some framework class into which random unrelated variables are tossed.
The use of gratuitous variables in header files actually reduces
productivity. I was an
advisor to a student whose PhD thesis demonstrates this, with
substantiating data, beyond
any doubt [http://portal.acm.org/citation.cfm?id=916690]. She shows that
if you introduce
gratuitous dependencies, your development time is longer. Since there is
no reason other
than sheer laziness to introduce such dependencies, they make no sense
(I'd been saying
this for years, which is why I was chosen to serve on her committee, and
while I was no
longer able to be a principle advisor to her, I was the outside member of
the committee).
[Folks at CMU say they are in the process of making every PhD dissertation
in the history
of the department be available online, and hope to complete that project
and make them
available in the near future. It has been actively underway for a while
now, so soon I
may be able to give a full-text citation]
A variable should have its scope limited to just those modules that use
it. If its
lifetime is global, that's one thing, but making all global variables (or
logically global
variables) visible to all modules at all times makes no sense whatsoever.
Therefore, it
has never made sense from a structural viewpoint to put anything in the
CWinApp-derived
class that is not used by the CWinApp-derived class.
joe
****
(I'm talking as designed here, not how MFC could have been designed)
Mark
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm