[Development] QList

[André Somers]

Hi,

Sent from my phone, please excuse my brevity

> On 25 May 2017, at 18:40, Christoph Feck <cfeck at kde.org> wrote:
> 
>> On 25.05.2017 13:53, André Somers wrote:
>> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev:
>>> Other problem, that IMO is more serious, is that Qt *requires* user to use QList,
>>> by returning or taking it as and argument in various places. That's almost only
>>> reason why I use QList in my code[*].
>>> 
>>> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with
>>> this APIs will break, unless QList will become an alias of QVector.
>>> 
>>> [*] And, fwiw, almost only reason I use QString, but that's off-topic here
>>> 
>> I think you bring up a good point there. Would not the best way out be
>> to fix exactly this problem? If these functions would not return a
>> container, but some type of view into such a container, that would leave
>> users free to choose the type of container they need for their job
>> instead of being forced into the direction Qt choose for its API. A view
>> might take the form of a pair of iterators, a range, or perhaps even
>> some specialized class that basicaly wraps a pair or iterators and that
>> provides convenience functions to/from the Qt containers.
> 
> If you only return a view to the container, then if the container is modified, the return value is no longer valid. Returning a full container (referenced, with copy-on-write semantics) will not have this problem.

Sure, but do you always or even most of the time need that feature? If not, why always pay for it? And it would be easy to turn it into a container when needed, but then you can choose the most appropriate for your task instead of always getting a QList (now) or a QVector (Qt6?)

André

> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development