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.
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:
for (auto rect : region) { ... }
vs.
for (auto rect : region.rects()) { ... } // oops, detach
const auto rects = region.rects();
for (auto rect : rects) { ... } // OK
we even had code that did
if (region.rectCount() == 1)
doSomethingWith(region.boundingRect()):
else
Q_FOREACH(QRect r : region.rects())
doSomethingWith(r);
presumably because the memory allocation made itself heard there.
When this is done throughout the code base, Qt will become easier to
use, and more efficient, and the pattern will be as imbued into
developer's brains as is being()/end() now.
And there's always static checkers for the odd error.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
