Any special reason why they put the length after the pointer? Or is it just a coincidence?
Question is not clear. The Slice is just an address of memory chunk combined with the length of that chunk. That's somehow better than "C strings" - that are just pointers and so you need to do some computation if you need to get length of the string. Such C strings have too many drawbacks - in particular strtok function that modifies input string (that shall be read only all times).
Well, both implementations do have a strict which has the length as last member. Is there any special reason for it? Something like struct-layout optimization?
Are .NET Core and Mono converging? I would have thought that they'd remain separate while both implementing .NET Standard, and becoming interchangeable as .NET Standard implementations.
I think Microsoft is missing a trick by at least making some of MVC5 target .NET standard. It would make it a lot easier to port apps over. Moving from asp.net to asp.net core is a big pain in the arse.
It seems like the kind of thing that should be possible - after all, Mono has had System.Web for a long time, and can run both MVC and Web Forms apps. I don't know anyone who has actually done so in production, though.
But although it's possible, I imagine there are lots of reasons why MS, or certain teams at MS, don't want it to happen. We'll see, though. I didn't expect them to make the decision to add WPF and WinForms support to .NET Core, but they did.
Everytime I start to think Microsoft is heading in the right direction they go and blow it all away again. This week we've already had a new asp.net core which drops support for .net standard and only supports .net core. And now, a new version of .net standard that .net fx isn't going to support. We are right back at the mess of portable class libraries with all their different supported profiles. It means app devs a…
Regards Portable Profile: I think the case is different. .NET Framework will just no longer evolve. It will always stay on .NET Standard 2.0.
.NET Standard is not a intersection. It is a small bubble being in a bigger bubble. And the biggest bubble is the latest. The reason Miguel and the Unity folks are so important in this process, is the fact that they have to agree to participate in the latest and biggest version of the Standard.
I do mainly desktop dev but reading that Core is now the platform with rapid improvements I wonder if it's possible to write WPF or UWP apps with .NET Core or Standard. Does anyone know?
Not WPF per se, but if you're looking for something similar check out https://github.com/AvaloniaUI/Avalonia
Xamarin Forms also has WPF, OSX, and GTK renderers, so it might be an option. Based on GitHub activity it looks like they're being worked on fairly actively, too.
> Given many of the API additions in .NET Standard 2.1 require runtime changes in order to be meaningful, .NET Framework 4.8 will remain on .NET Standard 2.0 rather than implement .NET Standard 2.1. .NET Core 3.0 as well as upcoming versions of Xamarin, Mono, and Unity will be updated to implement .NET Standard 2.1. At some point, is it reasonable to expect Xamarin, Mono, Unity, and .NET Core to all really be backed…
Mono and .NET Core will never merge. But it is not a black and white thingy. .NET Core has a sub project named corefx (Base Class Library), which acts as a master for most of the class library of Mono nowadays. However, the runtime below (mono or coreclr for .NET) are different animals. Mono is highly optimized on portable code (it runs in many more places than .NET Core) while .NET Core is tuned for performance. Uni…
That makes sense with regards to the runtimes and non-spec'd libs. But I was under the impression .NET Standard was essentially the class library spec and if .NET Core is/becomes the only impl of that class library spec it would seem strange to separate the spec from the impl when only one of each exists built by the same blessed implementer. I can definitely understand different compilers, AOT/JIT engines, GCs, etc. Even with minor .NET Standard impl differences in Mono, if they are so minor that they only augment .NET Core, it comes off as an optimization rather than a separate implementation. If the class library impl differences remain major, I would wonder why as surely, even when optimizing for portability vs performance, there is a lot of potential reuse.
Suggested naming standard: - .Net API Specification - (now known as .Net Standard) - .Net Windows - (now known as .Net Framework) - .Net Cross Platform - (now known as .Net Core)
Suggested naming standard: - .Net API Specification - (now known as .Net Standard) - .Net Windows - (now known as .Net Framework) - .Net Cross Platform - (now known as .Net Core)
I think .NET Standard is quite right. It is a" standard". And standards rarely have implementations on their own.
Mono and .NET Core will never merge. But it is not a black and white thingy. .NET Core has a sub project named corefx (Base Class Library), which acts as a master for most of the class library of Mono nowadays. However, the runtime below (mono or coreclr for .NET) are different animals. Mono is highly optimized on portable code (it runs in many more places than .NET Core) while .NET Core is tuned for performance. Uni…
That makes sense with regards to the runtimes and non-spec'd libs. But I was under the impression .NET Standard was essentially the class library spec and if .NET Core is/becomes the only impl of that class library spec it would seem strange to separate the spec from the impl when only one of each exists built by the same blessed implementer. I can definitely understand different compilers, AOT/JIT engines, GCs, etc.…
Consider e.g. the cryptography support in the .NET Standard. On Linux it is based on OpenSSL (AFAIR), on Windows based on the crypto library there, on MacOS on another one, on Android another one and let us not speak of iOS. All of them follow on the surface the same API spec. But behind the scenes all .NET implementations have different strategies to deal with. And for good reasons.
In this cases you need a standard but not a shared implementation.
Let me just check if I finally understand this: - .Net Framework: The Windows Specific (and nearly deprecated) branch - .Net Core: The replacement for Framework and cross platform branch (but with Windows specific libraries) - .Net Standard: A way to write something that runs on both .Net Framework and Core?
I would not call .NET Core having "Windows specific libraries". It is more like they have feature packages on-top, which are Windows specific.
Feature packages that contain Windows specific libraries? I guess I don't see the distinction you're trying to make.
That makes sense with regards to the runtimes and non-spec'd libs. But I was under the impression .NET Standard was essentially the class library spec and if .NET Core is/becomes the only impl of that class library spec it would seem strange to separate the spec from the impl when only one of each exists built by the same blessed implementer. I can definitely understand different compilers, AOT/JIT engines, GCs, etc.…
Consider e.g. the cryptography support in the .NET Standard. On Linux it is based on OpenSSL (AFAIR), on Windows based on the crypto library there, on MacOS on another one, on Android another one and let us not speak of iOS. All of them follow on the surface the same API spec. But behind the scenes all .NET implementations have different strategies to deal with. And for good reasons. In this cases you need a standard…
I don't think deferring by platform preference is enough of a reason to separate the standard from the abstracting implementation. Most languages, with or without a "standard" and multiple implementations, defer to the platforms' preferred ways of, say, obtaining cryptographically random numbers.