While the author's assessment isn't wrong, it does leave out the positives of having a stable ABI. The reason why you want a stable ABI is so that you can do things like compile dynamically loaded...
While the author's assessment isn't wrong, it does leave out the positives of having a stable ABI. The reason why you want a stable ABI is so that you can do things like compile dynamically loaded code with different compiler versions and still be able to load and run it.
I work on designing an API for 3rd parties to hook into our application, and we abandoned C++ as the language of choice decades ago because of this problem. I'd rather we were using C++ for much of it, and so would our developers, but we couldn't because every release of the compiler potentially meant breaking existing plug-ins. And forget about developers trying to support the current and previous version, too.
So yeah, it comes at a cost, but so does breaking the ABI frequently. Calling the standard library "dead" because of this issue is just dumb.
While the author's assessment isn't wrong, it does leave out the positives of having a stable ABI. The reason why you want a stable ABI is so that you can do things like compile dynamically loaded code with different compiler versions and still be able to load and run it.
I work on designing an API for 3rd parties to hook into our application, and we abandoned C++ as the language of choice decades ago because of this problem. I'd rather we were using C++ for much of it, and so would our developers, but we couldn't because every release of the compiler potentially meant breaking existing plug-ins. And forget about developers trying to support the current and previous version, too.
So yeah, it comes at a cost, but so does breaking the ABI frequently. Calling the standard library "dead" because of this issue is just dumb.