<div dir="ltr"><div dir="ltr"><div>> 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.<br>
</div><div><br></div><div>I believe that all sort of woes come to those wanting to make C++ look more like Java / C# with their AbstractCollection<T> / IEnumerable ; <br></div><div>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 <br></div><div>outweight the drawbacks by a large margin. <br></div><div><br></div><div>C++20 coroutines start making that much more feasible however, like this for instance and without creation of unnecessary temporary containers:</div><div> <a href="https://godbolt.org/z/gNsbjc">https://godbolt.org/z/gNsbjc</a></div><div>(it remains to be benchmarked whether the coroutine frame can be optimized sufficiently well in comparison to returning a container, considering <br></div><div>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 <br></div><div>of the coroutine though and thus is able to make better choices).<br></div><div><br></div><div>Maybe something for Qt 8 or 9 ? :p<br></div><div><br></div><div>Best,</div><div>Jean-Michaël<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 25, 2020 at 2:23 AM Jason H <<a href="mailto:jhihn@gmx.com">jhihn@gmx.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> Sent: Friday, April 24, 2020 at 4:14 PM<br>
> From: "Giuseppe D'Angelo" <<a href="mailto:giuseppe.dangelo@kdab.com" target="_blank">giuseppe.dangelo@kdab.com</a>><br>
> To: "Jason H" <<a href="mailto:jhihn@gmx.com" target="_blank">jhihn@gmx.com</a>><br>
> Cc: <a href="mailto:development@qt-project.org" target="_blank">development@qt-project.org</a><br>
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6<br>
><br>
> On 4/24/20 9:03 PM, Jason H wrote:<br>
> >> In fact, it is-a QList<QString>. What's the problem here with its naming?<br>
> ><br>
> > Because I can't QSringList{"me", "you"}.join() with a QList.<br>
><br>
> I didn't say that it's a typedef for QList<QString>, but is-a -- it<br>
> inherits, precisely to provide that kind of convenience.<br>
><br>
> > Thinking outsize of the box...<br>
> > 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.<br>
><br>
> All this => what's this?<br>
><br>
> > 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.<br>
> > QStableRef r9 = vector[9];<br>
> > vector.resize()<br>
> > // r9 is updated during resize() and still points to that it was meant to.<br>
> > 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);<br>
><br>
> QList today offers exactly that. In array-of-pointers-mode it also<br>
> offers stability of references.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Side note:<br>
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.<br>
_______________________________________________<br>
Development mailing list<br>
<a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
<a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
</blockquote></div></div>