afximpl.h (Was Re: access to AUX)
dhoward@kset.com
Thursday, January 25, 1996
I've actually found it useful to include "afximpl.h" in all my files. In
fact, the way that I do it is to include the "stdafx.h" in the SRC
directory. The stdafx.h is the standard include file used to compile MFC.
I always include this file at the very beginning as part of my precompiled
header.
Why?
The "stdafx.h" in SRC includes every header file in the MFC universe,
documented or undocumented. If you include this file, your code will
compile if it is any way possible in MFC. All the #define's and #pragma's
are set up to make MFC work.
The real bonus comes when you use the Visual C++ Cross Platform Edition for
the Macintosh. Rather than having the figure out all the new header files
that you need, the "stdafx.h" includes most all the Macintosh and MFC header
files that you will ever need. They all work together (because they had to
build MFC with it) with all the proper #define's and everything.
That's my recommendation of the week.
Mike Blaszczak -- mikeblas@interserv.com
Saturday, January 27, 1996
[Mini-digest: 2 responses]
On Thu, 25 Jan 1996, dhoward@kset.com wrote:
>I've actually found it useful to include "afximpl.h" in all my files. In
>fact, the way that I do it is to include the "stdafx.h" in the SRC
>directory. The stdafx.h is the standard include file used to compile MFC.
>I always include this file at the very beginning as part of my precompiled
>header.
>
>Why?
Let me try and guess. Uh, because you want your builds to include lots of
things you don't need, lots of things that are dangerous, and you want your
builds to be as slow as possible so you can later complain about how crummy
VC++ is in the performance department. Is that right?
>The "stdafx.h" in SRC includes every header file in the MFC universe,
>documented or undocumented. If you include this file, your code will
>compile if it is any way possible in MFC. All the #define's and #pragma's
>are set up to make MFC work.
It also has lots and lots of stuff you don't need. This clogs the pipes. It
bloats your PDB file when you build for debugging, and that in turn slows
down your machine: your linker and your debugger deal with megabytes of stuff
they don't care about.
There are dangerous things in MFC\SRC\STDAFX.H. These things aren't
dangerous to MFC because MFC was implemented with full knowledge of what's
going on in there. But, since you don't know what's going on in there, you
can get into pretty bad trouble.
One huge problem you'll run into deals with exceptions. If you _read_
MFC\SRC\STDAFX.H, you'll see that it redefines the way the exception macros
work. MFC uses this redefinition to be efficient, but your code shouldn't use
it--your code can end up leaking memory.
One medium-sized problem you'll run into involves register packing. I think
your code ill be a little less portable if you rely on code built with
_AFX_PACKING instead of the default packing the compiler uses. I guess
there's a chance that this will only show up if you start using third-party
libraries which rely on their own struct packing rules, so you're safe for
now... you won't be in trouble until later, when you forget.
One minor problem you'll run into is that you can run off and use
undocumented things without knowing it. If you suddenly play with an
undocumented structure, you'll build your empire around it just because
you've included The World. But, years later, when that structure changes,
you'll end up in a heap of trouble because the empire you built upon it will
come tumbling down. You didn't even know it was an unsupported,
implementation-level dodad because it you just included the world--you didn't
get warnings about AFXIMPL.H not being around.
>The real bonus comes when you use the Visual C++ Cross Platform Edition for
>the Macintosh. Rather than having the figure out all the new header files
>that you need, the "stdafx.h" includes most all the Macintosh and MFC header
>files that you will ever need.
>They all work together (because they had to
>build MFC with it) with all the proper #define's and everything.
This brute-force approach will hide problems that you'll probably wish you
knew about long after they've bitten you.
>That's my recommendation of the week.
I would strongly suggest not applying this advice.
.B ekiM
--
TCHAR szDisc[] = _T("These words are my own; I do not speak for Microsoft.");
-----From: "John Elsbree"
I don't want to sound repetitious, but I personally wouldn't recommend this
technique. It will make your compiles take longer, and it virtually guarantees
that something in your code will fail to compile when you install a newer
release of MFC.
Stick to only the documented parts of MFC, unless you absolutely *must* do
otherwise.
mfcTeam.m_johnels; // does not represent Microsoft
----------
From: owner-mfc-l@netcom.com on behalf of dhoward@kset.com
I've actually found it useful to include "afximpl.h" in all my files. In
fact, the way that I do it is to include the "stdafx.h" in the SRC
directory. The stdafx.h is the standard include file used to compile MFC.
I always include this file at the very beginning as part of my precompiled
header.
Steven Lewis -- smlewis@wln.com
Sunday, January 28, 1996
[Mini-digest: 2 responses]
While I fully agree with the advice to not ROUTINELY include afximpl.h,
there are times when it is required. I have a need to generate classes
which are essentially identical to MFC classes but slightly different.
I need, for example, to generate a class equivalent to CScrollView but derived
from CWnd. The best way to do this is to copy and edit the MFC code knowing
that I will have to redo this with each major release.
In these limited cases, the file REQUIRES afximpl.h
-----From: dhoward@kset.com
Of course, when I first wrote this, I knew it would cause this backlash.
All I can say is that it hasn't hurt me yet.
Before I used this method, the Visual C++ IDE was DOG SLOW. After I use
this method, the Visual C++ IDE is still DOG SLOW. Sorry mikeblas and
elsbree but your talk doesn't hold up. Whether or not I use it, it is still
DOG SLOW.
Yes, yes, I know to avoid afximpl.h. However, I still know what is
documented and what isn't. If you think that hiding "afximpl.h" in the SRC
directory is going to dissuade people from using it, you are naive. People
will just include it in their own "stdafx.h" (instead of in the .cpp file
that needs it) and the whole program will have access to it. You may think
that it is wrong but people will do it anyway.
And, frankly, if the Macintosh Cross-Platform Edition wasn't such a HACK, I
might not do this. I spent over a day trying to figure out which files to
include to get something compiled, then I ripped it all out and replaced it
with "stdafx.h" and it worked fine.
Besides, I can substitute in my own stuff at any time and recompile. It's
only code. In general, it's a good policy to put buffer classes and include
files between company code and MFC. I can always copy in the code, edit it
directly (which I had to do for the Mac) and bring it under my own source
control. All your voodoo and curses aside.
And, I should point out that the code ports between VC++ 1.5 and 4.0.
Dan
| Вернуться в корень Архива
|