On 12/07/2024 18:41, zxuiji wrote:
>
>
> On Fri, 12 Jul 2024 at 15:47, Henry Miller via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
>
> I don't want to pay for the costs to convert to the standard ABI and
> back just because somebody might in the future change the ABI of
> string or vector.
>
>
> That's not a reason to implement a standard ABI, that's a reason to not
> use the standard ABI, a bad one at that. Remember my point about making
> classes with no standard ABI inherit from ones that do? There's no
> reason std::string could not inherit from say std::stable::
> linked_list_string on said mythical cpu. You would still get your
> performance gains without sacrificing a standard ABI in the process. The
> point of a standard ABI is to ensure functions and data in said ABI
> follow the same size definitions. For example intmax_t related functions
> just need to be inlines that call the correct functions matching the
> current size of intmax_t. A standard ABI does not mean optimisations
> cannot be applied to the implementation of the ABI, only that the data
> and calls will be of a fixed size.

It is possible to implement the internal classes in such a manner, but
to me it makes more sense to optimize the internal classes as far as
they can possibly go. Giving implementers the freedom to do this is one
of the more important reasons for this proposal.

If you inherit, you are optimising for transport cost across public
APIs. That is a relatively rare occurrence, though, and it would be
better to optimise for all the other stuff you are doing with strings.


Hans Guijt