/*
 *
 * Copyright (c) 1994
 * Hewlett-Packard Company
 *
 * Copyright (c) 1997
 * Silicon Graphics Computer Systems, Inc.
*/
template <class _Tp, class _Alloc, size_t __bufsize>
void 
deque<_Tp,_Alloc,__bufsize>::_M_reallocate_map(size_type __nodes_to_add,
                                              bool __add_at_front)
{
  size_type __old_num_nodes = _M_finish._M_node - _M_start._M_node + 1;
  size_type __new_num_nodes = __old_num_nodes + __nodes_to_add;
  _Map_pointer __new_nstart;
  if (_M_map_size > 2 * __new_num_nodes) {
    __new_nstart = _M_map + (_M_map_size - __new_num_nodes) / 2 
                     + (__add_at_front ? __nodes_to_add : 0,0);
    if (__new_nstart < _M_start._M_node)
      copy(_M_start._M_node, _M_finish._M_node + 1, __new_nstart,0);
    else
      copy_backward(_M_start._M_node, _M_finish._M_node + 1, 
                    __new_nstart + __old_num_nodes,0);
  }
  else {
    size_type __new_map_size = 
      _M_map_size + max(_M_map_size, __nodes_to_add) + 2;
    _Map_pointer __new_map = _M_allocate_map(__new_map_size,0);
    __new_nstart = __new_map + (__new_map_size - __new_num_nodes) / 2
                         +
 (__add_at_front ? __nodes_to_add : 0,0);
    copy(_M_start._M_node, _M_finish._M_node + 1, __new_nstart,0);
    _M_deallocate_map(_M_map, _M_map_size,0);
    _M_map = __new_map;
    _M_map_size = __new_map_size;
  }
  _M_start._M_set_node(__new_nstart,0);
  _M_finish._M_set_node(__new_nstart + __old_num_nodes - 1,0);
}

Это из g++ (cygwin). Так что садитесь scorpi_ - два бала (по русской системе). Куда обращаться за помощью Вы сами знаете.

RTFM, решает. В отличии от вектора, на стратегию выделения памяти которого Вы ссылаетесь говоря о проблеме нехватки памяти, двухсторонняя очередь выделяет память фиксированными буферами под очередную порцию элементов, чтo решает в Вашем случае проблему нехватки памяти.

man operator new, man operator delete. operator new и operator delete! A не new и delete!
Вы уп╦ртый человек, который не слышит, что ему говорят. Пожалуй, только то, что здесь в кои веки пообсуждали C++, а не какой-нибудь отстойный хомяк, заставило Ваших собеседников терпеливо объяснять очевидные вещи, вместо того, чтобы сразу сказать то, чем дискуссия заканчивается: RTFM.

_M_reallocate_map
Ещё раз RTFM. Это реаллокация массива содержащего указатели на блоки (подмассивы).

1. Проблемы нехватки памяти нет. Есть проблема фрагментации.
2. Ходить нормальными указателями по этим блокам просто нереально. А для задачи нужно (в ассемблере с использованием SSE).
3. Отправлять эти данные дальше в качестве 3D текстуры для OpenGL нереально.
4. Поэтому я говорил о наращивании одного (еще раз одного) блока памяти и std::deque тут не помощник. (Да, с его блоками я ошибся)
5. В объяснениях я не нуждаюсь - к работе моих модулей претензий нет и помощи в решении проблем я тут никогда не искал. Я лишь описал проблемы того кадра, который упорно применяет свои отменные знания ООП и С++ и совершенно не в состоянии решить саму проблему. Признаюсь, это была глупая затея. Даже если бы я мог выложить в открытый доступ его код, ни к чему бы другому это не привело.

1. Проблемы нехватки памяти нет. Есть проблема фрагментации.
-----
Хммм... Как бы это помягче сказать... Наверное так - выполнение calloc/malloc/realloc, в принципе, не гарантирует выделение не фрагментированного участка памяти. Что гарантируется - что выделенная область будет выглядеть непрерывной. Какими средствами достигается эмуляция выделения непрерывной области и каковы при этом издержки на управление - вопрос отдельный.
Вообщем, остается повторится, - читайте доки - от модели процессора, через операционку, до стандарта языка.
Ах, да... совсем забыл... Одно из лучших решений по управлению фрагметированными данными разработано IBM, где-то году в 72-м. Можете ознакомится на досуге.
2. Ходить нормальными указателями по этим блокам просто нереально. А для задачи нужно (в ассемблере с использованием SSE).
-----
Угу... "Самый лучший язык программирования - ассемблер!" Ни один другой язык не дает эффективных решений...
4. Поэтому я говорил о наращивании одного (еще раз одного) блока памяти
-----
Эээ... У меня есть большое желание дать какому-нибудь студенту-первокурснику задачку отсортировать методом линейной сортировки массив из одного (еще раз - одного) элемента.

