У тебя же генерируется CMemoryException? Вот его и лови.
Хотя странно, если std::vector, там другой тип исключения; точно не помню, тоже про память. Короче, выясни тип исключения и лови, в чем проблема?
Кстати, имей в виду. Вектор растет не по одному элементу а кусками. Причем, алгоритм определения размера прироста обычно довольно простой - типа удвоения текущего размера. Т.е. если тебе не хватит места всего под один элемент, вектор попытается раздуться вдвое. И может лопнуть.
Далее, перевыделение памяти происходит так: выделяем новый кусок, копируем туда старые значения, освобождаем старый. В результате - память фрагментируется! Т.е. возможен случай, когда память вроде есть, на 1000 мелких кусочков. Но вот на один большой (равный в сумме 1000 мелких) - фиг вам.
Короче, при больших аппетитах полагается сразу определиться с примерно нужным размером и заказать его сразу + небольшой запас, возможно.
Нельзя с большим вектором работать точно также как с маленьким.

если есть vector<vector<point>>
и я точно не знаю размер внутренних векторов и внешнего вектора,
 но например хочу под это дело выделить кусок памяти 2Гб, как это можно сделать?

Никак, разве что свой аллокатор писать.
Либо дизайн пересмотри.
Например, можно сделать так: выделить большой пул для всех точек в виде vector<point>, а отдельную линию хранить как <начало-конец>.
Либо как-то еще упаковать, и прописать извлечение в виде объекта. Это требует довольно много кода, но при работе с большими массивами данных обойтись стандартными контейнерами не получится.
Например, у меня в программе векторные данные хранятся в виртуальной памяти (а не в хипе), в виде упакованных блоков, без всяких указателей. Для каждого слоя есть 2 параллельных пула: массив тэгов фиксированного размера (тэг - это структура, где записан тип объекта, экстент, размер, позиция во втором пуле и некоторые доп. данные). Второй пул содержит блоки разных размеров, где хранятся собственно данные (массив координат и т.д.). На оба пула сверху навернута поддержка списка свободных блоков. Все это закрыто в наборе классов, наружу торчат только ручки типа "Разместить объект", "Удалить", "Изменить". Объект извлекается в виде пары указателей (на тэг и данные), сверху навернуты объектные обертки. Причем их два типа (2 набора): "легкие" обертки, только для чтения, зато быстро создаваемые (например, прорисовка или поиск) и полновесные классы, для редактирования/создания.

Смысл примерно такой: упакованные данные занимают намного меньше места, меньше страдают от фрагментации, легко сериализуются (всем куском); 
для чтения (рисования) достаточно inline-оберток, которые преобразуют указатели к нужному типу и ничего не стоят. А полноценный объектный доступ нужен только при редактировании отдельных объектов. Тогда точки копируются в вектора (для полилиний), модифицируются, а потом снова упаковываются.

у меня проблема несколько в другом

у меня данные хранятся не в готовом для вывода виде,
 а в виде типа
1.есть описание объекта.(какая то фигура, например квадрат)
2.есть действия над объектом(переместить в точку, повернуть и т.д.)
т.е. весь файл например состоит из N таких фигур, но с разными действиями над ними, возможны вложенности одних фигур в другие.

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

вообщем проблема в том, что при каждой отрисовке гуляет размер вектора, который содержит данные для отрисовки,
и его размер может меняться, в теории я на каждой итерации могу оценить его размер, но это скажется по процессору.
скорее всего придется выводить "порциями", 
т.е. дошли до лимита скажем в 10к элементов- вывели, потом опять ищем.
но как этот лимит правильно определить хз, т.е. если вообще по 1 примитиву выводить лишней памяти не надо, но будет медленно.

вот код отрисовки, приходится еще выделять доп. память под временное хранилище.
vec это vector<vector<vector<point>>> , он содержит vector<vector<point>> т.е. список примитивов, которе приходят из разных тредов.




Это сообщение отредактировал(а) mrgloom - 4.10.2011, 14:45