Re: Programmer knowledge

From: Gerry Quinn (gerryq_at_indigo.ie)
Date: 03/24/04 

Date: Wed, 24 Mar 2004 11:37:32 GMT

In article <c3qh0c$9kv$1@newsg1.svr.pol.co.uk>, "Malcolm"
<malcolm@55bank.freeserve.co.uk> wrote:
>"Gerry Quinn" <gerryq@indigo.ie> wrote in message
>>
>> >The Windows API is far less pervasive than MFC.
>>
>> I'm not sure I understand that comment. Pervasive in what way?
>
>Here's a section of what my wizard produced for a "hello world" app.
>
>////////////////////////////////////////////////////////////////////////////
>/
>// CHelloApp
>
>BEGIN_MESSAGE_MAP(CHelloApp, CWinApp)
> //{{AFX_MSG_MAP(CHelloApp)
> ON_COMMAND(ID_APP_ABOUT, OnAppAbout)
> // NOTE - the ClassWizard will add and remove mapping macros here.
> // DO NOT EDIT what you see in these blocks of generated code!
> //}}AFX_MSG_MAP
> // Standard file based document commands
> ON_COMMAND(ID_FILE_NEW, CWinApp::OnFileNew)
> ON_COMMAND(ID_FILE_OPEN, CWinApp::OnFileOpen)
> // Standard print setup command
> ON_COMMAND(ID_FILE_PRINT_SETUP, CWinApp::OnFilePrintSetup)
>END_MESSAGE_MAP()
>
>////////////////////////////////////////////////////////////////////////////
>/
>// CHelloApp construction
>
>CHelloApp::CHelloApp()
>{
> // TODO: add construction code here,
> // Place all significant initialization in InitInstance
>}
>
>////////////////////////////////////////////////////////////////////////////
>/
>// The one and only CHelloApp object
>
>CHelloApp theApp;
>
>See what's happening? The wizard relies on special comments to tell it where
>to automatically inset code. You can't edit certain sections of the code
>without messing up the system. You are given a global instance of the
>application to work with. The message macros have redfined C++ syntax so far
>as to be effectively another programming langauge. The choice of MFC has
>completely altered the way you set out the program.

On the other hand, you have certain useful functions added already.
You could always delete them. And the message macros are greyed out and
you do not in general edit them. So the comment about 'another
programming language' is not really meaningful IMO. There is a global
instance of a CWinApp derived class, but how would you do it
differently?

However, my main disagreement here is that you have NOT altered the way
you set out the program. You have altered the way you set out a top
level framework which is only a tiny part of the program. A washing
machine may come in a blue or a red box, but it is not pervasively
affected by box colour. When I'm writing a game I quite often start
with a Dialog Box app, then after a while I move my game window out of
the dialog box (which is subsequently deleted) and into a more suitable
top-level framework. This is an important point about OO. Neither high
level nor low level objects have special priority.

>A user-defined wizard is surely the final stage before complete collapse.
>This is a common error in software, BTW, to make everything
>user-configurable, because it is technically possible to do so. However you
>wouldn't want a car where people can move round the positions of the gear
>stick, or a pen where you've got to specify the colour and the line width
>before writing each word.

Probably. People who like template metaprogramming probably go on to
write wizards to set up their template structure ;-)

>> Besides, the original criticism of MFC was addressed to C++
>> programmers.
>>
>You can use the Windows C library from C++.

Yes, but using C for anything GUI-related is an extraordinary step IMO.

>> Obviously MFC is irrelevant to C programmers so I'm not really
>> sure what your criticisms are based on.
>>
>Why not always use C++ instead of C? Because C++ gives you the power to do
>undesirable things. What's an example of an undesirable thing? MFC, for the
>reasons given.

I disagree - I find it quite good. You just have to know it.

>> MFC collection classes have certain merits in terms of intuitive
>> functions, although I have switched to STL now. (In case you
>> wondered - they mix just fine.)
>>
>This is an example of the pitfalls of using an immature language. In a
>narrow binary compatibility sense MFC collection classes and stl may mix,
>from a broader software engineering perspective, taking into account human
>factors, having two sorts of managed arrays is trouble. This is particularly
>the case if you use stl as it was designed, to implement your own generic
>algorithms and data structures.

What I mean is that when I dug out an old project that used MFC
collection classes, and added an element that used STL (and in fact
needed the extra power, for the first time ever), the necessary mixing
at the interface between old and new classes caused no problems.
[Incidentally, I would say STL was designed to implement
useful algorithms that can be applied to generic data structures.]

>> nobody is stopping you using STL or something else for these
>> things, and just using MFC for its main purpose, an API wrapper.
>>
>Microsoft don't want Windows programs to be easily portable to other
>platforms, which is why they try to tempt people into using MFC as more than
>a mere wrapper for a windowing system. Abstracting all the MFC calls and
>replacing with generic "button" and "scrollbar" and other types, for
>instance, is almost impossible.

Using MFC for buttons and scrollbars means you ARE using it as a wrapper
for a WIMP system. Naturally MFC functions won't work on any system it
isn't written to work for. If you want something that runs on many
systems, you need to use something other than MFC. The downside is that
it will probably be limited, respond slowly, and look odd on any
particular system. If you're rolling your own system, though, I doubt it
would be especially harder to call MFC for the Windows bits than to use
a particular Linux-based C++ WIMP library for the Linux bits. But you
would probably revert to C API calls if writing that sort of portable
WIMP library. Portability or app quality - this is an issue that will
always be there so long as there are multiple OSs. The more OSs
and OS variations there are, indeed, the worse portable apps will look
compared to native apps.

- Gerry Quinn

Relevant Pages

  • Re: How to enter object reference in map
    ... MFC gives you the ability to use these API's, but you don't have to use them. ... You could write Windows application in C++, C, or assembly. ... And the same does apply to MFC containers. ... You could hack out the afx dependency,, and they would be much the same as stl containers. ...
    (microsoft.public.vc.mfc)
  • Re: How to enter object reference in map
    ... MFC gives you the ability to use these API's, but you don't have to use them. ... But the point is, for lists, a lot of list development is being done on the side of STL. ... It does not have to be dependent on a windows environment either. ...
    (microsoft.public.vc.mfc)
  • Re: MFC oder doch nicht MFC?
    ... Was passiert wenn in der DLL ein Ctring ... aber in einem DLL-Interface die STL zu empfehlen ist so ... Gleiches gilt eingeschränkt für die MFC, ...
    (microsoft.public.de.vc)
  • Re: MFC oder doch nicht MFC?
    ... Willst Du nun extern auf die MFC verzichten oder nicht? ... std::map IMHO nicht viel gemeinsam) benötige. ... >Nimm die STL, nimm die STL, nimm die STL. ...
    (microsoft.public.de.vc)
  • Re: CString vs tstring
    ... I suse CString wherever I can, but I admit it's mostly because I've been ... using it for years and I always use MFC and it's already there. ... I really like some of the add-in support using vectors with STL and several ... Does the new VS 2005 have better MFC collection ...
    (microsoft.public.vc.mfc)