Hacker News Reader

Comment by zozbot234 | Hacker News Reader

C++ is really struggling with whether or not to break their ABI. But their "identity" is clear enough - much like C, they want to support their existing code, while still opening up support for newer features if possible. Rust could actually benefit from cribbing a few things that are now getting defined in C++, such as their support for heterogenous executors.

View on HN

C++ doesn't have a standardised ABI. I'm not aware of any languages that do, but I would be interested in any more information on this.

COM and Windows Runtime (WinRT) provide standardized ABIs across multiple languages. With the WinRT language projections, it's just like writing 'normal' code.

And with C++/WinRT you even get back the experience of how it was like to do ATL development.

So I gather that, much more than previous COM projections and templating libraries, C++/WinRT is much nicer to work with. And you can target the WinRT ABI with Rust, .NET (C#, F#, etc.), Python, and JS too.

I completely disagree, C++/CX was the best that Microsoft ever had closer to C++ Builder and they killed with their office politics.

On top of that, the C++/WinRT folks are adamant to push their east const preference into every Microsoft customer.

If you enjoy editing IDL files without tooling support and merging generated files by hand, please do.

I really didn't like C++/CX from the perspective of the fact that it added weird stuff to the existing syntax of the language, and it had no other compiler onboard other than Microsoft. These two probably killed it more than "office politics".

It is a framework for doing Windows development on Visual Studio, follows the same syntax as C++/CLI, in use since 2003, it doesn't matter if anyone else is on board.

Even today no other compiler can fit into WinUI/UWP workflows no matter what, unless one is willing to do lots of under the hood workarounds.

Office politics driven by people without any consideration for paying customers.

C doesn't have a standardized ABI, either, and yet it's the most widely used ABI in the world anyway.

Just because it isn't standardized doesn't mean it isn't stable & relied upon anyway. Clang & G++ are ABI compatible with each other, for example, and more importantly (and relevantly) both libstd++ & libcxx strive to maintain ABI compatibility ( https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html & https://libcxx.llvm.org/DesignDocs/ABIVersioning.html )

> both libstd++ & libcxx strive to maintain ABI compatibility

They don't, but they do keep it stable.

Alternative phrasing: they strive to maintain "backwards compatibility" rather than "compatibility with each other".

For libcxx & libstdc++ yes correct.

Clang, however, does strive to maintain compatibility with G++. So you can build a library with clang & use it from g++. It strives, and for the most part achieves, to be a drop-in replacement for GCC, which includes ABI compatibility.

There's the widely used Itanium C++ ABI [0], which contrary to the name is actually the one used on x86-64. Without a standard ABI it wouldn't be possible to dynamically link C++ libraries (which includes the standard library!), especially if they weren't compiled with identical compiler versions.

[0]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html

Reply on news.ycombinator.com