4 ms·

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

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.