[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