<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><a href="https://doc.qt.io/qt-5/qlist.html#details">https://doc.qt.io/qt-5/qlist.html#details</a></div><div><br></div><div><ul style="margin: 0.75em 0px 1.5em 20px; padding: 0px; border: 0px; vertical-align: baseline; list-style: none;"><li style="margin: 0.65em 0px 0px 15px; padding: 0px; border: 0px; vertical-align: baseline; line-height: 1em; list-style-image: url(https://doc.qt.io/style/list_arrow.png);"><font color="#000000" size="3"><span style="background-color: rgba(255, 255, 255, 0);"><a href="https://doc.qt.io/qt-5/qvector.html" style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; text-decoration: none; transition-duration: 0.3s;">QVector</a> should be your default first choice. <a href="https://doc.qt.io/qt-5/qvector.html" style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; text-decoration: none; transition-duration: 0.3s;">QVector</a><T> will usually give better performance than <a href="https://doc.qt.io/qt-5/qlist.html" style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; text-decoration: none; transition-duration: 0.3s;">QList</a><T>, because <a href="https://doc.qt.io/qt-5/qvector.html" style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; text-decoration: none; transition-duration: 0.3s;">QVector</a><T> always stores its items sequentially in memory, where <a href="https://doc.qt.io/qt-5/qlist.html" style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; text-decoration: none; transition-duration: 0.3s;">QList</a><T> will allocate its items on the heap unless <code style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline;">sizeof(T) <= sizeof(void*)</code> and T has been declared to be either a <code style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline;">Q_MOVABLE_TYPE</code> or a <code style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline;">Q_PRIMITIVE_TYPE</code> using <a href="https://doc.qt.io/qt-5/qtglobal.html#Q_DECLARE_TYPEINFO" style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; text-decoration: none; transition-duration: 0.3s;">Q_DECLARE_TYPEINFO</a>. See the <a href="http://marcmutz.wordpress.com/effective-qt/containers/#containers-qlist" style="margin: 0px; padding: 0px; border: 0px; vertical-align: baseline; text-decoration: none; transition-duration: 0.3s;">Pros and Cons of Using QList</a> for an explanation.</span></font></li></ul><br><div>Иван Комиссаров</div></div><div><br>20 мая 2019 г., в 13:40, NIkolai Marchenko <<a href="mailto:enmarantispam@gmail.com">enmarantispam@gmail.com</a>> написал(а):<br><br></div><blockquote type="cite"><div><div dir="ltr">And on the matter of "you should have read all the discussions so you had years to port away from QList"<div><br></div><div>I am sorry, what? QList was never indicated as deprecated or somehow undesirable in Qt docs far as I know and not every developer actively reads these topics.</div><div>Moreover with all the discussions that were going on about "somehow saving the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't bother.</div><div><br></div><div>This *really* is not something I expected being thrown around as a serious argument here.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko <<a href="mailto:enmarantispam@gmail.com">enmarantispam@gmail.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"><div dir="ltr">I was speaking strictly of the cases where users already have auto used in their code _expecting it to signify owning container_.<div>Imagine if they expect ownership in these cases. If the actual owning container that exists somewhere else somehow goes out of scope </div><div>when the user expected to own it for a while (but declared it as auto) you are introducing nasty bugs while maintaining SC.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 20, 2019 at 12:35 PM Edward Welbourne <<a href="mailto:edward.welbourne@qt.io" target="_blank">edward.welbourne@qt.io</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">On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov <<a href="mailto:vitaly.fanaskov@qt.io" target="_blank">vitaly.fanaskov@qt.io</a>> wrote:<br>
>>   If a user needs a regular container, range might be simply assigned to it.<br>
<br>
NIkolai Marchenko (16 May 2019 20:38) replied<br>
> It depends on what you expect the average usecase to be.<br>
> If we assume that a regular container is generally more used then you are preventing ppl from "almost always auto"<br>
<br>
First: I don't believe we've committed to "almost always auto" as a Qt<br>
coding style (it leaves the reader to work out what everything is, which<br>
I - as a reviewer - really don't like).  Being explicit about what type<br>
of container you want to use has its virtues (albeit, as Marc points<br>
out, auto's ambiguity is good when the API is in flux).<br>
<br>
Second: if we return a container, the API designer has to decide which<br>
type of container to return, which forces the caller to do a conversion<br>
if that wasn't the type they wanted.  Returning a range lets the caller<br>
chose how to store the values.<br>
<br>
However, that's only a win if the supplier wasn't already holding the<br>
values in a container, which CoW lets us return cheaply.<br>
<br>
The win (assuming C++ ranges work enough like python generators) comes<br>
when you're traversing some population of things and selecting some to<br>
return, while skipping the rest; classically that might be implemented<br>
as a traversal with a call-back object to act on each item; but a range<br>
lets the caller just iterate over the results found, turning the<br>
call-back's code into a loop's body, which is far easier to follow; or<br>
collecting the results into a container of the caller's choosing.<br>
<br>
        Eddy.<br>
</blockquote></div>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Development mailing list</span><br><span><a href="mailto:Development@qt-project.org">Development@qt-project.org</a></span><br><span><a href="https://lists.qt-project.org/listinfo/development">https://lists.qt-project.org/listinfo/development</a></span><br></div></blockquote></body></html>