231–240 of 341 posts
Tizen would be OK if you didn't have to use eclipse
Tizen supporting .NET is the interesting thing in this article to me. If Microsoft got so far as getting UWP apps running on Tizen, Microsoft and Samsung could potentially offer a pretty compelling offering against Android.
Earlier quoted context omitted.
It does them. But it repeats the story with generics, where back-compat (in this case, lack of reified generics) requires hacks for acceptable performance. For example, in Java, you have this: http://docs.oracle.com/javase/8/docs/api/?java/util/function... Note all the permutations. This is necessary, because there's no way to define a generic interface that would have acceptable perf, due to boxing. So you end up de…
That doesn't affect me in any way though, from my POV, lambdas work.
Nice. Now please make C# a first-class citizen in Android and start to migrate from Java to C#.
Please just make C-ABI's first-class citizens (especially on the GUI front), then all other languages can bind to that.
What's really needed is some standard higher-level ABI (that does things like classes in a sane way), but which is made out of the existing C ABI building blocks in a manner that allows any existing language with C FFI use it. We can then add a new FFI layer that maps higher-level concepts better, but everyone can still play regardless.
This is exactly what COM was, and what its current evolution, WinRT, is. Any language that can do C structs and function pointers can ultimately do COM/WinRT, but it establishes things like lifetime semantics (refcounting), runtime metadata API, standardized futures etc on top of that. Then languages take that and map it to things that make sense there.
But it needs to be a shared public spec, preferably standardized.
Earlier quoted context omitted.
What magic are you talking about? Various .Net frameworks have silly amounts of magic, but C# itself?
When I started going into C# from Java a bit, there were two things slightly annoying me: - Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist. After I while I found out that the author of that snippet had used class extensions and not bothered to mention. - The var keyword: While this is sometimes nice for quick…
One thing that VS can now do (as of VS 2015) is tell you where exactly the "missing" extension method is, and offer to add a corresponding `using` declaration for you.
Not sure if VSCode or VS/Mac support that, though. But they are all built on the same code analysis engine, so there's no reason why they couldn't.
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
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.
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 la…
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.
Earlier quoted context omitted.
They said "has support for", not "is". This is a natural consequence of having value types (structs). You can even change the bit packing and other layout properties of structs.
Are you replying to the proper comment? In any case, he stated that an Android C# app would be more performant than an app coded in Java without supplying any metrics to prove his point. >This is a natural consequence of having value types (structs). You can even change the bit packing and other layout properties of structs. And yet the JVM still beats the CLR in performance.
On mobile memory-constrained devices? Can you share a benchmark demonstrating that?