[Development] QList

NIkolai Marchenko enmarantispam at gmail.com
Wed May 24 15:36:51 CEST 2017


Not necessarily. It really depends on which type Qt decides to use in place
of what is now returned as a QList.
As far as wrapper is concerned, it doesn't even need to be a singlular type
if the interface matches since it will be a template anyway.


P.S. I am not really involved with Qt development so I am obviously missing
a lot of context. I just saw that this wasn't even mentioned throughout
this thread or the previous one and finally decided to comment.
I just, personally, see the problems I already mentioned above about
incorrect code perception significant enough that QVector solution feels
wrong.
Users will see, for example, codebases with "QList.something.prepend" and
assume things. Completely incorrect things. And debugging older codebases
is already hard as it is, even when things actually mean what you assume
they do.
The current solution that seems to be heading to Qt6 (qvector alias) will,
imho, in the long run, produce a lot of confusion. Not when switching from
5 to 6, but when trying to debug/finetune the code.


On Wed, May 24, 2017 at 4:24 PM, Konstantin Tokarev <annulen at yandex.ru>
wrote:

>
>
> 24.05.2017, 16:19, "NIkolai Marchenko" <enmarantispam at gmail.com>:
> > I was talking about the solution that assumes making a QArrayList type
> and deprecating QList entirely,
> > not the one that aliases QList to QVector which I, personally, don't
> like, since it will produce a lot of the code perception problems and
> incorrect perfomance assumptions.
>
> So, do you propose to replace QList with QArrayList in existing APIs? That
> would be a serious pessimization for small types.
>
> > Not to mention people will still widely use QList as it's "easier to
> type "(don't laugh) and "looks like a default container by simplicity of
> its name"
> > (again, don't laugh, I am just outlining potential problems with new
> users)
> >
> > On Wed, May 24, 2017 at 4:12 PM, Konstantin Tokarev <annulen at yandex.ru>
> wrote:
> >
> >> 24.05.2017, 15:49, "NIkolai Marchenko" <enmarantispam at gmail.com>:
> >>> A semi-sane idea that I think no one has suggested yet:
> >>>
> >>> What if, starting from Qt6, QList becomes a wrapper for QArrayList
> with a contructor from this type?
> >>> After all making existing code slightly _slower_ because of the
> wrapping overhead is way less problematic than breaking it outright.
> >>> It will nudge the users of QLists that need to be fast to switch but
> will leave users of "default no brainer container" happy as they likely
> wouldn't even notice.
> >>
> >> If existing Qt APIs switch from QList to QVector in Qt 6, such change
> will make it hard to support both Qt 5 and Qt 6 in the same code base.
> >>
> >>>
> >>> On Tue, May 23, 2017 at 5:27 PM, Thiago Macieira <
> thiago.macieira at intel.com> wrote:
> >>>> On Tuesday, 23 May 2017 04:56:52 PDT Olivier Goffart wrote:
> >>>>> In my opinion for Qt6, we should make prepend, takeFirst amortized
> O(1) in
> >>>>> QVector.
> >>>>
> >>>> That is not very difficult once we move the begin pointer out of the
> d pointer
> >>>> and into the main QVector class. We need to add an interface to
> QArrayData to
> >>>> shrink and expand the buffer without relocating it. With that, we
> practically
> >>>> hide the allocated capacity information from QVector too.
> >>>>
> >>>> --
> >>>> Thiago Macieira - thiago.macieira (AT) intel.com
> >>>>   Software Architect - Intel Open Source Technology Center
> >>>>
> >>>> _______________________________________________
> >>>> Development mailing list
> >>>> Development at qt-project.org
> >>>> http://lists.qt-project.org/mailman/listinfo/development
> >>> ,
> >>>
> >>> _______________________________________________
> >>> Development mailing list
> >>> Development at qt-project.org
> >>> http://lists.qt-project.org/mailman/listinfo/development
> >>
> >> --
> >> Regards,
> >> Konstantin
>
>
> --
> Regards,
> Konstantin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170524/4e1035fa/attachment.html>


More information about the Development mailing list