[Development] Rvalue pinning in Qt
Giuseppe D'Angelo
giuseppe.dangelo at kdab.com
Tue Jun 21 03:26:20 CEST 2022
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?". Consider
> In 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 | giuseppe.dangelo at kdab.com | 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220621/1a2300e2/attachment-0001.bin>
More information about the Development
mailing list