Re: MFC future?

In article news:<1134656107.669751.172870@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Rt
wrote:
> Obsolete? I don't think so. It is the IL concept that is obsolete.

The issue is not that the IL concept is obsolete -- it isn't, by any means
-- but that it is being misapplied (or, perhaps, applied over-zealously).
ILs have their place in certain types of architecture which require a
certain degree and type of security, and in those architectures ILs are
invaluable ... I'm thinking of browser-hosted applets, smartcards, plug-in
application architectures, things like those.

Note that it is the security aspect that is important, here, not that the
level of abstraction allows a single binary to be run on multiple disparate
platforms.

The idea that running an app in a sandbox enables runtime checks on
correctness to be made is an important one, and it does have application
for traditional desktop- and server-based applications as well as the
special cases I mentioned above. On the these more general computing
platforms, though, the sandbox is something of a last resort: if your
applications are provably correct and known to be trusted there is no
potential for the runtime errors that a sandbox can detect, so the sandbox
is arguably not needed. Of course, in the real world applications are not
provably correct and may not be trusted (and may not be supposed to be
running at all, in the all-too-common case of malware) so a sandbox may
have a part to play.

> ... all ILs assume the programmer wants less control ...

No. There are two issues here:

One is that an IL targets a virtual machine, and the virtual machine is an
abstraction of the underlying hardware. What control over that hardware the
VM gives depends in part on how much work the implementors of the VM wanted
to do, and in part on the capabilities that the underlying hardware may be
expected to have -- the VM abstracts a nebulous "generic" computer that
will map more-or-less well onto a number of physical platforms, and it
won't give total control over any one of them. That's not because anyone
thinks the programmer doesn't *want* control, it's because it is difficult
if not impossible to provide that control in a generic way.

The other reason is security. Part of the *purpose* of a VM is typically to
remove "control" from the programmer (whether he wants it or not) for the
sake of security. What the programmer *wants* isn't important, it's a
question of what it is *safe* to give him. This can be very important when
the code running in the VM is not known or trusted by the system on which
it is run - the VM polices the behaviour of the code and allows it only
those facilities that are permitted by some security policy. For example, a
typical JVM can distinguish between Java applications and applets running
in a browser; the JVM enforces a policy that states that applications can
access filestore but applets cannot.

> ... would you choose a programming language today (with an IL)
> for your next development project based on how hard it is to deal with
> memory leaks in C++? I didn't think so.

That's interesting, but really has nothing to do with the question, because
garbage collection and ILs are orthogonal concepts. It's true, though that
when people look at IL-based systems today they tend to be thinking of Java
or .NET -- both of which do happen to use GC (and you can't turn it off).
With C++ (as you say) the language doesn't force you to use GC, but you can
used GC libraries if you wish.

In Java there can be serious resource management problems because the
language doesn't provide sufficient control primitives to allow resources
and resource scopes to be managed simply and effectively. Java does 99% of
the work of managing memory (and provides you with no help at all with the
last 1%) but leaves you out in the cold when it comes to managing any other
sort of resource -- Java's finalizers are a waste of space as they're not
guaranteed to be called, and finally blocks only work if you remember to
write them.

In contrast: C++'s variable scopes and deterministically-called destructors
provide the tools for management of resource lifetimes for all kinds of
resources; and there are standard programming idioms that -- if you stick
to them -- make it quite hard to 'forget' what little management code you
need to write. I'd say that dealing with memory leaks in C++ is actually
far easier than dealing with memory leaks in Java -- that is: if you have a
memory leak in C++ you *can* deal with it. If you're unlucky enough to have
one in Java you will probably have to rewrite your application architecture
to ensure that it doesn't happen, because there are no facilities in the
language to "fix" it.

I understand (though I have little first-hand experience) that the position
with C# is much the same as with Java, but that with Managed C++ you do add
destructors to the toolset, and that most if not all of the resource
problems that are impossible to solve in Java are at least approachable.

Cheers,
Daniel.


.