5 ms·

Better support for mixed managed/native code for one. There's P/Invoke, and .NET's byte code includes instructions for low level pointer manipulation (which C#

Better support for mixed managed/native code for one. There's P/Invoke, and .NET's byte code includes instructions for low level pointer manipulation (which C# exposes). You could even compile C/C++ to CIL and obviate the need for some architecture specific binaries.

kuschku 10y ago
Actually, with the JNA (not JNI), one can invoke native code from Java even easier than in C# – you just define a Java Interface containing the relevant C functions, bind the library, and get an Object implementing it.
- KMag 10y ago
  But that C/C++ code you're calling still needs to be compiled to native code. The GP was referring to .NET CIL (bytecode) supporting (by design) a large subset of C/C++ semantics. The GP wants to avoid shipping N different binaries for N platforms in cases where the C/C++ code being called isn't already on the platforms. I haven't used Managed C++ and I'm fuzzy on the details, but my understanding is that a fairly large subset of C/C++ can be efficiently compiled to .NET CIL. (Of course, the class loader for untrusted security contexts will refuse to load classes that use the type-unsafe/memory-unsafe portions of .NET CIL, just like the Java classloader for untrusted applets won't load classes making arbitrary JNI calls.)
  - int_19h 10y ago
    Based on what I know about CIL and C++, the entirety of C and C++ can be compiled to [unverifiable] CIL. The sole exception is setjmp/longjmp - this might be doable on top of CLI exceptions, but I'm not sure. And, indeed, VC++ lets you do just that. There are some bits of the standard library, mostly new stuff like threads and atomic, that had some issues, as I recall. But it's more about the amount of effort that's needed to target what's essentially a completely different platform. The thing to know about CIL is that it has: - structs; - unions; - raw data pointers, with pointer arithmetic; - raw function pointers; - dynamic stack allocation (like alloca in C); - tail calls; - exceptions with exception filters (arbitrary expression evaluation when deciding whether to transfer to a given catch-block or not) and finally blocks. I'm actually curious if there's any language that cannot be compiled down to this efficiently.
    - pjmlp 10y ago
      Dynamic languages cannot be easily mapped to CIL, which is why IronPython was the genesis of DLR extensions, later added as standard part of .NET.
      - int_19h 10y ago
        Dynamic languages typically aren't compiled, though. So either a language would have some kind of VM of its own (which is typically implemented in C, and hence can be implemented in CIL), or else they have some form of JIT compilation, which can use CIL as a target.
        pjmlp 10y ago
        Those are scripting languages. If you bothered to read why DLR was created, you will see why CIL wasn't enough. Or why Java following the same linr of thought had to follow DLR changes to the CLR and introduce invokedynamic byte code and its related infrastructure.
        int_19h 10y ago
        I know why DLR was created. I work on a team that has one of the guys who was working on it, and specifically on IronPython. My point is that they are two different layers in the stack. CIL and JVM are lower level. DLR is a higher level layer. Said higher level can be implemented on any kind of lower level that's powerful enough - for example, you could have a kind of DLR directly on top of native code. All that matters for the lower level is that it's flexible enough to permit something like DLR to be implemented on top of it. CIL is undeniably flexible enough for that.
        pjmlp 10y ago
        I remember reading some articles that justified DLR as CIL not having enough semantics that allowed to properly implement optimization algorithms commonly used in dynamic languages, like method lookup and call site caches. Then again, maybe I understood it wrongly back then and I surely don't have the knowledge of your team.
- int_19h 10y ago
  With C#, you can implement an IUnknown-derived interface completely in C++ (with `class` etc), and then define it in C#, and it transparently does all the mapping of members for you. Yes, it's COM. People assume that makes it non-cross-platform, but there's nothing Windows-specific about COM, it's just a slightly higher-level ABI than C. So Mono supports it on Linux in the same manner. Not sure what the story is in .NET Core.

kuschku 10y ago

Actually, with the JNA (not JNI), one can invoke native code from Java even easier than in C# – you just define a Java Interface containing the relevant C functions, bind the library, and get an Object implementing it.

KMag 10y ago
But that C/C++ code you're calling still needs to be compiled to native code. The GP was referring to .NET CIL (bytecode) supporting (by design) a large subset of C/C++ semantics. The GP wants to avoid shipping N different binaries for N platforms in cases where the C/C++ code being called isn't already on the platforms. I haven't used Managed C++ and I'm fuzzy on the details, but my understanding is that a fairly large subset of C/C++ can be efficiently compiled to .NET CIL. (Of course, the class loader for untrusted security contexts will refuse to load classes that use the type-unsafe/memory-unsafe portions of .NET CIL, just like the Java classloader for untrusted applets won't load classes making arbitrary JNI calls.)
- int_19h 10y ago
  Based on what I know about CIL and C++, the entirety of C and C++ can be compiled to [unverifiable] CIL. The sole exception is setjmp/longjmp - this might be doable on top of CLI exceptions, but I'm not sure. And, indeed, VC++ lets you do just that. There are some bits of the standard library, mostly new stuff like threads and atomic, that had some issues, as I recall. But it's more about the amount of effort that's needed to target what's essentially a completely different platform. The thing to know about CIL is that it has: - structs; - unions; - raw data pointers, with pointer arithmetic; - raw function pointers; - dynamic stack allocation (like alloca in C); - tail calls; - exceptions with exception filters (arbitrary expression evaluation when deciding whether to transfer to a given catch-block or not) and finally blocks. I'm actually curious if there's any language that cannot be compiled down to this efficiently.
  - pjmlp 10y ago
    Dynamic languages cannot be easily mapped to CIL, which is why IronPython was the genesis of DLR extensions, later added as standard part of .NET.
    - int_19h 10y ago
      Dynamic languages typically aren't compiled, though. So either a language would have some kind of VM of its own (which is typically implemented in C, and hence can be implemented in CIL), or else they have some form of JIT compilation, which can use CIL as a target.
      - pjmlp 10y ago
        Those are scripting languages. If you bothered to read why DLR was created, you will see why CIL wasn't enough. Or why Java following the same linr of thought had to follow DLR changes to the CLR and introduce invokedynamic byte code and its related infrastructure.
        int_19h 10y ago
        I know why DLR was created. I work on a team that has one of the guys who was working on it, and specifically on IronPython. My point is that they are two different layers in the stack. CIL and JVM are lower level. DLR is a higher level layer. Said higher level can be implemented on any kind of lower level that's powerful enough - for example, you could have a kind of DLR directly on top of native code. All that matters for the lower level is that it's flexible enough to permit something like DLR to be implemented on top of it. CIL is undeniably flexible enough for that.
        pjmlp 10y ago
        I remember reading some articles that justified DLR as CIL not having enough semantics that allowed to properly implement optimization algorithms commonly used in dynamic languages, like method lookup and call site caches. Then again, maybe I understood it wrongly back then and I surely don't have the knowledge of your team.
int_19h 10y ago
With C#, you can implement an IUnknown-derived interface completely in C++ (with `class` etc), and then define it in C#, and it transparently does all the mapping of members for you. Yes, it's COM. People assume that makes it non-cross-platform, but there's nothing Windows-specific about COM, it's just a slightly higher-level ABI than C. So Mono supports it on Linux in the same manner. Not sure what the story is in .NET Core.