On Wed, 24 Aug 2022 at 07:18, Will Hawkins <hawki...@obs.cr> wrote: > > On Tue, Aug 23, 2022 at 12:33 PM Jonathan Wakely <jwak...@redhat.com> wrote: > > > > On Mon, 22 Aug 2022 at 19:15, Will Hawkins wrote: > > > > > > Until now operator+(char*, string) and operator+(string, char*) had > > > different performance characteristics. The former required a single > > > memory allocation and the latter required two. This patch makes the > > > performance equal. > > > > If you don't have a GCC copyright assignment on file with the FSF then > > please follow the procedure described at https://gcc.gnu.org/dco.html > > Thank you. > > > > > > > > libstdc++-v3/ChangeLog: > > > * libstdc++-v3/include/bits/basic_string.h (operator+(string, > > > char*)): > > > Remove naive implementation. > > > * libstdc++-v3/include/bits/basic_string.tcc (operator+(string, > > > char*)): > > > Add single-allocation implementation. > > > --- > > > libstdc++-v3/include/bits/basic_string.h | 7 +------ > > > libstdc++-v3/include/bits/basic_string.tcc | 21 +++++++++++++++++++++ > > > 2 files changed, 22 insertions(+), 6 deletions(-) > > > > > > diff --git a/libstdc++-v3/include/bits/basic_string.h > > > b/libstdc++-v3/include/bits/basic_string.h > > > index b04fba95678..bc048fc0689 100644 > > > --- a/libstdc++-v3/include/bits/basic_string.h > > > +++ b/libstdc++-v3/include/bits/basic_string.h > > > @@ -3523,12 +3523,7 @@ _GLIBCXX_END_NAMESPACE_CXX11 > > > _GLIBCXX20_CONSTEXPR > > > inline basic_string<_CharT, _Traits, _Alloc> > > > > Please remove the 'inline' specifier here, since you're moving the > > definition into the non-inline .tcc file. > > > > There's a separate discussion to be had about whether these operator+ > > overloads *should* be inline. But for the purposes of this change, we > > want these two operator+ overloads to be consistent, and so they > > should both be non-inline. > > Thank you for the feedback. I sent out a v2 of the patch. Again, I > hope that I followed the proper procedure by having my mailer put the > patch in reply to my previous message.
It looks like the patch got attached in this thread, not the [PATCH v2] thread: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600176.html Presumably it was meant as a reply to: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600175.html It's more conventional to put the patch in the same email, not as a separate reply, which would avoid that problem. You can use git scissors to separate the patch submission from the preceding discussion and comments, see https://git-scm.com/docs/git-mailinfo#Documentation/git-mailinfo.txt---scissors For example, see my patches like the one at https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600109.html where the "informational" part comes first, describing where it was tested, then the patch (and its commit msg) come after the -- >8 -- scissors. If you use git send-email to send mails, you can use --in-reply-to=$MessageId to make the email a reply to the specified $MessageId from a previous mail in the thread. Anyway, the v2 patch looks fine and I'll apply it to trunk after testing - thanks!
