Re: MFC future?

In article news:<uSvIfn19FHA.3980@xxxxxxxxxxxxxxxxxxxx>, Tom Serface wrote:
> This is just another illustration of the mixed message MSFT is sending to
> the community. Over the last few years they have managed to make C# look
> "cool" and "productive" and MFC (and C++) look "dated" and "unhip". I don't
> know if this is intentional or not (I suspect it's just one group doing a
> better marketing job), ...

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 haven't seen any major commercial desktop applications (including those
> from Microsoft) written in C#. That doesn't mean they don't exist, but I
> have asked around a lot. However, for RAD programming for internal use C#
> is sure easier to use to cobble together form or web based applications.

It seems to me that MS must have had some considerable investment in Java at
around the time of the Sun lawsuit, and that C# is the workaround they came up
with to salvage that investment (mechanical translation from Java to C#
wouldn't be difficult -- the concepts are very similar).

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?).

> Bottom line: I agree with you. The whole .NET message is often very
> confusing. In fact, I think it's misnamed.

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.

> Microsoft may have the resources to make the "pcode" idea work efficiently
> enough to actually make it fast enough for prime time ... or the computers
> may just catch up with the power needed to run these types of programs.

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).

> 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.

Cheers,
Daniel.



.

Relevant Pages

  • Re: Article of interest: Python pros/cons for the enterprise
    ... from many articles and postings across the internet memory management ... There are other downsides to garbage collection, ... not the way it goes in practice nowadays, ...
    (comp.lang.python)
  • Re: MFC future?
    ... major desktop applications written in C#. I've only seen a couple in Java. ... > it's the memory management model used in environments like .NET and Java. ... > everything is managed by garbage collection the garbage collector ends up ...
    (microsoft.public.vc.mfc)
  • Re: Heap and Memory Footprint
    ... If you have any mixed language objects (i.e. Java objects which have underlying native memory associated), when the object is created memory is allocated in both the Java heap and the C native heap. ... It is important to explicitly call close- otherwise if the object gets promoted to the old area, the memory will not be freed until the object gets garbage collected from the old area which can take a very, very long time (and in the worst case you may have the process hit a memory limit without a garbage collection occurring as only the Java heap's behaviour will trigger garbage collection). ...
    (comp.lang.java.machine)
  • Re: out of memory
    ... it is possible to Manage to write your own custom Managed Memory leak. ... Garbage Collection IS automatic, but unless you put your cans out on the ... the purpose of Memory Management ... A good practice is to put the app first on a staging server and then put it ...
    (microsoft.public.dotnet.framework.aspnet)
  • On Java being slow (was Re: C++, C# or Java.)
    ... > Very common mantra from nearly every java pundit except me. ... Poor programmers is a somewhat standard excuse, ... Garbage collection, of course, can theoretically be made faster than ... explicit memory management when given enough memory, ...
    (comp.lang.java.programmer)