On the topic of pointers I would suggest that stdabi::string::verXX would
use uint16_t/uint32_t/uint64_t/etc
instead of actual pointers. The reason is due to what data model the
library is compiled under compared to
the reliant software. It also addresses future changes to the API when
pointers of a bigger size become possible.

Here's a rough example of what I would expect:

namespace stdabi
{
   namespace string
   {
       class ver2024
      {
      private:
          uint64_t datamodel, addr, size;
      public:
          int32_t initstring( uint64_t datamodel, uint64_t text, uint64_t
size );
          // Pointer functions MUST NOT BE DEFINED HERE! Use std::string
for those.
          int32_t appendstr( uint64_t text, uint64_t size );
      }
      ...
   }
}
namespace std
{
    constexpr uint64_t STD_DATA_MODEL64 = (((sizeof(void*)) << 4) |
sizeof(long)) << 4) | sizeof(int) ...
#if STD_VERSION >= 2035
    constexpr uint128_t STD_DATA_MODEL128 = (((sizeof(void*)) << 8) |
sizeof(long)) << 8) | sizeof(int) ...
#endif
#if STD_VERSION < 2035
    class string : stdabi::string::ver2024
    {
    public:
        string( char *text = NULL, size_t size = 0 )
        {
            if ( initstring( STD_DATA_MODEL64, (uintptr_t)text, size ) != 0
)
                // throw or something
        }
    }
#else
    class string : stdabi::string::ver2035
    {
         // similar but using STD_DATA_MODEL128
    }
#endif
}

By making pointers exclusive to compile time and not part of the stdabi it
becomes possible to unify the abi that is linked (for example linking x86
apps to an x86_64 library directly). This is the very thing I'm doing in my
own library launcher pair. I did not realise until reading it in this chain
however that there are differences in calling conventions between the GNUC
family of compilers. For now I've tacked __cdecl onto my global API define
but will need something to address that 16byte aligned vs 4 byte aliigned
thing I read on wikipedia

