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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
