[Development] Views

[Konstantin Shegunov]

>
> On Thursday, 16 May 2019 08:26:08 PDT Mutz, Marc via Development wrote:
> This one is simple: Array of struct -> struct of arrays. Well-known
> optimisation in the games industry.
>

Assuming that the data structure is simple enough and can be kept
contiguous in memory, and the view can be simply constructed cheaply by
means of contiguous blocks. The moment you need a couple of semantically
different layouts on top of that "struct of arrays" you're already treading
on thin ice. Not every problem can be simmered down to a vector and a
struct, sorry, otherwise people, much smarter than me, wouldn't have
invented trees and hashes. Yes, the user should *actually* think before
just using either arbitrarily, but this doesn't mean their implementation
complexity should be used as hindrance.


> You basically have a dichotomy: Either you have contiguous storage, in
> which case you return pointers, or you have non-contiguous storage, in
> which case you need some form of runtime-dispatch Iterator Pattern.
>

Yes, and you can have infinitely many types of contiguous or non-contiguous
presentations based on either one these two storage kinds. Are we having a
different view class for each case where we may need to present the
internal data in a different way?


> Sure, but you'd have to change the public API to return that view
> instead of the contiguous-storage one.


Indeed, that's true. However changing the internal data layout nontrivially
almost certainly leads to changing the implementation of the view. Binary
compatibility ties your hands here if the view's implementation isn't
private. Making its implementation private in turn can eat much of the
benefit you claim.


> Well, then see QAIM::roleNames(). Apart from the questionable design to
> return a node-based associative container for the O(10) elements in
> there, instead of a (view to a) sorted array of structs[1], it is a
> prime example of how the API requires a particular implementation.


User story:
The API is always going to rule supreme over any implementation detail or
efficiency. The API is what you present to the user, not the
implementation. The moment you start sacrificing good API, one that's
fleshed out and convenient to the user, for a simpler implementation you
end up where the STL is - so convoluted it's hardly worth making anything
with it. Take the glorified std::vector - appending a vector to another
takes 3 arguments, and removing an element from it, or accessing its value
through an iterator for that matter, involves rather poorly hidden pointer
arithmetic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190517/e83015fd/attachment.html>