> -----Original Message-----
> From: development-bounces+kai.koehne=theqtcompany....@qt-project.org
> [mailto:development-bounces+kai.koehne=theqtcompany....@qt-project.org]
> On Behalf Of Bubke Marco
> Sent: Thursday, October 15, 2015 10:14 PM
> To: Thiago Macieira <thiago.macie...@intel.com>; development@qt-
> project.org
> Subject: Re: [Development] r-value references in API (was: RFC: Proposal for a
> semi-radical change in Qt APIs taking strings)
>
> On October 15, 2015 17:58:27 Thiago Macieira <thiago.macie...@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.
Ok. I'll try to rephrase this then to come up with an easy advice:
'''
Consider providing an && overload for simple setter functions that take a not
trivially copyable value type as an argument (e.g. QString, QVector ...).
For example:
void setName(const QString &name) { m_name = name; }
void setName(QString &&name) { m_name = std::move(name); }
'''
Anyhow, we could also decide that, now that we expect C++11 to be available, we
can also rely on move semantics and only use pass-by-value. This was actually
suggested by Olivier in 2012 (!), see
http://permalink.gmane.org/gmane.comp.lib.qt.devel/3484 :
Lars replied back then though that this "moves the code required for making the
copy for the cases where the compiler can't optimize it away to the caller, ie.
from a shared to a non shared location. This can increase the total size of the
code generated." (see http://permalink.gmane.org/gmane.comp.lib.qt.devel/3502).
Olivier then retracted the proposal. Should we reconsider it though, now that
we can expect C++11 from 5.7 onwards? Or does the code size increase still
hold? Shall we do some more experiments with this?
> 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 understand that there are other uses of r-value references, but for the
moment I'd personally like to keep the discussion focused on simple setter
functions, because they're so common.
Regards
Kai
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
