35 ms·
Having actually used UWP SDK for C++ fairly recently, I was left with the impression that it's a complete non-starter for most folks. It assumes too much skill
by general_ai 10y ago
Having actually used UWP SDK for C++ fairly recently, I was left with the impression that it's a complete non-starter for most folks. It assumes too much skill on the part of the developer (i.e. "everything is asynchronous"), it uses a significantly extended superset of C++, and it inexplicably comes with _no_ libraries for such basic things as image processing, signal processing, linear algebra, etc -- stuff that Apple knocks out of the park. It's just basically WPF and very little else. Enough perhaps to write business apps, but way inadequate for anything outside this narrow niche. And because everything is async, and UI uses opaque data binding, the debugging experience tends to be a bit of a nightmare. I'm not sure what Microsoft was thinking, but Apple's approach to async (concurrent and serial queues in GCD) is an order of magnitude easier to understand, use, and debug, and OS X and iOS SDKs come with a ton more high quality features.
- bostand 10y agoI have no idea what your problems are, but I code UWP in C# which is the preferred language and its all fine and dandy here. (c++ .net is not real c++ anyway)
- general_ai 10y agoC# maybe. But C# is not suitable for what I do (fast deep learning on video, images, and audio). Any kind of managed language is hostile to those kinds of things and just plain not designed for them. I want to drop down to SIMD intrinsics and assembly when I need perf, and C# won't let me do so. But I think even folks with much more modest needs suffer with UWP. For instance, try to load an image from your hard drive (using UWP C++), resize it with Lanczos and get access to its pixels. The API is a fucking nightmare, there's no way to resize an image that I could find (unless you want to show it in the UI, in which case all is taken care of for you, but you can't get pixels from there). On macOS/iOS, it's just a few lines of rather plain looking code.
- pikzen 10y ago.Net offers reasonable SIMD access through the System.Numerics package. Roslyn offers writing plain IL Assembly, which is heavily used throughout SharpDX, and ultimately, P/Invoke is fast and allows you to call any C++ library you might want if you really want to get down to the metal. Seems a better alternative to me that having to deal with the hilariously bad C++ UWP API
- general_ai 10y agoReally, you call this "reasonable SIMD" access: https://msdn.microsoft.com/en-us/library/system.numerics(v=vs.111).aspx https://msdn.microsoft.com/en-us/library/system.numerics(v=v...? For comparison get a load of Apple Accelerate: https://developer.apple.com/reference/accelerate https://developer.apple.com/reference/accelerate. Now that's "reasonable" SIMD access, and extremely heavily optimized on both macOS and iOS for both speed and power efficiency. Similar capabilities are just one command line incantation away in Linux. And if that's not enough, you get real, actual assembly, not some "IL assembly" where you have no control over what it will emit when converted to machine code. Here's another constraint you may have failed to consider: my code doesn't just run on Windows. I compile the same C++ code across all supported platforms with fairly minimal #ifdefs to adjust to platforms and SIMD ISA. Windows is the only platform that fights me every step of the way. Linux is great. macOS is great. iOS and Android are great. Goddamned bare metal is great (cross-compiling on Linux). UWP is awful and hostile.
- pikzen 10y agoFor 90% of the usage of SIMD instructions where people just want to parallelize iterating on lists, yes, that's reasonable enough. Apple Accelerate isn't a SIMD API, it's a higher level API that happens to use SIMD for its utilities. Apple makes great APIs, yes, I can't deny that. You seem to have forgotten P/Invoke where your performance critical C++ code can actually be called from C#. You get your assembly and everything whenever you want, for a low initial cost of calling your FFI. And you also get a pretty damn good UWP experience, as well as WPF, WinForms and a long list of UI toolkits. Let's be real for a second though, the Android NDK is an absolute joke , and calling the C++ experience on Android "great" might be pushing it a bit far.
- becarefulyo 10y agoThere is a new XAML feature called x:Bind where the XAML compiler code-gens the data binding code instead of the framework doing it all at runtime. You can set breakpoints in the generated code. https://msdn.microsoft.com/en-us/windows/uwp/xaml-platform/x-bind-markup-extension https://msdn.microsoft.com/en-us/windows/uwp/xaml-platform/x... Instead of C++/Cx, you can use the new C++/WinRT, which uses standard C++ syntax and adds "await" to make async programming much easier. https://github.com/Microsoft/cppwinrt https://github.com/Microsoft/cppwinrt