[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