On Sun, 14 Jul 2024 at 00:10, Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Saturday 13 July 2024 08:33:57 GMT-7 Hans via Std-Proposals wrote:
> > > You're making an extraordinary claim in your proposal and making an
> > > extraordinary requirement of standard library developers. You need to
> > > provide extraordinary proof.
> >
> > What? What is extraordinary about my claim? No, scratch that, what do
> > you even think I'm claiming? How is adding FOUR SIMPLE CLASSES an
> > extraordinary requirement?
>
> If they are simple, please provide the implementation.
>
> You're asking that the Standard Library add a new set of classes that
> promises
> stability. But you have not provided any evidence or method by which such
> new
> classes would be more stable than the current classes are right now and
> have
> been for two decades.
>
> > I want the default for classes to be unstable. Nobody has to do
> > anything, anything at all, to make that happen, it's just a default.
>
> Ok, now this is a new argument.
>
> First, are you referring to *new* classes to be added to the standard? If
> so,
> we already have mechanisms to do what you're saying. There's no need to
> have a
> new paper. Of course, classes are added to the experimental set with eye
> towards becoming stable, eventually.
>
> Or are you proposing that the current classes become unstable? Why would
> we
> want that? What's the transition mechanism for people who currently rely
> on
> the fact that they are stable?
>
> > The
> > entire standard library stays as it is, unchanged, identical, the same,
> > no changes. Then we go and add... FOUR CLASSES. Why do you want me to
> > write a bloody standard library just to demonstrate that you can add
> > FOUR CLASSES to it? Did you make that same COMPLETELY UNHINGED demand of
> > the people that wanted to add std::flatmap? Because that got added, and
> > I assure you it is way more code than what I'm proposing.
>
> No, I didn't because their fundamental development of the class wasn't
> different. See above for why.
>
> If you think my request is unhinged, then it's a good chance that we're
> misunderstanding each other. Quite frankly, I still don't know what you
> want.
>
> Maybe you do need to write a paper in detail, because just the email
> discussion isn't getting to the point.
>
> > If you really want to help, you can start by READING THE PROPOSAL, and
> > suggesting improvements to the text. That would be a far greater help
> > than just endlessly repeating demands for information that is already in
> > the proposal anyway.
> >
> > You can find the proposal here:
> >
> https://docs.google.com/document/d/1P1mL1J0rXJlRnLYrcquzLVqE3jPd_IC6uQYnMIE6
> > 8vA/edit
>
> Fair.
>
> In "What are the issues with ABI?", you say that there is no guarantee of
> interoperability between different versions of a single implementation of
> the
> standard library. That's false. All three major implementations do promise
> it.
>
> Next, you claim that implementors have reluctance in optimising. That's
> false
> too: there is a lot of optimisation work that goes in all three in every
> release. Yes, their hands are tied by the ABI, but that does not preclude
> all
> optimisation. You are correct that some forms would be disallowed, but
> your
> statement does not say that. It's overly broad. Plus, you have to show
> evidence that such disallowed optimisation would be wanted: please provide
> a
> few examples of where that could have happened but for the need to keep
> ABI.
>
> std::regex is not such an example. The reason it isn't being changed is
> not
> ABI, but behaviour, in particular of the flavour of regular expression
> that
> class supports. Applications are written with an expectation in mind and
> that
> is what the Standard is for. Changing std::regex would break the
> Standard's
> promise, so it would be far easier to add a new class and deprecate the
> old
> one until it can be safely removed (q.v. Qt5 adding QRegularExpression
> that
> replaced the old QRegExp, and Qt6 removed the latter).
>
> The next bullet point says there's a reluctance in the committee members
> in
> evolving classes for fear of breaking the ABI. While that is true to some
> extent, your paper would benefit from more examples. You cannot generalise
> on
> one example alone.
>
> You refer to two strategies to keeping ABI from C, but you failed to note
> that
> as a derivative from C, C++ already has the two available. More
> importantly,
> C++ has been using those two strategies for 30 years. The majority of the
> Standard Library class implementations are actually of the "set in stone"
> type
> of structure, while the opaque handle type is what Qt has very
> successfully
> used for 30 years too. So saying "good candidate for adoption into C++" is
> unnecessary, since C++ already adopted the two 30 years ago.
>
> And given that C++ *has* adopted them and you claim that there are ABI
> problems, you need to discuss why.
>
> Your solution is proposed to declare which classes are stable and which
> may
> not. I'm claiming we already have that, it just happens that the entirety
> of
> the Standard Library is in the former category, while the experimental
> stuff is
> found in Technical Reports. Moreover, library implementors have availed
> themselves of techniques to mark their implementations of the
> future-stable
> Standard Library as "in development". Therefore, I am claiming that your
> proposal was adopted with great success, 30 years ago.
>
> Providing tools to enforce by the compiler so one knows whether they are
> using
> unstable ABI in their content that itself marked for stability would be
> nice.
> Can you expand your paper with the actual mechanisms by which the compiler
> should do that? Not a placeholder.
>
> You're saying that a stable class must be standard layout. Why? That seems
> unnecessary.
>
> You should answer your question on pointers too; don't leave the question
> open. In doing so, you should also ponder what happens to a class like
> std::unique_ptr<T> where T is not explicitly marked stable.
>
> In discussing the stability of the standard library, you say that it does
> not
> help with interfacing with other standard libraries. That's true. It's not
> desired, so it's also not a problem.
>
> You then propose that the current classes in the Standard Library not be
> marked as stable. That has a huge effect that you're not addressing at all
> in
> your paper. Developers *expect* stability and have come to rely on it for
> the
> Standard Library as it is today. Voiding that contract is either going to
> be
> shot down very quickly, or you need to provide a path to mitigating the
> effects.
>
> Or, alternatively, that's a distinction without a difference, in that the
> implementations will keep the stability whether the Standard mandates it
> or
> not, and will still require the Standard not to change in a way that
> breaks
> that promised stability. In that case, we'd have to wonder why we need a
> special group of classes that promise no more stability than the existing
> grouping does.
>
> In the std::stable namespace section, you say "committee-supplied ABI" but
> that's woefully short of details. Is it just a description of the class
> layout
> in the form of a C structure (and hence the "standard layout" requirement
> from
> above")? If so, say so. For me, ABI implies much more, including the size
> and
> alignment of types, which the committee could never provide for all
> possible
> target architectures.
>
> There are other ABI problems that would need addressing. For example,
> whether
> a parameter passed by value is destroyed by the caller or by the callee.
> This
> differs between the MinGW ABI used by Clang and GCC on Windows and the
> MSVC
> ABI. If your intent was to allow passing of non-trivially-destructible
> types
> as parameters across Standard Libraries (assuming the name mangling is not
> an
> impediment), you'd need to somehow fix this problem. Another one is for
> the two
> classes that allocate memory in your proposal: std::string and
> std::vector.
> Without solving the problem of name mangling, the there may be two
> ::operator
> new / ::operator delete pairs, and therefore deleting memory allocated by
> the
> other cannot be guaranteed to work.
>
> There will probably be more problems. Therefore, this paper is not going
> to
> advance until there is concrete proof of it working and the problems
> having
> been solved. It needs an implementation provided by its supporters to show
> that it can work and that the problems have solutions.
>
> Because if it can't show that, then communication across implementations
> using
> C++ types is still impossible, and thus the stability is confined to
> inside of
> a single Standard Library implementation. And that brings us back to where
> we
> are today: those libraries pretty stable.
>
> > If you believe that there is no ABI issue, there is no point in
> > discussing: you don't believe there is an issue, and from your
> > perspective EVERYTHING I say is wasted effort. There is no need for you
> > to engage in that case.
>
> I did not say it's a wasted effort. I am merely skeptical that this is a
> workable solution. But improving your proposal may reveal that I am wrong.
>
> I am also very skeptical that there is a problem to be solved in the first
> place. The implementations are stable, the cases where a change was
> desired
> but not permitted due to stability are few and far between, usually minor,
> and
> communication between Standard Libraries may be desired by users, but not
> by
> the implementors themselves so attempt to move in that direction is
> unlikely
> to gain traction.
>
> Finally, your working on the proposal may spur other ideas in parallel
> tracks
> that are workable. In particular, I am very interested in a way to mark
> functions and classes exported from libraries and, by consequence, marking
> what is internal and thus subject to change.
>
> > If you DO believe there is an issue (and you've held both positions in
> > your various emails so I don't know which it is), we can discuss my
> > proposed solution. Or, if you think you have a better idea, tell us
> > about it.
>
> I don't have a better idea.
>
> But here's a suggestion: your paper seems to be addressing three things in
> one. It might be adviseable to split and address each in sequence:
>
> a) a core language change to the syntax that would allow marking of
> classes
> and functions as stable
> (I'm not particularly interested in the stability argument, but as I said
> above, a syntax for exporting and importing across dynamic library
> boundaries
> is very much needed)
>
> b) an addition to the Standard Library of some classes whose memory layout
> is
> more tightly defined by the Standard, with an eye towards communication
> between
> Standard Library implementations and possibly with other languages. You
> can
> rely on all the C ABI, but you'll need to define every single behaviour
> above
> that of C, like when destructors get run.
> (Personally, I think this is the most interesting portion)
>
> c) a discussion of relaxing the current stability requirements in the
> regular
> classes in the Standard Library, with the possible fall-outs and
> transition
> mechanisms.
> (this one I would vehemently oppose)
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>