Re: Argh! MS Office

In article <6v3ep8Fhvs9vU1@xxxxxxxxxxxxxxxxxx>, Chris Ridd
<chrisridd@xxxxxxx> wrote:

On 2009-02-06 17:12:49 +0000, Elliott Roper <nospam@xxxxxxxxx> said:

<snip>
And where Flash is a Zune. Oh dear.

Wrapping a turd in a Common Language Runtime is going to make it slow
as well as smelly.

If you mentally replace CLR with JVM, that gives you an idea of the
performance. Though I suspect the CLR's a tiny bit faster. Still feels
like a bad idea.

Have you looked at the CLR? Or is it CLI? Or is that CIL?
I think you get closest with the latter. CILly
It is *Postscript*
Well, reverse Polish and all numbers turned into ASCII strings.
It is time to revive tooth polarity for describing the mental anguish.

--
To de-mung my e-mail address:- fsnospam$elliott$$
PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248
.

Relevant Pages

  • Re: .NET and multilanguage programming (was: More static type fun.)
    ... neither the JVM nor .NET type systems can express ... > for languages in which every value is a first class object. ... - CLR assumes all pointers can be null, so enforces a check at every ... - No support for polymorphism (in the current version. ...
    (comp.lang.lisp)
  • Re: Hash table performance
    ... Note that an "Entry instance" is a value type on the CLR, ... JVM is incapable of expressing. ... Note that there is no object creation on the CLR and, indeed, I believe that ...
    (comp.lang.java.programmer)
  • Re: Brackets in C#
    ... // some other long-running code ... In this case you won't help the CLR in any way. ... could collect the Foo - Instance very earlier. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: Does project load DLL multiple times?
    ... | I thought it was only for avoiding dynamic compilation. ... Here is a snip from the MSDN Magazine article talking about NGEN ... native images are loaded by the CLR just like any other DLL. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Performance monitoring: strange error in .Net 2.0
    ... > There seems to be a strange interaction/conflict between ... bug in CLR 2.0 to me. ... My workaround is starting a separate thread before logging on to the other ...
    (microsoft.public.dotnet.framework.clr)
Loading