Re: Dialog based application and generated OnPaint for the dialog class
Good points. I'd be more worried about it taking time it doesn't need to
take, but that is not likely the case here either.
I have an application that never uses a document (I guess it could, but it
was so simple it didn't really need to persist any data), but I left it
there anyway because I didn't want to cause problems. I can't imagine that I
would have saved any perceivable space.
I recently did a program where I statically linked MFC and it added about
150K to the size of the program (compared with not statically linking it).
Since I no longer have to distribute software on 360K floppies I wasn't too
worried about the extra size and it made me wonder why people think MFC is
so "bloated". 150K seems a fair price for the functionality.
Tom
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:ajvrb3tr7e4qnqn9pikajqsr0o50ho9fpq@4ax.com...
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).