[haiku-development] Re: [haiku-development]
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 17 Dec 2021 16:05:36 +0000
I think we are on the same page with this, though I would add caveat
that there may be some cases where we want to extend the legacy C++98
kits with some specific features when it adds value. For me, adding
support for noexcept moves to BString is one of those examples.
The specific case for adding these compatibility constants is for the
BError class. Since this new addition to the API is not specific to
the network kit, I thought it might be good to live in libbe.so. But
it may be too early.
It can be:
1. Stay in libbe.so but be modern C++ only.
2. Stay in libbe.so in the BPrivate namespace as modern C++ only.
3. Move to libnetservices2.a for now
4. Move to libshared.a
The normal process for introducing a new API is:
First put it into the BPrivate namespace, AND in a static library (or make it
header-only)
This way, apps that use it essentially bundle a copy of it, and being in a
private namespace (and hidden symbol visibility now) it is isolated from other
uses and from future updates.
When the API is considered mature, add the needed ABI future-proofing: the
Perform() method, vtable reserved slots, and reserved fields.
Only then it is safe to move the class to a shared library, and out of the
BPrivate namespace.
This process is a bit annoying, but everytime we tried to skip steps in it, we
end up with apps relying on a specific ABI, and this means more work to either
update these apps, or use even worse hacks to keep the ABI compatible.
So we should make it a general rule that all new APIs are fist distributed as a
static lib, and moved to a .so only when they are stable. It would save us a
lot of trouble. Especially for something like BError, if the approach ends up
being used, it will be used really everywhere, and so an ABI breakage would be
very annoying if it's not kept in a static lib.
However, this would mean it can't be introduced in core libbe classes yet. I
would say this is a good thing at this point where we are trying to keep the
core ABI stable and someday ship an R1 release (even if that's not fun).
--
Adrien.
Other related posts:
