Массивы против контейнеров

[Igors]

Не дай бог ..
..
Страшный и непредсказуемый desperateContainer,..
..
..и нам пипец.
..
слупый и опасный метод..

Скажите, а почему Вас совершенно не волнуют соображения эффективности? Хотели ли мы освободить память занимаемую указателями? Не всегда, как показывает пример. Зачем тогда столько эмоций? 

В некоторых случаях мне приходится управлять данными "без контейнеров", в стиле С. Да, это требует заметно больше усилий и аккуратности. Зато получается намного чище, код быстрее а иногда.. даже текст короче Удобство контейнеров разлагает, приучает ими бездумно ляпать к месту и не к месту. Чего там мне думать сколько где памяти выделилось почем зря? За меня все сделают, я ж классы вывчыв!! На мой взгляд это скользкая дорожка к "говнокоду"

[Пантер]

Igors, использование контейнеров в с++ и "говнокод" это совершенно разные вещи.
ИМХО!
Нужно пользоваться контейнерами. Вектор занимает столько же памяти, сколько и обычный массив. Вот если производительность критична и доказано, что отказ от контейнера повысит ее, то тогда и только тогда стоит использовать си-подобный код.

[Igors]

Вектор занимает столько же памяти, сколько и обычный массив. Вот если производительность критична и доказано, что отказ от контейнера повысит ее, то тогда и только тогда стоит использовать си-подобный код.

Вектор часто занимает заметно больше памяти т.к. ему нужен пул чтобы эффективно расти. Может не устроить что нельзя использовать указатель на элемент вектора (при добавлении/удалении элементов). Удаление из вектора катастрофично по скорости. Поведение вектора (да и др. контейнера) трудно знать точно. Очищает ли память clear()? Сколько раз вектор перераспределит память если добавить в него напр 100К элементов? На злополучной Вындоуз платформе добавляются еще проблемы. Конечно, для большинства задач все эти мелочи несущественны, но не для всех.

Нужно пользоваться контейнерами.

Раньше это звучало немного иначе

Учение Маркса всесильно потому что оно верно

[Пантер]

> Вектор часто занимает заметно больше памяти т.к. ему нужен пул чтобы эффективно расти
man vector::reserve
> Может не устроить что нельзя использовать указатель на элемент вектора (при добавлении/удалении элементов).
Тут немного не понял
> Удаление из вектора катастрофично по скорости
man vector::pop_back. Из массива ты вообще удалить ничего не можешь.
> Поведение вектора (да и др. контейнера) трудно знать точно
Уверен? Откуда такие данные?
> Очищает ли память clear()?
Вроде, это не оговаривается. Можно вызвать vector::reserve. Есть еще хорошее решение через swap.
> Сколько раз вектор перераспределит память если добавить в него напр 100К элементов
Смотря как добавить.
> На злополучной Вындоуз платформе добавляются еще проблемы
Подробнее, пожалуйста.

На крайний случай можно написать свой Allocator.
Я не навязываю, а высказываю свою точку зрения. Есть предложение перенести спор в другую ветку, где можно продолжить дискуссию.

[SASA]

Удобство контейнеров разлагает, приучает ими бездумно ляпать к месту и не к месту. Чего там мне думать сколько где памяти выделилось почем зря? За меня все сделают, я ж классы вывчыв!! На мой взгляд это скользкая дорожка к "говнокоду"

Очень часто при инспекции кода я прошу переписать сишные массивы на контейнеры. Т.к. там уже есть ошибка, или она с большой вероятностью появится. Я приветствую использование сишных массивов только в одном случае - приложение работает медленно -> мы провели анализ -> выяснили, что узкое место это работа с контейнером -> переписали на сишные массивы -> написали длинный коментарий почему мы так сделали.

P.S. Это только моё мнение, а не первый удар в холеваре 

[Igors]

Я не навязываю, а высказываю свою точку зрения. Есть предложение перенести спор в другую ветку, где можно продолжить дискуссию.

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

[Пантер]

Фух, чуть не запорол тему. Не делал еще такого разделения тем.
Igors, твой ход.

[Igors]

Пантер, спасибо за хлопоты

> Вектор часто занимает заметно больше памяти т.к. ему нужен пул чтобы эффективно расти
man vector::reserve
> Может не устроить что нельзя использовать указатель на элемент вектора (при добавлении/удалении элементов).
Тут немного не понял
> Удаление из вектора катастрофично по скорости
man vector::pop_back. Из массива ты вообще удалить ничего не можешь.
> Поведение вектора (да и др. контейнера) трудно знать точно
Уверен? Откуда такие данные?
> Очищает ли память clear()?
Вроде, это не оговаривается. Можно вызвать vector::reserve. Есть еще хорошее решение через swap.
> Сколько раз вектор перераспределит память если добавить в него напр 100К элементов
Смотря как добавить.
> На злополучной Вындоуз платформе добавляются еще проблемы
Подробнее, пожалуйста.

