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
smime.p7s
Description: Firma crittografica S/MIME
