4 ms·

So, being pedantic, really it means you rely entirely on the GC for memory management. You can run unmanaged code on the CLR.

• pionar 13y ago
  That's not correct. Unmanaged code, by it's definition, is not run on the CLR. It's run natively by the OS, and is compiled to machine code, not IL. Managed code, on the other hand, by MS' own definition: "All of these languages share a unified set of class libraries and can be encoded into an Intermediate Language (IL). A runtime-aware compiler compiles the IL into native executable code within a managed execution environment that ensures type safety, array bound and index checking, exception handling, and garbage collection." [0] [0] http://msdn.microsoft.com/en-us/library/windows/desktop/bb318664%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb31... EDIT: I should add, that while unmanaged code does not run on the CLR, the CLR does act as a bridge between managed and unmanaged code.
  • MaulingMonkey 13y ago
    To expand on this... "So no native code is used." was probably somewhat misleading. More specifically, no native code is explicitly used. IL may be compiled down to e.g. x86-64, but you won't have a C DLL being PInvoked from your C# (or other .NET language), nor a C++/CLI DLL compiled against x86-64 specifically. Among other advantages, this usually implies: - Less interop overhead (unmanaged <-> managed transitions are expensive) - Easier dependency management (just include the assembly instead of assembly + native DLLs via installer or whatever) - Portable (more likely to run on e.g. the Mono Runtime on a Linux box with an ARM processor without requiring a build specific to ARM and possibly to Linux)
• f7t7ft7 13y ago
  That's one aspect, but probably not the most important, given that Lua already has GC without the CLR.