MFC ?

[none]

What does MFC stand for? Google gives:

http://www.devarticles.com/c/a/Cplusplus/Using-MFC-in-Cplus-Basic-Application-Skeleton/

But in the bottom of this page the term is also used :

http://www.codeguru.com/cpp/cpp/cpp_mfc/general/article.php/c14535__2/

I assmue that it is used to describe a design pattern in this context, but which?

 

[Alf P. Steinbach]

* none:

What does MFC stand for? Google gives:

http://www.devarticles.com/c/a/Cplusplus/Using-MFC-in-Cplus-Basic-Application-Skeleton/


But in the bottom of this page the term is also used :

http://www.codeguru.com/cpp/cpp/cpp_mfc/general/article.php/c14535__2/

I assmue that it is used to describe a design pattern in this context,
but which?

No, it's the infamous Microsoft Foundation Classes, a C++ class framework that
from a modern perspective embodies ~all possible wrong ways to do things. In the
last article you cite the author refers to a design pattern used in MFC. That
means that the design pattern is an abomination and should never be used.


Cheers & hth.,

- Alf

 

[Immortal Nephi]

* none:


No, it's the infamous Microsoft Foundation Classes, a C++ class framework that
from a modern perspective embodies ~all possible wrong ways to do things. In the
last article you cite the author refers to a design pattern used in MFC. That
means that the design pattern is an abomination and should never be used.

Are you referring Microsoft is not following C++ Design Pattern
rules? What is the reason why MFC should be avoided? I have heard
that MFC does not improve performance. If you want to use WIN32
programming, WIN32 API functions are recommended instead of using MFC.

 

[Alf P. Steinbach]

* Immortal Nephi:

Are you referring Microsoft is not following C++ Design Pattern
rules?

There are no rules. But there's good, and there's bad, and what's good and
what's bad depends on context. MFC was good for its purpose in its day. One main
consideration was to be immediately usable for C programmers, instead of being
safe. In addition to that it was created when C++ didn't have standard
exceptions, didn't have RTTI and didn't have templates, so MFC had to provide
kludgy ways to emulate such functionality, mostly via macros.

What is the reason why MFC should be avoided?

Dont't know, I haven't heard about that. I suggest you ask that in a Microsoft
group.

