4 ms·
> That way every language only needs to provide a connection to an intermediate specification, and it can connect to any language supporting that same specifica
by dwaite 6y ago
> That way every language only needs to provide a connection to an intermediate specification, and it can connect to any language supporting that same specification.
The intermediate specification would be another language, so it would have the same impedance mismatch as the other N languages do.
You have memory management issues, OOP inheritance issues, semantic differences. Just trying to do a interoperability layer for the different versions of character strings would be incredibly hard.
Microsoft did something similar to this with CLI, but most people will note that JScript.Net and VB.Net are really new languages that just are optimized for porting Javascript and Visual Basic code over. They also defined a proprietary extension to C++ that allowed it to deal with managed objects so that it could interoperate with CLI code - but this did not aim to expose unmodified C++ code. Rather, it allowed you to use proprietary extensions to manually build bridges between the two.
- flohofwoe 6y ago> The intermediate specification would be another language, so it would have the same impedance mismatch as the other N languages do. Yes, but even though this is a limitation, every language only needs to care about connecting to this one intermediate "language". This is also why going through a C API already works quite well. Also it's interesting to note that Microsoft's latest version of the WinRT APIs are providing a standard C++17 wrapper on top of COM APIs and don't require C++ language extensions anymore.
- pjmlp 6y agoTo the anger of Windows devs being told to wait for ISO C++23 or even ISO C++26, hoping that the standard gets the relevant papers for C++/WinRT VS tooling to catch up with C++/CX from 2012. Right now it is hardly better than ATL/WRL, but so is life when Windows team wins its political battles with DevTools.