cfeck at kde.org
Thu May 25 18:40:46 CEST 2017
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
More information about the Development