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