3 ms·

What's the pro of not having a stable ABI?

• Ygg2 1y ago
  Being able to change things. It's like all downsides of backwards compatibility but on a binary level As to things ABI prevents: - scoped_lock was added to not break ABI by modifying lock_guard - int128_t has never been standardized because modifying intmax_t is an ABI break. Although if you ask me, intmax_t should just be deprecated. - unique_ptr could fit in register with language modifications, which would be needed to make it zero-overhead, compared to a pointer - Many changes to error_code were rejected because they would break ABI - status_code raised ABI concerns - A proposal to add a filter to recursive_directory_iterator was rejected because it was an ABI break - A proposal to make most of <cstring> constexpr (including strlen) will probably die because it would be an ABI break. - Adding UTF-8 support to regex is an ABI break - Adding support for realloc or returning the allocated size is an ABI break for polymorphic allocators - Making destructors implicitly virtual in polymorphic classes - Return type of push_back could be improved with an ABI break - Improving shared_ptr would be an ABI break - [[no_unique_address]] could be inferred by the compiler should we not care at all about ABI Source: https://cor3ntin.github.io/posts/abi/ https://cor3ntin.github.io/posts/abi/
  • TuxSH 1y ago
    > Making destructors implicitly virtual in polymorphic classes Not sure what to think of this one. Either one introduces a new keyword to opt out (not great), or all public destructors of an abstract base class are implicitly marked virtual (not great and another "hidden" language feature like threadsafe-statics). After all, an abstract base class does not need its destructor to be public.