[Development] QtCS 2017 QtCore sessions

Marc Mutz marc.mutz at kdab.com
Tue Oct 17 17:28:54 CEST 2017


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




More information about the Development mailing list