Внимание! Хвост темы с базаром про ООП\не ООП перенесен в религиозные войны. Ругайтесь там, если охота. А здесь прошу высказываться по теме, если есть что сказать. Все прочее будет удаляться без предупреждения.

Очень интересное мнение участников про malloc.



А что участники думают по поводу этого?
std::vector для классов, которые внутри себя выделяют память не подходит, потому что вектор все время переконструирует и вызывает оператор=(), когда закончилось место в буффере/удаляют элемент из середины массива; это все дико тормозит.

Кстати. Еще в правила: не нужно использовать NULL. Это макрос и он задефайнен где-то там. Лучше 0. Или, с выходом С++0х можно еще nullptr.

Это сообщение отредактировал(а) Randajad - 18.3.2012, 12:33

Код на C++, в котором в первой же строке константа определяется макросом... что тут еще можно думать?   

И что же вы находите такого плохого в дефайнах препроцессора? 

А что тут думать? Вопрос находится в теме "как не надо писать код". Ответ очевиден.   
Самый быстрый доступ к элементам в векторе. Самое быстрое удаление/вставка в середину в списке.
Если тебе не нужен случайный доступ, а достаточно последовательного, то лучше выбрать список.
Если тебе необходим случайный доступ, а размер элементов не больше указателя, то быстрее вектора вряд ли что будет.
Если ты используешь большие массивы больших элементов и случайный доступ необходим, то можно сделать нечто среднее, между списком и вектором. Т.е. в списке у тебя хранятся сами элементы, а в векторе хранятся указатели на них. Таким образом, при добавлении/удалении элементов, вектор будет работать только с простыми указателями (это быстро), а список с элементами. Пример такого контейнера - QList (Qt).

Это все хорошо, но необходим также доступ к элементам в стиле обычного массива. 
Так что увы, ничего подходящего не нашел, кроме как самописный вариант.

Я имел ввиду чтобы:
array<int> arr;
Было равно int arr[];
И все элементы стояли друг за другом в одном куске памяти. 

если у объекта тривиальный конструктор/деструктор накладных немного. если нетривиальный, объект (или объекты с ним связанные) может быть обескуражен неожиданной сменой адреса. так что именно vector подходит "для классов, которые внутри себя выделяют память".
память кстати по-разному выделять можно. скажем, копирование при записи. так что это скорее проблема класса-содержимого, а не контейнера.
желание иметь элементы в памяти "одним куском", причем именно элементы, а не указатели законно, но не понятно. приведите пример, когда это действительно необходимо. мне в голову приходит только работа с низкоуровневыми библиотеками, но они в основном работают с элементарными типами данных, для которых перемещение в vector реализовано как раз через memmove. кстати. никто не мешает вам сделать свою специализацию класса vector.

Объекты внутри себя не хранят ссылок друг на друга, в этом вся фишка.
Выделение через new памяти для каждого объекта не хорошая идея потому, что размер объекта маленький, а их число порядка десятков тысяч. Таким образом из-за выравнивания и данных менеджера памяти получится слишком большое количество памяти "впустую".

10?)) Это еще ничего))) Вот сейчас у меня проект, в котором есть функция принимающая 43 параметра, причем одного типа mxArray... Корень всех бед проекта...
И самое паршивое что я сделать ничего не могу, т.к эта функция дергается из длл-ки написанной в матлабе( А математику делаю не я... Вот и наступает вынос мозга когда человек делающий мат часть начинает требовать передачи параметров номер 3,9,12 как uint8, 14,16 как стринг... но все нуно конвертить в mxArray ))   

А почему так мало? Уж если автор идиот, то должна быть пара тысяч.

Добавлено @ 18:51
Тысяч 30 - это то, что читается в оперативу и анализируется на диване. А жалкие две и хорошим то стилем стоит брать чужие в единственном случае - если писаны наставником/преподавателем/автором книги, которую можно рекомендовать на роль учебника. И только за образец. Потому что их быстрее переписать, не заглядывая, чем пристроить. Этот объём - не тот случай, когда оправдано разделение труда в команде.

Добавлено @ 18:59
Как раз единственно допустимое. Маллок/реаалок - это для скаляров. 


Это сообщение отредактировал(а) ТарасАтавин - 29.8.2013, 19:09

Самое веселое - это писать вообще без отсупов, а на плюсах так ещё и всё в одну строку.

Добавлено через 1 минуту и 11 секунд
Вот ещё пособие, как делать не надо: 

Добавлено через 4 минуты и 1 секунду
И поминавшийся здесь явный вызов конструктора. Конструктор и деструктор придуманы именно для того, чтоб вызываться автоматически, чтоб уж точно не забыть из вызвать и, наоборот, не забыть, что уже вызвал.

Рекурсия бывает оправдана при обработке рекурсивных данных, например, деревьев. Но рекурсия на пустом месте - это именно то, чего делать не надо.