Re: Programmer knowledge

From: Malcolm (malcolm_at_55bank.freeserve.co.uk)
Date: 03/24/04 

Date: Tue, 23 Mar 2004 23:25:34 -0000

"Gerry Quinn" <gerryq@indigo.ie> wrote in message
> I know you can - when he said the "C library", and contrasted it
> with "MFC not being really C++" naturally I thought he meant a
> library that was part of C. I simply don't know anything about this >
Windows C Library because I use a C++ library and have no need
> to revert to C.
>
As it happens, the MS Windows SDK C-callable API isn't part of any standard.
However it is basically just a typical platform-specific C library, with the
quirk that the entry point isn't generally main().
>
> >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.
>
> It is essentially. There is some additional support for their beloved
> DocView architecture, some useful general-purpose classes, and
> some support for using resource scripts etc. but these are extras
> and you can use it just as a wrapper quite easily.
>
I think there is a strong case for using MFC without the wizards. I must
admit that I have never tried this.
>
> The wizards don't really do anything mysterious or arcane.
> (Incidentally, you can write your own wizards if you want, though
> it's not something I've got into.)
>
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.
>
> Programming praxis has left you behind.
>
Don't use that word. Nilges.
>
> Besides, the original criticism of MFC was addressed to C++
> programmers.
>
You can use the Windows C library from C++.
>
> 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.
>
> 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.
>
> 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.
>
> How could you - you've already implied that all your Windows
> programs are either unmaintainable, or written in C! Since I
> assume your programs are maintainable, you couldn't have any use
> for a C++ wrapper.
>
Virtually every C programmer knows C++ and has access to a C++ compiler, so
choice of C is a deliberate rejection of C++e's extra features. It's a lot
easier to make a total hash of a C++ program than of a C program. However
one is often either forced to use C++, by needing to use libraries written
in it or by command from on high, or one decides to discard any reservations
and give it a try.