[Development] r-value references in API (was: RFC: Proposal for a semi-radical change in Qt APIs taking strings)

Bubke Marco Marco.Bubke at theqtcompany.com
Thu Oct 15 22:14:13 CEST 2015


On October 15, 2015 17:58:27 Thiago Macieira <thiago.macieira at intel.com> wrote:

> On Thursday 15 October 2015 07:34:30 Koehne Kai wrote:
>> > -----Original Message-----
>> > [...]
>> > 
>> > >BTW: functions storing a passed QString as-is should provide a
>> > >QString&& overload, and that might be a good idea even when otherwise
>> > >using QStringView only.
>> > 
>> > Yes, agree with this.
>> 
>> I guess this advice is not only for QString arguments though (from 5.7
>> onwards). Which other types should get an && overload?
>> 
>> Does API exposed via Q_PROPERTY/ QML benefit from an r-value reference
>> overloads, too?
>> 
>> I think it's a good idea to create some recommendations for 5.7 now, before
>> everyone develops his own rules ...
>
> I didn't address this in my reply to Marc...
>
> This part of his proposal falls apart the moment that the API function calls 
> something else to do the processing. Now you need to duplicate almost every 
> code path from the user-facing API down to the processing of the data. And 
> when the API has two data types, now the permutations explode...
>
> rvalue refs only make sense for very simple sink functions. Not even most 
> QString overloads would be able to do it.
>

I see the move semantics as a good way for ownership transfer. It is a much better ideom than sharing because you easily ask for țrouble if you share. Working on the same data structure from many processors is very inefficient. So the move semantics would make it clear that you should not share. Otherwise if you want process read only data you can use const references. I think the new model is much better than all type of pointers. The problem with pointers is that they can be null and you should check in interfaces but semantically you have no description in your concept that the structure is not there. 

I think the feature is to young to tell what "makes sense or not". We still have to find best practice. 


More information about the Development mailing list