How to insert the whole array into the end of a QList?

[Chris Kawa]

If you just want to construct a new QList out of an array then

QList<int> values(std::begin(array), std::end(array));

if you want to add values to existing list then

values.reserve(values.size() + std::size(array));
std::copy(std::begin(array), std::end(array), std::back_inserter(values));

[StudyQt1]

@Chris-Kawa Thank you very much for your reply, it seems Qlist is different from std::list

[Cobra91151]

@StudyQt1

It is not recommended to mix standard array - int array[4] with QVector<int>.
Please check out this comment: https://forum.qt.io/topic/107848/how-to-insert-different-arrays-into-a-qvector/8
You can use std::array in the QVector. Please check out the examples below:

Code:

std::array<int, 4> array = { 2, 6, 4, 8 };
QVector<std::array<int, 4>> vector;
vector.push_back(array); // or vector << array;

for (int i = 0; i < static_cast<int>(vector[0].size()); i++) {
     qDebug() << vector[0].at(i);
}

Adding values to QList by using loop:

int arr[4] = { 2, 6, 4, 8 };
int arrSize = sizeof(arr) / sizeof(*arr); // Gets the size of array
QList<int> list;

for (int i = 0; i < arrSize; i++) {
     list.append(arr[i]);
}

qDebug() << list;

[Chris Kawa]

it seems Qlist is different from std::list

Very different. in Qt6 QList and QVector are the same thing: Qt containers compared with std containers

[StudyQt1]

@Cobra91151 Thank you for your codes, let me test its speed with std::copy

[Christian Ehrlicher]

@Chris-Kawa said in How to insert the whole array into the end of a QList?:

If you just want to construct a new QList out of an array then
QList<int> values(std::begin(array), std::end(array));

if you want to add values to existing list then
values.reserve(values.size() + std::size(array));
std::copy(std::begin(array), std::end(array), std::back_inserter(values));

Or use the convenient QList::append(const QList<T> &o) :)

[Chris Kawa]

@Christian-Ehrlicher append is not good here. It takes a list, so you'd first have to construct it from the array and then append it, doing a copy of the values twice.

To be honest there's no good api in Qt to do this. My example does the copy once, but it copies the values one by one, which is wasteful for ints. Ideally you'd want to resize the list once and just memcpy the values. Unfortunately resize will initialize the new values, which is unnecessary, since we'd overwrite them anyway. Also can't do that in Qt5, since list might not be one chunk of memory.

It's a common problem actually, same in std. That's why there are proposals for something like resize_uninitialized(size) or resize(std::uninitialized, size), but nothing yet. Custom allocator can be used to circumvent that, but it's ugly as hell.

[Christian Ehrlicher]

Ok, when you want to avoid this small allocation then your std::copy() is the correct way. But I doubt this is the real usecase here - I'm pretty sure in the real world there is already a second container.

[Chris Kawa]

@Christian-Ehrlicher Sure, it depends a lot on the actual code and it might not be the case here, but I'm just pointing that out because I find this problem a lot in my particular line of work. There's some data in a non-Qt container from another lib and then I want to use it in some Qt api which takes a list. few hundred thousands of ints might not sound like a lot but it becomes a problem if you have a couple of sets like that and you need to update them e.g. 60 times a second while also doing a bunch of other work. Doing one 0.5Mb memcpy vs doing it twice one int at a time (and also updating the size counter by one each time) becomes a huge difference and a potential bottleneck. On some hardware you get a dedicated DMA channels for such cases and not using them would make this extra wasteful.

[Kent-Dorfman]

As you guys are seeing, that's the problem with parallel container framerworks within the same language. I understand and appreciate the philosophy behind Qt containers (copy on write) but really with they would have just stuck with the STL stuff. :^P

[Chris Kawa]

@Kent-Dorfman Qt is older than STL and early STL implementations were shady to say the least. It's just legacy code now and, in this case at least, STL has the same problem.
Other languages often compromise performance for ease of use and don't give you any say in it. The nice thing about C++ is also the ugly thing about it - if defaults don't meet your needs you can roll your own, and so many do. My company for example has its own standard library, which always puts low level performance above everything else, but has some non-trivial gotchas as a result. Qt usually follows the "easy to use and good enough for average case" mantra, but sometimes interacts poorly with non-Qt code.