🚀 go-pugleaf

In article <1992Aug12.193916.17762@microsoft.com> stevesi@microsoft.com (Steven Sinofsky) writes:
>In article <pathak-100892175041@virtual.mitre.org> pathak@mitre.org (Heeren Pathak) writes:
>>In article <1992Aug10.171802.18367@nntpd.lkg.dec.com>,
>>feldman@toklas.enet.dec.com (Gary Feldman) wrote:
>>> 
>>> I'm just starting to look at compilers and windows programming (for myself).
>>> One thing that struck me was that Borland appears to have added a non-standard 
>>> C++ extension, to bind messages to member functions (the "= [WM_FIRST + mesage]"
>>> construct).  It seems like a nifty idea, but if you use it, doesn't it lock
>>> you into buying compilers from Borland?  
>>> 
>>
>>From what I understand, Borland's extensions are being debated by the ANSI
>>committee and may actually become part of the standard.
>
>To the best of my knowledge and after checking with several representatives
>on the ANSI XJ316 (the C++) committee, the Borland extension has not been
>proposed, let alone debated by the XJ316 folks.
>

It's important to keep in mind, in the midst of all the compiler vendors'
posturing in regard to ANSI C, that the important, definitive standard for
ANSI C hasn't been released yet. The new issue of Sun Expert, if you can
find it, has an excellent discussion on this topic, based primarily on the
insights of John Gillmor of Cygnus, one of the near-founders of Sun
Microsystems. John's conclusion is that the ANSI C committees need to
take a decade off, and he offers to throw a retirement party for them
if they'll do so (and he's serious).

IMHO, the important issue for users of C on the IBM is whether the
parts of various software tools fit together well, and at the moment,
it's a bit more work than some of us would like for it to be.

>
>
>Microsoft does not use a language extension, everything that is used
>for the message routing is standard ANSI C++.  MFC will compile with
>BCC 3.1.
>

Another magazine that arrived in the day's mail, the September issue
of Byte, contains a good, thorough review of Microsoft C 7, and gives
a thumbs-up to Microsoft's handling of its C++ extensions to the
Windows API. The review avoids saying if it thinks this way better
than that of Borland, but you get the idea that that's what the
reviewer had in mind.

>>Comparing class libraries, I prefer the Borland class library.  While it
>>doesn't cover the entire Windows API, the sections it does cover contain a
>>much higher level of abstraction the Microsoft Foundation Classes.  When I
>>looked at the MFC a month or two ago, I wasn't impressed.  Most of the MFC
>>seems to be a wrapper around Windows function calls.  While this is great
>>for those who already know Windows and are porting their code, I am
>>doubtful that the MFC will provide the flexiblity that a well designed
>>Object-Oriented Application Framework provides.  
>>
>
>OWL and MFC provide nearly identical functionality in almost every
>area.  MFC provides substantial abstraction in the areas of OLE, custom
>controls, object persistance (that is much more automatic than OWL's).
>OWL has 54 classes and MFC has 87, and the classes that the two have
>in common are essentially identical, except that MFC is substantially
>more complete.  Often at first look, people consider MFC less "abstract"
>than OWL only because it uses the same names as Windows APIs and has
>all the functionality of Windows.  
>

Perhaps. But just a couple of days ago, for instance, I went to the MFC
looking for some date functions, and what I found was an incomplete
date class that warned me _against_ inheriting from it and customizing
it, as you would normally do.

Getting back to the Byte review, I think they took a really nice tack on
this issue, pointing out that it's Microsoft C Version 7, but MFC Version
1.00. "The initial version of a C++ class library typically suffers
from a few oversights," wrote reviewer Othar Hansson, "and I would expect
changes in future versions of the MFC (luckily, the source is provided
for do-or-die modifications)."

Back to my date class example, MFC actually came a lot closer to having
the functionality that I needed than did Borland's Object Windows
Library, but in fact, neither one got me all the way there. The key
difference was that with Borland's greater degree of abstraction, I was
able to inherit their basics and add my customizations much more quickly
than with the Microsoft implementation of my code, which forced me to
completely reinvent the class. 

Microsoft does have a lot to recommend it, by the way, not the least of
which is its P-code optimizations and outstanding documentation.

 --------------------------------------------------------------------

joe@xcluud.sccsi.com