Re: Programmer knowledge

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

Date: Tue, 23 Mar 2004 04:57:30 GMT

In article <c3np45$71b$1@newsg1.svr.pol.co.uk>, "Malcolm" <malcolm@55bank.freeserve.co.uk> wrote:
>"Gerry Quinn" <gerryq@indigo.ie> wrote in message
>>
>> 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.

>> If you use the Windows API you no longer 'really' have a C++
>> program in just the same sense. And MFC is just a wrapper for
>> the Windows API. It's not going to stop working unless the API
>> changes, and then everything that uses the API will stop working.
>> Core product or not.

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

A contraire, it is you who does not understand. 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.

In truth, OO is such an obvious win for GUI development above all things
that the thought of using C seems absurd to me.

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.

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

>> If you meant you do use the Windows API, then you have been
>> cutting off your nose to spite your face by, for spurious
>> 'technological' reasons, refusing to use a fairly straightforward C++
>> wrapper for the API calls.
>> MFC may not be perfect, but it's surely better than nothing!
>>
>That's the problem, it's not a "fairly straightforward C++ wrapper". A C
>program, using the API, is much easier to follow and to maintain. Which is
>quicker to write is a more difficult question - the MFC wizard will produce
>a shell program automatically. However many of the labour-saving devices end
>up wasting a lot of time, for instance I once tried to add some portable C
>files to my project, and found that the system refused to compile them
>because of the lack of pre-compiled header information. A couple of hours
>later, I gave up and redid the project from scratch. Pre-compiled headers
>are supposed to save time.

Pre-compiled headers do save time. 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.

C is quite obsolete in the context of conventional Windows desktop
software, IMO. You don't want to be writing GUIs in particular in that
sort of language. C has more of a place in an OS like Linux whose users
accept or even demand primitive '80s-style interfaces.

>Not every technology is good, and most technologies are not suitable for all
>situations. Use of C++ in itself is an open invitation to programmers to
>waste days playing with the language and looking up obscure points to do
>with virtual inheritance of templated multiple base classes. MFC adds a lot
>of features that you often don't want, for instance you don't generally want
>sub-windows to be dockable and configurable by your users if you are writing
>an internal tool, or else they'll just get the program into an unusable
>state and then come asking for help.

If you don't like features, be they of a language or a library, don't
use them. Sure, a lot of foolish people do think that template
metaprogramming should be part of normal programming activity (except
for rare cases, it is only for writing libraries), or that dockable
windows must improve a GUI. But the same criticism is often made of C,
i.e. it allows incompetent programmers to write bad code.

Gerry Quinn 

-- 
http://bindweed.com 
Screensavers, Games, Kaleidoscopes
Download free trial versions
Quantcast