[Development] Proposal: Deprecate QVector in Qt 6

[Jean-Michaël Celerier]

> I however want some generic indexable/iterable type, where it doesn't
care if the final storage is QList or  QVector... When I am working as an
API, I don't want to choose for my users what that type is and make them
pay for conversion. Which I think QList was historically the right choice.
Ideally I want to have a QIterable for processing lists/arrays/vectors. I
think the developer should be able to determine the storage best for their
application, not me.

I believe that all sort of woes come to those wanting to make C++ look more
like Java / C# with their AbstractCollection<T> / IEnumerable ;
every time I've seen people try to go towards that path it has ended in
pain and tears and ultimately reverting to std::vector as the benefits did
not
outweight the drawbacks by a large margin.

C++20 coroutines start making that much more feasible however, like this
for instance and without creation of unnecessary temporary containers:
https://godbolt.org/z/gNsbjc
(it remains to be benchmarked whether the coroutine frame can be optimized
sufficiently well in comparison to returning a container, considering
that both clang and GCC nowadays are able to optimize out new / delete
pairs... I'd be inclined to believe that the compiler has more domain
knowledge
of the coroutine though and thus is able to make better choices).

Maybe something for Qt 8 or 9 ? :p

Best,
Jean-Michaël

On Sat, Apr 25, 2020 at 2:23 AM Jason H <jhihn at gmx.com> wrote:

>
>
> > Sent: Friday, April 24, 2020 at 4:14 PM
> > From: "Giuseppe D'Angelo" <giuseppe.dangelo at kdab.com>
> > To: "Jason H" <jhihn at gmx.com>
> > Cc: development at qt-project.org
> > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> >
> > On 4/24/20 9:03 PM, Jason H wrote:
> > >> In fact, it is-a QList<QString>. What's the problem here with its
> naming?
> > >
> > > Because I can't QSringList{"me", "you"}.join() with a QList.
> >
> > I didn't say that it's a typedef for QList<QString>, but is-a -- it
> > inherits, precisely to provide that kind of convenience.
> >
> > > Thinking outsize of the box...
> > > It seems that all this is cause d by someone wanting to store a
> pointer to an item in QVector, which may be reallocted and therfore have
> moved.
> >
> > All this => what's this?
> >
> > > It seem then that the only thing to do is to use a traditional QList,
> or return only some kind of ref which will be a stable reference to the
> item.
> > > QStableRef r9 = vector[9];
> > > vector.resize()
> > > // r9 is updated during resize() and still points to that it was meant
> to.
> > > It's not good practice to store a ref to something that can be
> realloated. I don't know how you can prevent people from doing that with
> offering T& operator[](int i);
> >
> > QList today offers exactly that. In array-of-pointers-mode it also
> > offers stability of references.
>
> Yes. I agree. I think the OP kicked this off with a thing about soring
> refs to items in QVector which is relocatable. My post was just to say this
> is a bad idea fro QVector. This is not immediately obvious though. The
> API/docs fail to communicate that storing pointers/refs to items is a bad
> idea. Which then as me agree with you and Lars's current thinking.
>
> I however want some generic indexable/iterable type, where it doesn't care
> if the final storage is QList or  QVector... When I am working as an API, I
> don't want to choose for my users what that type is and make them pay for
> conversion. Which I think QList was historically the right choice. Ideally
> I want to have a QIterable for processing lists/arrays/vectors. I think the
> developer should be able to determine the storage best for their
> application, not me.
>
> Side note:
> It also kicked off a thing in my brain about .NET and the managed runtime,
> where C++ on .NET got ^, the handle operator, which allows dereferencing to
> items given that everything is relocatable due to memory compaction. I
> think it could be a great thing if C++ has such a thing, as I attribute 99%
> of all long boot time lockups on Raspberry Pis to memory fragmentation
> (completely anecdotally) And if C/C+ could offer some kind of memory
> management beyond malloc/free, we could get the next 99% of lockups and
> random crashes avoided.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200425/5e8fef5b/attachment-0001.html>