Re: C++ Programmer's Goldmine is on line now: http://www.cppgoldmine.comze.com/

From:

David Wilkinson <no-reply@effisols.com>

Newsgroups:

microsoft.public.vc.mfc,microsoft.public.vc.language

Date:

Sat, 17 Jan 2009 06:11:28 -0500

Message-ID:

<#br6ZRJeJHA.4180@TK2MSFTNGP06.phx.gbl>

David Ching wrote:

.NET performance is certainly an issue but .NET apps are still very
usable even if they are noticeably less snappy than native apps. In
general, all but the most impatient will be satisfied with .NET apps
running on a reasonably modern system. Especially since the
productivity of developing in .NET means the app tends to be more
full-featured and nice to use once it gets started.

I am using Xenocode PostBuild to get around the need to have .NET
installed.

I guess we define "wiz-bang" differently. For me, the real "wiz-bang"
features of .NET are the reusable things like layout panels. I rely on
the Telerik 3rd party framework for the ribbon (which of course comes
with a designer).

Sure, but hiring back Mike B. and forming a team around MFCX (as Bob
thought of) would represent probably 20x time the commitment. Again, no
one is saying their effort is insubstantial, but it is far from what I
would call a recommitment to MFC. I'm comparing to the kind of
deliverables Microsoft had in the VC2 - VC6 timeframes which established
VC as the premier development tool of Windows apps. Show me those kind
of deliverables and then I will recognize a recommitment to MFC.

I don't have any direct evidence but it does seem a stretch to call
those deliverables a recommitment to MFC, so it is speculation that it
was for other reasons advantageous to MS. I'd love to be proven wrong
and see some substantial additions to MFC(X) in Dev10.

David:

For me the major reason I do not consider incrementally allowing .NET components
into my existing MFC applications is the need to switch to dynamic linking of
CTR/MFC. Does Xenocode PostBuild do anything about that, or it just for .NET code?

As for MFC, I will not be happy until every way in which the IDE in inferior to
VC6 in convenience, reliability and speed is eliminated. I cannot believe this
would be a major effort. Surely it must be possible to figure out why the Add
(Control) Variable Wizard takes so long to come up (at least for some people,
including me). Of course, while they were at it they should replace this Wizard
with something at least as functional as the member variable tab of the VC6
ClassWizard. I cannot believe that one of this could not achieve this in a few
days, if given the opportunity (and some money...). Yet it is over six years
with nothing being done about it.

--
David Wilkinson
Visual C++ MVP