Hi, On 20/06/2022 17:39, Thiago Macieira wrote:
On Monday, 20 June 2022 07:46:57 PDT Giuseppe D'Angelo via Development wrote:A fancy name for: "if a function/class is operating on a rvalue, should it store a copy of it in order to keep it alive?". ConsiderIn other words, remove the rvalue reference and store a copy from the const- lvalue reference overload you already have.
Well, not necessarily. Say the input is a lvalue std::u16string; you don't want the tokenizer to unconditionally copy it.
So it just takes a reference, and should continue to do so.(Looking at std::views::all: this is the case where the input is a non-view lvalue, so you'll wrap it in ref_view -- i.e. merely hold a reference to it.)
std::u16string someLongString = u"..."; auto tokenizer = QStringTokenizer(someLongString, u"X");For this reason QStringTokenizer moves and stores the input if it's an rvalue, but only keeps a reference if it's an lvalue.This means QStringTokenizer must have a QString member and a QString & member. The simplest implementation removes one of them.
Not always, see above.
QString s = getString(); auto tok = QStringTokenizer(s, u"x");would take a copy (given `s` is a view after [4]), while now it only takes a reference.Yup.Opinions?My only objection is to calling this by a fancy name, "rvalue pinning". Simply call what it is: take all parameters by const-lvalue and never store a reference.
It's also imprecise. We should use the C++20 range terminology which is more accurate, but I don't want to cause even more confusion (given we don't use that logic, and probably _can't_ use the logic just yet).
Thanks, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