1) reserve, resize - то да, но когда размер фиксирован и известен - не такая уж большая выгода по сравнению с обычным массивом (ну удобный деструктор, можно выскочить по exception). А вот когда добавляем/удаляем - имеем проблемы с производительностью и перерасходом памяти. erase() вообще ужасен. QList обещает "быстрое" удаление - но то по сравнению с тем ужасом.

Пример: QList имеет 10K элементов. Удаляем элемент из середины. Это значит сдвигаются  5К указателей и перекачивается 20К (40К в 64 бит). Это цена 1 erase. Ну оно конечно "быстро" по сравнению с вектором где конструктор копирования будет вызван 5К раз - но очень "относительно".

2) По поводу хранения указателей на элементы вектора. Это "плохая привычка", храните индексы. Хорошо, вот живой пример.

Код

C++ (Qt)
// треугольник хранит индексы 3 точек
struct Triangle {
 size_t  mIndices[3];
};
 
typedef QVector3D Vertex;
 
// простая 3D модель
struct CModel {
 QVector <Vertex> mVertices;  // вектор 3D точек
 QVector <Triangle> mTriangles;  // вектор треугольников
};
 

Теперь мы каким-то образом обнаружили что некоторые точки и/или треугольники нужно удалить. Просто так нельзя - ведь индексы уплывут. Каким образом мы можем это сделать с нашими прекрасными контейнерами? Или вектор здесь не подходит? Хорошо, возьмите любой другой std или Qt.

3) Я не утверждал что нужно использовать "просто массивы" вместо контейнеров. В большинстве случаев выход - написание своего контейнера.

[BRE]

В большинстве случаев выход - написание своего контейнера.

Я правильно понял, что спор окончен, т.к. все стороны согласны, что нужно использовать контейнеры? 

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

[Пантер]

1. Ты сам привел выгоды:

удобный деструктор, можно выскочить по exception

. Этого уже вполне достаточно.
1.1 Разве в QList удаление приводит к сдвигам?

[BRE]

1.1 Разве в QList удаление приводит к сдвигам?

QList организован как вектор. Если удалять в середине, то будет сдвигать.

[Igors]

1.1 Разве в QList удаление приводит к сдвигам?

Да, просто он сдвигает массив адресов (или POD) что дешевле

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

Разве приведенный мной пример ну такой уж "специальный случай" (аж 2 структуры)? По-моему так он очень заурядный. Вот и покажите мне богатырскую силу контейнеров для такой простенькой задачки - удалить ненужные точки/треугольники 

[BRE]

Разве приведенный мной пример ну такой уж "специальный случай" (аж 2 структуры)? По-моему так он очень заурядный. Вот и покажите мне богатырскую силу контейнеров для такой простенькой задачки - удалить ненужные точки/треугольники 

В некоторых случаях мне приходится управлять данными "без контейнеров", в стиле С. Да, это требует заметно больше усилий и аккуратности. Зато получается намного чище, код быстрее а иногда.. даже текст короче

Если взять этот код (как ты его называешь "в стиле C") и обернуть его в класс, то получиться контейнер. Эффективность этого контейнера (!) сильно пострадает по сравнению с тем кодом "в стиле С"?

[Igors]

Если взять этот код (как ты его называешь "в стиле C") и обернуть его в класс, то получиться контейнер. Эффективность этого контейнера (!) сильно пострадает по сравнению с тем кодом "в стиле С"?

То всего лишь "как назвать", непринципиально. Проблемв пользоваться стандартным или городить свое (жизнь заставляет)

Знатоки STL/Boost/Assistant и др. - ну где де же Вы? Покажите мне "велосипедисту" как грамотно решить задачу в посте #7 (крутые итераторы, лямбда и все такое). А то вот у меня что-то со стандартным вектором выходит сложно и длинно 

[BRE]

То всего лишь "как назвать", непринципиально. Проблемв пользоваться стандартным или городить свое (жизнь заставляет)

Ну так и я про это. 
Частенько стандартных контейнеров бывает достаточно, а когда стандартные чем-то не подходят, то можно "по-велосипедить" и сделать узкоспециализированный контейнер (ничего страшного здесь нет). Но это все равно будет контейнер!
И вовсе не обязательно это делать с использованием "стиля С", так же как ожидать стандартных решений на все случаи жизни.