> 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 <jh...@gmx.com> wrote: > > > > Sent: Friday, April 24, 2020 at 4:14 PM > > From: "Giuseppe D'Angelo" <giuseppe.dang...@kdab.com> > > To: "Jason H" <jh...@gmx.com> > > Cc: development@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@qt-project.org > https://lists.qt-project.org/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
