Memory issues

[SABROG]

Тут, как я понял, не правильно сравнивать контейнеры только по скорости добавления элементов. По идее у std::list должны быть быстрее операции удаления и добавления в произвольное место списка.

[BRE]

Тут, как я понял, не правильно сравнивать контейнеры только по скорости добавления элементов. По идее у std::list должны быть быстрее операции удаления и добавления в произвольное место списка.

Согласен, но как я написал выше, QList<T> это std::vector<T*>. А что бы сравнить скорости нужно писать функционал вставки/удаления в произвольном месте для std::vector<T*>, а мне лениво. 

Сейчас еще посмотрю, но по моему для T <= (void*), QList вообще превращается std::vector<T>.

[Igors]

QList не является связанным списком, это массив указателей на T, т.е. его прямой аналог std::vector<T*>.

Да если sizeof(T) > sizeof(void *), иначе это аналог std::vector<T>. (::isLarge в исходниках). Это разумно, незачем тратить указатель например на int  который сам <= указателя

[BRE]

Да если sizeof(T) > sizeof(void *), иначе это аналог std::vector<T>. (::isLarge в исходниках). Это разумно, незачем тратить указатель например на int  который сам <= указателя

Ну я вроде выше и писал.

[Igors]

А stl-ные контейнеры?
Быстрее и эффективней Qt-ишных. Почему не использовать их?

Я не берусь утверждать кто из них быстрее/эффективней. И с удовольствием пользуюсь STL, намного меньше писать. Просто не везде он подходит. Например

struct Point {
  float x, y, z;
};

Для такого элемента неэффективно использовать new и создавать служебные данные (которые превысят начальный размер). Остается std::vector но он страдает теми же недостатками что и QVector. Проще написать свой класс - невеликое дело.

[BRE]

Проще написать свой класс - невеликое дело.

Для таких данных, по мне, проще написать свой аллокатор.
Также для таких классов удобно переопределить оператор new, для более эффективного их хранения.

[Winstrol]

Вот и получается - проще самопальный контейнер писать 

А stl-ные контейнеры?
Быстрее и эффективней Qt-ишных. Почему не использовать их?

+1 Никогда не понимал порнографии вроде Qlist. Причем hardcore.

[Winstrol]

Я не знаю, является ли QList аналогом std::list, но я четко вижу, что QList кушает как и положено не больше 500Мб при попытке поместить в контейнер ~100млн. int'ов, в то время как std::list'у при аналогичном коде не хватает 1,6Гб съеденной оперативы после чего программа падает, даже не ругнувшись в отладчик о нехватке памяти.

Скорее всего, реализация вызывает new/delete на каждый чих.
Для наглядности можно поэкспериментировать с таким фрагментом.

Код

C++ (Qt)
for (j = 0; j < NUM_TEST; ++j)
{
    new int[3];
}
 

В этой ситуации надо
-отказаться от использования std::allocator, заменив на какой-нибудь small object allocator.
-во все том же stlport используется достаточно пристойный node allocator.

[SABROG]

+1 Никогда не понимал порнографии вроде Qlist. Причем hardcore.

А обычный std::list тоже thread safe, implicit shared и reentrant?

вставки/удаления в произвольном месте для std::vector<T*>, а мне лениво. 

В Qt есть не все контейнеры как в stl, но есть еще тот же QLinkedList. Говорить, что контейнеры Qt медленнее, сравнивая лишь по одной операции добавления и по 1-2ум контейнерам не лень, а делать тесты лень.

Если в Qt что-то хуже или работает не так, почему бы не спросить троллей как правильно или чтобы это исправили? Я понимаю, что всем надо в срок уложиться, сдать заказ и времени клепать багрепорты нет, легче выбрать что-то другое. Но ведь проблема никуда не пропадет, если вы о ней не сообщите.

[BRE]

В Qt есть не все контейнеры как в stl, но есть еще тот же QLinkedList. Говорить, что контейнеры Qt медленнее, сравнивая лишь по одной операции добавления и по 1-2ум контейнерам не лень, а делать тесты лень.

Я написал о том, с чем столкнулся в недалеком прошлом сам. Я не занимался специальным тестированием контейнеров.

Если в Qt что-то хуже или работает не так, почему бы не спросить троллей как правильно или чтобы это исправили? Я понимаю, что всем надо в срок уложиться, сдать заказ и времени клепать багрепорты нет, легче выбрать что-то другое. Но ведь проблема никуда не пропадет, если вы о ней не сообщите.

Да я если честно языкам не обучен.

[Winstrol]

А обычный std::list тоже thread safe, implicit shared и reentrant?

И std::list и Qlist не thread-safe.
Что касается implicit shared, особой пользы от этого не вижу.
А если надо, то всегда легко сделать  explicit sharing

Код

C++ (Qt)
boost::shared_ptr<SharedClass> sharedObj = anotherObj;
 

Если собираемся менять sharedObj, то делаем.

Код

C++ (Qt)
template <class T>
void unsharePtr(boost::shared_ptr<T>& ptr)
{
    if (!ptr.unique()) ptr=boost::make_shared<T>(*ptr.get());
}
...
unsharePtr(sharedObj);
sharedObj->не const метод
 

[Igors]

Если в Qt что-то хуже или работает не так, почему бы не спросить троллей как правильно или чтобы это исправили? Я понимаю, что всем надо в срок уложиться, сдать заказ и времени клепать багрепорты нет, легче выбрать что-то другое. Но ведь проблема никуда не пропадет, если вы о ней не сообщите.

Да я если честно языкам не обучен.

Как будто роман собираемся писать:) Взял да написал за 5 минут, а что ошибки в языке будут - стесняться нечего, если что отвечайте: My English is much better than your Russian.
Предлагаю:

--------------------
Hello Qt

We've got a problem. The following fragment runs out of memory under Windows XP and Mac OSX 10.5.2 (Carbon) although memory is released Ok under Linux

Код:

	#define  NUM_TEST		(200LL * 1024 * 1024)

	int i, j;
	QVector<int> theVector[10]; 

	for (i = 0; i < 10; ++i) {
		theVector[i].reserve(NUM_TEST);
		for (j = 0; j < NUM_TEST; ++j)
			theVector[i].append(1);
		theVector[i].resize(2);
		theVector[i].squeeze();
	}

Looking sources files we can guess the problem is related with ::realloc that does not release memory in fact

Thank you
Russian Qt Forum
---------------------

Так пойдет?

[Winstrol]

Looking sources files we can guess the problem is related with ::realloc that does not release memory in fact

Стало быть и отсылать надо команде разработчиков realloc.

[Igors]

Стало быть и отсылать надо команде разработчиков realloc.

А кто их заставлял пользоваться realloc? И realloc ли это вообще? (не 100%). И почему мы имеем разные результаты на разных платформах? У BRE работает у меня нет. Что это за кросс-платформенность такая? Обещали по squeeze память освобождать - вот пусть и освобождают.

[BRE]

Стало быть и отсылать надо команде разработчиков realloc.

+1. 

Я уже писал, но повторюсь. Это не проблема Qt, это проблема (а точнее особенность) стратегии менеджера памяти конкретной OS. Тролли эту проблему/особенность обойти не смогут.
Конечно, можно написать репорт.
Только ответ скорее всего будет один: для конкретной задачи нужно подбирать правильный контейнер, учитывая его особенности.