[Development] QtCS 2017 QtCore sessions

[Thiago Macieira]

On terça-feira, 17 de outubro de 2017 08:28:54 PDT Marc Mutz wrote:
> On 2017-10-10 14:49, Thiago Macieira wrote:
> > == QStringView ==
> > * NEVER return QStringView (but QRegularExpression wants to)
> > ** Consequence of "never return a reference" (but containers do)
> > ** Lifetime issues
> > 
> >     auto s = lineedit.text().left(n);
> >     s valid?
> > 
> > * We can be flexible on having exceptions:
> > ** The API needs to be specifically designed for dealing with
> > references
> > ** Clear naming, such as QRegularExpression::captureView()
> > 
> > Discussion not finished
> 
> I certainly hope so, because the above does not make any sense. See my
> talk at QtWS. Returning QStringView is not different from c.begin() or
> str.data(). You need to document the lifetime of the data, that's it.

Indeed, docs and proper documentation naming is required. We just concluded 
something we already knew: we need to avoid surprises. So when there's no 
benefit to returning QStringView, return QString.

> In fact, I'm slowly moving to the conclusion that APIs should, in
> general, not be formulated in terms of owning containers, except, maybe,
> in areas where data is typically shared between classes, but even then
> only in addition, as an extension. In Sean Parent's terms: "Goal: no raw
> containers". Classes should accept and return views, and use whatever
> data structure is most efficient for them, internally. A prime example
> of the cleanup this provides is QRegion::begin/end(). Before you had to
> call .rects(), forcing a memory allocation for the common case where the
> region is just one rectangle. Not only is begin()/end() more efficient,
> it's also easier to use:

I don't doubt it. But, again, case-by-case basis. The performance improvement 
would be very nice to have, but that needs to be coupled with the API 
complexity and the not painting ourselves into a corner should we later decide 
to change internals.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center