But the C++ design patterns in MFC, such as reinventing exception handling,
throwing pointers as exception objects, reinventing RTTI (which was discussed in
one of the OP's article references) and reinventing templates, two-phase and
n-phase construction, reliance on globals, reliance on generated boilerplate
code and copy/paste programming, etc. etc., should certainly be avoided.

Almost none of the constraints influencing the design of MFC are there today.

I have heard
that MFC does not improve performance. If you want to use WIN32
programming, WIN32 API functions are recommended instead of using MFC.

Please ask that in a Microsoft group; it's off-topic here (see the FAQ).


Cheers & hth.,

- Alf

 

[Salt_Peter]

        Are you referring Microsoft is not following C++ Design Pattern
rules?  What is the reason why MFC should be avoided?  I have heard
that MFC does not improve performance.  If you want to use WIN32
programming,  WIN32 API functions are recommended instead of using MFC.

MFC is built on a client-application framework or dialog framework, it
locks you into a predefined model that probably does not fit your plan
and whose underlying code you never get to see - its propietary. Those
frameworks imply a GUI, C++ does no such thing. MFCs raison d'etre is
the false pretext that inheritance is bad, so it uses macros to build
psuedo-class inheritance.
Take a look at WTL, same framework but with support for templates.
What MFC should have been. WTL generates the same app in 50K which
runs faster and more extendeable than the same 300K app in MFC.

As far as C++ is concerned, what you learn in MFC you need to forget.

 

[Bo Persson]

* Immortal Nephi:

There are no rules. But there's good, and there's bad, and what's
good and what's bad depends on context. MFC was good for its
purpose in its day. One main consideration was to be immediately
usable for C programmers, instead of being safe. In addition to
that it was created when C++ didn't have standard exceptions,
didn't have RTTI and didn't have templates, so MFC had to provide
kludgy ways to emulate such functionality, mostly via macros.

Not to mention that it also had to space optimize for the win16
environment. At the time, things like the message maps were a
reasonable way of avoiding having a lot of virtual functions that were
never called. At the expense of some kludgy macros, and some runtime
costs.


Bo Persson

 

[Jerry Coffin]

(e-mail address removed)>,
(e-mail address removed) says...

On Apr 17, 5:00 am, "Alf P. Steinbach" <[email protected]> wrote:

[ ... ]

Are you referring Microsoft is not following C++ Design Pattern
rules?

No, what he's referring to is the fact that it has "Microsoft" in the
name, and therefore is widely viewed as am embodiment of evil.

In reality, MFC does use a general design that's generally considered
outdated in C++ circles (most of the classes belong to a single,
large hierarchy). It has a number of other shortcomings as well, such
as including more implicit conversions than some people prefer.

Nonetheless, the "~all possible wrong ways to do things" is an
serious exaggeration.

What is the reason why MFC should be avoided? I have heard
that MFC does not improve performance.

Almost no framework improves performance -- they generally make
development easier at some cost in performance. In the case of MFC,
the reduction in performance is pretty small (smaller than with most
alternatives).

Exactly how much it eases development is open to some argument (and
has been argued, incessantly, for almost two decades now. The system
as a whole (MFC in conjunction with Visual Studio) clearly improves
productivity compared to programing for the raw API. The question is
how much of that is really due to MFC, and how much to the other
"stuff" they provide that they don't provide for the raw API. From a
practical viewpoint, that doesn't matter a whole lot: you're
comparing what IS available against what people imagine could be made
available if somebody (e.g., Microsoft) wanted to. Regardless of
whether MFC is a major contributor here or not, if you want to use
those, you're pretty much stuck with MFC.

At least if you use Microsoft's development tools, you're also stuck
with the fact that while they provide alternatives (WinForms, WPF,
..NET in general), they take pretty much the same situation even
further: even worse-designed frameworks, only rendered marginally
usable by *lots* more support in the environment.

If you decide to use other tools, you have a few choices: wxWidgets
was originally designed as essentially a clone of MFC, and that's
pretty much still the case. It includes pretty much all the same
problems as MFC, but without the wizards and such that let you ignore
most of the cruftiness in MFC. There are a few IDEs oriented toward
wxWidgets, but at least when I've tried them, they've been rather a
mixed bag. None I've found really competes with VS/MFC.

Qt is a rather nicer design, but unless the software you develop is
free, open source, the price is *quite* steep. At least in my
experience, its advantages are also mostly theoretical -- using it is
more enjoyable, but not really any faster. Qt does *much* better than
most portable frameworks at following the native look and feel in
each platform -- but it's still well short of perfect. There's still
a *bit* of an awkward, foreign feel compared to an MFC application.

There are quite a few others, but you get the general idea. There are
always at least a few qualifications associated with any "better"
framework; it's better for some purposes, but not as good for others.

If you want to use WIN32
programming, WIN32 API functions are recommended instead of using MFC.

Recommended by whom and for what?

 

[Öö Tiib]

Qt is a rather nicer design, but unless the software you develop is
free, open source, the price is *quite* steep.

What price? QT is LGPL. There are some special cases for hand held
devices, where Nokia has some business interest, but MFC does not work
there either.

At least in my
experience, its advantages are also mostly theoretical -- using it is
more enjoyable, but not really any faster. Qt does *much* better than
most portable frameworks at following the native look and feel in
each platform -- but it's still well short of perfect. There's still
a *bit* of an awkward, foreign feel compared to an MFC application.

MFC app looks professional with its 16-color toolbar buttons? Come on.
It looks like "two decades ago".

 

[Jerry Coffin]

What price? QT is LGPL. There are some special cases for hand held
devices, where Nokia has some business interest, but MFC does not work
there either.

It's available under LGPL, but there's also a commercial license.
See:

http://qt.nokia.com/products/licensing/licensing#qt-commercial-
license

for more details. Depending on what you're developing, you may not
need that, but if you do, the price is quite steep (or was the last
time I checked anyway).

MFC app looks professional with its 16-color toolbar buttons? Come on.
It looks like "two decades ago".

With any reasonably current version of VS, you get 24-bit toolbar
buttons by default. That's definitely the case with VS 2008 and 2010.
I don't have a copy of VS 2003 installed right now to check, but I'm
_pretty_ sure it was true then as well.

It hardly seems reasonable to complain that if you develop MFC
applications with, say, VS 6, the results (at least by default) look
like something from the 1990's. After all, it IS from the 1990's!

 

[Öö Tiib]

It's available under LGPL, but there's also a commercial license.

You originally seem to claim that one can use it only for free and
open source products and that is certainly not true. LGPL is not
suitable for the people who produce closed source software AND need to
enhance or repair the QT library itself in process AND refuse to
publish the source code parts that they made to extend or repair the
library. It is really special case. Does not matter to most.

With any reasonably current version of VS, you get 24-bit toolbar
buttons by default. That's definitely the case with VS 2008 and 2010.
I don't have a copy of VS 2003 installed right now to check, but I'm
_pretty_ sure it was true then as well.

I got VS 2005 IDE here. NO, it has 16 color toolbar bitmaps. 2005 is
patched 6 times so it is stable. VS 2010 is still beta. You seriously
suggest to use anything from it versus well tested and stable GUI like
QT? 2010 IDE itself is good example of "awkward and foreign
feel" (your words) as bonus it is seriously unstable too.

 

[Jerry Coffin]

[ ... ]

I got VS 2005 IDE here. NO, it has 16 color toolbar bitmaps. 2005
is patched 6 times so it is stable. VS 2010 is still beta. You
seriously suggest to use anything from it versus well tested and
stable GUI like QT? 2010 IDE itself is good example of "awkward and
foreign feel" (your words) as bonus it is seriously unstable too.

VS 2010 is released, not beta. That the beta was unstable is hardly
unexpected.

You've also ignored VS 2008 completely, and it definitely uses 24-bit
bitmaps for the toolbar as well.

I've made no secret of the fact that I think Microsoft's recent IDEs
have been pretty poor -- I think they're serious steps backwards from
VS 6 in many ways -- but that doesn't affect the programs that they
produce.

 

[Öö Tiib]

VS 2010 is released, not beta. That the beta was unstable is hardly
unexpected.

That "released" is also not stable, as expected.

You've also ignored VS 2008 completely, and it definitely uses 24-bit
bitmaps for the toolbar as well.

That is true, VS 2008 can select count of bits for toolbar bitmap.
Have switched to other solutions, that is why i did not even notice
that it is not 16 colors anymore for VS 2008. I do not use it because
it seems to leak memory (grows from 200MB to 1GB rather quickwith
medium size project) and then tends to hang when debugging. It is best
to debug with VS 2005 and to build releases with Intel's compiler and
that leaves 2008 out of toolchain.

When someone asks for C++ GUI that is useful for making Windows
applications (commercial or otherwise) then QT is currently most sexy.

 

[Jerry Coffin]

That "released" is also not stable, as expected.

In my experience, it's more stable than any service pack of VS 2005,
or VS 2008 (with or without SP1).

[ ... ]

That is true, VS 2008 can select count of bits for toolbar bitmap.
Have switched to other solutions, that is why i did not even notice
that it is not 16 colors anymore for VS 2008. I do not use it because
it seems to leak memory (grows from 200MB to 1GB rather quickwith
medium size project) and then tends to hang when debugging. It is best
to debug with VS 2005 and to build releases with Intel's compiler and
that leaves 2008 out of toolchain.

It seems a bit strange that on one hand you claimed to be unaware of
the very existence of VS 2008, or even really simple characteristics
of what it produces, but suddenly you turn around and claim in-depth
knowledge of its memory usage and stability.

Self-contradictory claims like this raise *substantial* doubts about
your veracity.

When someone asks for C++ GUI that is useful for making Windows
applications (commercial or otherwise) then QT is currently most sexy.

I guess that depends somewhat on what you consider "sexy". Just for
example, recent versions of MFC support ribbon bars in addition to
classic menus. I can't say I'm particularly fond of them personally
(a euphemism for "I really despise them") but Microsoft Office uses
them, and quite a few people take that as synonymous with "how things
should be done." It's fairly trivial to support with MFC, but I don't
know of any other framework that supports them (and I specifically
looked for it in Qt -- if it's there, it's *very* well hidden).

 

[Öö Tiib]

In my experience, it's more stable than any service pack of VS 2005,
or VS 2008 (with or without SP1).

2010 i won't use anyway since it removed custom build rules. There is
some sort of terrible trash (do not remember the MS name of that
concept) instead of these so using it is out of question. IDE that can
not integrate simple Perl script has no right to call itself IDE IMO.

[ ... ]

That is true, VS 2008 can select count of bits for toolbar bitmap.
Have switched to other solutions, that is why i did not even notice
that it is not 16 colors anymore for VS 2008. I do not use it because
it seems to leak memory (grows from 200MB to 1GB rather quickwith
medium size project) and then tends to hang when debugging. It is best
to debug with VS 2005 and to build releases with Intel's compiler and
that leaves 2008 out of toolchain.

It seems a bit strange that on one hand you claimed to be unaware of
the very existence of VS 2008, or even really simple characteristics
of what it produces, but suddenly you turn around and claim in-depth
knowledge of its memory usage and stability.

Where did i say that i did not know that VS 2008 existed? I have them
all (since MSVC 6.0) in boxes somewhere, and so i verified, yes it did
have 24 bit bitmaps. If I do not use the MFC since 2004, then i do not
also care about its characteristics in 2008. 2008 was less stable than
2005 and so i uninstalled it. Perhaps will install again when more
service packs come out.

Self-contradictory claims like this raise *substantial* doubts about
your veracity.

It was you who claimed that 2003 had 24 bit toolbar bitmaps, i opened
2005 and even that did have 4 bit toolbars. Seems that we enjoy at
least equal level of *substantial* doubts there.

I guess that depends somewhat on what you consider "sexy". Just for
example, recent versions of MFC support ribbon bars in addition to
classic menus. I can't say I'm particularly fond of them personally
(a euphemism for "I really despise them") but Microsoft Office uses
them, and quite a few people take that as synonymous with "how things
should be done." It's fairly trivial to support with MFC, but I don't
know of any other framework that supports them (and I specifically
looked for it in Qt -- if it's there, it's *very* well hidden).

Nope, it is not in QT, MS has something patented in that ribbon to
block competitors. One can not use these on other platforms unless he
avoids selling the product in US. Usability engineers do not usually
suggest such thing anyway. It is basically a tabbed toolbar? It takes
too much clicks/keypresses to activate, looks distracting and most
users like menus more.

 

[Jerry Coffin]

[ ... ]

Where did i say that i did not know that VS 2008 existed? I have
them all (since MSVC 6.0) in boxes somewhere, and so i verified,
yes it did have 24 bit bitmaps.

You started out by saying:"MFC app looks professional with its 16-
color toolbar buttons? Come on. It looks like 'two decades ago'. "

So, at least now you're admitting that was an outright falsehood.

[ ... ]

It was you who claimed that 2003 had 24 bit toolbar bitmaps, i
opened 2005 and even that did have 4 bit toolbars. Seems that we
enjoy at least equal level of *substantial* doubts there.

What I actually said was: "I don't have a copy of VS 2003 installed
right now to check, but I'm _pretty_ sure it was true then as well."

Trying to treat that as being dishonest in any way is simply twisting
the truth.

[ ... ribbon bars ]

Nope, it is not in QT, MS has something patented in that ribbon to
block competitors. One can not use these on other platforms unless he
avoids selling the product in US. Usability engineers do not usually
suggest such thing anyway. It is basically a tabbed toolbar? It takes
too much clicks/keypresses to activate, looks distracting and most
users like menus more.

Doing a bit of looking, MS seems quite open to licensing. Regardless
of that, MFC supports it, and Qt doesn't. Quite a bit of the "sexy"
parts of Qt have serious problems as well. The difference is that no
customer I've talked to seems to want any of Qt's poorly designed
elements, while quite a few *do* want (vociferously in some cases)
Microsoft's.

 

[Öö Tiib]

You started out by saying:"MFC app looks professional with its 16-
color toolbar buttons? Come on. It looks like 'two decades ago'. "
[ ... ]
What I actually said was: "I don't have a copy of VS 2003 installed
right now to check, but I'm _pretty_ sure it was true then as well."

Yes and i don't see the difference. I did not have 2008 installed
right then. I looked into what i had installed (VS 2005). GUI
designing support there still was same crap as i remembered. Today i
dug out my copy of 2008 looked into and agreed that i was mistaken
about particular count of bits. Did i start to accuse pointlessly of
lack of honesty and veracity? I even attached smiley to my reply to
display that i did not mean it too seriously.

Doing a bit of looking, MS seems quite open to licensing. Regardless
of that, MFC supports it, and Qt doesn't. Quite a bit of the "sexy"
parts of Qt have serious problems as well. The difference is that no
customer I've talked to seems to want any of Qt's poorly designed
elements, while quite a few *do* want (vociferously in some cases)
Microsoft's.

Why to worry? Apparently I do not compete with you satifying these
boisterously demanding Windows customers. There are plenty of
customers ... talented developers are in constant deficite. Also i
don't care to bash MS. Fine company and big deal of todays world wide
computerisation is thanks to Windowses running on every piece of scrap-
iron. VS 2005 IDE is useful (QT-creator or XCode aren't even close).
VS 2010 i won't use since it has lost vital features. Tabbed button
ribbons of MFC in VS 2010 are therefore all yours. ;-) If you are
happy with all that thing then good for you. Peace.