Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Visual C++: the need for MFC

Reply
Thread Tools

Visual C++: the need for MFC

 
 
jacob navia
Guest
Posts: n/a
 
      06-16-2008
Jerry Coffin wrote:
> In article <d6ac9a2d-fce0-4d88-bd8f-21fbae48d780
> @m3g2000hsc.googlegroups.com>, http://www.velocityreviews.com/forums/(E-Mail Removed) says...
>
> [ ... ]
>
>> Jocob is correct. Writing applications using in32 is not particularly
>> difficult.

>
> It isn't _particularly_ difficult, that's true.
>
> OTOH, using the raw API, you have about 50 lines of code to register a
> window class, create a window and make it visible. You have another 30-
> 40 lines for even an extremely minimal message processor. You have
> another 25 lines for a message loop plus calling the above. If you want
> an MDI application, roughly double all of those (i.e. you have to
> register an extra window class, create not just two but three windows,
> be ready to respond to messages to do things like cascade and tile the
> child windows, etc.)
>
> For beginners, this is rather intimidating: they have to write a couple
> of hundred lines of code (or so) just to get to the point of a bare
> minimum program that doesn't really even DO anything yet -- it just
> creates an empty window that you can resize, minimize, maximize, etc.
>
> For experienced programmers, it's no longer intimidating, but it is
> repetitive and boring. Nearly the only reasonable alternative is to use
> a library of one sort or another -- if you don't use a conventional
> library of object code, then you use a "library" of source code from
> which to cut and paste chunks of code to avoid retyping the same junk
> over and over and over again.
>


If you use lcc-win you just start the "wizard", check a few
checkboxes and all that is generated for you.

MDI applications are also generated. You have nothing to do but
fill the blanks.

The generated code is just straight C/Win API. It will compile
in all windows compilers. You are NOT forced to use lcc-win
afterwards!

> The bottom line is that for most people's programs most of the time,
> writing to the raw Win32 API is a pointless waste of time.
>


You gain all that time with the extra features that NO OTHER LIBRARY
can ever offer:

1: Stability. Contrary to the library XXX, the windows API is EXTREMELY
stable, and will not disappear any time soon. You can even run your
programs uder linux or solaris using the windows emulator "wine".


2: Speed. There isn't any time consuming layer of code between you
and the API.

3: Simplicity. If the library forgot to give you the feature "xxx" you
are dead. Using the windows API you get ALL features you have
available.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
 
 
 
Juha Nieminen
Guest
Posts: n/a
 
      06-16-2008
jacob navia wrote:
> 3: Simplicity.


This one made me ROTFL.
 
Reply With Quote
 
 
 
 
Jerry Coffin
Guest
Posts: n/a
 
      06-16-2008
In article <g35unk$mdf$(E-Mail Removed)>, (E-Mail Removed) says...

[ ... ]

> If you use lcc-win you just start the "wizard", check a few
> checkboxes and all that is generated for you.


Of course -- but if you're using Wizard-generated code, you might as
well also save recompiling those bits along with the code you care
about, and pull those pieces from a library instead.

> MDI applications are also generated. You have nothing to do but
> fill the blanks.


Yippie.

> The generated code is just straight C/Win API. It will compile
> in all windows compilers. You are NOT forced to use lcc-win
> afterwards!


Oooh! I can certainly see how "it does the same thing as everybody else,
but 15 years later" qualifies for an exclamation point.

> > The bottom line is that for most people's programs most of the time,
> > writing to the raw Win32 API is a pointless waste of time.
> >

>
> You gain all that time with the extra features that NO OTHER LIBRARY
> can ever offer:


What a bunch of BS.

> 1: Stability. Contrary to the library XXX, the windows API is EXTREMELY
> stable, and will not disappear any time soon. You can even run your
> programs uder linux or solaris using the windows emulator "wine".


MFC (for one obvious example) has been sufficiently stable that I have
code originally written for 16-bit Windows that works, unmodified,
beautifully under both 32-bit and 64-bit Windows.

Of course, if WINE meets its goals, it should allow essentially all
Windows programs to run under any system that can host WINE -- whether
it uses other libraries or not.

> 2: Speed. There isn't any time consuming layer of code between you
> and the API.


What makes you think that code generated by your Wizard will be any
faster than the same code if it was in a library instead?

> 3: Simplicity. If the library forgot to give you the feature "xxx" you
> are dead. Using the windows API you get ALL features you have
> available.


