In article <1992Jul10.022828.17618@cmcl2.nyu.edu> checker@acf3.nyu.edu (Christopher Hecker) writes:
|Oh please.  You know, I listen to your stories about getting no response
|from the ANSI committee, and then I look at posts like this.  The
|committee members are only human, if you insult them and their work you
|are bound to get shoddy service.

You mistake cause and effect.  It is after years of receiving insults
and no service that I begin to insult back.

|Didn't MS rely on a non-standard implementation of pointers to members
|to do the MFC classes?

No.

|I could be wrong,

and are

|but I don't think MFC will
|compile under other compilers without substantial changes to the (ugh)
|macro definitions.

No.  Several other compiler vendors have already licensed MFC to work
with their compilers.  Another compiler vendor has "vendor specific"
"interpretations" of parts of ARM that keeps their particular compiler
from compiling MFC, but even they now allow a compiler-switch to invoke
the alternative "interpretation" of this issue that the other compilers
agree to.

|Oh please, again.  Microsoft had a chance to encapsulate the windows
|interface at an abstract level with their class library, yet they chose
|to provide a paper thin `translation layer.'  Are you saying that no one
|thought about the fact that a `real' windowing class library would be
|portable between window APIs, like X and PM, and not lock people into MS
|Windows?  I don't think MS is the devil incarnate, like some folks do,
|but I wouldn't accuse them of altruism, either.

I can't speak of other people, but I know the people at Microsoft thought
about this issue extensively.  The result is that C++ programs written
in MFC can be ported easily to the large majority of machines that
"real world" customers use GUI on around the world.  MFC is "paper thin"
because that thinness results in small fast GUI programs.  MFC could have
invented its own yet-another programming paradigm in order to try to lock
people using MFC into MFC, at the expense of making those people learn
yet-another paradigm, and at the expense of making those people's code
big fat and slow, but such an approach was not taken.

Its EASY to write big fat slow layers over existing code, layers that
only do part of the job.  Its HARD to write something lean and mean.
I think the people on MFC did the right thing and the hard thing,
in deciding to make a lean and mean "real world programmer" interface.
"Real World" programmers don't want their GUI apps burdened by fat slow code.
"Real World" programmers don't want their GUI apps restricted to using
only part of their GUI environment.

jimad@microsoft.com (Jim Adcock) writes:

>As recently as a week ago I would have argued against such vendor-specific
>extensions...
>But, with committee members themselves arguing that
>such vendor-specific extensions are a good thing, who am I to complain?
>Kind of begs the issue why do we need this standard anyway, if compiler
>vendors aren't suppose to follow it?

Oh please.  You know, I listen to your stories about getting no response
from the ANSI committee, and then I look at posts like this.  The
committee members are only human, if you insult them and their work you
are bound to get shoddy service.  Maybe they should be robots that only
look at proposals with their official hats on, but that's not reality.

Why can't there be an ANSI standard with some vendor specific features
implemented as added-value?  Are vendors not supposed to ship libraries
that aren't in the standard either?  As long as you make an educated
decision about when to use what you will be okay.


>Note that when Microsoft addressed this same issue on its MFC software,
>the decision was to follow the ANSI-C++ draft, and not use extensions
>to the virtual dispatch syntax that would prevent the MFC software from
>compiling on other people's compilers, such as cfront, zortech, borland, etc.

Didn't MS rely on a non-standard implementation of pointers to members
to do the MFC classes?  I could be wrong, but I don't think MFC will
compile under other compilers without substantial changes to the (ugh)
macro definitions.  Is that the case?

>Microsoft *should* just "do their own thing" and lock programmers into
>the Microsoft compiler, rather than giving programmers the choice?

Oh please, again.  Microsoft had a chance to encapsulate the windows
interface at an abstract level with their class library, yet they chose
to provide a paper thin `translation layer.'  Are you saying that no one
thought about the fact that a `real' windowing class library would be
portable between window APIs, like X and PM, and not lock people into MS
Windows?  I don't think MS is the devil incarnate, like some folks do,
but I wouldn't accuse them of altruism, either.

For what it's worth, I think DDVTs are a joke.  They break encapsulation
and spread knowledge of the windows api throughout every piece of your
code.  Microsoft should love them:)


Chris