What exactly would be the benefit of this?
Apart from that, C# and Java are not very different from each other. You can get many of that "features" from other Java languages, no need to move away from the JVM, so you can still benefit from the largest community.
You could even compile C/C++ to CIL and obviate the need for some architecture specific binaries.
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.)
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.
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.
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.
Then again, maybe I understood it wrongly back then and I surely don't have the knowledge of your team.
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.
EDIT: Instead of downvoting, please point out how LINQ is actually superior?
How do you extend the the java Stream API? for LINQ you just drop in a few extra extension methods for IEnumerable<T>, IOrederedEmumerable<T>, IQueryable<T>, etc.
How do you reverse a stream in java? (I know you need to evaluate the whole stream for that) You can write a utility method, but that will break the fluent readable logic. In C# you can do the very same thing, with the same method usable as an extension method keeping the readable fluent expression.
Starting a stream is a PITA itself, as it differs for Iterables, Arrays, Collections... Been there, done that. Not that with some utilities these could not be overcome, but it was an inferior experience to LINQ.
By calling .reverse() on it, and making it iterate the other way around?
> extension methods
Extension methods are something that’s really really problematic, and easy to create confusion with.
That said, I’d just import the functions I want to call on the stream into my local namespace with import static.
Edit: Just checked: https://docs.oracle.com/javase/8/docs/api/java/util/stream/S... no reverse().
Fyi for 1 year I have been working on a Stream API heavy app. Now working on a C# project with quite some LINQ. I know both sides to some extent...