>I am new to MFC programming so please bear with me if I am indeed way off
>base here, but isn't type safety in MFC an oxymoron?
Okay. But you've confused me; you start out with this arrogant and abrasive
"type safety in MFC is a joke" subject line, and then suddenly say you're
just getting your feet wet. Which is it? Do you know enough about what
you're talking about to make condemning statements, or are you just trying to
>It seems as though every object ever created in MFC ends up as a far/near
>pointer at some point in time - with no particular type assigned to it.
Sure. But this is true for any system. All objects live _somewhere_ in memory.
>Alot of parameters are passed simply as long ints so they can be changed
>into pointers to structures and objects.
This is the Windows way. In messages, a generic LPARAM is often used to hold
a pointer to user-defined data. In MFC, the wrapping functions you use always
have a real type. MFC wraps the Windows API; it doesn't replace it.
>Now that VC++ supports templates can we expect stuff like this to go away
Maybe you should be more specific about what parameters you're talking about.
But, as I said, MFC wraps the Windows API and doesn't replace it. Even with
What problem do you expect to solve with templates, specifically? There _are_
typesafe and templated collection classes in MFC. But you make it sound like
you're worried about the way simple Windows-based parameter passing works.
That's quite under the covers and removed from you; it's all inside of MFC.
>Are there any immediate plans on rewriting MFC in such a way as to
>finally scrub alot of old ideas of solving problems (like RTTI) that will
>be done away with in the new C++ standards?
Probably not. There is type information built into MFC's CObject, and that's
what MFC needs. MFC often uses this type information to see what a pointer
is pointing at at runtime, and that could be replaced by RTTI. But MFC also
needs to make assumptions about RTTI across different runs of the same program;
in its persistence implementation, for example. The C++ RTTI doesn't provide
a mechanism for this, and MFC needs it.
MFC could be implemented with some real C++ RTTI (for runtime typing) and some
CObject MFC type information, but that would be redundant and therefore very
expensive. So, don't expect it to happen.
>What about message maps? I understand how they are needed to link into
>the C element of Windows, but isn't there a better way for doing all
> Things like ClassWizards make everything seem simpler but for my
>buck things are much more complex than they need to be.
Why, specifically? There are less complex ways, but it's not always that less
complexity is actually better, you know.
> Is creating a large virtual lookup table really as bad as
> the problems the current situation brings to the table?
What problems are you worried about, specifically? It's hard to address your
concerns if you don't state them. In the meantime, a large vtable is almost
unconceivable. It would have to be reinitialized every time a CWnd-derrived
object is created. That could be tens of thousands of times a second. You
can't afford that penalty at runtime. The message-map solution gets around it
in a very flexible, convenient way.
I hope that my comments help you figure it out. If you had posted more
specific comments, I might have been able to be more specific in my answers.
>The RED WINGS rule!
They did look impressive last season; I was surprised to see The Devils