3 ms·
The CLR is not "most other VMs." You might say it's the exception that proves the rule. ;) Further, as I've pointed out to you before, the CLR does not really
by Rusky 7y ago
The CLR is not "most other VMs." You might say it's the exception that proves the rule. ;)
Further, as I've pointed out to you before, the CLR does not really support unmodified C and C++ as well as WebAssembly does. It supports C++/CLI instead, which is not a superset of standard C or C++. And worse, the main (only??) compiler for C++/CLI has no plans for keeping newer features of C++ working on the CLR.
In the context of this discussion about integrating GC into a VM that supports C and C++, the CLR is an odd choice of example anyway. The CLR doesn't aim to support existing languages unmodified, every port I've seen has been similar to C++/CLI in diverging from its original definition, specifically because of its memory and object models. And those are precisely what WebAssembly does away with.
- pjmlp 7y agoWebAssembly also does not support unmodified C and C++. What do you call emscripten and the language extensions it makes use of, then? One of the major features for .NET Core 3.0 was C++/CLI support. It is a major .NET language in Windows desktop applications, as it is more convenient than writing P/Invoke annotations. Also CLR is just the example more people nowadays can relate to, I can give other C and C++ bytecode examples.
- Rusky 7y agoYou don't have to use emscripten or its language extensions to build C or C++ for WebAssembly. And in the other direction, emscripten's raison d'etre is unmodified C and C++, by providing the platform APIs those unmodified programs use. .NET Core 3.0's C++/CLI support, again, is not standard C++ and never will be! It's just the same C++/CLI on a more up-to-date CLR.
- pjmlp 7y agoSo then help me here, I am kind of lost, in which ISO C page are EMSCRIPTEN_BINDINGS, EXPORTED_FUNCTIONS described, or WebIDL for that matter?
- Rusky 7y agoAs I originally pointed out, the difference between C++ and C++/CLI is that C++/CLI is not just a superset of standard C++. Things are changed or missing, not just added. You can't just take a pre-existing standard C++ program and drop it in a C++/CLI compiler because you'll hit all those differences. (Things may have been better in the past, but the C++/CLI spec has not kept up with the C++ standard at all and so the main implementation, when asked for "C++17 and C++/CLI," just kind of shrugs and makes a mess.) This is not true of emscripten. It does add some Javascript binding functionality, but that's no different from e.g. Linux or Windows offering their own platform APIs beyond the C++ standard library. You can just take a lot of pre-existing standard C++ programs, often including those that use platform-specific APIs, and drop it in emscripten!