Плюс тот факт, что в приведенном примере realloc сможет выделить новую память, а new нет. realloc конечно же не панацея и в общем случае от проблемы фрагментации адресного пространства не избавит, но в этом конкретном - сработает. Просто когда-то были выкинуты из проекта все вызовы calloc/malloc/realloc и все было переведено на new/delete (за исключением моих модулей). Мотивировалось все это тем, что это С, а мы используем С++ и т.д., и т.п. Вобщем та часть проекта в конце-концов стала соответствовать всем критериям качественного объектно-ориентированного кода (пропускали даже через PClint с проверкой на соответствие рекомендациям из "Effective C++"). Но при использовании программы быстро обнаружились проблемы с памятью. Из работающей программы была сделана правильная объектно-ориентированная.
То, что с доками по процессору можно решить эту проблему, я знаю. А переход на 64-битную архитектуру вообще ее снимет и объектно-ориентированный код станет опять рабочим. Только когда это будет...

Это Ваши слова Просто на тот момент не было другой возможности использовать SSE. Сейчас заменяем ассемблер на Intel'овские классы.

Спровоцировали. Было ведь видно, что веду речь об одном непрерывном блоке, а перевели разговор на std::deque и поймали...

А переход на 64-битную архитектуру вообще ее снимет
-----
Ничего он не снимет. Абсолютно ничего. ВаааПще ничего. Ну что у тебя поменяется с того, что вместо адресации 2^32, ты сможешь адресовать 2^64? Ответ - ничего. Те же самые проблемы с той же самой фрагментацией, в том же самом количестве. Тем более, что физической памяти тебе это не добавит, а вот лишних циклов узкой шины - вполне...
Еще раз - послушай не глупых людей - учи матчасть.

1. Проблемы нехватки памяти нет. Есть проблема фрагментации.
Без комментариев, так как ясно, что нужды иметь 1,5 GB continuous memory нет.
2. Ходить нормальными указателями по этим блокам просто нереально. А для задачи нужно (в ассемблере с использованием SSE).
С итераторами Вы тоже не знакомы?
3. Отправлять эти данные дальше в качестве 3D текстуры для OpenGL нереально.
То есть glTexImage3D Вы выучили, а glTexSubImage3D нет?
4. Поэтому я говорил о наращивании одного (еще раз одного) блока памяти и std::deque тут не помощник. (Да, с его блоками я ошибся)
И из-за незнания API ошиблись ещё раз.
Я лишь описал проблемы того кадра, который упорно применяет свои отменные знания ООП и С++ и совершенно не в состоянии решить саму проблему
Почему меня не оставляет ощушение, что Вам просто не хватает образования, чтобы разобраться в его коде?

Apropos Лиса, нашёл сейчас в её исходниках ещё одного сишного "гения" запутавшегося в С++

// C++ sucks! There's no way to do this with a macro, at least not
// that I know, if you know how to do this with a macro then please do
// so...
static const PRUnichar sHTMLTagUnicodeName_a[] =
  {'a', '\0'};
static const PRUnichar sHTMLTagUnicodeName_abbr[] =
  {'a', 'b', 'b', 'r', '\0'};

...at least not that I know...
-----
That is a keyword.

// C++ sucks! There's no way to do this with a macro, at least not
Это одна строка. Этот ####### форум вставляет в преформатированный текст лишние переносы строки. Я год добивался чтобы этот баг исправили, весной они наконец-то это сделали. А недавно видимо скопи-пейстили этот баг обратно. Бардак-с.

Ага, надействуешься тут сам, когда на цены курсов посмотришь.

Ба! Встретил наконец-то знакомое слово - эмуляция Мы, все ближе приближаемся к определению (формальному) программирования как отображения (можно и гомоморфного) объекта в среду отображения (компи). Кто добавит уточнение(я) в мое определение в столь свободной форме? Если, конечно же, оно имеет хоть какой-то смысл. А вообще, хорошая программа - это работающая программа.

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

Спасибо и за это. Так и хочется задать СЕБЕ (себе, ...) вопрос - Чем это я занимаюсь всю свою жизнь? Возможно, пора бросать? Некоторые прочтут и ответят, что ТЫ мол и не начинал. Таковы жестокие правила и ... этого ФОРУМА, а может быть и самой ЖИЗНИ?

Это воспитание последних 15-ти лет... И с вами Я весйма видержанно-мягок...

А у Вас были возражния по ключевым моментам спора с человеком?

Глушков, Цейтлин, Ющенко. "Алгебра. Языки. Программирование". Есть и другие источники, но этого достаточно. Это по поводу формализаций. Если мой склероз, отдыхает.

Как -то, спасая проект, успешно заваливаемый одним "продвинутым" программистом, пришлось написать эмулятор мультиплексного канала ЕС... (IBM 360). Алгоритм работы этого ящика (стойки) идеально подходил под алгоритм работы сетевого коммутатора. Делайте скидку на 80 годы. Конечно же, я не отрицаю диалектику в том числе и в терминологии. Пока коментов нет. А ту книжечку почитайте, если найдете.

IRULAN, как мы видим, НАРОД слинял на другие темы. Не смотря на то, что обещали оставаться до победного конца - ответа на Вашу мольбу. Я не могу ответить на прямой вопрос, но, если есть желание, попытаюсь спасти тему следующим вопросом-просьбой. Этот вопрос имеет прямое отношение к тестированию "будущих" (действительно) программистов - пришлите любой рисунок, который можно сделать путем срисовывания с реального объекта. К примеру - вид из окна. Желательно прорисовать контуры увиденного. Увиденное может быть и воображаемым.