On 12/07/2024 15:03, Thiago Macieira via Std-Proposals wrote:
>> The current status quo is not sufficient because it fossilizes every
>> class, the moment it is first released. Look at the woes Linux went
>> through when the standard mandated SSO over CoW in std::string! Look at
>> the performance complaints related to std::regex, std::deque,
>> std::unordered_map, etc.! These things happen because of the current
>> status quo.
>
> I am looking at that and I addressed in my paragraph: the design was that
> libstdc++ would keep ABI and strictly speaking, it did. The issue was

I disagree with that. No 'design' was involved in the stability of
libstdc++. Instead its developers realised, at some point, that they
were no longer able to change anything because too many people relied on
their existing ABI. Calling that 'design' is like falling of a ladder
and then shouting "I meant to do that!"

> downstream of that library, because it was poorly explained to library
> developers. That was a mistake.
>
> So I repeat my question: knowing that there will be mistakes, why is your
> proposal *more* stable than the current state of affairs?

My design removes the issue of ABI stability being poorly explained to
library developers. It formalizes what is, and what isn't stable. It is
precisely the answer to the problem you formulated here.

>> Performance: any transfer through an std::stable class does incur a
>> cost, but if carefully designed, that cost should not be more than that
>> of an std::move. That is, std::stable::string, if it has a large enough
>> SSO buffer, can handle a move from std::string either by copying the SSO
>> buffer, or by just moving the pointer. This still implies two moves take
>> place (into, and out of std::stable::string), potentially copying as
>> much as 64 bytes.
>
> I think you need to put your ideas to the test. Please write a prototype
> standard library that shows how this would work, so my questions on cost can
> be assessed.

Sure, why not. FOR THE PURPOSE OF EXPOSITION, instead of implementing a
stable class myself and defining its ABI, I'll borrow the existing class
from the standard library. THIS IS NOT HOW IT WOULD WORK IN THE REAL
WORLD, but it is close enough that it will suffice FOR AN EXAMPLE.

#include <iostream>
#include <string>

namespace std::stable {
   class string {
     public:
       // You can construct a stable string from a normal string.
       string (const std::string &data) :
         m_data (data) {}

       // You can construct a normal string from a stable string.
       operator std::string () { return m_data; }

     private:
       // In a real-life implementation, this would have a
       // standard-supplied, fixed ABI. For this example I'll
       // just use the existing std::string.
       std::string m_data;
   };
}

// This is a function in a public interface. Because it is marked
// as such (using the 'export public' keywords), passing instable
// types here is an error.
// export public
std::stable::string make_greeting (std::stable::string name) {
   std::string greeting = "Hello ";
   greeting += name;
   return greeting;
}

// Client code can be using a completely different implementation
// of std::string.
int main (int argc, char **argv) {
   std::string name = "world";

   if (argc > 1)
     name = argv [1];

   std::string result = make_greeting (name);

   std::cout << result;
   return 0;
}

Please note that this is an example that shows how it would work in
general. It is not a complete implementation.

>> Porting: this requires adding markup to functions in the public API,
>> ensuring that all parameters involved are stable (the compiler will not
>> allow unstable parameters), and likely a change to the build script
>> since the toolset has to be told it is creating a static or dynamic
>> library (this can potentially affect code generation: any function that
>> is not part of the public API can be more aggressively optimized. See
>> section "new optimisation opportunities" in the paper).
>
> You can start with -nostdlib++ with GCC and Clang for your library.

Are you actually serious about me writing a complete standard library?
You want me to embark on a multi-year project, just to provide an
example for a paper?

>> - It also still doesn't solve the problem that people would still use
>> unstable classes in public interfaces, unless you plan to specify the
>> serialisation ABI for every class in the known universe. My solution
>> calls for a handful of stable classes, not millions, and as such seems
>> more practical.
>
> I thought those two are exactly what you're trying to specify, when you talked
> about syscall-like ABIs. From this current reply, it sounds you want something
> more like Qt-style ABI which makes each class is just one pointer to the
> private implementation and most functions are out-of-line.

It was another poster who was talking about syscall-like ABIs, not me.
And his proposal doesn't solve the ABI issue anyway, as his var_args
parameter can still contain any number of unstable classes.


Hans Guijt