Complete nonsense from beginning to end. Using a library does not
restrict you from using the API directly when/if you want to do
something the library doesn't support directly.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      06-16-2008
Jerry Coffin wrote:
> In article <g35unk$mdf$(E-Mail Removed)>, (E-Mail Removed) says...
>
> [ ... ]
>
>> If you use lcc-win you just start the "wizard", check a few
>> checkboxes and all that is generated for you.

>
> Of course -- but if you're using Wizard-generated code, you might as
> well also save recompiling those bits along with the code you care
> about, and pull those pieces from a library instead.
>
>> MDI applications are also generated. You have nothing to do but
>> fill the blanks.

>
> Yippie.
>
>> The generated code is just straight C/Win API. It will compile
>> in all windows compilers. You are NOT forced to use lcc-win
>> afterwards!

>
> Oooh! I can certainly see how "it does the same thing as everybody else,
> but 15 years later" qualifies for an exclamation point.
>


Yes, this is nothing new. Obviously when something works, and
works well, the fact that has worked well for 15 years is a flaw.
It must be thrown away and replaced with the latest fad immediately.

>>> The bottom line is that for most people's programs most of the time,
>>> writing to the raw Win32 API is a pointless waste of time.
>>>

>> You gain all that time with the extra features that NO OTHER LIBRARY
>> can ever offer:

>
> What a bunch of BS.


That means actually:

"I disagree with the views of jacob". Apparently you are unable
to discuss in a less emotional way. Well, who cares.

>
>> 1: Stability. Contrary to the library XXX, the windows API is EXTREMELY
>> stable, and will not disappear any time soon. You can even run your
>> programs uder linux or solaris using the windows emulator "wine".

>
> MFC (for one obvious example) has been sufficiently stable that I have
> code originally written for 16-bit Windows that works, unmodified,
> beautifully under both 32-bit and 64-bit Windows.
>


MFC is obsolete and hasn't been updated for several YEARS now.
Obviously, the code written using MFC will still work, but you can't use
all the features that have been added to the API using MFC now.

Microsoft decided to go the C# way, and all the MOUNTAINS of code
written using MFC are all obsolete. The MFC which they depend on
is no longer being developed.

That shows the problem with using third party libraries very well!

Either you port the MFC code to using the API (a huge task) or
you rewrite the applications form scratch, or you use the API for the
new features, and leave the old code as is...

Nice alternatives.


> Of course, if WINE meets its goals, it should allow essentially all
> Windows programs to run under any system that can host WINE -- whether
> it uses other libraries or not.
>
>> 2: Speed. There isn't any time consuming layer of code between you
>> and the API.

>
> What makes you think that code generated by your Wizard will be any
> faster than the same code if it was in a library instead?
>


Because there is one layer of indirection less than when you call
the API directly. The library needs to translate the calls you
do into library code that calls the API anyway.

Note that we are talking about using the API directly in your
application. The "wizard" code just gets you started with a
common boilerplate, it doesn't write the application for you.

>> 3: Simplicity. If the library forgot to give you the feature "xxx" you
>> are dead. Using the windows API you get ALL features you have
>> available.

>
> Complete nonsense from beginning to end. Using a library does not
> restrict you from using the API directly when/if you want to do
> something the library doesn't support directly.
>


Yes, you are right. You have just to learn the library, then
learn the API anyway. Fine. Go on using MFC then. It is no longer
developed but who cares?

Or switch to the Borland library (forgot the name).
It is no longer being developed.

Or switch bto one of the COUNTLESS libraries done during the last
15 years of windows. Most of them are no longer running, forgotten,
whatever.

Only those people that used the windows API are now able to develop
their applications without any problems now!




--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      06-17-2008
In article <g36nmh$kfc$(E-Mail Removed)>, (E-Mail Removed) says...

[ ... ]

> > Oooh! I can certainly see how "it does the same thing as everybody else,
> > but 15 years later" qualifies for an exclamation point.
> >

>
> Yes, this is nothing new. Obviously when something works, and
> works well, the fact that has worked well for 15 years is a flaw.
> It must be thrown away and replaced with the latest fad immediately.


Please read what I said -- I only commented on the exclamation point,
and specifically its use to emphasize something that's been well known
and in widespread use for well over a decade.

> >>> The bottom line is that for most people's programs most of the time,
> >>> writing to the raw Win32 API is a pointless waste of time.
> >>>
> >> You gain all that time with the extra features that NO OTHER LIBRARY
> >> can ever offer:

> >
> > What a bunch of BS.

>
> That means actually:
>
> "I disagree with the views of jacob". Apparently you are unable
> to discuss in a less emotional way. Well, who cares.


Not so -- below I pointed out exactly HOW each point is BS. Worse, your
reply is based almost entirely on more BS -- specifically, the false
claim that MFC is no longer in active development.

> >> 1: Stability. Contrary to the library XXX, the windows API is EXTREMELY
> >> stable, and will not disappear any time soon. You can even run your
> >> programs uder linux or solaris using the windows emulator "wine".

> >
> > MFC (for one obvious example) has been sufficiently stable that I have
> > code originally written for 16-bit Windows that works, unmodified,
> > beautifully under both 32-bit and 64-bit Windows.
> >

> MFC is obsolete and hasn't been updated for several YEARS now.


False! It was updated (significantly) for Visual Studio 2008 -- which is
to say within the last few months (note how I've used the exclamation
point to emphasize something that clearly is NOT known to many
developers).

> Obviously, the code written using MFC will still work, but you can't use
> all the features that have been added to the API using MFC now.


I'm not sure about _all_, but then again, I'm pretty sure you can't use
_all_ the new features from the raw API either -- a fair amount is now
available only via .NET.

> Microsoft decided to go the C# way, and all the MOUNTAINS of code
> written using MFC are all obsolete. The MFC which they depend on
> is no longer being developed.


A communist leader once (rather famously) claimed that repeating a
falsehood (or maybe "lie") often enough could make it true. His theory
should have died with him, but apparently some aren't willing to let
even the worst of ideas go.

> That shows the problem with using third party libraries very well!
>
> Either you port the MFC code to using the API (a huge task) or
> you rewrite the applications form scratch, or you use the API for the
> new features, and leave the old code as is...
>
> Nice alternatives.


You left out the obvious alternative: continue to use MFC which is still
undergoing active development, directly contrary to your false claims.

[ ... ]

> >> 2: Speed. There isn't any time consuming layer of code between you
> >> and the API.

> >
> > What makes you think that code generated by your Wizard will be any
> > faster than the same code if it was in a library instead?
> >

> Because there is one layer of indirection less than when you call
> the API directly. The library needs to translate the calls you
> do into library code that calls the API anyway.


I suppose if you insist on using an amazingly primitive compiler that
can't generate calls inline, this could be true. A decent compiler will
remove this handicap, and make quite a bit of the other code faster as
well.

The reality is that the code should be put into functions for the sake
of organization, and the compiler should take care of trivia like
whether to actually call it or generate it inline. Yes, if you've really
verified that the compiler is doing the wrong thing with code that's
really critical, it can be worthwhile to do some work to get what you
want -- but it's _incredibly_ unlikely to be the case here --
registering a window class (for example) isn't usually something you do
in a tight or deeply nested loop. Quite the contrary, it's something you
rarely do more than a handful of times even in a reasonably large
program, and it's slow enough that the difference between calling or
inlining the function that does it is likely to make a difference in the
range of parts per million, not something you'd even reasonably measure
in fractions of a percent.

> Note that we are talking about using the API directly in your
> application. The "wizard" code just gets you started with a
> common boilerplate, it doesn't write the application for you.


Gee really. Next you're going to tell me that despite the name, it
really doesn't do any magic or read the user's mind?

> >> 3: Simplicity. If the library forgot to give you the feature "xxx" you
> >> are dead. Using the windows API you get ALL features you have
> >> available.

> >
> > Complete nonsense from beginning to end. Using a library does not
> > restrict you from using the API directly when/if you want to do
> > something the library doesn't support directly.
> >

>
> Yes, you are right. You have just to learn the library, then
> learn the API anyway. Fine. Go on using MFC then. It is no longer
> developed but who cares?


Repeating the falsehood yet again still hasn't made it true. In any
case, if you know the API well enough to use it directly, using MFC (for
one example) is truly trivial. Trying to act like it adds a great deal
of extra work is so misleading that it borders on (yet another)
falsehood.

> Or switch to the Borland library (forgot the name).


Presumably you mean OWL.

> It is no longer being developed.
>
> Or switch bto one of the COUNTLESS libraries done during the last
> 15 years of windows. Most of them are no longer running, forgotten,
> whatever.


Most that I've seen still run as well as they ever did. Just for
example, changing the name from wxWindows to wxWidgets doesn't seem to
have caused any major problem with keeping the code working.

> Only those people that used the windows API are now able to develop
> their applications without any problems now!


Rather the contrary -- they've had problems all along, and they continue
to do so. In reality, rewriting most of the applications two or three
times over using one library after another would STILL have been less
work than doing it just once using the raw API.

Also keep in mind that when Win32 was introduced, there were substantial
changes in how messages were packed, so anybody using the raw API
previously had to do substantial rewriting just to get their code to
work under Win32.

