Type safety is a joke in MFC

Type safety is a joke in MFC

Post by Tim Triemst » Sat, 22 Jul 1995 04:00:00



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?

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.  
Alot of parameters are passed simply as long ints so they can be changed
into pointers to structures and objects.

Now that VC++ supports templates can we expect stuff like this to go away
soon?  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?

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
this?  Things like ClassWizards make everything seem simpler but for my
buck things are much more complex than they need to be.  Is creating a
large virtual lookup table really as bad as the problems the current
situation brings to the table?

I haven't seen OWL and because it isn't the "industry standard" I'm
shying away so far.  I'm using Symantec C++ which I have to turn off the
ANSI compliance on to get anything to build.  Not my normal way to work
so it is kinda frustrating.  I very much prefer to stick in ANSI when
possible.

Any comments on ways to make the class declaration simpler, or even what
to expect in MFC in the future would be appreciated.

--

The RED WINGS rule!  Practice throwing your octopi!
That cup is going to be a tough target when Yzerman holds it over his head!

 
 
 

Type safety is a joke in MFC

Post by blaszczak on B » Sun, 23 Jul 1995 04:00:00



 >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
learn?

 >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
 >soon?

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
templates.

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
 >this?

Probably not.

 > 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.

.B ekiM

 >The RED WINGS rule!  

They did look impressive last season; I was surprised to see The Devils
beat them.

 
 
 

Type safety is a joke in MFC

Post by Jason D. Morr » Sun, 23 Jul 1995 04:00:00



>Sorry if I'm venting.  I'd prefer to say that I'm interested in what to
>expect in the future.  I'd like to see how OWL handles these problems and
>anyone that can give me a comparison would be appreciated.  I realize
>that MFC is closer to the API and that has benefits with regards to OS
>feature support.  But I personally would rather have cleaner code if
>possible.
>--


I had many of the same thoughts you did when I first started with MFC.  After
using it for about a year, and becoming pretty familiar with it I finally
decided to take a look at what Borland had to offer.  OWL produces MUCH cleaner
code and provides a real OO class library.  Not to mention that it provides a
fuller encapsulation of many aspects of Windows, my personal favorite is the
TDib class, I still can't figure out why MS left out such an important class.
If you're willing to part with $80 I would suggest you go out and get a copy of
Turbo C++ 4.5 and take a look at how OWL does things.  It's a real eye opener.

                                                    -Jason-

 
 
 

Type safety is a joke in MFC

Post by Tim Triemst » Sun, 23 Jul 1995 04:00:00


Quote:> you start out with this arrogant and abrasive [...] subject line, and then
> suddenly say you're just getting your feet wet.

True, I'm not an overly-beginner type, but my primary experience isn't in
MFC so I appoligize for the abbrasiveness of the post.  I had recently
tried to build a sample Common Control trrview application sent out with
the development library.  I'm using Symantec 7.0 (upgraded to 7.01) and
came accross an error message that HTREEITEM was undefined.  I also had
errors with LPNMHDR and such not being declared.  Based on the naming
conventions it was easy enough getting things to build by casting to
pointers of the handle type but the sample program performed slightly
unexpectedly.  So I wanted to look into the structures and figure out
what was going on behind the scenes.  And, it just seemed like every
trace though the data types was failing in searches through the MSDN
(they showed using the types but never layed out the structures.)  Going
through the source code just felt like a huge trek though endless
typedef's of LONG INT's into any data type it felt like.

As far as templates:  Hows about tree-items that are type safe so as to
have a treeitem template that can be created for whatever type of data
item you would want to put into the tree.  Custom functions for each data
type for how the item is named etc.  I realize that this can of course be
done the way the current system is setup, it just doesn't feel proper :)

As far as message maps, sorry about the fickel-ness but all those crazy,
long UPPER_CASE_ONLY macros are annoying.  They also clog compiler's
memory.  I realize that a very large part of all these "problems" as I
see them are related to the static nature of C++.  I've become very
acustom to using Objective C under NeXT and the code results so much
cleaner and easier to maintain.  I feel so dependent on the classwizard
and it makes me less comfortable with my own code because of it.

Sorry if I'm venting.  I'd prefer to say that I'm interested in what to
expect in the future.  I'd like to see how OWL handles these problems and
anyone that can give me a comparison would be appreciated.  I realize
that MFC is closer to the API and that has benefits with regards to OS
feature support.  But I personally would rather have cleaner code if
possible.

--

 
 
 

Type safety is a joke in MFC

Post by Taskin Ucpin » Tue, 25 Jul 1995 04:00:00




