[PATCH v4] libstdc++: implement concatenation of strings and string_views

[Giuseppe D'Angelo]

Hello,

Il 17/10/24 06:32, François Dumont ha scritto:
> As a side note you should provide your patches as .txt files so that any
> email client can render it without going through an editor.

Apologies for that. Do you mean I should use text/plain attachments 
instead of text/x-patch?


> And regarding the patch, I wonder what the std::move is for on the
> returned value ?
> 
> Like this one:
> 
> +    {
> +      return std::move(__lhs.append(__rhs));
> +    }
> 
> As it's a C&P the question might not be for you Giuseppe.

Well, I'll gladly give it a shot. :) I'm assuming you're talking about 
the operator+(string &&lhs, const char *rhs) overload, whose 
implementation I copied for operator+(string &&, string_view)?

By spec https://eel.is/c++draft/string.op.plus#2 it must do:

> lhs.append(rhs);
> return std::move(lhs);

The call to std::move in the specification is likely a pre-C++20 
remnant, before the adoption of P1825, which made lhs "implicitly 
movable". So in principle right now you could just write:

> lhs.append(rhs);
> return lhs;

Before P1825, `return lhs` would've caused a copy of `lhs`, not a move, 
even if `lhs` is a variable with automatic storage of type rvalue reference.

In C++23 this area has been further modified by P2266.

In any case both papers are new features, and are not to be treated as 
DRs. Therefore, since this operator+ overload's code has to be 
compatible with pre-C++20 semantics (the code is from C++11), the call 
to std::move must be left in there.¹

The behaviour described by the current wording can also be achieved by

> return std::move(lhs.append(rhs))

(the actual implementation in libstdc++), because lhs.append returns a 
reference to lhs; so the implementation is completely equivalent to the 
specification in the Standard. Even if the standard were changed to do a 
plain `return lhs;`, libstdc++'s code would still be correct (we can't 
just `return lhs.append(rhs)`, as that would cause a copy; append 
returns an lvalue reference.)



¹ I just C&P'd the implementation of operator+(string, string_view) from 
the const char * overloads, and that includes these pre-C++26 patterns 
in the code. A prior review also noticed a "typedef" instead of a 
"using". In general, I'm really not sure if I should favour consistency 
with the existing code or can liberally apply refactorings to code meant 
to be compatible only with the latest standards (such as new features), 
any advice is appreciated :)

Thank you,
-- 
Giuseppe D'Angelo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: Firma crittografica S/MIME
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20241017/d637b7f5/attachment.p7s>