4 ms·

I don’t understand why they don’t do more about ABI. Compared to C# or java it’s such a pain to share code in C++. To me this would open up a lot of opportuniti

I don’t understand why they don’t do more about ABI. Compared to C# or java it’s such a pain to share code in C++. To me this would open up a lot of opportunities to create more libraries.

gpderetta 7y ago
They do. ABI breaking changes are routinely voted down unless they are really worth it (and the only non backward compatible change that was accepted that I'm aware is the std string changes in C++11).
- Ididntdothis 7y ago
  Maybe things are better now but in the past almost every new library I added to my projects required a lot of fiddling with headers , link options and other stuff. With C# this is so easy in comparison.
- steveklabnik 7y ago
  This paper is related and interesting: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p186...
  - Scramblejams 7y ago
    Thanks for the link, a good read. As somebody who kicks C++'s tires once in a while and is always put off by the incredible complexity of the language, and the complexity and friction and fragility of its workflow, I was sad not to see any explicit mention of pairing an ABI break with removal of the bad parts. (Yeah, I know, that might mean source-level backwards incompatibility...) Makes me wonder if it's ever even discussed at a high level.
gumby 7y ago
ABIis hard because C++ structures are typically more complex than C structures. While the C documentation could simply include the struct (and the ABI would constrain padding, etc), consider a simple std::string, which may (OK, will) have small string optimization: different runtime libraries might make different tradeoffs as to how to do this. You'd have to constrain the entire standard library for your platform which could forestall improvements down the road. The committee already unwittingly made that mistake with std::map and doesn't want to make that mistake again.
- CoolGuySteve 7y ago
  C++ also insists on inlining code extensively across the provider/client boundary, so if the offset of any data element changes the binary library is no longer backwards compatible. This is exacerbated by the lack of usability in compilation toolchains that promotes header-only libraries just for build simplicity and for which the data structures often won't be compatible across .so boundaries.
  - gumby 7y ago
    Not dissing your comment, just pointing out that the committee is not just aware of the problem but slowly doing what it can to address them. C++17 and C++20 have a bunch of features to improve both of these factors. There are also a number of features not really intended for user code designed to help make libraries faster, and more stable. The downside of course is, well, just look at library source. But really the source to the C standard library has similar issues. I don't like header-only libraries because they slow down compilation, and slowly the trend is starting to abate.

I don’t understand why they don’t do more about ABI. Compared to C# or java it’s such a pain to share code in C++. To me this would open up a lot of opportunities to create more libraries.

gpderetta 7y ago

They do. ABI breaking changes are routinely voted down unless they are really worth it (and the only non backward compatible change that was accepted that I'm aware is the std string changes in C++11).

Ididntdothis 7y ago
Maybe things are better now but in the past almost every new library I added to my projects required a lot of fiddling with headers , link options and other stuff. With C# this is so easy in comparison.
steveklabnik 7y ago
This paper is related and interesting: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p186...
- Scramblejams 7y ago
  Thanks for the link, a good read. As somebody who kicks C++'s tires once in a while and is always put off by the incredible complexity of the language, and the complexity and friction and fragility of its workflow, I was sad not to see any explicit mention of pairing an ABI break with removal of the bad parts. (Yeah, I know, that might mean source-level backwards incompatibility...) Makes me wonder if it's ever even discussed at a high level.

gumby 7y ago

ABIis hard because C++ structures are typically more complex than C structures. While the C documentation could simply include the struct (and the ABI would constrain padding, etc), consider a simple std::string, which may (OK, will) have small string optimization: different runtime libraries might make different tradeoffs as to how to do this. You'd have to constrain the entire standard library for your platform which could forestall improvements down the road. The committee already unwittingly made that mistake with std::map and doesn't want to make that mistake again.

CoolGuySteve 7y ago
C++ also insists on inlining code extensively across the provider/client boundary, so if the offset of any data element changes the binary library is no longer backwards compatible. This is exacerbated by the lack of usability in compilation toolchains that promotes header-only libraries just for build simplicity and for which the data structures often won't be compatible across .so boundaries.
- gumby 7y ago
  Not dissing your comment, just pointing out that the committee is not just aware of the problem but slowly doing what it can to address them. C++17 and C++20 have a bunch of features to improve both of these factors. There are also a number of features not really intended for user code designed to help make libraries faster, and more stable. The downside of course is, well, just look at library source. But really the source to the C standard library has similar issues. I don't like header-only libraries because they slow down compilation, and slowly the trend is starting to abate.