>I had many of the same thoughts you did when I first started with MFC.  After
>using it for about a year, and becoming pretty familiar with it I finally
>decided to take a look at what Borland had to offer.  OWL produces MUCH cleaner
>code and provides a real OO class library.  Not to mention that it provides a
>fuller encapsulation of many aspects of Windows, my personal favorite is the
>TDib class, I still can't figure out why MS left out such an important class.
>If you're willing to part with $80 I would suggest you go out and get a copy of
>Turbo C++ 4.5 and take a look at how OWL does things.  It's a real eye opener.

First of, I am not trying to start a new MFC-OWL war but I had a similar
experience.  I have used OWL for years now and decided to give a shut to
MFC because ALOT OF PEOPLE were using it.  After a few months of trial, I
have decided to go back to OWL because of very similar reasons that you
gave. Now, I still use MFC if and only if it is a requirement in a project.

However, truth stays the same A LOT OF PEOPLE are still using MFC, and OWL
code is becomming less and less used.  I hope Borland can find a way of
increasing the popularity of OWL. Otherwise, we will all end-up using MFC.

Taskin

 
 
 

Type safety is a joke in MFC

Post by blaszczak on B » Tue, 25 Jul 1995 04:00:00


 > I'm using Symantec 7.0 (upgraded to 7.01) and
 > came accross an error message that HTREEITEM was undefined.
 > I also had errors with LPNMHDR and such not being declared.

It sounds like your compiler doesn't have current Win32 SDK headers.

 >  Going through the source code just felt like a huge
 > trek though endless typedef's of LONG INT's into any data
 > type it felt like.  

And this is what your were complaining about in your original note?
These structures are defined by the Windows SDK as parts of the
Windows API.  They're _not_ a part of MFC.

 > As far as templates:  Hows about tree-items that are type
 > safe so as to have a treeitem template that can be created
 > for whatever type of data item you would want to put into the tree.

Most people use tree controls for strings.  I guess if you have
some item data associated with each one, it would be convenient to
have such a template.

 > As far as message maps, sorry about the fickel-ness but all
 > those crazy, long UPPER_CASE_ONLY macros are annoying.
 > They also clog compiler's memory.

Why do you feel that the compiler's memory is your concern?  If it
is an issue for you, you should worry more about using WINDOWS.H to
get definitions for the Windows API.  This file (and its children)
include definitions you often don't even need, and _LOADS_ more stuff
than AFX.H or AFXWIN.H defines.

.B ekiM

 
 
 

Type safety is a joke in MFC

Post by Davide Marca » Sun, 30 Jul 1995 04:00:00



...

Quote:>> OWL produces MUCH cleaner code and provides a real OO class library.

...

Quote:>First of, I am not trying to start a new MFC-OWL war but I had a similar
>experience.  I have used OWL for years now and decided to give a shut to
>MFC because ALOT OF PEOPLE were using it.  After a few months of trial, I
>have decided to go back to OWL because of very similar reasons that you
>gave. Now, I still use MFC if and only if it is a requirement in a project.

I always use MFC in my programs, but I gave a look at OWL too.
MFC has a good support for some features, like OLE2, ODBC, object
persistence, and so on.
But it also has some poor things: for examples, if you want to use it
in a program, you *MUST* follow the document-view architecture,
otherwise you won't get many supports.

Quote:>However, truth stays the same A LOT OF PEOPLE are still using MFC, and OWL
>code is becomming less and less used.  I hope Borland can find a way of
>increasing the popularity of OWL. Otherwise, we will all end-up using MFC.

The main reason for this is that OWL is distributed *only* with
Borland's compilers, but MFC is distributed with Microsoft's,
Symantec's, Watcom's (what other?) compilers.

Quote:>Taskin

Bye bye!

Davide Marcato.
- Young C++ programmer under Windows.


 
 
 

Type safety is a joke in MFC

Post by Chris Marrio » Sun, 30 Jul 1995 04:00:00



>But it also has some poor things: for examples, if you want to use it
>in a program, you *MUST* follow the document-view architecture,
>otherwise you won't get many supports.

That's not true at all - I've written LOTS of MFC programs which don't use
the Doc/View architecture. Just because the App Studio doesn't write
them doesn't mean that YOU can't!

Chris
--
--------------------------------------------------------------------------
 Chris Marriott, Warrington, UK      | Author of SkyMap v2 award-winning

            For full info, see http://www.execpc.com/~skymap  
      Author member of Association of Shareware Professionals (ASP)
--------------------------------------------------------------------------