On 2019-05-20 23:14, Konstantin Shegunov wrote:
On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development
<development@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.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
