Date: Mon, 18 Aug 2025 14:32:33 +0000
On Monday, August 18th, 2025 at 1:52 PM, Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> wrote:
> On 18. Aug 2025, at 13:56, Bo Persson via Std-Proposals std-proposals_at_[hidden] wrote:
>
> > On 2025-08-18 at 13:18, Andrey Semashev via Std-Proposals wrote:
> >
> > > On 18 Aug 2025 13:33, Ben Crowhurst via Std-Proposals wrote:
> > >
> > > > There is a history of STL implementations introducing string
> > > > optimisations, for example, copy-on-write in GCC (<=4), adoption of
> > > > small string optimisation (SSO) - with varying details across GCC,
> > > > Clang, and MSVC.
> > > >
> > > > Focusing on SSO, using std::string, along with std::string_view and move
> > > > semantics, introduces a frustrating folly.
> > > > Why? What is the problem with SSO?
> >
> > If you get a string_view to a string, and then move the string, the string_view may, or may not, move along - all because of SSO.
>
>
> If you have a string_view or a span to a moved from object there is no reason to believe that the view/span is still valid. It is at least implementation defined behavior if not undefined behavior. If the view still works after a move you just got lucky. It is quite similar for iterators to be invalid for some containers after certain operations on the container.
>
> This is certainly not a reason to disallow SSO. If you need a string+string_view with a specific behavior you should implement your own. (Hopefully compatible/convertible to a std::string.)
>
I'm not pushing back on SSO; the discussion was geared towards formalising the behaviour under a specific container type, i.e. std::small_string. Allowing std::basic_string to be, as many consumers assume, a wrapper around a C-style pointer.
> > I too prefer the performance of small strings over fixing this.
The migration path to a std::small_string implementation with well-defined behaviour as documented in a future standard would be limited, given an identical std::basic_string interface.
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
My argument is about seeking clarity, though it may be a case of closing the stable door after the horse has bolted.
> On 18. Aug 2025, at 13:56, Bo Persson via Std-Proposals std-proposals_at_[hidden] wrote:
>
> > On 2025-08-18 at 13:18, Andrey Semashev via Std-Proposals wrote:
> >
> > > On 18 Aug 2025 13:33, Ben Crowhurst via Std-Proposals wrote:
> > >
> > > > There is a history of STL implementations introducing string
> > > > optimisations, for example, copy-on-write in GCC (<=4), adoption of
> > > > small string optimisation (SSO) - with varying details across GCC,
> > > > Clang, and MSVC.
> > > >
> > > > Focusing on SSO, using std::string, along with std::string_view and move
> > > > semantics, introduces a frustrating folly.
> > > > Why? What is the problem with SSO?
> >
> > If you get a string_view to a string, and then move the string, the string_view may, or may not, move along - all because of SSO.
>
>
> If you have a string_view or a span to a moved from object there is no reason to believe that the view/span is still valid. It is at least implementation defined behavior if not undefined behavior. If the view still works after a move you just got lucky. It is quite similar for iterators to be invalid for some containers after certain operations on the container.
>
> This is certainly not a reason to disallow SSO. If you need a string+string_view with a specific behavior you should implement your own. (Hopefully compatible/convertible to a std::string.)
>
I'm not pushing back on SSO; the discussion was geared towards formalising the behaviour under a specific container type, i.e. std::small_string. Allowing std::basic_string to be, as many consumers assume, a wrapper around a C-style pointer.
> > I too prefer the performance of small strings over fixing this.
The migration path to a std::small_string implementation with well-defined behaviour as documented in a future standard would be limited, given an identical std::basic_string interface.
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
My argument is about seeking clarity, though it may be a case of closing the stable door after the horse has bolted.
Received on 2025-08-18 14:32:36