Re: MFC future?



Hi Daniel,

"Daniel James" <wastebasket@xxxxxxxxxxxxxxxx> wrote in message
news:VA.00000ca3.04289459@xxxxxxxxxxxxxxxxxxx

> It's perfectly understandable that MS should give prominence to it's
> newest
> (and so, presumably, least well-known) technology in order to get it
> better
> known. With ".NET" they've done that in spades, and I agree that this has
> had
> the unfortunate side-effect of drawing attention away from MFC, and of
> making
> MFC look less "cool" than it did before.

I can't argue with that and I understand.

> I've heard (from Microsoft's C++ people, at conferences, etc.) that "many"
> of
> MS's internal developers working on .NET applications have started to
> switch
> from C# to C++ now that (in VS2005) C++ supports the full range of
> facilities
> of the .NET runtime -- that was relayed in a way that suggested the number
> of
> people involved was not small, but the evidence is only anecdotal.

> So, I'd say, there must be quite a bit of C# code about inside MS --
> though
> what it's for I couldn't say (parts of "Vista" maybe?).

Note that I didn't say no one was using it, just that I hadn't seen any
major desktop applications written in C#. I've only seen a couple in Java.
They may be out there and just not on my RADAR screen. However, from what
I've heard not much of Vista is managed code.

> I agree. For a while everything seemed to have to have "net" in its name
> to be
> regarded as "cool", and MS fell for that as much as any.

Yeah, but it really doesn't seem to have much to do with "the NET" or "a
NET" so ... Of course, Visual Studio Managed doesn't have the same punch.
Fortunately they have dropped the .NET extention.

> MS have been playing with "pcode" for years -- people forget that MS C/C++
> for
> DOS had an option to generate interpreted code rather than native machine
> code
> (mostly for space efficiency) -- so they should have some experience! The
> state
> of networked computing hadn't then reached a level of maturity then that
> required "run anywhere" executables or MS might have preempted Java by a
> decade
> or so.
>
> pcode *can* work efficiently enough for prime time. The problem isn't
> pcode,
> it's the memory management model used in environments like .NET and Java.
> When
> everything is managed by garbage collection the garbage collector ends up
> having a lot of work to do, and memory footprints tend to balloon because
> collectors are written to be fast rather than rigorous. The .NET runtime
> is
> actually far better than the JVM in this respect because it does allow for
> explicitly managed memory as well as GC heap, so the burden on the
> collector
> can be kept to a minimum (in C++, at least).

No doubt.

>> Until then, I say, use the best tool for the job you're doing. Every
>> project is different.
>
> Other things being equal, that's *always* the best advice.

Safe advice at least :o)

Tom


.