Re: Dialog based application and generated OnPaint for the dialog class

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

The problem is that some of this code is required if you run on older platforms.

But given that whether you statically or dynamically link MFC to your app, the size of the
MFC library is so massive that the few bytes required for this code make no noticeable
impact, it seems a waste of time.

On the whole, we are no longer programming PDP-11s, and there are real problems worth
worryng about. Code size is no longer one of them. So it is not worth worrying about.
(On the other hand, data size can kill you. Data size, yes, worry about that. And then
worry about paging. ANd if there is lots of array processing, worry about cache hits.
Those worries buy you orders of magnitude performance improvement. There is no measurable
performance improvement in removing the OnPaint handler in a dialog app).

I once had a client who spent massive amounts of effort to remove the CDocument class from
their apps because "we don't have any documents", by which they meant "we don't write out
a file". Of course, most of doc/view logic broke. They had spent months trying to fix
things up so that it wouldn't crash in some unpleasant way due to access faults caused by
attempts to access the now non-existent document. So I finally asked them if they had a
genuine number for the cost of removing this code. They gave me an estimate, about 50
hours as I recall. I said "multiply this by twice the hourly salary of the programmer who
worked on it." [the number was large, several thousand dollars] "Now tell me *precisely*
why spending this number of dollars generated any benefit for the company. You delayed
product delivery, your product doesn't actually work right..." [which is why I had been
called in] "...which is hurting your credibility with your customers, and you have made no
measurable gain in code size. Why did you do it?" Answer "We didn't need the class so it
seemed to make sense to remove it". I put this sort of effort in the "irresponsibly
stupid" category of activities--expending massive effort to solve nonexistent problems or
problems created by extremely poor judgment. Actually, they DID have a document. It
turns out the "document" was virtual, and existed at the end of a serial cable, in an
embedded system. So I put the document back, moved the communications code from the view
to the document, put the data returned from the controller in the document, and we
accomplished two goals: the program actually worked reliably, and we were able to now have
two views (a "control view" and a "graph view", which was their other problem I was
supposed to solve) on the embedded controller. I was able to accomplish everything except
the graphing in substantially less time than they had spent removing the document class;
the graphing was fairly complex and took another week before we were all happy with the
information displayed.

There are places to expend effort; the key is to identify the places that have meaningful
payoff. If it doesn't have a payoff, don't even worry about it. There are real problems
to worry about.
joe
On Tue, 7 Aug 2007 21:48:03 -0700, "Tom Serface" <tom.nospam@xxxxxxxxxxxxx> wrote:

Yeah, but it's got to beg the question about how much other "insignificant"
stuff has accumulated in there and if it might add up to "more significant"
if all added together. Don't know.

Tom

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:av8ib3d8lhjc1gh8cflidsl0c3qgcbmcd9@xxxxxxxxxx
Ignore the code. It is generated by the framework, it works, there is no
need to ever
look at it. I've safely ignored this code for years, and the right thing
always happens,
so don't worry about it in the slightest. Probably 80% of my apps are
dialog-based, and I
never touch this code. I'm not even sure it does anything any longer, but
it just isn't
worth worrying about.n It doesn't even make sense to consider "removing
it". It takes
virtually no space, it is totally harmless, and there is no justification
for considering
removing it. It just doesn't matter. Certainly it doesn't matter in the
slightest in
terms of code size.
joe
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Sending Outlook E-mail via VB6
    ... The Merg ... Today's problems don't worry me, ... I am using VB6-SP6 to develop and app with an Access DB backend. ... environment that uses MS Exchange/MS Outlook. ...
    (microsoft.public.vb.general.discussion)
  • Re: Lisp Application Server
    ... The base image is running. ... A request to start an app is made. ... runtime forks, then loads the app. ... I suppose the CLR doesn't have to worry ...
    (comp.lang.lisp)
  • Re: Clone public component in CE 6.0
    ... If this is tricky in you app, you can also write a very simple little app to ... and do not have to worry about QFE's. ... The easyest way of doing this is by not starting explorer at all. ... _OEMINCPATH into the sources file, ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Lisp Application Server
    ... way that Java VMs run byte code? ... The runtime forks, then loads the app. ... I suppose the CLR doesn't have to worry about things like modifiable types. ... As far as memory is concerned, I think it depends on how nice your applications and libraries are. ...
    (comp.lang.lisp)
  • Re: How to keep only 5 most recent files in certain folder
    ... > files is currently being written to by another app. ... I worry about that with every program I write. ... As a UNIX ... support engineer one of the frequent calls my team receives is "I ...
    (comp.unix.programmer)