Porting from 32- to 64-bit Windows _can_ be reasonably painless as long
as you use the types that were designed specifically to support the
port. Unfortunately, most Win32 code doesn't, and most Win32
documentation doesn't even make clear what types are needed when. As
such, unless all your code was written very carefully within the last
couple of years or so, you're going to be rewriting a lot of it again if
it uses the raw API. By contrast, if it uses almost any halfway decent
library, all of that is handled in the library, and you deal only with
far more abstract types that haven't changed a bit.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
Matthias Buelow
Guest
Posts: n/a
 
      06-17-2008
jacob navia wrote:

> Only those people that used the windows API are now able to develop
> their applications without any problems now!


And they'll run only on Windows (Wine is a half-working hack, not a
robust platform.) Applications today are best developped in a
cross-platform way, this not only makes them easier ported to other
existing systems, it also makes them more portable towards future
developments just in the same way that writing in a higher-level
language compared to assembler will make your software more portable if
the industry moves on from processor type X to processor type Y.
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      06-17-2008
Jerry Coffin wrote:
>> MFC is obsolete and hasn't been updated for several YEARS now.

>
> False! It was updated (significantly) for Visual Studio 2008 -- which is
> to say within the last few months (note how I've used the exclamation
> point to emphasize something that clearly is NOT known to many
> developers).



MFC's last update was in 1998. Ten years passed and nothing was updated,
until now. I did not know about this new release. So, obviously a
library that is updated in a 10 YEAR basis is considered OK.

There is no point in discussing this further.

Use MFC. I will go on using the API.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Dilip
Guest
Posts: n/a
 
      07-01-2008
On Jun 17, 12:49*am, Jerry Coffin <(E-Mail Removed)> wrote:
> False! It was updated (significantly) for Visual Studio 2008 -- which is
> to say within the last few months (note how I've used the exclamation
> point to emphasize something that clearly is NOT known to many
> developers).


Jerry needs no support from me but just to bolster his point, please
read the Visual C++ team blog's latest entry:
http://blogs.msdn.com/vcblog/archive...the-booth.aspx

The recent updates to MFC apparently was the talk of TechEd 2008.

Also, I don't know if Jerry knows about this but John Torjo's template
based C++-GUI library is also shaping up to be a fine competitor:
http://msdn.microsoft.com/en-us/magazine/cc534994.aspx
 
Reply With Quote
 
feedscrn
Guest
Posts: n/a
 
      07-04-2008
I suppose it depends on what you are after...

If you are developing your own applications, please see above posts.

Otherwise, if you are looking for a job in C/C++, then the above is
probably a moot point. It would then be prudent to learn MS or
whatever compiler would impress a potential employer these days.

Feedscrn
 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      07-07-2008
In article <22a707fe-d775-4a99-b3af-dd8ed82d5159
@r66g2000hsg.googlegroups.com>, (E-Mail Removed) says...
> On Jun 17, 12:49*am, Jerry Coffin <(E-Mail Removed)> wrote:
> > False! It was updated (significantly) for Visual Studio 2008 -- which is
> > to say within the last few months (note how I've used the exclamation
> > point to emphasize something that clearly is NOT known to many
> > developers).

>
> Jerry needs no support from me but just to bolster his point, please
> read the Visual C++ team blog's latest entry:
> http://blogs.msdn.com/vcblog/archive...the-booth.aspx
>
> The recent updates to MFC apparently was the talk of TechEd 2008.


Right -- I should also mention that although it's clearly the _largest_
update to MFC in quite a while, this really is NOT the first in ten
years as was stated elsethread. Documentation of them has been minimal
(to put it nicely) but I believe every release of the compiler has
included at least a few minor updates to MFC.

> Also, I don't know if Jerry knows about this but John Torjo's template
> based C++-GUI library is also shaping up to be a fine competitor:
> http://msdn.microsoft.com/en-us/magazine/cc534994.aspx


Yup -- while this clearly has a lot less support, it also looks like
quite a decent library.

--
Later,
Jerry.

The universe is a figment of its own imagination.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Need help with exposure of object in MFC visual c++ Test C++ 2 03-17-2006 01:43 AM
Derive from MFC DLL to MFC APP yopwojtek C++ 1 08-06-2005 05:12 PM
Debug (DLL MFC) -> Debug (Static MFC) ringos75 C++ 0 04-14-2005 01:50 PM
Visual C++ MFC error with Windows XP Jimmie C++ 1 08-26-2003 02:17 AM
Re: Using advanced MFC components without the use of MFC Scott McPhillips C++ 0 07-05-2003 03:46 AM



Advertisments