Re: Programmer knowledge

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

Date: Tue, 23 Mar 2004 12:16:32 GMT

In article <c3opu2$akd$1@titan.btinternet.com>, binary@eton.powernet.co.uk wrote:
>Gerry Quinn wrote:
>>>>
>>>> The C library doesn't have windows or controls at all.
>>>>
>>>The Windows C library has a set of functions for opening windows, drawing
>>>text and graphics, and managing other devices.
>>
>> I see. I don't know anything about that library; I don't use C and the
>> original post referred to C++, not C.
>
><shrug> You can use the Windows API from either C or C++. Malcolm is
>perfectly correct.

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.

>>>> If you use the Windows API you no longer 'really' have a C++
>>>> program in just the same sense.
>
>The Windows API is far less pervasive than MFC.

I'm not sure I understand that comment. Pervasive in what way? Unless
you mean a few helper classes, but they only pervade where you put them.
Now that STL is functioning okay, they can be replaced with ease.

>>>> And MFC is just a wrapper for
>>>> the Windows API.
>
>No, it's not /just/ a wrapper.

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.

>>>You don't understand. Formally MFC is a C++ wrapper for the Windows API.
>>>However it is very difficult for a human programmer to use it like that.
>>>Instead code is automatically generated by "wizards" and non-C++ files
>>>like resource scripts are included. Now unless you have the whole wizard /
>>>scripting system in place, your code investment is in danger, because the
>>>program isn't human-readable without these aids.

>> Visual Studio wizards
>> are not part of MFC, nor necessary in any way to its use. You can of
>> course create resource scripts for dialogs etc., but you can just as
>> well construct a CDialog and instantiate MFC controls such as CButton,
>> without recourse to any resource script. It's easy - at least as easy
>> as creating windows and controls with C function calls.
>
>Not everyone finds it so. If you like the MFC, great! By all means use it.
>But it's not as universally popular and intuitive as you appear to think.

I just said it was easy. It is clearly not universally popular, and
perhaps not intuitive (what Windows API wrapper was ever going to be
intuitive?). But deriving a class from CWnd and putting a few CButton
member variables in it is hardly rocket science. 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.)
 
>> In truth, OO is such an obvious win for GUI development above all things
>> that the thought of using C seems absurd to me.
>
>I've seen Windows programs written in C, and I've seen Windows programs
>written in C++. I'm not claiming it's impossible to write a maintainable
>Windows program in C++, but I haven't seen it done yet.

Programming praxis has left you behind. Besides, the original criticism
of MFC was addressed to C++ programmers. Obviously MFC is irrelevant to
C programmers so I'm not really sure what your criticisms are based on.

>> The wizards don't do anything out of the ordinary, even for dialog
>> boxes. And whatever they may do for dialog boxes, they do less for
>> anything else. MFC, by contrast, is of general utility - standard
>> C-style API function calls are very rarely necessary.
>
>Ha. I once needed a CList of CLists. Couldn't do it, no matter how I twisted
>things around. I mean, okay, it might have been possible - I don't know.
>But that's not the point: It should have been /easy/.

I suspect you might need to declare a class/struct for the inner CList.
The code would have been horribly longwinded if you did otherwise
anyway, although it should work with STL. 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.)

>> [It could be suspected that a program using MFC will actually be less
>> likely to become obsolete than a program using standard API calls,
>> because MS programmers will have shied away from implementing MFC in
>> terms of calls they suspect may change, or put in defences against such
>> changes.]
>
>Actually, a program using standard API calls and due care with regard to
>portability will be far less likely to become obsolete, because it will be
>much easier to port to Linux when MS eventually goes to the wall.

Get real, Richard. Linux isn't going to take over the desktop. Linux
is probably not even going to exist except as history when MS goes to
the wall in twenty years or a hundred. And if it did there would be no
point porting software to an OS whose users don't pay for it. Lastly
even if your forebodings came true, and if for some reason you did want
to port software, "due regard to portability" means separating the
program internals from the OS interface, and in that regard it's
irrelevant whether you use MFC for the interface or not. If you use the
MFC helper classes all through your code, you might affect portability,
but nobody is stopping you using STL or something else for these things,
and just using MFC for its main purpose, an API wrapper.

>> If your portable files don't need
>> access to other program resources, they will compile as soon as you add
>> them. It's true that resource scripts are a bit untidy and spread out,
>> but as I've pointed out they are not really anything to do with MFC.
>
>And MFC has nothing to do with C++. It's a poorly designed hack. If you want
>to check out a really classy GUI C++ library, look at C++ Builder. That
>rocks.

What, that ancient 'OWL' thing? I haven't *seen* a program with big
green tickmarks and big red x's in years! (C++ Builder is Borland's
counterpart to Visual Studio. But AFAIK it can be used with MFC too.)
Do people really still use OWL?

>> If you don't like features, be they of a language or a library, don't
>> use them.
>
>Right. That's why I don't use MFC.

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.

- Gerry Quinn