[Development] Views

Mutz, Marc marc at kdab.com
Tue May 21 08:14:00 CEST 2019

On 2019-05-20 23:14, Konstantin Shegunov wrote:
> On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development
> <development at qt-project.org> wrote:
>> All I'm saying is that there are tons of examples (QGradient) where
>> the
>> use of an owning container in the API is just a very bad idea and
>> limits
>> the implementor's freedom and/or performance. E.g. QGradient could
>> have
>> inline storage for two or three stops to avoid allocating memory for
>> the
>> most-common cases. I mean, QPainter is full of (QPoint *, int
>> nPoints)
>> APIs that surely were added just for performance. Ditto for QString,
>> btw. Nowadays, with views, we can have the same API, but have it
>> accept
>> many owning containers transparently. I'm not saying that there must
>> be
>> no owning containers in the API. But there is a lot of low-hanging
>> fruit
>> out there.
> Okay, I can live with that, and I do see why it'd make sense in some
> cases to iterate the data directly. But then as a container can have
> many different iterables, it seems reasonable to consider adding a
> couple of methods that return views and take it from there. Why the
> push to remove the owning container(s) API? In time it may prove
> you're right, so then we can migrate the getters to the view API and
> eventually deprecate these methods. Or they could coexist, or w/e. The
> point is why reach for the top if there's low-hanging fruit?

You need to have an idea where you'd like to go before you go there. The 
problem with co-existence is that you impose the lowest common 
demoninator of both methods on the class implementation. If you have a 
view, the impl needs to store the data, if you have an owning container 
API, it needs to store it (assuming CoW) in that exact container. So, 
yes, co-existence as a path to the goal of no raw containers in APIs, 
but not as the end state.

More information about the Development mailing list