On 25.05.2017 19:03, André Somers wrote:
On 25 May 2017, at 18:40, Christoph Feck <[email protected]> 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?)
Indeed in most cases you really do not need this feature, but unless
there will be a compile-time error, we will see subtle bugs/crashes
introduced where that feature was relied upon.
I have seen many crashes in the big KDE code base from Qt3->Qt4 porting
just because the code compiled fine (e.g. after mass-renaming class or
method names), but semantics changed in subtle or unexpected ways.
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
